LEAF CANbus decoding. (Open discussion)

Until we know more, we do not even know what this
data is, much less what to call it.

"Guess-o-Cap" (Capacity)?
"Tick Byte"?

Perhaps try to relate it to data that we know better:
What are %GIDs saying after a "full" charge?

Turbo3 said:

Now the hard part. What do we call it? If we make this health what do I call the old one? Do you think we need both?

Click to expand...

By the old one, are you referring to hlth(LeafSpy)/H(leafDD)/Xfactor(CANary)? I personally think that until we know what it represents, the old value should be called something ambiguous (like Xfactor ) and 5B32 should be given the SOH moniker. I think it is still useful to continue to watch the other value since it does seem to be tracking degradation of something and one day it may be interesting but right now it is telling me my leaf is at <50% and I cannot find anything that has degraded that much - even my series resistance is still reading in the 90-100mOhm range.

garygid said:

What are %GIDs saying after a "full" charge?

Click to expand...

I does roughly track gids/281 - about as closely as Ah. It is *really* (within 1%) close to Ah/65.6.

Assuming this CA:5B3 D2>>1 "Tick-Byte" has significance,
any idea what values would be significant?

Assuming that this is capacity or "health" related,
then higher would be better and lower would be worse.

But, would 62% (if it is a percent at all) be reasonably
good for a 30 month old car, or bad?

Assuming your car has lost significant battery capacity,
but your car still shows 12 bars, it seems that the
Capacity Bars are lagging, lying, or both, right?

If the battery internal resistances is N initially, then
M later on (larger), a way of expressing the degradation
would be N/M as a percentage, where 50% would mean
that the resistance has doubled (M = 2*N).

TickTock said:

Turbo3 said:

Now the hard part. What do we call it? If we make this health what do I call the old one? Do you think we need both?

Click to expand...

By the old one, are you referring to hlth(LeafSpy)/H(leafDD)/Xfactor(CANary)?

Click to expand...

How about just Hx..

Probably the main value that has significance is 70% since this is the threshold for battery replacement. Hopefully noone will be looking at numbers much below that for long. My memory may be playing tricks on me but I am pretty sure this value was labeled "SOH" (i.e State of Health) on the test instrument. It represents the % remaining of the spec capacity.

garygid said:

Assuming this CA:5B3 D2>>1[ snip-I don't think we need a new name] has significance,
any idea what values would be significant?

Assuming that this is capacity or "health" related,
then higher would be better and lower would be worse.

But, would 62% (if it is a percent at all) be reasonably
good for a 30 month old car, or bad?

Assuming your car has lost significant battery capacity,
but your car still shows 12 bars, it seems that the
Capacity Bars are lagging, lying, or both, right?

Click to expand...

Bars definitely lag - I am right on the edge of losing my 4th bar based on my capacity (200 gids after 100% charge, 70% SOH, 47Ah) but I am still showing 11 bars. I was showing 12 bars for two months after the reset. The bars did the same thing the last time they reset me in 2012 (took 3 months to get back down to the 10 bars I went in with).

GregH said:

TickTock said:

Turbo3 said:

Now the hard part. What do we call it? If we make this health what do I call the old one? Do you think we need both?

Click to expand...

By the old one, are you referring to hlth(LeafSpy)/H(leafDD)/Xfactor(CANary)?

Click to expand...

How about just Hx..

Click to expand...

Works for me.

If it is really the Capacity, it should be CAP, rather than "health", right?

The BAD news:
One must lose 4 bars to be eligible for the new capacity warranty, right?

Lose 1st at 85% (approximate values) 11 showing
lose 2nd at 77.5% 10 bars showing
lose 3rd at 70% 9 bars showing
lose 4th at 62.5% 8 (less than 9) bars showing.

So, the warranty kicks in when you lose the 9th bar, at
8 bars showing, or about 2 months after 62%, not 70%, right?

On a different topic, I started looking for an embedded timestamp on the canbus this morning. Although SOCmeter, CAnary, etc do add timestamps based on the uC RTC clock, I wanted to read the time as viewed by the car. Particularly because I have a few log files with bogus uC timestamps due to the coin battery getting removed, etc and it would be nice to figure out exactly when I took the log. Also, Gary is reporting significant slowness on the RTC and needs to set the clock frequently so we could use this to auto-sync the uC clock. I am pretty sure canbus messages 5fa, 5fb, and 5fc are some sort of timebase. 5FA is constant for most logs but changes day to day so potentially a date. The upper 5 bits of the third byte seem to return the day of the month. 5fc seems to include a seconds*4 counter in the second byte and minutes in the 3rd. 5fb is also sent along with 5fa and 5fc twice a second but haven't figured out anything useful there. I'll keep puzzling this out, but thought I'd ask if anyone else has already looked at these and decoded them.

Making progress:

5fa3>>3 = day
5fa6>>4 = month
5fb2,D3>>2 = year

5fc2[7:2] = seconds
5fc2[1:0],D3[7:4] = minutes

TT, you do really good work!
Sincerely, Gary

Thanks Gary.

5fc2[7:2] = seconds
5fc2[1:0],D3[7:4] = minutes
5fc1[7:3] = hour
5fa3[7:3] = day
5fa6[7:4] = month


[edit: year failed further tests - still looking..]

garygid said:

If it is really the Capacity, it should be CAP, rather than "health", right?

The BAD news:
One must lose 4 bars to be eligible for the new capacity warranty, right?

Lose 1st at 85% (approximate values) 11 showing
lose 2nd at 77.5% 10 bars showing
lose 3rd at 70% 9 bars showing
lose 4th at 62.5% 8 (less than 9) bars showing.

So, the warranty kicks in when you lose the 9th bar, at
8 bars showing, or about 2 months after 62%, not 70%, right?

Click to expand...

The dash display of Battery Capacities per the first Nissan LEAF service manual are as follows:

53.75% - 59.99% - 7 segments of 12 illuminated
60.00% - 66.24% - 8 segments of 12 illuminated
66.25% - 72.49% - 9 segments of 12 illuminated
72.50% - 78.74% - 10 segments of 12 illuminated
78.75% - 84.99% - 11 segments of 12 illuminated
85.00% - 100.0% - 12 segments of 12 illuminated

My year shows 0x1FE3>>2 = 2040

TickTock said:

5fc2[7:2] = seconds
5fc2[1:0],D3[7:4] = minutes
5fc1[7:3] = hour
5fa3[7:3] = day
5fa6[7:4] = month

Click to expand...

:| Nothing is ever easy. I cannot find anything that gives the year and furthermore, these messages are not present in 2013 Leaf logs.

TickTock, would be interesting to see if that timestamp changes if you change the eyebrow or nav clock.

Turbo3 said:

My year shows 0x1FE3>>2 = 2040

Click to expand...

Yeah - I get the same. I get the same on 2012 logs and it returns 1fe2 on my 2011 log. Doesn't make sense. Problem is I only have one 2011 carcan log (at that time I was only able to log one can bus at a time and usually chose to log the evcan).

Good idea Jeremy, I did start to test this. I wanted to change the year to see if it would help me find the year. However, it only seems to let you change the time - not the date so I aborted the experiment. I will go back and see if the hour changes the value - would be interesting to know if they are related.

No luck finding a date on the 2013 logs. Looks like they changed quite a bit of the traffic. I was able to find the time in the 2013, though:

• 509:d3[7:2] = seconds
  5f9:d5 = minutes
  5f9:d6[7:3] = hour

However, this only works on the 2013's (at least it works for the two I have log files from and doesn't work on my 2011).

My technique to find the date on the 2011 came up empty on the 2013 - I queried for all message bytes that never changed in a log and then looked for which of those changed from logs on different days. Essentially all the bytes that never changed within a log on the 2013 also never changed from day to day. So if there is a date embedded in the 2013 data, it is overloaded onto a message that also outputs different information on the same byte. Makes it a lot harder to find...

JeremyW said:

TickTock, would be interesting to see if that timestamp changes if you change the eyebrow or nav clock.

Click to expand...

Just tried it. Changing the time on the eyebrow has no effect on the time reported on the canbus but off-setting the navigation clock does.

I have added a option to auto-sync the CANary with the car time but need to add code to support the different 2013 messages before I publish. Anyone know of a message that conclusively identifies the model year? I could add it as a config option or even deduce it based on the missing 59a/59b/a9c messages but this may change with a sw update so it would be nice if there was a more direct indicator.