Possible to add stop charging on Nissan Leaf?

[dalathegreat]

0x1BD contains a section to stop charging, by modifying this bit you can stop it.
frame.data[1] = (frame.data[1] & 0xE0) | 2; //request charging stop

I am using muxsan CAN bridges, so I'm unsure if this is possible to transfer over to OVMS. But just as an FYI to you guys more knowledgeable of the OVMS system :)

[markfinn]

I couldn't get that (the failsafe request from the HVBAT) to work from OVMS.

But,

can can1 tx standard 1f2 30 71 60 b0 00 3c 03 88 did work. It's a Charge_StatusTransitionReqest with a value of 3 -- "stop".
I'm a little hazy on what device is supposed to be sending this normally. The reaction of the car was to turn off the EVSE. I was too far away to hear if any relays in the car flipped. The charge lights kept showing that a charge was in progress. I didn't try to re-start the charge from software yet, but pressing and releasing the EVSE disconnect (not actually unplugging it) did NOT restart the charge, even though the charging status lights went out while the button was pressed.

I generated my message by msg[2] := msg[2] & 0xcf | 0x60, then updating the checksum.

The last byte seems to be a crappy checksum. for the messages I've seen it's ((sum(all the nibbles in the first 7 bytes) + 0xa) & 0xf) | 0x80

I actually don't think this is the right way to do it, I think maybe faking the HVBAT "charge complete" signal or the (EVC?) Keep_SOC would be better. I will try out a few more things in a few days

@dalathegreat your leaf messages repo has been very helpful.

[grnbrg]

I was able to get charging stopped with:

  `can can1 tx standard 1db 00 1a 00 00 00 00 e3`

On the down side, I've collected a P31E1 DTC -- "EV/HEV HV System Interlock Error", but I also set a couple of flags that seemed interesting. :)

The last byte (For 0x1DB, anyway) appears to be a CRC-8, with a polynomial of 0x85, and an initial value and final XOR of 0x0. See http://www.sunshine2k.de/coding/javascript/crc/crc_js.html for a CRC tool.

The good news is that we seem to have proved that turn off an ongoing charge is at least possible!!

BTW: The initial issue post by @dalathegreat appears to have a typo -- based on his CAN bus files, the message to stop charging should be 0x1DB, not 0x1BD.

[dalathegreat]

Amazing progress 👍 Yeah sorry about the typo, 0x1DB is the place to be.

By setting frame 3, bit 4 high, you indicate a full charge has been completed. Maybe this is more gentle? 'LB_Full_CHARGE_flag'

frame.data[3] = (frame.data[3] & 0xEF) | 0x10; //full charge completed

This paired with the
frame.data[1] = (frame.data[1] & 0xE0) | 2; //request charging stop

And finally recalculating the CRC, results in a clean termination of the charge, with the charge lights shutting off.

Good that the DBC files were helpful :)

[glynhudson]

The good news is that we seem to have proved that turn off an ongoing charge is at least possible!!

Nice work, this is really cool! Would be a super useful feature 👍

[dalathegreat]

Anyone have the possibility to try this one? Should be gentle since it's just a request to stop and also flag that battery is full.

can can1 tx standard 1db 00 02 00 10 00 00 e3 df

02 signals the request charging stop
10 signals that full charge is completed
e3 signals the PRUN counter (not really needed since it accepts one error message, read more on the github CAN page for more info)
df is the CRC

With the OVMS, is it possible to read the previous 0x1DB message and use it as template before applying these requests? The proper way to send this message would be
1db prev 02 prev 10 prev prev prev+1 CRC
The +1 should be on the low nibble.

[markfinn]

The command as is didn't do anything for me. I tried it several times to make sure the clock byte wasn't the problem.

I'll look into it more a little later

[markfinn]

Hmm, I wired it in to send on an event using the latest 1db value as a base, and it didn't work:

I (63894) webcommand: HttpCommandStream[0x3fa34284]: 2001444 bytes free, executing: event raise mark.battkill
I (63894) v-nissanleaf: mark bat kill1 0x00 0xE0 0xC5 0x6A 0x62 0x00 0x02 0x16 <- this is the last 1db recieved
I (63894) v-nissanleaf: mark bat kill2 0x00 0xE2 0xC5 0x10 0x62 0x00 0x03 0x47 <- I sent these
I (63904) v-nissanleaf: mark bat kill3 0x00 0xE2 0xC5 0x10 0x62 0x00 0x00 0x4D <-this too

[dalathegreat]

On frame[3] by sending 0x10 instead of 0x6A, you disable a lot of things that you shouldn't. You disable mainrelay permission, set interlock to 0, discharge power status to undefined state, and flip the voltage latch flag.

Sending 0x7A is way better than that. But I still don't get why it doesn't cancel the charge.

So my last suggestion for you markfinn is to try just spamming this while charging
0x00 0xE2 0xC5 0x7A 0x62 0x00 0x03 0x0A

[markfinn]

I'm fully charged now, so I can't try anything more at the moment.

I did try or'ing 0x10 on to frame[3] also but that didn't have a different effect. Coming to think of it nothing happened. no errors, no relay clicking. I think my packets were completely ignored.

[dalathegreat]

If we go back to trying 1F2, you did a mistake in the original attempt

I generated my message by msg[2] := msg[2] & 0xcf | 0x60

It should be msg[2] := msg[2] & 0x9F | 0x60

So we still have things to try! :)

[markfinn]

You're right that I used the wrong mask there, but my result still would have been that same packet.

[markfinn]

I'm going to try man-in-the-middling the 0x1db packet since that seems to work for you. I'll use the clock byte to force my packets to be read by the VCM while the real ones look out of sync. I'm not happy about that as a real solution, but I'd at least like to see why it works for you on MUXSAN but not here.

I'll report back after I write the code and drive some charge off the battery.

[markfinn]

Sending full charge completed and failsafe stop charging request stop DID work.

It was especially responsive when emulating the MITM with the clock byte. It was less responsive when just sending one packet, sometimes not working, and sometimes I think clicking a relay in the car but NOT deactivating the EVSE followed by the relay clicking back and charge continuing.

I am a concerned about using the failsafe to stop charging. I'm pretty sure I read something (probably in the service manual?) that the car counts how many times one of the relays is forced open under power id marks the relay as bad after some number of uses. I would not be surprised if that was the failsafe relay. The manual is laid out in a way that I find very hard to search, so I don't know when I'll find that section again.

brief code chunk:

    case 0x1db:
    {
      if (MITM) {
        unsigned char new1db[8];
        memcpy(new1db, d, 8);
        new1db[1] = (new1db[1] & 0xe0) | 2;
        new1db[3] |= 0x10;
        new1db[6] = (new1db[6] + 1) % 4;
        new1db[7] = leafcrc(7, new1db);
        m_can1->WriteStandard(0x1db, 8, new1db);
      }
//normal 0x1db processing continues here

[markfinn]

As a separate comment... if using failsafe turns out to be bad, I think there are still other options:

0x1f2 Charge_StatusTransitionReqest might still warrant consideration

MITMing the signal from the PDM that says the AC voltage is applied (0x390?). Basically try to look like a power outage.

Another option would be the TargetChargeSoc bit in 0x1f2. we couldn't stop charging with that last one, but we might be able to bring back the 80% mode.