NiallDarwin commented 3 years ago

Title explains this issue. I'm just putting notes here as I research.

Message 5BC apparently contains GIDS. 'EV Can' sheet of this Googledoc here:

https://docs.google.com/spreadsheets/d/1EHa4R85BttuY4JZ-EnssH4YZddpsDVu6rUFm0P7ouwg/edit#gid=0

& in DBC format here: https://github.com/dalathegreat/leaf_can_bus_messages/blob/master/EV-can_AZE0.dbc

samsta commented 3 years ago

Great news!

Sent from my iPhone

On 20/01/2021, at 7:22 PM, Niall Darwin notifications@github.com wrote:

Title explains this issue. I'm just putting notes here as I research.

Message 5BC apparently contains GIDS. 'EV Can' sheet of this Googledoc here:

https://docs.google.com/spreadsheets/d/1EHa4R85BttuY4JZ-EnssH4YZddpsDVu6rUFm0P7ouwg/edit#gid=0

& in DBC format here: https://github.com/dalathegreat/leaf_can_bus_messages/blob/master/EV-can_AZE0.dbc

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

samsta commented 3 years ago

Are you able to establish a relationship between SOC, SOH, and GID (I assume we’re going to derive the former from the latter 2?) using LeafSpy, or is that already in one of the docs you linked to (haven’t read them yet)?

Sent from my iPhone

On 20/01/2021, at 7:28 PM, Samuel Nobs samsta@me.com wrote:

Great news!

Sent from my iPhone

On 20/01/2021, at 7:22 PM, Niall Darwin notifications@github.com wrote:

Title explains this issue. I'm just putting notes here as I research.

Message 5BC apparently contains GIDS. 'EV Can' sheet of this Googledoc here:

https://docs.google.com/spreadsheets/d/1EHa4R85BttuY4JZ-EnssH4YZddpsDVu6rUFm0P7ouwg/edit#gid=0

& in DBC format here: https://github.com/dalathegreat/leaf_can_bus_messages/blob/master/EV-can_AZE0.dbc

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

NiallDarwin commented 3 years ago

1DB & 1DC which are always present look bloody useful. They shows: 1DB Usable SOC Total voltage *Relay cut request - basically help, shut me down! 1DC

Charge & Discharge power limits and a couple of other interesting things.

NiallDarwin commented 3 years ago

Are you able to establish a relationship between SOC, SOH, and GID (I assume we’re going to derive the former from the latter 2?) using LeafSpy, or is that already in one of the docs you linked to (haven’t read them yet)?

Still researching. Seems sensible. As per usual things aren't simple. Switching the power on to the leaf battery and just listening resulted in only 1DB & 1DC messages. Running your battery controller program provoked all the usual messages. However after stopping your program then power cycling the leaf battery it was still giving many messages. Turning the Leaf battery off for 4-5 minutes and then back on and its still giving many messages. Both traces are saved. Working on it now.

NiallDarwin commented 3 years ago

55B contains SOC but in the comments on the DBC there is this: "State of charge. LB_SOC is a 0.1% resolution SOC that is used on startup by Leaf Spy Pro and then ignored in favor of 0x7BB groups, and seemingly used nowhere in the car"

NiallDarwin commented 3 years ago

From Dala's EV-can_AEZ0.dbc:

Q 0x50C ALU Question for LBC CM SG 1292 ALU_QUESTION_FOR_LBC "B2h = first question 5Dh = second question"

Answer 0x55B CM SG 1371 LB_ALU_ANSWER "Question:B2h Answer(LBC):AAh Question:5Dh Answer(LBC):55h

What is ALU? I think it's some type of handshake. From my own CAN captures on G1 car I think Q & A are reversed. 55B changes first then 50C changes in response.I think LBC asks the Q on 55B and receives the answer from VCM on 50C. On the G1 car these change every 5 messages. On the G2 battery the 55B remains the same. Is it worth us putting in a 0x50C response into the battery controller?

@samsta can we get a trace of your car to see if G2 is the same?

*Ref: G1 Batt in car power on AC on drive up to 40kW primary CAN0 EV CAN1.csv G2 Battery ex-car no current.csv

samsta commented 3 years ago

I don't know if it's worth doing it as I don't understand what it's doing and why it's needed.

If we don't see the battery being questioned I don't quite see the point in responding. Do we see either 0x50C or 0x55B on the altar?

On January 26, 2021 at 11:17 AM, Niall Darwin notifications@github.com wrote:

From Dala's EV-can_AEZ0.dbc:

Q 0x50C ALU Question for LBC CM SG 1292 ALU_QUESTION_FOR_LBC "B2h = first question 5Dh = second question"

Answer 0x55B CM SG 1371 LB_ALU_ANSWER "Question:B2h Answer(LBC):AAh Question:5Dh Answer(LBC):55h

What is ALU? I think it's some type of handshake. From my own CAN captures on G1 car I think Q & A are reversed. 55B changes first then 50C changes in response.I think LBC asks the Q on 55B and receives the answer from VCM on 50C. On the G1 car these change every 5 messages. On the G2 battery the 55B remains the same. Is it worth us putting in a 0x50C response into the battery controller?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

NiallDarwin commented 3 years ago

Do we see either 0x50C or 0x55B on the altar?

As I stated above:

On the G2 battery* the 55B remains the same.

Maybe I should have clarified that's on the G2 battery connected to the Altar. No we do not see 0x50C, that's why I asked

Is it worth us putting in a 0x50C response into the battery controller?

samsta commented 3 years ago

I still don't know if it is worth it. Perhaps you could try sending the response from SavvyCAN to see if the 55B changes? If that's the case and it improves the situation in any way then yes, it's worth it.

On January 26, 2021 at 2:35 PM, Niall Darwin notifications@github.com wrote:

Do we see either 0x50C or 0x55B on the altar?

As I stated above:

On the G2 battery* the 55B remains the same.

Maybe I should have clarified that's on the G2 battery connected to the Altar. No we do not see 0x50C, that's why I asked

Is it worth us putting in a 0x50C response into the battery controller?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

NiallDarwin commented 3 years ago

It's a 2 minute job to plug into a car and check for the presence of this message and I think it's absolutely worth it. You don't have to do anything, I just need to get my hands on a g2 Leaf at a charger.

On Tue, Jan 26, 2021 at 3:38 PM sam nobs notifications@github.com wrote:

I still don't know if it is worth it. Perhaps you could try sending the response from SavvyCAN to see if the 55B changes? If that's the case and it improves the situation in any way then yes, it's worth it.

On January 26, 2021 at 2:35 PM, Niall Darwin notifications@github.com wrote:

Do we see either 0x50C or 0x55B on the altar?

As I stated above:

On the G2 battery* the 55B remains the same.

Maybe I should have clarified that's on the G2 battery connected to the Altar. No we do not see 0x50C, that's why I asked

Is it worth us putting in a 0x50C response into the battery controller?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/samsta/BatteryController/issues/10#issuecomment-767249117, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMIBEIYNY3HVO2RTPCNNUJ3S3YTMDANCNFSM4WKFL4UA .

samsta commented 3 years ago

That will confirm the presence or absence of this message, yes. But what I'm really interested in is if these handshakes cause the SOC to be updated without powering down or if it just makes the battery controller busier sending stuff that makes no functional difference.

Hence my suggestion to use SavvyCAN. In particular the custom sender window 1 is one that we should use more often to experiment and test hypotheses. It should be perfectly capable of sending these responses while the battery controller is doing everything else.

If the responses cause the SOC to be updated, we're onto something.

On January 27, 2021 at 8:15 AM, Niall Darwin notifications@github.com wrote:

It's a 2 minute job to plug into a car and check for the presence of this message and I think it's absolutely worth it. You don't have to do anything, I just need to get my hands on a g2 Leaf at a charger.

On Tue, Jan 26, 2021 at 3:38 PM sam nobs notifications@github.com wrote:

I still don't know if it is worth it. Perhaps you could try sending the response from SavvyCAN to see if the 55B changes? If that's the case and it improves the situation in any way then yes, it's worth it.

On January 26, 2021 at 2:35 PM, Niall Darwin notifications@github.com wrote:

Do we see either 0x50C or 0x55B on the altar?

As I stated above:

On the G2 battery* the 55B remains the same.

Maybe I should have clarified that's on the G2 battery connected to the Altar. No we do not see 0x50C, that's why I asked

Is it worth us putting in a 0x50C response into the battery controller?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/samsta/BatteryController/issues/10#issuecomment-767249117, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMIBEIYNY3HVO2RTPCNNUJ3S3YTMDANCNFSM4WKFL4UA .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

NiallDarwin commented 3 years ago

G2 car does the same as G1 car.

55B changes first then 50C changes in response. I think LBC asks the Q on 55B and receives the answer from VCM on 50C.

If 55B byte 2 = 55 Then 50C byte 6 =B2 If 55B byte 2 = AA Then 50C byte 6 =5D

55B byte 2 remains the same for 5 messages then changes. 50C byte 5 increments 00 to 03 then returns to 00 =>There are 8 possible responses, two pairs of 4 First 4: If 55B byte 2 = 55 Then 50C byte 6 =B2 0x50C 0x00 0x00 0x00 0x00 0xB2 0xA6 0x50C 0x00 0x00 0x00 0x01 0xB2 0x31 0x50C 0x00 0x00 0x00 0x02 0xB2 0x0D 0x50C 0x00 0x00 0x00 0x03 0xB2 0x9A Second 4: If 55B byte 2 = AA Then 50C byte 6 =5D 0x50C 0x00 0x00 0x00 0x00 0x5D 0xC8 0x50C 0x00 0x00 0x00 0x01 0x5D 0x5F 0x50C 0x00 0x00 0x00 0x02 0x5D 0x63 0x50C 0x00 0x00 0x00 0x03 0x5D 0xF4

Next, how to get this onto the CAN network? I'm going to have a go with savvy CAN as you suggested

NiallDarwin commented 3 years ago

Note from Dala's DTC file: CM SG 1292 HCM_CLOCK_50C "PRUN Detection of frozen data. Message-PRUN-Diag. The transmitting node adds a message counter of 2bits or more to the end of the last data area (or just before the checksum). The value of the counter, which is initially 0, increments by one everytime new data is transmitted, and returned to zero when reaching the max value. The receiving node lets the first message pass without check, but for second next message and following, it check whether the counter number is different from the previous message."; Note 1292 is the decimal of hex 50C

NiallDarwin commented 3 years ago

I wrote my first ever 'working' Python CAN code to try out the 55B/50C messages. It responded to 55B with the appropriate 50C message. I ran this on a second pi connected to the LBC-BatteryController Pi CAN network. The LBC seemed to accept the messages and update its 55B messages accordingly. Unfortunately it didn't seem to affect the SOC numbers given out by the LBC.

So another route is needed. Paths forwards as I see them are:

See if LeafSpy gets updated SOC with changed test rig & controller program: (a) Modify batterycontroller program to not transmit to Leaf Battery (b) Connect OBD2 device to rig, connect to battery with LeafSpy (c) Responses from Leafspy should satisfy battery controller and allow it to happily turn on contactors. If not, further modify it to make an unsafe, supervised only test program which will switch the battery on regardless of LBC data (d) See if reported SOC changes with this setup
Continue with 55B/50C message investigation to see if we’ve missed anything.
id where SOC is in other messages (1DB & 5BC) and see if that’s changing.

This almost feels like it can be a whole plethora of git issues rather than just the one. @samsta do you think I should split this into several or just keep it here in one unruly lump? @JimsterCoder any of this interest you?

samsta commented 3 years ago

No, these aren't separate issues. They are just prototyping approaches to try and understand and hopefully solve the issue at hand: Obtain SOC/battery charge level without powering down

So keep them in here in one unruly lump

samsta commented 3 years ago

Also, I think number 3 should be prioritised

JimsterCoder commented 3 years ago

This is of interest to me. I agree that #3 should be top dog.

On Mon, Feb 22, 2021 at 5:02 PM sam nobs notifications@github.com wrote:

Also, I think number 3 should be prioritised

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/samsta/BatteryController/issues/10#issuecomment-783060095, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMF4FDHQSVB5VFBTMFPAURLTAHJOZANCNFSM4WKFL4UA .

NiallDarwin commented 3 years ago

Yesterday James & I spent some time looking into #3. We found SOC in a few places and it wasn't changing in any of them. I suspect that the messages carrying SOC all get their data from the same source. I also feel as though we are gumming it up some how. @samsta how hard is it to change the rate at which you're asking for info from the LBC? If we play with that maybe we might unblock it.

samsta commented 3 years ago

Lines 419 and 420 of testcan.cpp is where the timer for the group poller is configured to poll a new group every second. That's where you'd need to make a change if you wanted to change the interval between the groups

NiallDarwin commented 3 years ago

I've played with that all the way up to 300000 and it seems not to affect the rate of message sending. Did I get the wrong one? https://youtu.be/ORC7y4x4T8A

samsta commented 3 years ago

The line numbers above referred to the unmodified code on GitHub as I can't possibly know what local changes you have. It appears as though the right line numbers on your local, modified version would be 423 and 424

The interval is set to 1 sec and 0 nanosecond at the moment.

NiallDarwin commented 3 years ago

Yes, I had the wrong one. Thank you.

NiallDarwin commented 3 years ago

Something else I'd like to try is for us to simply listen and see if our sending messages is upsetting it. We still need TAOS happy so that it can charge/discharge. This could either be done by lying to TAOS (and creating a potentially dangerous situation if we don't do our manual monitoring properly) or by getting the data we need from 1DB & 1DC messages. 1DB Contains: Current Relay Cut Request: Emergency Stop type thing Total Voltage Relay Permission Discharge Power Status (emergency/flat battery type)

1DC has: Discharge power limit (divide by volts to get max amps) This I think we can use instead of our calculations-the LBC has done it for us Charge power limit (ditto) Charge Power status (Emergency/full battery)

55B has: SOC (Actual ) ground fault detection (possibly a good safety measure)

5BC has: Temperature segment for dash (as a % of whatever Nissan's limits are) Output power limit reason

5C0 cycles through three iterations showing min, avg, max of: temp

NiallDarwin commented 2 years ago

@JimsterCoder has done a lot on this but it seems maybe we still don't have it long-term. If the code can control powering up and down the LBC we can do two things:

1 Carefully control what startup messages go to the LBC relative to when it's powered on.

2 If #1 fails (after a minute or a year) brute force getting accurate SOC by automatically power-cycling the lbc.

@JimsterCoder, keen to press on with this?

JimsterCoder commented 2 years ago

@JimsterCoder, keen to press on with this?

Yes, of course.

NiallDarwin commented 2 years ago

Cool, thanks

NiallDarwin commented 2 years ago

After some significant uptime the code seems to be achieving this goal. It seems either to start happy and remain that way or to very quickly fail. Issue 13 may help us with proving this out.

NiallDarwin commented 2 years ago

Revisiting this after a few months I'm frustrated that I haven't explained what we did to make it work*. I recall using information from this website about controlling a Leaf Inverter: http://productions.8dromeda.net/c55-leaf-inverter-protocol.html

From it I definitely added a dumb 50B message at 100ms as per his findings I did not add 1D4 as it is related to torque I might have added 11A at 10ms

So we need again to test which of these affect battery behaviour.

*Also known as celeron55 on mynissanleaf.com https://mynissanleaf.com/viewtopic.php?t=25027&start=10 **Note to self & James: Better documentation!

NiallDarwin commented 2 years ago

Figure out what the minimal is that we need to send the battery to keep it happy.

1 Display fault code on console (1DB LB_Failsafe_Status: Caution Lamp Request ). Test.

2 Try to cause fault; Stop transmitting anything.

3 Try to remove fault; Add messages back, starting with 50B then 11A. If these don't fix it choose at random

JimsterCoder commented 2 years ago

1 complete. BC running and showing 0 for Failsafe status

2 progrees:

1 Set rates within happypoller.cpp of 1d4, 1f2, 11a to 100ms. Battery happy for at least 10 mins. 2Removed 50b & 50c. Changed happypoller to 1000000ms (1000s James). Seemed happy for over 10 minutes. Idea: If the LBC gets the messages it wants when first powered up does it then not care that it stops receiving them? We haven't powered off the LBC for at least 24 hours. 3 As 2 but power cycle lbc. Power on process: 1/ start battery controller. 2/ connect lbc to power Yes, battery upset now. 4 Add in 50b & 50c, leave happypoller at huge time. use power on process as above. Battery Happy 5 Remove 50c, only 50b being sent. battery happy. 6 only send 50c. Battery unhappy Conclusion seems to be only 50b required 7 removed 1d4, 1f2, 11a & 50c. Only 50b being sent. Powered up and will leave running for extended period to test theory.

JimsterCoder commented 2 years ago

7 followup. Niall says battery is still happy several days later.

8 to reduce bandwidth further I propose only sending a 50b reply to every 10x 55b received (if this keeps the battery happy, put the filter in the Teensy code), this would drop the reply rate from 100ms to 1000ms.

JimsterCoder commented 1 year ago

FOR THE RECORD. After battery has gone to 'unhappy' mode (Failsafe is 4=Caution Lamp Request), it will not go to Failsafe=0 without being rebooted (according to the Chief Chimp). To wit, the BC was not running for several days, after starting it, Failsafe was stuck at 4. After rebooting LBC, Failsafe is 0 and has stayed there.

JimsterCoder commented 10 months ago

This issue has been solved by adding back in some messages which had been removed as they were thought unnecessary. See Sept 1, 2023 "WIP add back messages to battery" This fixed the SOC problem, it now updates as it should.

NiallDarwin commented 10 months ago

Well done :)

Sept 1, 2023 "WIP add back messages to battery"

Is this the name and date of a commit?

JimsterCoder commented 10 months ago

Yes.

On Tue, Nov 14, 2023 at 9:05 AM Niall Darwin @.***> wrote:

Well done :)

Sept 1, 2023 "WIP add back messages to battery" Is this the name and date of a commit?

— Reply to this email directly, view it on GitHub https://github.com/samsta/BatteryController/issues/10#issuecomment-1808963687, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMF4FDA6R5BYPBNKM5JWPMLYEJ4O5AVCNFSM4WKFL4UKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBQHA4TMMZWHA3Q . You are receiving this because you modified the open/close state.Message ID: @.***>

samsta / BatteryController

Obtain SOC/battery charge level without (Manually) powering down #10

1 Carefully control what startup messages go to the LBC relative to when it's powered on.

2 If #1 fails (after a minute or a year) brute force getting accurate SOC by automatically power-cycling the lbc.

1 Display fault code on console (1DB LB_Failsafe_Status: Caution Lamp Request ). Test.

2 Try to cause fault; Stop transmitting anything.

3 Try to remove fault; Add messages back, starting with 50B then 11A. If these don't fix it choose at random

1 complete. BC running and showing 0 for Failsafe status

2 progrees: