Loss of SoC while parked in OFF?

have not monitored this but did you try noting the SoC, power cycling (maybe off for about a minute) and then booting again and checking the SoC? i think that while the car is in READY the SoC is only an estimate. it could be that the SoC is lower than you think when you are powering the car off.

 

It might be temperature or surface charge effects.

 

Remember the old days what you could do to "borrow" a little gas with a hose and a little suction??? Was there a Leaf parked next to you.....Maybe they figured out a way to charge their batteries from yours....(^.^)

 

It could be that. I wish I had some EE knowledge or someone who's an EE w/battery experience can chime in.

When I attended a SF Bay Area Leaf meeting where the Leaf's Chief Vehicle Engineer + a whole bunch of Nissan folks were there, Kadota-san (the CVE) gave some explanation about the Leaf's GOM (guess-o-meter aka DTE aka "Distance" to Empty) and had a slide up about "mysterious moves" of either the 12 segment SoC graph or the GOM. Unfortunately, I was in the back and he stepped away from the mic for some important parts, so I couldn't hear all of it. Also, the slide said "Nissan Strictly Confidential" and since we weren't supposed to be using any recording devices, I wasn't about to take pics of it.

One thing that he conveyed was essentially, you really only know the SoC when there's no load on the battery (when the car isn't on). Everything after that is a guess. My Nissan Leaf Forum • View topic - Nissan Engineering Team Visit Dec. 3rd: Recap posted sort of a summary. I think there were other useful interpretations in that thread.

I ran this by a friend of mine (has some EE knowledge, has a Chevy Volt and also flies RC airplanes) and he essentially said yes.

 

phil would know for sure, but the open-circuit SoC thing is what i was trying to get at in my above post. that seems to be the most likely reason why the SoC would differ and why i suggested he repeat the test with no (significant) delay between power-down and power-up to see if the SoC delta remains.

 

i did this experiment myself. first i took a 3 mile trip which i'd characterize as mildly uphill. started out with the SOC at about 84.5% as read by the scangauge. i arrived at my destination showing 67.5% SOC. i powered the car down until the scangauge shut off and then powered it back up into ready. the SOC showed 65%.

coming back, i took a slightly longer route (3.8 miles) that ends in a long downhill stretch. at the end the SOC read 48.8%. after powercycling, to my surprise it read 50.5%.

so it looks like the car is undercounting coulombs. perhaps this is all just within the tolerance of the counting hardware, N=1 is not really a good experiment.

 

I was going to try this today but left my tablet at home. I'll try it tonight, or tomorrow morning at the latest.

On the Scanguage, is there another xgauge you can use for SoC? The way (I think) it was explained by Vincent is that there could be many PIDs/xgauges that report total battery pack SoC. He said the difference is that one computer may be reporting it to another, and so on, since other ECUs may need the SoC value for their own functions. I haven't tried any other (been using the one that works the whole time I've been using Torque), but recently Vincent helped me identify 2 SoC PIDs. He told me to continue to use the one I've been using since the SOC data was shorter and may be more accurate (3 bytes versus 24 bytes). I guess I can test both too, when I get the chance.

 

i think i am using the 1st SoC xgauge that was suggested to me in the scangauge thread in this forum. i actually tried all of them when my SG was at firmware 3.x but the first one i tried in 4.x worked, so i didn't try any others.

 

I looked at all 3 SoC PIDs in Torque. There's "SOC", "SOC Ign-On", and "SOC All Batt". The SOC and All Batt ones displayed the same value. The Ign-On displayed a higher value. At the time of my test, my SoC was 33.3% as displayed by the SOC and All Batt. The Ign-On one displayed 33.5%.

With regard to the changing SoC values, I had parked the car for about 10 minutes. I turned it on, then I checked the SoC and then shut off the car. I waited about a minute and then turned the car back on. The values were the same, no change.

While I was looking through the available list of PIDs, I saw another one called "SOC Delta". At the time, this value showed 0.1%. Not sure what that is or what that means, but thought I would point that out.

FWIW, I think the fluctuating SoC in the Scangauge may be due to it using some other SoC PID, maybe one that is calculated or something. Just a guess, maybe Vincent will know .

 

is there a list of these torque PIDs somewhere? or are they on the spreadsheet that's in google docs?

i think that's expected behavior. both power-on events measure the open-circuit voltage of the battery (and by extension the SoC). the amount of current drawn from the battery is pretty small during the time the car was on, so the SoC probably would not budge.

the OP had driven for a while, noted the SoC and then turned the car off, coming back later to find the SoC had changed.

well, all i know is that the leaf and the pip use the same type of battery technology, and the leaf lead engineer said that the true SoC of at least a LiOn battery could not be known until the open-circuit voltage was measured. so it seems reasonable that the SoC can fluctuate like this.

 

Here's the post that has the spreadsheet.. but yes, its a link to the spreadsheet in Google Docs. The last one is dated 3/20/12.

http://priuschat.com/forums/obdii-a...om-pids-torque-android-app-5.html#post1500513

 

Adrian Black's spreadsheet only use 015B, the same one you 're using.

It is true for some other PIDs but not applicable for SoC in the Gen3. In Gen1 & Gen2, there is a separate Battery ECU to keep track of SoC and this info is copied to the HV ECU. You can get the SoC from either ECU.

On the Gen3, the Battery Smart Unit keep track of SoC but it is not accessible on the CAN Bus. It is serially connected to the HV CPU and you can only get the SoC from the HV CPU.

I don't recall saying more accurate, there should be the same, just quicker response for the shorter msg. It makes no difference if you're monitoring or logging a few PIDs at a time. Howerver, if your no. of PIDs are a lot, you can notice the lagging especially if yours is using BT connection or your Android device is slow or there are many background programs running.

The SG don't have these problems because it is using direct connection, it can only display 4 PIDs at a time and it has a dedicated CPU.

Vincent

 

I think the Ign-On one is the estimated value at the end of the previous use before you power down. This value is stored in non-volatile memory and retrieve upon your next power on.

Every battery blocks have slightly different voltage levels so their SOC are also different. Delta SOC is the difference between the highest and lowest battery block.

I don't think it is the SG, I bet you could observe the same if you were to monitor it for a longer time.

There is a patent#6285163 which describes the SoC correction for every power up. Perhaps this is what the OP is seeing?

Vincent

 

Thanks, Vincent. You are a wealth of knowledge.

 

I have not configure the torque PIDs to read information yet.
If you can tell me, what's the Hybrid total battery voltage at rest and at full charge?
Thanks

 

In my last logging session, when I left work with a full charge, sitting in the parking lot with the car Ready, it was showing 221V.

The max during my logging session was 222V and the minimum was 188V. When I parked the car in my drive way (after depleting my EV range), it was 198V.

Is that what you were looking for?

 

Perfect, thank you tracksyde.
Your numbers are giving me the values I was looking for.

 

A case could be made for either charge stored or charge discharged from these capacitors and maybe some others effecting SOC power on/off readings.
The inverter/charger had some really big capacitors as seen in this image


Not sure what gen this is. Maybe II

Was just reading a App note on dealing with charge stored in decoupling caps when power off/on resetting an I2C bus temp sensor array. (Analog Devices) . The time delay for devices to actually power down after you turn the power off.
Anyway just another idea.

 

don't get me started about power rails and i2c buses