BMW i3 CCS/charge port controller

[mikeselectricstuff]

Uh guys? So ehhh...found out why I only got 8 amps from the Tritium....... My silly prepaid access app thingy needs at least a 20 Euro balance! So as they say in America : I was outta quarters:)

..and the machine with its big fancy touchscreen didn't even tell you this..?
It's a sad reflection on the state of charging that I don't find this at all surprising - many chargers have a terrible user interface.

[P.S.Mangelsdorf]

Uh guys? So ehhh...found out why I only got 8 amps from the Tritium....... My silly prepaid access app thingy needs at least a 20 Euro balance! So as they say in America : I was outta quarters:)

..and the machine with its big fancy touchscreen didn't even tell you this..?
It's a sad reflection on the state of charging that I don't find this at all surprising - many chargers have a terrible user interface.

I truly don't understand the insistence on apps. Swiping a credit/debit card works perfectly fine for gas pumps and seems like far less hassle.

[davefiddes]

@davefiddles can you have a look at efcaec25? Seems very small.

Yeah. That should be more than 4 TX and 1 RX packets. I'm having a look. Looks like it ought to be a good one to decode as it looks like it covers the whole start up.

Apologies for the encryption confusion. Forcing a decode to TLS in Wireshark causes everything in the TCP stream to be classed as "TLS Continuation Data" which isn't right. I forgot it did that.

[CCSknowitall]

And to verify that you are sending what you intended (and to prove I’m not bsing):
Efacec23.pcap- you’re requesting 51 A, voltage limit 400v target 400v, EV maximum current limit 125A, remaining time to bulk soc 1800s, remaining time to full soc 3000s. You’re also in EV ready, no error, soc is 24%, bulk charging complete is “no”. Total capture time is 1.455 seconds. I lose the station packets 141 ms in, for the rest I just see your requests.

Efacec24.pcap- 20A request. Everything else is the same. Total capture is 1.459 seconds.

Efacec25.pcap- only 5 frames of homeplug. Appears to capture slac parameters at the very start of charge. (CM_SLAC_PRAM.CNF and CM_START_ATTEN_CHAR.IND)

Efacec_startup2.pcap- identical to ‘23pcap. You’re in the current loop requesting 51A. Capture lasts 1.38 seconds. I lose the station packets 141 ms in, for the rest I just see your requests.

Ionity2.pcap- almost identical to efacec25, 5 frames of homeplug.

Looking at the time stamps, I think we are off by an order of magnitude, so 15 seconds instead of 1.5, add a 0 to all the times I mention above.

Not sure why I’m losing the station to EV packets. Will need to look into further.

[davefiddes]

This is a bit embarrassing. I found a really stupid bug in my conversion script that caused it to barf on odd length packets and ignore anything that came afterwards on that channel. Most packets are even lengths hence the vaguely sane packet captures. With this fixed the captures make a *LOT* more sense and have no obvious decode errors in Wireshark. I've updated my repo with freshly converted captures: https://github.com/davefiddes/BMW-i3-CCS

The efcaec25.pcap is the most interesting. It shows the full setup of the HomePlug network, IPv6 neighbour discovery and then CCS comms. The CCS comms looks a lot better and shows packets from both sides for the duration of the capture.

The ionity2.pcap is also much improved but it only shows HomePlug connection packets. I've not compared with efcaec25.pcap to see why it didn't get any further.

A final discovery: It seems that the latest Saleae Logic 2 software is much improved over the earlier 1.x and allows indefinitely long captures. I installed 2.3.29 alongside my existing 1.2.18 install and ran a 90+ second 16MS/sec capture on my ebay knock off Saleae Logic 8 probe. Perhaps this will be easier than wrestling with Sigrok.

[Jack Bauer]

Excellent work Dave. Just merged your pull request. New pcaps here :
https://github.com/damienmaguire/BMW-i3 ... Caps/Part2

I'll do another round tomorrow.

[davefiddes]

Looking at the time stamps, I think we are off by an order of magnitude, so 15 seconds instead of 1.5, add a 0 to all the times I mention above.

Sorry. I should have said but my script doesn't do anything sensible with packet timestamps. I'll look into that tomorrow. I think that scapy is just timestamping them with the time it takes the script to run on my PC so a bit random. They are obviously all in order and TX/RX interleaved correctly.

[Jack Bauer]

Could you give a link to the knock off Saleae please?

[davefiddes]

This is where I got mine: https://www.ebay.co.uk/itm/111674825674

[Jack Bauer]

When the new Logic 2 was released from Saleae it wouldn't work with my original Logic 8 so I never bothered trying again. Just downloaded the latest version and of course it works just fine! Longer captures on the way

[Jack Bauer]

@mikeselectricstuff the big fancy touchscreen was too busy showing me pictures of perfect people with glowing smiles plugging in their sexy new cars to bother with anything like perhaps why it wasn't pumping out power....

[davefiddes]

When I tried Logic 2 at the beginning of the year I could have sworn it didn't work. Tried it again today and it did. I think Saleae probably realise the knock offs are a good gateway drug for their newer more capable analysers.

[CCSknowitall]

Fantastic! I can see now.

You’re setting a voltage limit of 386V during charger parameter discovery, but then requesting 386V during precharge. Unfortunately efacec25 cuts off before the current loop, so I can’t see if this switches during your power delivery request and current loop. I think it does because startup2 showed max voltage limit of 400v.

You should set a maximum a few volts above your target voltage (target being your desired pack voltage during voltage mode if you use that). I think on the can side the lim is reusing inputs during various states, and during charger parameter discovery the EV target voltage input is used as the EV maximum voltage value sent over plc .

On the PLC side, the car should not change its maximum voltage limit between discovery and current demand, and some stations may store and use the limit sent during the discovery phase. Sending EV maximum voltage is required during discovery, but not in current demand. Some stations may ignore the limit sent in current demand. So an inconsistent behavior between different stations could be caused by this.

You may have other issues too, I will check some more in a few hours.

[CCSknowitall]

Oh, you also have EV Cabin Conditioning set as true, so that appears to be a flag somewhere on the can side. This is an optional display value, but probably best to set to false because why not?

I don’t see anything else in charge parameter discovery that you are doing wrong. 24% soc, 125A max current, fullSOC 100, BulkSOC 80. Just that 386V as your EV max voltage limit here, then using 386V as your target voltage. Precharge request and power delivery (sent after contactor close) do not contain a EV max voltage, so some chargers are going to complain if you close in and are at or slightly above the EV max voltage.

The efacec being sloppy here was to your benefit!

[Jack Bauer]

Ok I think I see a potential screwup. In the one actual log I have from a CCS session the voltage limit transmitted in 0x2f1 sits just over 400v most of the time but drops to 360v (probably batt V) during the precharge phase. Changed the vcu code to do exactly this now. I had been leaving it at battery voltage EXCEPT when in energy transfer which is obviously wrong. I was also messing about with the CV target in 0x2fa. Now set to a fixed value regardless of state.

[Jack Bauer]

New batch of captures with software mods as above :
https://github.com/damienmaguire/BMW-i3 ... Caps/Part3
This time using the new V2 Saleae software. Its not perfect as during the Efacaec charge it droped out and needed to be restarted several times but sure looks cool watching the data flying across the screen.
Efacaecst=startup
Eafacaecen=Charge end
Numbers are in the middle during energy transfer.

Mr.Ionity still doens't like me and complains about power availability even with plenty of money on my account. I did a capture and let it fully time out and got the attached on the screen before unplugging.

Now I caught something interesting. After pulling the plug I caught a burst of spi data. In afterplug.sal

Gassing up the car now and fortifing myself for a trip to the worst located charge point in the entire country to get a Circontrol capture.

[SciroccoEV]

Just turned up in the post...

[CCSknowitall]

When I try to convert these new capture files using spi2pcap, I get this error:

Code: Select all

me@me-VirtualBox:~/BMW-i3-CCS/SPI_Caps/Part3$ python3 spi2pcap.py -i "afterplug.sal" -o "afterplug.pcap"
Traceback (most recent call last):
  File "spi2pcap.py", line 197, in <module>
    reader.__next__()
  File "/usr/lib/python3.8/codecs.py", line 322, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xd9 in position 12: invalid continuation byte

Fortunately I should have some time to really go through all of these captures this weekend, once I can get the pcaps.

[davefiddes]

My script doesn't read the Saleae Logic captures directly as they use a proprietary file format and it requires further processing. In their software you have to set up an SPI Analyzer with the details of Damien's set up (SPI - Enable: Channel 0, SPI - Clock: Channel 1, SPI - MISO: Channel 2, SPI - MOSI: Channel 3, MSB first, 16-bits per transfer, CPOL = 1, CPHA = 1) then click on "Export Table" to export as a CSV text file.

Unfortunately the CSV file format that Logic 2 produces is quite different from the Logic 1 version we've used on the earlier captures. I'm working on an update to my script that handles both formats. I have already fixed the way the script processes packet timestamps so that they are correct. I hope to have an update later this afternoon.

[CCSknowitall]

Ah ok, that makes sense. I got the Saleae Logic program installed so I can do that once the script is fixed. Tremendous thanks for doing the heavy lifting!

It'll be around 12 hours before I have time again to work on this. The Ionity file is the most important for me right now for decoding.

[Jack Bauer]

I second that. Mega thanks Dave:)

Sooo....I guess they don't call you the CCSknowitall for no reason:) First successful charge on a Circontrol Rapition 50 today with the modified Vlimit behaviour.

Captures on the repo :
https://github.com/damienmaguire/BMW-i3 ... Caps/Part3

cirstart3 is probably the best. All the way from plug in to ramping to 100amps.
the others have various fails. Seem ol mr.cir don't really like you asking for 125Amps.

charged in bulk phase for about fifteen minutes before it tripped out with charge error on screen. Sorry I didn't catch that. Guessing its not liking all the timers ans soc staying static.

[davefiddes]

Seems to have been a successful day!

My latest https://github.com/davefiddes/BMW-i3-CCS has all of today's captures including the ionity failure, circontrol success and efacaec. The new captures have a lot more packets so there should be more fun stuff to dig through!

The ionity failure and afterplug captures are interesting. They are full of homeplug communications status notifications that I (and Wireshark) don't understand. Perhaps there's a signal integrity thing going on? Quite how the EVSE was able to talk after it was unplugged is unclear to me...

I also made another discovery. Someone has been working on ISO 15118 dissectors for Wireshark: https://github.com/geynis/v2g-ws-dissectors. I wouldn't describe it as being able to "see" but it does lift the veil a little on what's going on. No dissection of the EXI packets which is obviously where the fun stuff happens. Just need to write a schema-less EXI decoder in lua. What do you expect for €5999 less than the competition.

[Jack Bauer]

The ionity thing has me driven a little mad. I even called their support line. Rebooted the charger etc. No joy. Support can't see any feedback info from the charger either.

Edit: huh. We never even see the SLAC commands in the ionity file ...

[CCSknowitall]

A bit longer than I expected to get to this, but I did go through all of them. Here’s my analysis.
Cirrun2.pcap - All valid. Current: 50 - 100A, Remaining Time To Bulk SoC: 17870 seconds, Remaining Time To Full SoC 69360 seconds
Cirstart.pcap: Has a startup (duh).
Charge Parameter Discovery
EV Cabin Conditioning: True
EV Error Code: NO_ERROR
SOC: 24%
EV Max Current Limit: 125A
Max Voltage Limit: 402V
Full SOC 100%
Bulk SOC 80%
*ALL GOOD!*
Cable Check Request - all good on your side. Note you are setting EV Cabin Conditioning and battery conditioning as true.
Current Loop - did you open your contactors in the loop? Station goes from 377 to 402V. No appreciable current flow. Not a great practice to open your contactors in the loop unless an emergency, and do send a power delivery request to shutdown. The station did not like this and went into emergency shutdown.

Cirstart2.pcap - another startup, looks like cirstart.pcap as far as messaging. Except you closed in at 193V when your pack is at 377V. Ouch! Don't do that! Your ramp to 50A looks fine otherwise. In the current loop you have maximum and target voltage set to 402V, ideally you should make your maximum higher than target.

Cirstart3.pcap - again closing in at way low voltage, 197V. Are you controlling this? Or does the LIM do it automatically? You'll get a pretty big current spike out of your batteries doing this. Ramp to 100A looks good. In the current loop you have maximum and target voltage set to 402V, ideally you should make your maximum higher than target.

Efacec1 - Efacec5 - current loop only, I see no issues other than max/target voltage.
Nice 126A in Efacec4! Shouldn't try to ask for more current than your maximum current limit though. A good station will fault you.

Efacecen.pcap - station went into fault, EVSE_Malfuction. Looks like you opened your contactors in the current loop without shutting down the station first (send power delivery request, then open contactors). Because of this, the station went to 420V even though you requested 0A, and shutdown. Some converters cannot operate without a load, and/or some output current. Be a good EV citizen and shut down properly, ok? You could potentially damage a station this way.

Efacaecst.pcap - Efacec startup capture. You closed in at around pack voltage this time, which is good. I see no issues here that aren't already covered above.

Ionity_fail1.pcap - No idea what's going on here. There's no high level packets in the pcap. And the MAC Ids here are not yours. I wonder if you (er, the chip) is picking up another station's PLC. Since you aren't going into SLAC, I wonder if you are not getting a good connection to the cable. Try holding up/supporting the cable until the lock engages. This is an issue in CCS1 markets with liquid cooled cables. You have a different port and a different cable than what normally causes this, but it's worth a shot. I would put a cheap scope on the pilot wire and make sure you have a solid connection. You should see the low level 1kHz square wave easily.

Other notes:
EVCCID is 0000[MAC in HEX]
Some stations take a while in charge parameter discovery, make sure you are using a state or flag to hold your Max voltage limit, not some sort of timer or anything.

[Jack Bauer]

Ok I need to find where the battery and cabin conditioning is set over can and shut them off.

So regards contactor control. That is handled by the LIM. I can request a contactor close but if I do something silly like ask it to close during cable test for example it will ignore me and shutdown. All of those captures were run on the same day with the EXACT same firmware in the vcu. Efacec closes at the correct voltage yet Circontrol closes wayyyy too soon. Hmmmm.

Can the software folks take a look here and tell me if I'm being stupid....again...

Code: Select all

            case 4:
        {
    Chg_Phase=ChargePhase::Subpoena;//precharge phase in this state
    CONT_Ctrl=0x0; //dc contactor mode control required in DC
    FC_Cur=0;//ccs current request from web ui for now.
  EOC_Time=0x1E;//end of charge timer
  CHG_Status=ChargeStatus::Init;
  CHG_Req=ChargeRequest::Charge;
  CHG_Ready=ChargeReady::Rdy;
  CHG_Pwr=44000/25;//49kw approx power
    CCSI_Spnt=0;//No current

        if((Param::GetInt(Param::udc)-Cont_Volts)<20)
        {
           lim_stateCnt++; //we wait for the contactor voltage to be 20v or less diff to main batt v

        }

        if(lim_stateCnt>10)//need to close con at pch stage
        {
           lim_state++; //next state after 4 secs
           lim_stateCnt=0;
           CONT_Ctrl=0x2; //dc contactor to close mode
        }

    }

The idea is we wait for the voltage measured by the LIM at the EVSE side of the contactors to get less than 20 volts under the actual measured battery voltage and start counting cycles through the state machine. Each cycle takes 200ms so 10 cycles , 2 seconds the voltages must match before we request a close. I wonder is this delay too long for the Circontrol and its actually ramping DOWN when we close but just right for Efacaec....

I think you are dead right about the ionity plug issue. I actually called their support line and the agent was adament about having the plug inserted fully and asked me to hold it in place at one point. That and my crappy cheap Aliexpress ccs socket.... Yeah. Need to do some investigations.

Edit : I am sending a CV target of 398V and a Max of 402V over can to the lim. I suspect the 2014 LIM doesnt use the seperate target value.

Edit 2 : From what I can tell on the CAN side (0x03c) I am not asking for air con or battery conditioning. Searching for any more...