Problems starting a charging session between the WB PI board and ABB Terra DC charger

[crtg]

Your Setup Platform: PEV Firmware Version: i.e. V01_00_06 Host Controller Interface: Ethernet Host: FreeV2G (EV_v1.0.6_1)

Describe the bug I am trying to setup a session between the Whitebeet PI and the ABB Terra DC 24kw charging station. Communication lines are connected to the WB, actual DC output is not connected. Very likely the charging station will check DC link voltage at certain point and figure out there is no vehicle connected and terminate the charging process. However, the charging terminates right after the SLAC with the following UART output.

[ 9634.017] [WARN ] V2GDIN12: EVSE did not accept our SessionSetupReq! [ 9634.025] [NOTICE] V2GSVC: TCP: We were disconnected from the server [ 9634.026] [NOTICE] V2GAPP: Received event 'Session stopped'

Expected behavior I was expecting to start the charging session which would be then stopped by the charger due to the undervoltage.

Logs terra_WB_PI_uart.txt terra_dc_WB_PI_application_output.txt terra_dc_WB_PI_wireshark.pcapng.txt

Additional context Unfortunately I don't have any detailed error codes from the charging station at the moment. I would be grateful for any hints where to look for problems. If you think that the missing DC voltage is the problem I can connect a bidirectional power supply to charging station to simulate the EV.

[lho-stx]

Hey @crtg,

your EVSE is responding to the sessionSetupRequest in frame 197 with response Code OK. According to standard it should response with the response Code OK_NewNessionEstablished.

[V2G-DC-393] The SessionSetupRes message shall contain the specific ResponseCode “OK_NewSessionEstablished” if processing of the SessionSetupReq message was successful and a different SessionID is contained in the response message than the SessionID in the request message.

Your charger is violating the DIN standard here. You can try to disable DIN protocol and see if the charging is successful with ISO protocol.

Best regards, lho

[crtg]

Hi Iho,

thanks for your fast response. It seems that the ABB charger I have (despite being brand new) only supports the DIN standard. Are you sure it violates the protocol? I have tried the charger with two EVs (Hyundai Kona, BMW iX) and the charging starts normally. We have to support both DIN and ISO protocols on our charge controller we are developing.

Thanks, Crt

[lho-stx]

Hey @crtg,

I double checked, but unfortunately the charger does not comply to DIN. The software of the EVs accepting the violation are probably less restrictive on protocol violations.

We will discuss internally if we can enhance the Whitebeet firmware with the option to accept some of the protocol violations.

Best regards, lho

[crtg]

Hi,

thanks for your fast response. Is there any industry wide list of shortcuts taken at implementing the DIN charging standard? Is seems that the EVs and charging stations are mostly able to speak to each other despite not being fully compliant to the standard.

I have found out that our charging station is supposed to be compliant also with ISO15118. I have disabled the DIN standard in Application.py, but the script dies at wrong response when setting the configuration. ;-( Any ideas are highly appreciated.

ABB_Terra_ISO_response.txt terra_dc_WB_PI_ISO_wireshark.pcapng.txt

Regards, Črt

[lho-stx]

Hey,

unfortunately I don't know about such a list, but I know from experience that there multiple EV that are less restrictive on protocol violations because of multiple EVSE not following standards, so it seems this is a know issue at EV manufacturers.

Regarding your problem: The setup fails, because the EV says "Wrong state, not in the state to receive the command". It indicates that the last V2G session was not stopped correctly. Does this happens even when you power cycle the unit? Does this happens when you add self.whitebeet.v2gStopSession() in the_initialize(self) method of Ev.py ?

Best regards, lho

[crtg]

Hi Iho,

thanks for your response. If I add the self.whitebeet.v2gStopSession() in the _initialize(self) method of Ev.py the application will crash with the error Warning: Module did not accept command 27:ae, return code: 17.

However, if I restart everything I get slightly further. It seems that the EV.py stays in the "while not (self.state == "end"):" with self.state == "sessionStarting". I tried to uncomment the #self.logger.log("Receiving 0x{:x}".format(id)) to see the response from WB module, but it seems there is any. Also the ABB charger stays in some limbo state "charging delayed until power available". I am waiting to get additional info from the manufacturer, but I have attached all logs from the EV board. Do you have any idea?

Application.py log.txt terra_dc_WB_PI_wireshark.pcapng.txt UART log.txt

Thanks, Črt

[lho-stx]

Hey @crtg,

yes, in frame 140 the charger stops the session, probably because it does not support ISO (please see attached image).

Maybe your charger does not support ISO15118-2 as stated or you need to configure something?

Nevertheless, I will continue to look into the other issue.

Best regards, lho

[crtg]

Hi Iho,

thanks for your response. According to the datasheet the ISO15118 is supported and I have also heard of cases when this type of charging stations have been used with plug and charge functionality. I will investigate if there is any configuration needed or if ISO15118 is working when PNC is not in use on the EVSE side.

Thanks for now and please keep me posted about the other issue.

Regards, Črt

[crtg]

Hi Iho,

there has been some progress on our side. :-) The charging station has some parameters which are not visible to us. One of them was also support for ISO15118 which was disabled by the default. Using the ABB support we were able to switch it on. Now the WB PI module connects to the charging station. The charging process starts, however I have observed (reported and measured) higher DC voltage than the battery script requires. It seems that the process ends in state waitChargingStarted. I went through the WB user manuals. I have found the session charts from the EV side, but I am missing the information when to switch on the battery relays.

Regards, Črt

Receiving 0xc1 Receiving 0xc1 "DC Charge Parameters Changed" received EVSE min voltage: 150 EVSE min current: 1 EVSE min power: 0 EVSE max voltage: 451 EVSE max current: 60 EVSE max power: 451 EVSE present voltage: 404 EVSE present current: 0 EVSE status: 0 EVSE isolation status: 1 EVSE voltage limit achieved: 0 EVSE current limit achieved: 0 EVSE power limit achieved: 0 EVSE peak current ripple: 3 chargingReady

---

Battery ._last_calc_time: 0 .in_voltage: 404 .in_current: 0 .max_voltage: 410 .max_current: 10 .max_power: 12000 .target_voltage: 404 .target_current: 2 ._capacity: 50000 .full_soc: 100 ._level: 49000 ._soc: 98 .full: False .charging: False

ABB_terra_ISO15118_Application.txt terra_dc_WB_PI_wireshark_ISO15118.pcapng.txt Application_output.txt

[lho-stx]

Hey @crtg,

this is good to hear.

Regarding the battery voltage:

Your battery asks for 404V and the EVSE is delivering 404V, this is ok.

Regarding the other question:

The EVSE has a SASchedule with max. power of 12kW and a duration of 86400 (seen in frame 164). The EV then sends a PowerDeliveryRequest in frame 603, the EVSE then closes the TCP connection. In the PowerDeliveryRequest there is a charging profile that does not match with the SASchedule maximum values.

The fail of the session is most likely due to mismatching configuration. I had a look into the Ev.py file and in line 537 a new charging profile overwrites the charging profile just received from the SASchedule. Can you please try removing the line:

self.schedule = {'schedule_tuple_id': 1, 'charging_profile_entries_count': 3, 'start': [0, 1800, 3600], 'interval': [1800, 1800, 82800], 'power': [25000, 18750, 12500]}

and see if this fixes your problem?

Regarding the power switch: You can close the power switch in the PreCharge phase, when the difference between battery voltage and EVSE output voltage is safe to connect. You can just wait for the EVSE output voltage to match your battery voltage.

Thank you and best regards, lho

[crtg]

Hi Iho,

thanks for your investigation. You were correct. I removed the line above and some other code related to charging schedules and now I am in charging state with stable output voltage on the DC link. I didn't manage to sync the python script and the battery contactors yet, but this should work. I was confused because I have measured higher DC voltage than requested, but I assume this part of the EVSE internal cable/isolation check.

Feel free to close this ticket, but I would still be interested to hear if you are going to do any modifications on DIN protocol. In two weeks I will test your EV module also with different DC chargers than ABB.

Regards, Črt

[lho-stx]

Hey @crtg,

I am glad that I was able to help! If there are any new FW release it will be announced here, so please check the README of this repository periodically!

Best regards, lho