BMW i3 CCS/charge port controller

[alexbeatle]

I got my Type1 LIM. Right away it started behaving and responding much more predictable. P/N: 61359380352

Question: For the Type 1 socket does the plug latch need to be commanded to lock, i.e. message sent?

My LIM doesn't activate the latch nor when plug is inserted nor when charge completed.
After cracking open and fixing the latch cam mechanism, the latch feedbacks 1kOhm when unlocked, 11kOhm when locked.
(Fun fact, on Type1 BWM latch, if the latch is engaged without the plug inserted, there's a small edge on the cam that presses the button and makes the FB read 1kOhm just like when unlatched - someone posted good pictures)

I also tried sending the OBD reset as somebody suggested, but without a luck.

Meh, my LIM stopped locking the charging port when I plug in I measured the lock, it’s 1 kΩ unlocked, 11 kΩ locked as it should be.
Problem solved by sending a OBD reset:
https://github.com/cschleifenbaum/Stm32 ... 901d1e09e6

The lock status always remains in error state according to LIM.

image.png (11.36 KiB) Viewed 11774 times

LIM however reads the wall charger info, pilot, gives a-ok to charge, which I use it to kick BMS to wake AC charger via CAN and the charger wakes up. Though I don't have HV connected to the charger yet, but the charger starts sending back healthy status messages and detects AC on input. Wall charger says the car is charging.
Charge port LED is white when nothing plugged in; slowly pulsing blue during charge and green when finished.

Logs..
Plugged in..

Pressed stop charging button..

Unplugged..

Edit: I also put a scope on the latch motor outputs of the LIM. Doesn't look like LIM is even trying to kick the motor.

[alexbeatle]

So I tried both wiring versions per wiki without luck. - Lock pin#3 to ground or lock pin#3 connected to lock pin#4.
I plugged in my Type2 LIM and it immediately detected the inlet lock correctly! Measuring voltages on the feedback leg 1B-16 I'm getting same voltage values but opposite polarities on Type2 vs. Type1 LIMs. Connection error? How can it be inverted?
Type 2 LIM:
1. Leave inlet lock pin #3 floating - 1B-16 reads -4.26VDC
2. Connect lock pin #3 to ground - 1B-16 reads -0.76VDC in unlocked, and -2.94VDC in locked state
Type 1 LIM:
1. Leave inlet lock pin #3 floating - 1B-16 reads +4.26VDC
2. Connect lock pin #3 to ground - 1B-16 reads +0.76VDC in unlocked, and +2.94VDC in locked state
If I connect the lock pin #3 to #4 as per one of the diagrams, the feedback 1B-16 reads constant +4.3VDC no matter the lock position.

[alexbeatle]

To close the loop.
Speaking with @Shockazulu1 who used ZombieVCU + Type 1 LIM + Type 1 i3 charge port combo to successfully charge in the US. LIM does not lock the inlet on his vehicle during the AC charging either, but it does during the DC charging. Yet another difference for the Type 1 vehicles!?
Guess I'll see how it goes at the public AC and DC chargers.
He uses this diagram:

Big thanks to @Shockazulu1!

[asavage]

That's my diagram
Ricky is successfully charging his RAV4 EV, using the LIM and i3 Charge Inlet that I sold him a while back.

Could you edit the Wiki to add that information (Type 1 LIM does not lock Charge Inlet when AC Charging; Type 2 LIM does)?

[tom91]

Type 1 LIM does not lock Charge Inlet when AC Charging:
-the switch in the charging handle is also the unlock trigger for the catch on the handle. Some EVSEs with tehered type 1s do not have any other way to stop charge.

Type 2 LIM locks Charge Inlet when DC Charging:
-required by charging standards

Type 2 Lim always locks when charging
-required by charging standards

[alexbeatle]

Type 1 LIM does not lock Charge Inlet when AC Charging:
-the switch in the charging handle is also the unlock trigger for the catch on the handle. Some EVSEs with tehered type 1s do not have any other way to stop charge.

Good point. I have a separate button to stop the charge, but LIM also reports when the Type 1 plug handle button is pressed, so gotta use that to exit to exit my charge routine.

[Volkmar]

Hi Folks,

I have the following setup: Zombie VCU, Tesla SDU OI board, BMW LiM, Volvo batteries with this BMS: viewtopic.php?t=2123
I do not want to use an AC onboard charger because for home charging I have a CCS2 DC Charger and on the road there are enough fast charging stations.
I´m not really skilled in electronics, so please excuse me if I ask stupid questions.

The current status is that when the CCS2 plug is plugged in, the BMW LiM activates the lock and starts HV request, after about 10 seconds this stops and restarts a second time. The first time, the possible voltages and currents of the charger can be read in the Zombie VCU interface, but the second time, you can't.

While studying the forum I read somewhere that the car charging station requires the SoC. My BMS doesn't provide SoC and Zombie says in the WIKI that it's just for information? Is that correct or does anyone of you have an idea where I can get the SoC from in this setup?

In addition, the SoC in the Zombie is wrong because it starts at 100% every time after 12V has been completely gone. Is it possible to store the correct SoC for Zombie in the interface? I stored the battery capacity in the zombie.

I hope someone has an idea where I can start troubleshooting and can give me a hint.

Thank you guys !!!

Best regards

Volkmar

[alexbeatle]

Code: Select all

            if(ChargeType==0x09) lim_stateCnt++;

to

Code: Select all

            if(ChargeType==0x04 || ChargeType==0x28|| ChargeType==0x09) lim_stateCnt++;

Is type 0x28 a combo of AC-Type2 and DC-Type2? If so, then for type 1 should also add 0x14?

[tom91]

Is type 0x28 a combo of AC-Type2 and DC-Type2? If so, then for type 1 should also add 0x14?

Please use context both of coding and the original post. What were we trying to achieve? Hint: Type 1 DC fast charging.

What are you trying to achieve?

[alexbeatle]

Please use context both of coding and the original post. What were we trying to achieve? Hint: Type 1 DC fast charging.

What are you trying to achieve?

Yes, sorry, I'll elaborate. I attempted a DC charge at EVSE, yesterday, but was unsuccessful. Reviewing the logfile my code kept waiting in the initiation phase for the EVSE to id itself as DC-Type2 = 0x9, but in fact it was DC-Type1 identifying itself as 0x4. so no charge and EVSE timed-out.

Looks like the correction for the DC-Type1 was addressed with this.

Code: Select all

            if(ChargeType==0x04 || ChargeType==0x28|| ChargeType==0x09) lim_stateCnt++;

I'm adding ChargeType==0x04. I'm curious what is 0x28? Below are the EVSE type codes I'm aware of that LIM returns. Hence, I wonder if 0x28 is the AC+DC combo type 2 EVSE and if so, should 0x14 be added as the AC+DC Type 1 EVSE?

Code: Select all

0...none
1...AC-Type1
2...AC-Type2
3...Chahdemo
4...DC-Type1
5...AC-CN 
8...DC-Type2
10...DC-GB_T

[tom91]

I wonder if 0x28 is the AC+DC combo type 2 EVSE and if so, should 0x14 be added as the AC+DC Type 1 EVSE?

No idea where the 0x28 came from, might be my bad or from a log. No point adding more unless you find details in a log.

This is from the DBC

image.png (10.22 KiB) Viewed 8706 times

[alexbeatle]

…
This is from the DBC
image.png

What’s the difference between DC-Type1 0x4 and DC-Type1C 0x8?

[tom91]

What’s the difference between DC-Type1 0x4 and DC-Type1C 0x8?

DOH thats what I meant by 0x28 meant to be 0x08.

No idea what the difference is, its BMW magic

[alexbeatle]

We're in business!
2 successful trials at the Electrify America CCS Type 1 using Damien's code migrated to my Teensy VCU. Slow speed for now - 5A and 20A, but proves the concept. VCU controls the LIM using BMS limits. LIM controls 2x small 15ohm contacts, which in trigger larger kilovacs.
Still a few kinks (ex. Full and Bulk SOC times are off), but the backbone works great. Thank you.
Attaching the log for the 5A charging session if of interest. Unfortunately the SavvyCAN crashed on the 20A so no log, but this video is from the 20A session.
https://www.instagram.com/reel/DBdKXENx ... _copy_link

[alexbeatle]

I attempted to charge at a different network today - EVGo. Unfortunately, not successful.
Plugged in vehicle, payment authorised, but within seconds says comm failures with the vehicle.
There were 2 stations. The second one was occupied, but I saw the driver had to start his charging session twice to start on his OEM car.
I tried twice, both times unsuccessfully. I don't have another EVGo nearby, but they're quite common, so would be good to figure them out.
I'll go back tomorrow to try again.
Logs below.
Looks like my state machine enters the CableTest, but then the pilot goes static so charging drops.

Please let me know if you see anything I do not.
Thanks in advance.

[alexbeatle]

Went back to the EVGo today - no go. Fails on the CableTest again. Attaching logs. I saw a car successfully charging on it before me, though.
Today I added LIM contactor re-test code thinking this was the issue. I can hear contactors toggling when I initiate the re-test and they return A-OK status. celeron55's kind wiki writeup helped me, thank you!

I wonder if the below Shockazulu1's issues are somehow related to mine as my CableTest fails so quickly, no contacts close as if vehicle's response isn't fast enough.
Could you please let me know if Shockazulu1's timing changes made it to the main revision or if not, is this the timing related to <case 3> of the LIM code?

Code: Select all

        case 3:
        {
            //I don't like this state CableTest here. Should it remain in Initialisation ....
            Chg_Phase=ChargePhase::CableTest;
            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;//39kw approx power
            CCSI_Spnt=0;//No current
            if(Cont_Volts<=50)lim_stateCnt++; //we wait for the contactor voltage to drop under 50v to indicate end of cable test
            if(lim_stateCnt>20)
            {
                if(CCS_Iso==0x1) lim_state++; //next state after 2 secs if we have valid iso test
                lim_stateCnt=0;
            }

I have tested the original issue charger with and without the faster contactor close and that charger only works with the faster close setting.

I went to re-test Electrify America with which I was successful before, though at a different location now and it charged no problem. I tested charging at 20A/5kW and 50A/14kW, both charged successfully.
The oddity with this one though, is I'm not sure where it's getting the remaining time to charge from. Says it's receiving from the vehicle, the value is in minutes, but decrements faster then once a minute. Not quite sure where it is taking these values from, as seen in the logs I'm sending 1800s for BulkSOC time and 2400s for FullSOC time, for now.
Attaching logs.



Appreciate your input.

[tom91]

Your failed logs show no voltage during cable test. So changing timing at that point does not work as its after seeing voltage on the charge port.

[muehlpower]

alexbeatle wrote: ↑Tue Oct 22, 2024 9:44 pm
What’s the difference between DC-Type1 0x4 and DC-Type1C 0x8?
DOH thats what I meant by 0x28 meant to be 0x08.

No idea what the difference is, its BMW magic

BMW says.:

00 Kein Ladeverfahren
01 AC-Laden mit Typ1-Stecker
02 AC-Laden mit Typ2-Stecker
03 DC-Laden nach CHAdeMO-Protokoll
04 DC-Laden mit DC-Pins über Typ1-Combo-Dose
05 AC-Laden-CN
06 AC-Laden über Typ1-Combo-Dose
07 AC-Laden über Typ2-Combo (Kern)-Ladedose
08 DC-Laden mit Kernpins über Typ2-Combo (Kern)-Ladedose
09 DC-Laden mit DC-Pins über Typ2-Combo (Kern)-Ladedose
0A DC_Laden_mit_DC_Pins_nach_GB_T
FD Schnittstelle ist nicht verfügbar
FE Funktion meldet Fehler
FF Signal_unbefuellt

I think it means DC charging with the AC pins of a type 2 socket.

[uhi22]

If we trust the BWM source, the dbc would be wrong in the red marked cases:

Assuming the prefix "C" in the dbc means "core", so the 6mm pins.
Arg, wrong color of number 9, this is DC via 8mm, aka DC extended, so *not* core, wrong suffix C in the DBC.

[muehlpower]

Assuming the prefix "C" in the dbc means "core", so the 6mm pins.
Arg, wrong color of number 9, this is DC via 8mm, aka DC extended, so *not* core, wrong suffix C in the DBC.

Assuming “C” stands for “combo”, then everything fits except 0x8

[alexbeatle]

Lots of different forums claim EVGo is no good - random charging fails, randomly some cars can charge while others can't. The person charging his car today told me his car would fail to charge few hours earlier, but worked this time and he finds this to be a normal practice.
Not sure what to think, I attempted 6 times at 2 stations that are next to each other today, but no go. Though I noticed, sometimes the latch extends and then retracts and logs say "latch error", other times the latch stays on, yet still "comm with car fails". The plug latch looks a little wider than others I've seen, but observing the port latch, it seems to latch it without issue.

Went to a different charging network today - ChargePoint - success. Multiple sessions at different amp rates - all worked. Though initiation before energy transfer takes quite a while.
If interested, here's a log of charging at 125A (max. charger capacity), with the current slowly derating per BMS charge curve. 150A is what I set my BMS max. charge current, but my VCU selected the lowest between the capability and availability.
The time-to-charge for this one always started at 5hrs, no matter the charge current requested. Oh, and minutes decrease at the rate faster than once a minute .

[tom91]

150A is what I set my BMS max.

If you are using the "standard" BMW I3 contactors do not do this, anything above 100A for long periods will cook the contactors.

[alexbeatle]

If you are using the "standard" BMW I3 contactors do not do this, anything above 100A for long periods will cook the contactors.

Thanks for checking. My LIM drives TE 2203194-1 contactors which have 15.3Ohm coil resistance to make LIM happy. I use these then to drive a pair of KILOVACs EV200 (max. 500A), which actually connect the charge port to the main bus. I think I will limit the BMS charge current to 130A though. 150A is on the limit of the 35mm2 charging port cable.

Anybody explored the Time2Go value in the 0x2FA? Perhaps this is the key to displaying the remaining charge correctly on the chargers.
dbc says it's in minutes on first 2 bytes, but Zombie sends these 0xFC and 0xFD commands there too...

Code: Select all

    uint8_t bytes[8];
//Lim command 3. Used in DC mode.
[b]    if(CP_Mode==0x4||CP_Mode==0x5) bytes[0] = 0xFC;
    else bytes[0] = 0xFD;[/b]
//bytes[0] = 0xFD;// FD at standby, change to FC on 5% pilot. Change back to FD during energy transfer
    bytes[1] = 0xFF;//these bytes are used as a timer during energy transfer but not at setup
    bytes[2] = (uint8_t)Chg_Phase<<4;  //upper nibble seems to be a mode command to the ccs station. 0 when off, 9 when in constant current phase of cycle.
    //more investigation needed here...
    //Lower nibble seems to be intended for two end charge commands each of 2 bits.

    bytes[4] = 0xff;
    bytes[5] = 0xff;
    bytes[6] = 0xff;
    bytes[7] = 0xff;
    can->Send(0x2fa, (uint32_t*)bytes,8); // this msg varies from 82ms to 1s intervals.

image.png (10.27 KiB) Viewed 8070 times

[alexbeatle]

I fixed the issue with the time-to-charge by dividing Full_SOCt and Bulk_SOCt by 10 before sending to LIM. This is indicated by the dbc and the comments in the Zombie code, but doesn't look like is implemented in the code itself.

Code: Select all

    //Lim command 2. Used in DC mode
    uint16_t V_limit=0;
//if(lim_state==6) V_limit=401*10;//set to 400v in energy transfer state
//if(lim_state!=6) V_limit=Param::GetInt(Param::udc)*10;
    //if(lim_state==4) V_limit=Param::GetInt(Param::udc)*10;// drop vlim only during precharge
    if(lim_state==4 || lim_state==5) V_limit=Param::GetInt(Param::udc)*10;// drop vlim only during precharge
    else V_limit=415*10;//set to 415v in all other states
    uint8_t I_limit=125;//125A limit. may not work
    bytes[0] = V_limit & 0xFF;  //Charge voltage limit LSB. 14 bit signed int.scale 0.1 0xfa2=4002*.1=400.2Volts
    bytes[1] = V_limit >> 8;  //Charge voltage limit MSB. 14 bit signed int.scale 0.1
    bytes[2] = I_limit;  //Fast charge current limit. Not used in logs from 2014-15 vehicle so far. 8 bit unsigned int. scale 1.so max 254amps in theory...
    bytes[3] = Full_SOCt & 0xFF;  //time remaining in seconds to hit soc target from byte 7 in AC mode. LSB. 16 bit unsigned int. scale 10.Full SOC.
    bytes[4] = Full_SOCt >> 8;  //time remaining in seconds to hit soc target from byte 7 in AC mode. MSB. 16 bit unsigned int. scale 10.Full SOC.
    bytes[5] = Bulk_SOCt & 0xFF;  //time remaining in seconds to hit soc target from byte 7 in ccs mode. LSB. 16 bit unsigned int. scale 10.Bulk SOC.
    bytes[6] = Bulk_SOCt >> 8;  //time remaining in seconds to hit soc target from byte 7 in ccs mode. MSB. 16 bit unsigned int. scale 10.Bulk SOC.
    bytes[7] = 0xA0;  //Fast charge SOC target. 8 bit unsigned int. scale 0.5. 0xA0=160*0.5=80%

[alexbeatle]

I found the manufacturer of the EVGo station - the infamous ABB Terra 53 and 54, side by side.
Looks like these had issues, but resolved here.

I have LIM from 2015 and the OEM i3 charging inlet socket. So all of the wires are from the inlet to the LIM plug directly into LIM without additional connections.
Would you say shortening the comm wiring was the only change that allowed you to charge? In the ZombieVCU code, I only see the timing comment for initialisation with efacec charger, so I'm assuming there's no special code related for the ABBs.

Code: Select all

//2 secs efacec critical! 20 works. 50 does not.

Thanks in advance.