search

Sevenstax / FreeV2G

Python based Host MPU Application for the use with 8DEVICES WHITE-BEET Embedded ISO15118 Module modules to realize IEC/ISO15118 and DIN70121 conform charging communication between electric vehicles (PEV) and elevtric vehicle supply equipment (EVSE). FreeV2G can e.g. been used with a Raspberry Pi.
Other
51 stars 25 forks source link

Getting "waiting for energy transfer mode selection" error. #326

Open nikunjp26 opened 3 weeks ago

nikunjp26 commented 3 weeks ago

latform: EVSE Firmware Version: i.e. V02_01_00 Host Controller Interface: Ethernet Host: Own Implementation

Dear Team

image

umc02.zip

Please check the uart and wireshark logs as per the snapshot and help to solve the issue.

Best Regards, Nikunj Patel

lho-stx commented 3 weeks ago

Hey @nikunjp26,

I already inspected this log and we have several findings. There are two charging sessions in here. Both are failing because of different reasons, but there are similarities in the behavior of the PEV between the two sessions.

Charging session 1

In this session the charging fails in the cable check. The EVSE is sending a CableCheckResponse and the host application is communicating the cable check status to the WHITE Beet. After around 1.5s the PEV sends a TCP FIN message.

323_session1_perftimer

This is violating the ISO15118-2, because the CableCheckResponse timeout per table 109 of the ISO15118-2 is 2s. It is expected that the EVSE is sending a CableCheckResponse with the status set to ongoing between 1.5s to 2s after the first CableCheckResponse. Our impression is, that the PEV V2G stack vendor used the performance timer as timeout value (again, the PEV should close the session after 2s not 1.5s). In the second session are findings that are also implying this behvior.

Another finding is, that the PEV sends an ACK packets with a wrong sequence numbers. In the next picture you see retransmissions of the WHITE Beet, due to the PEV not responding, then a packet with ACK flag set, but a wrong sequence number.

323_session1_seq_no

After this the next expected message is arriving. What's interesting is the fact, that the wrong sequence number is the ACK number of the previous packet send by the PEV plus the payload size of the next regular packet. It seems the PEV is thinking it already had send out the regular packet. This is true for all V2G messages send by the PEV in both sessions. Although it should not affect the communication (the packets with the wrong sequence number are ignored by the WHITE Beet) but it will be important in the next session.

I don't have any real advice for you in the moment for this issue, except I am creating a special firmware for your next testing session, where we change the performance timer leading the WHITE Beet to send out the CableCheckResponse faster then expected following ISO15118-2. If the session then continues, the PEV most likely uses the wrong timeout value.

Charging session 2

In this session the session is failing because the PEV closes the session after an AuthorizationResponse. In addition to this, the strange ACK behavior and wrong sequence numbers are seen again.

323_session2

You can see the TCP packet with the FIN flag set send from the PEV ~3s after the AuthorizationResponse. Remember our theory, that the PEV V2G stack vendor used the PerformanceTimer as timeout value? This is exactly the PerformanceTimer for AuthorizationResponse added to the PerformanceTimer of the ChargeParameterDiscoveryResponse. This aligns with this assumption.

Nevertheless, this does not explain why the PEV is closing the session in first place. If we have a look at the sequence number of the FIN packet, we can see it is wrong again. Interestingly the sequence number (207) is the previous ACK number (173) plus the payload size of a ChargeParameterDiscoveryRequest (34 Bytes). It seems the PEV thinks it already had send out the ChargeParameterDiscoveryRequest (which it didn't per this logfile), then runs into this wrongly set timeout value and then sends a FIN packet with a wrong sequence number. The wrong sequence number also leads the WHITE Beet to not responding to the FIN packet, which in turn leads the PEV to reset the TCP connection. The PEV has seen the AuthorizationResponse, you can tell it because of the ACK number of the PEV beeing the sequence number of the AuthorizationResponse plus the payload length of AuthorizationResponse.

For this issue I do not have any advice and I do not have an idea how to get the PEV to send out the correct packet. You mentioned other charger working with this setup. Is it possible to create a log file of a working session, e.g. with a PLC sniffing tool?

The other logs are still under investigation.

Best regards, lho

nikunjp26 commented 1 week ago

Dear Iho,

we check the 1.5 second issue in umc02-session-ev file but the sequence numper you mention 115 packet is not matching with our packet.

did you apply any filter?

best regards, nikunj patel

lho-stx commented 1 week ago

Hey @nikunjp26,

yes, in order to work with the log files I separated them into two files (the log files you provided have charging sessions of multiple WHITE Beets in it). In the original file packet 115 is packet 224.

Best regards, lho