Getting stared with Whitebeet.

[TESolution]

Hello, I am trying to get started with FreeV2G using Whitebeet EI. Previously I used application versions V01_00_01 and V01_01_07. Setting connection between the board and EV (Tesla X) gave me following results: "No EVSE ID available" or got stuck on "Set duty cycle 5%".

I decided to update firmware to V02_00_01 and the application has taken a step forward (SLAC matching successful, V2G started), but session has not started finally. "We did not receive a frame before the timeout of 30s" "EVSE loop finished"

Are you able to advise me possible solutions? I had discussed it with Codico support and despite the existing similar open issues I was asked to describe my case here.

[lho-stx]

Hey @TESolution,

Thank you for the UART logs, it seems the V2G session setup fails. To look for possible V2G session errors I need a wireshark log of the session. Please enable the port mirror by placing self.whitebeet.networkConfigSetPortMirrorState(1) right above evse.loop() in Application.py and rerun your session. Please also make sure you are directly connected to your Whitebeet and there is no network switch or similar in between!

Thank you and best regards, lho

[nststx]

Hi @TESolution,

Does your issue still persist? If it does please capture a Wireshark log with port mirror enabled so we can further investigate the issue. If you need any help in doing so, please let me know.

Best regards, Niklas Stoffers

[TESolution]

Hello,

Thank you for follow up. To be honest I gathered the Wireshark logs, but after more tests I can see it works a bit randomly. There are cases when I was able to go further. I could see the notification "ready to charge, check power source" on the car's dashboard. If no actions taken application disconnects after timeout.

I am trying to better understand the software layers, so answer on following questions would be appreciated.

1. I am curious which state according to IEC 61851-23 it represents. Basically, I would like to be sure if I can apply the voltage at this stage.

2. If a car is waiting for voltage now, how long does DC voltage should remain at certain level? Assumption - max DC charger voltage for isolation check or max. battery voltage. DC relays are not closed yet, I checked it measuring positive and negative nodes of the CCS connector.

It is obvious that before the DC relay is closed, the charger output voltage should drop to level below 60V. Due to that I am wondering what the next steps would be?

3. I would also like to ask you if I understand correctly that I can simply change charging parameters in Python script (Application.py)?

   Set limitations of the charger

       evse.getCharger().setEvseMaxVoltage(400)
       evse.getCharger().setEvseMaxCurrent(100)
       evse.getCharger().setEvseMaxPower(25000)

Best regards

[lho-stx]

Hey @TESolution,

I kindly ask you to provide some sort of wireshark log (e.g. failing session and a successful session)? With a log I can inspect the communication between EV and EVSE and see where the session is stuck.

1. I do not know in which condition your vehicle is showing you the notification "ready to charge, check power source", but according the IEC the ready state is either state C or stade D (with ventilation on). Please let me know if I misunderstood your question! You can check this by measuring the CP voltage Level. The peek-to-peek voltage in state C is 6V, for state D 3V.

2. Regarding the voltage levels: This is not in the scope of the ISO15118, I can not give you any answer to this. You can have a look at charin, a organization for interoperability of charging systems. They have design guides, whitepapers and best practices.

3. Yes, you can update the charging parameters by changing the values in the python script.

Best regards, lho

[nigaru05]

Hello @TESolution, @lho-stx and @nststx

I have a problem similar to that of @TESolution , I am working with a WB-CARRIER-BOARD-EI with the FW V02_00_01 PnC and the TAG EVSE_v2.0.1_4, when trying to load the TESLA: Terminal

I attach a txt file with a debug port output prueba_debug_tesla_v2.0.1_4.txt

In the txt you can see that TESLA uses DIN protocol. (I clarify it because with an eGolf that uses ISO 15118 the load works correctly). The strangest thing is that with the FW V01_01_07 EIM and the TAG EVSE_v1.1.7_1 the TESLA did start charging.

On Monday I will configure the mirror and upload the log.

Best regards.

[TESolution]

Hello @lho-stx ,

Please see attached package with logs from my runs.

• ETH
• UART
• Console

Tesla Logs.zip

[nigaru05]

Hello @TESolution ,

Sorry I got into your issue. While you wait for the resolution with v2.1, if you want you can try with FW V01_01_07 and TAG EVSE_v1.1.7_1. You have commented that you had the "No EVSE ID available" problem, I have had it too, you can see the solution at issue #133 and it is the following: 1 - Hardcode evseid (as ISSUE #16 )

2 - And then, when communicating by DIN70121 it is necessary to properly set the Energy transfer modes to 1 : DC extended.

I hope I could have helped you. And sorry again.

[nigaru05]

Hi @TESolution,

I have been able to communicate with a Tesla (DIN protocol) with the FW V02_00_01, PNC and TAG EVSE_v2.0.1_4 or TAG EVSE V02_01_00 and arrive at the load authorization request. I was only able to do it with a single charger combination:

• Protocol 0.
• Energy transfer mode in 1. (ony)

On page 137 of the manual, it clarifies that with DIN protocol the WB hangs if DC extended is not offered.

But, it has only worked for me with the combination of Protocol 0 and Energy 1

I will continue testing. I hope I've helped. Best regards.

[nststx]

Hi @nigaru05,

Thanks for trying to help out! There was indeed an issue with an incorrect selection of the energy transfer mode under DIN protocol with the V02_00_01 firmware. If configured, the EVSE would offer DC_core mode (mode 0) under DIN although that mode is currently not supported by any EV. This issue has been fixed with the new V02_01_00 firmware. The note from the User Manual is also only valid starting with the V02_01_00 firmware. Previously you could configure DIN with DC_core without the board rejecting the configuration. You can either remove energy mode 0 from the transfer mode options list (as you did) or update your board to the V02_01_00 firmware to fix this issue.

Best regards, Niklas Stoffers

[nststx]

Hi @TESolution,

Thanks for coming back with the logs. Unfortunately the Wireshark log comes in an unusual format and also seems to lack the actual payload data. However I'm pretty sure that you're probably facing the same issue as @nigaru05. Could you try the suggested workaround and remove energy transfer mode 0 from the configuration or update your board to the V02_01_00 firmware? Please let me know if the proposed solution works for you.

Best regards, Niklas Stoffers

[TESolution]

Hi @nigaru05, @nststx,

Changing the protocol makes a difference in my case. Using DIN protocol I got another information on the car's dashboard about lack of voltage, but nothing strange - I have no voltage connected. The main difference is that I received battery voltage value from the car. I also checked voltage on the connector, but it looks like car's relays are still open.

@nigaru05 what is your test setup? Did you make a next step since setting connection with WB, e.g. isolation check and pre-charge?

Best regards

[nststx]

Hi @TESolution,

I'm glad that you were able to go a step further. Just to be sure you're still using EVSE firmware version V02_00_01 and are now charging with DIN protocol and the DC extended mode configured, right?

Regarding the car's relay: It should close during the precharge phase when the voltage monitor of the car detects the correct DC voltage. Thus if you want to transition from the precharge to the actual charge phase you'll need to apply the correct voltage. Once the car detects the correct voltage it will close it's relay and start the actual charging with a request to deliver power.

Best regards, Niklas Stoffers

[TESolution]

Hello @nststx,

This is correct. I progressed due to change to DIN protocol. Energy transfer mode was not that critical. Even default settings allowed me to set communication with the car. And just to confirm - yes, I am still using firmware V02_00_01.

I am not sure if there is lack of isolation check in your description. According to IEC61851 standard, isolation check finishes with quick output voltage discharge before pre-charge sequence and disconnecting device close. Nevertheless I am not sure if it is obligatory.

Or is it just a flag in the available code called: isolation_level: 0 ? which could inform system and a car about EVSE isolation check readiness?

Best regards,

[nststx]

Hi @TESolution,

Thanks for the clarification. I thought that you already proceeded through the isolation check and were currently at the precharge phase and thus I didn't mention it. However if that's not the case you have to perform a cable check before precharge. During the cable check phase you would perform the isolation check. The isolation check is mandatory if you want to charge. After a successfull isolation check you would need to set the EVSE isolation level to valid (1) as an invalid (0) isolation level indicates that the isolation self test has not been carried out which according the the IEC61851-23 should prevent charging. Basically the whole process would work like this:

1. ChargeParameterDiscovery finishes
2. EV requests cable check
3. EVSE Whitebeet sends notification about requested cable check
4. Check DC voltage. Needs to be less than 10V
5. Apply maximum EVSE voltage to DC line
6. Check isolation resistance according to IEC 61851-23
7. Ramp down voltage to 20V or less
8. Set EVSE isolation status to 1 (if measured isolation resistance meets IEC requirements)
9. Notify EVSE Whitebeet that cable check finished successfully
10. Move on to precharge

Note: Make sure that after successfull isolation check you always set isolation level to 1 in your update dc charge parameters message.

I hope I could help with my answer. If you have any further questions, feel free to ask!

Best regards, Niklas Stoffers

[TESolution]

Dear @nststx ,

Nothing to add, fully agree with you.

What would be the most efficient way of development own embedded system uses WB in your opinion? I planned to use another WB (Carrier Board - PI) as EV instead of real car. The WBs would be controlled by own embedded system or PC for EV (for EVSE: ETH or SPI). I know there is SPI example available for Raspberry what I would like to start evaluating SPI.

I am going to build evaluation setup represented by following top level block diagram:

I can imagine following top level block diagram (target):

I will be grateful for any response on that and guidelines.

Best regards

[ttu-stx]

Hi TeSolution, your setup does not look atypical. But we would recommend to use an EV simulator instead of WB PI to save effort. You can request a simulator via our homepage or through Codico. BR