SLAC matching timeout for EV but not EVSE

[Vickkram]

Hello,

I have been trying to connect WB-CARRIER-BOARD-PI 1.1(EV) and a WB-CARRIER-BOARD-ES (EVSE).

I have been following the process outlined in the README document and what ends up happening is that for the EVSE terminal a "SLAC matching successful" message appears, but under the EV terminal it reads: "We did not receive a frame before the timeout of 60s"

log (EV) Set the CP mode to EV Start the CP service Set the CP state to State B Set SLAC to EV mode Start SLAC EVSE connected Start SLAC matching We did not receive a frame before the timeout of 60s EV loop finished Goodbye! Log(EVSE) Set the CP mode to EVSE Set the CP duty cycle to 100% Start the CP service Start SLAC in EVSE mode EV already connected Start SLAC matching Set duty cycle to 5% SLAC matching successful Set V2G mode to EVSE

[nststx]

Hi @Vickkram,

thanks for submitting your issue. Unfortunately, I will need more information to help you with your problem. Could you please tell me which firmware version and FreeV2G version you're using for both WB EV and EVSE? I will also need a Wireshark capture from your session with port mirror enabled. To enable port mirror please put evse.whitebeet.networkConfigSetPortMirrorState(1) in the line above evse.loop() in Application.py. If you need any help with this, please let me know.

Best regards, Niklas Stoffers

[Vickkram]

Hi @nststx

I really appreciate the fast response.

The version of the EV is V01_00_06. Unfortunately due to the EVSE being a bridging board I don't know how to check/update the firmware on the board (if there is a way please let me know)

slactimeout_wireshark.zip

[nststx]

Hi @Vickkram,

Thanks for the clarification about the board and firmware version. I've overread that your EVSE is an ES and not an EI board. In that case using an ES board with FreeV2G doesn't really work. The ES board is only capable of doing SLAC and CP (although there were known issues about CP management in the SLAC firmware) and is missing our ISO15118 stack for high level communication. However FreeV2G focuses mostly on HLC and was not designed to be used with the SLAC firmware.

Best regards, Niklas Stoffers

[Vickkram]

Hi @nststx,

We decided to use the EV board with a charger instead rather than an EVSE board and are still running into issues. Can you see anything in these logs that would suggest what the issue would be? No changes to the FreeV2G code were made.

Logs_with_charger.zip

[nststx]

Hi @Vickkram,

I'm sorry for the late response. I was out of office for some time and didn't have the opportunity to take a look at your logs. However I was able to take a look at them today. Here is what I found:

In frame 161 the EVSE sends a SessionSetupResponse containing the response code OK(0). However this doesn't adhere to the DIN70121 specification. According to the specification (requirement [V2G-DC-388] and [V2G-DC-393]) the EVSE must send the response code OK_NewSessionEstablished instead (at least in this specific scenario). Thus the EV Whitebeet closes the TCP connection because this indicates a sequence error.

Unfortunately there is not much that can be done about this. You should be able to perform a charging session with a charger that adheres to the standard. Do you maybe have some kind of other charger that you can try this with?

Best regards, Niklas Stoffers

[nststx]

Hi @Vickkram,

Due to a similar issue I've taken a look at the DIN spec again regarding the SessionSetup response codes and found out that I actually missed one requirement last time. Although the EVSE still shouldn't send the response code "OK" but "OK_NewSessionEstablished" the EV should nevertheless actually accept the "OK" response code. Thus this is an issue with our firmware. We will fix this with the upcoming EV firmware update.

If you still have any questions left, feel free to ask them here!

Best regards, Niklas Stoffers

[Vickkram]

Hi @nststx

Awesome! When can I expect the next firmware update?

Cheers, Vickkram

[chitranshtirex]

HI @nststx,

We're currently utilizing the latest WHITE-beet-EI firmware version V02_01_00 and WHITE-beet-PI firmware version V01_00_06. However, Codico team informed us that the most recent WHITE-beet-PI firmware version is V01_00_07, which primarily addresses an update process issue found in V01_00_06.

Could you kindly provide us with the details of the PI firmware version that doesn't have the SLAC matching timeout problem?

Thank you, Chitransh

[lho-stx]

Hey @chitranshtirex,

V01_00_07 is the latest PEV firmware and I advise you to use this version. The problem mentioned in this issue was fixed in EVSE V02_01_00.

There are multiple reasons why a SLAC matching timeout can occur, it is not necessarily the problem from this issue. If you have issues please create a new issue and add log files:

https://github.com/Sevenstax/FreeV2G/issues/new?assignees=&labels=&projects=&template=bug_report.md&title=

Best regards, lho