Charge session stops in Charge Parameter Discovery just after authentication

[AlbertoGilardoni-eaton]

Setup Platform: EVSE Firmware Version: V02_10_00 Host Controller Interface: SPI Host: Own Implementation

Describe the bug V2G Communication stops when Authorization Status is set to 0 (I don't even have the time to send the schedules). Here it should wait for the schedules, if I try to send the schedules and the requested entries is 0, I have to send the Code to "Unable to deliver schedules" or I send anyways the schedules? In any case I can send both and I get an error in return, so the frame Set Schedules 0x27:0x6C seems that is never accepted.

To Reproduce Here's my charge flow:

EV connected Start SLAC matching Set duty cycle to 5% SLAC matching successful Set V2G mode to EVSE Start V2G (Start Listen sent)

V2G Session Started: Protocol: DIN70121-2:2012 Session ID: EEF3BC19FC3BC653 EVCC ID: 000000050000

Selected Payment Method: External payment

Authorization Status Requested, timeout: 54999

-> Athorization status set to '0' (Authorization succeeded)

EV Energy Transfer Mode Selected: Energy Request: 100.000000 Max Voltage: 500.00 Max Current: 50.00 Max Power: 25000 Selected Energy Transfer Mode: DC extended Energy Capacity: 100 Full SoC: 99 Bulk SoC: 80 Ready: 1 Error Code: No Error SoC: 0

Schedules requested: timeout = 54991, max entries = 0

EV DC Charge Parameters Changed: Max Voltage: 500.00 Max Current: 50.00 Max Power: 25000 Ready: 1 Error Code: No Error SoC: 0 Target Voltage: 0.00 Target Current: 0.00 Full SoC: 99 Bulk SoC: 80 Charging complete: 0

CP state changed: A

Expected behavior It should wait for the schedules?

Logs log_bug_whitebeet_20230502.txt

[nststx]

Hi @lb-rt,

Thanks for submitting your issue. I will take a look at it in the upcoming days and come back to you until the end of next week.

Best regards and thanks for your patience, Niklas Stoffers

[AlbertoGilardoni-eaton]

I can now correctly send the schedules and the cyclic 'Update DC Charging Parameters' frame, but the session closes anyways. Seems like the same issue of ticket 130, https://github.com/Sevenstax/FreeV2G/issues/130

[AlbertoGilardoni-eaton]

In case here's the wireshark log 20230504_EVSE_ChargeParameterDiscoveryReq.zip

[nststx]

Hi @lb-rt,

I've just taken a look at your logs. However I'm not sure if your Whitebeet log that you attached to your first message still matches the Wireshark log that you send in the last messages as you said that you were already able to go a step further in the mean time. Could you do me a favor and capture a new Whitebeet and Wireshark log just to make sure that both logs come from the same charging session?

Best regards, Niklas Stoffers

[AlbertoGilardoni-eaton]

Hi, It's not really the same charge but the result was quite the same, I can't do another test right now because my EV test equipment is not available until next week. What I'm sure is that I had always these two messages at the end:

[ 848.713] [CRIT ] V2GLIB: ARRAY_SIZE_EXCEEDED: The number of elements in an subelement array is too large [ 848.831] [NOTICE] V2GCPS: Change State from B to A

But if I remember correctly the message just before was stating that the charge parameter discovery was processed. I don't remember if for a brief moment it also went to C state or not, this I have to test it again.

[AlbertoGilardoni-eaton]

I put you again the logs of basically the same test as before: WB_parameterdiscovery.txt WB_parameterdiscovery.zip

Do you know what's wrong? There's maybe wrong data in what I send in the ChargeParameterDiscoveryRes ? I think I don't even have time to send the frame, because the session stops when I send the schedules, when I receive 0x27:0x84 I answer with 0x27:0x6C and the command is accepted, but then CP goes to A state

[lho-stx]

Hey @lb-rt,

I suspect the framing message to set the schedules was received, but in the processing of the schedules there is a problem. Most likely we can sort the problem out when I have access to the specific framing message used to set the schedules! Can you provide a log that contains the framing messages? You are using SPI for communication, in my comment on #176 I shared the details of creating the SPI log with you.

I am looking forward to the SPI log!

Thank you. lho

[AlbertoGilardoni-eaton]

Hello, So I have a SPI log, the log starts when the EVSE receives Session started, so 0x27:0x80. Do you need more data?

I attached also the UART log.

Session_2.zip wb_log_uart.txt

[lho-stx]

Hey,

we are currently working on different issues and will come back to you as soon as possible!

Thank you for your patience, lho

[nststx]

Hi @AlbertoGilardoni-eaton,

Thanks for coming back with the SPI logs. I already have a guess about what the source of your problem could be. However since the SPI log starts after the "Session started" notification I am missing the initial configuration messages to confirm that. Please take a look at issue #194. In there another customer had exactly the same issue as you do, due to a misconfiguration of the "Peak Current Ripple" parameter in the "Set DC charging parameters" message for EVSE. The issue stems from the example in the User Manual being wrong for that message.

Could you please check if you're maybe facing the same issue? If not please capture another SPI log which also contains the initial configuration commands so I can check if something is going wrong there.

Best regards, Niklas Stoffers

[AlbertoGilardoni-eaton]

Hello, I tried to reconfigure the Peak Current Ripple and it worked, so yes the problem was the User Manual example. I can finally continue with the charging process. Thank you. Alberto

[nststx]

Hi @AlbertoGilardoni-eaton,

I'm glad that we were able to fix your issue. If you have any questions left, feel free to ask! Closing as this is a duplicate of #194.

Best regards, Niklas Stoffers