Session stopped after Charge Parameter Discovery Response about freev2g HOT 9 OPEN

Hey @nikunjp26,

the EV sends a SessionStopReq, which is not allowed after a ChargeParameterDiscovery. Therefore the Whitebeet stops with a SessionError. The EV does not comply to the sequence defined in the standard. If the EV wants to signal an error it shall close the TCP connection.

I see no reason why the EV can not handle the response, all parameters are in range and the timeout requirements are also met (time for the EVSE sending the answer is ~1s).

The EVSE Status Code in DC EVSE Status is set to "EVSE not ready (0)". Please try setting it to "EVSE ready (1)" prior to ChargeParameterDiscoveryRes and see if the EV then proceeds.

Can you do me a favor and send me a wireshark log of a successful charging session with another EV (and tell me which EV was used)?

Thank you,
lho

from freev2g.

Dear Iho,

Please find the below logs files with successful charging sessions.

1. Hyundai Kona EV
   hyundai_kona_76_to_100_40Amp_Success.zip

2. Tata Nexon EV
   Nexon_wireshark_13122022.zip

from freev2g.

Dear Iho,
We tried as per your suggestion, and you can find the below logs of different scenarios which we tested here with the xuv400 ev car but still we are not success to charge the car and still car is stopping the session.

We also observed the below strange behavior during our different trials. it will be good if you explain more about this.

1. Communication was stop in service discovery process if we select the ISO15118 Protocol.
2. Communication was stop after the charge parameter discovery if we selected the DIN protocol.

xuv_charge_ISO15118_and_isolation_Invalid.zip
xuv_charge_parameter_request_failed_single_transaction.zip
xuv_ISO15118_Selected.zip

Waiting for your quick support as we are stuck at this point.

let us know if need more details.

Best Regards,
Nikunj Patel

from freev2g.

Hey @nikunjp26,

I am sorry to hear this. I will investigate the logs and share my findings with you.

Best regards,
lho

from freev2g.

Dear Iho,

here i am attaching the logs which captured on uart which can help you . We got some warning with below messages during testing.

[ 683.792] [WARN ] V2GDIN12: V2GSVC_NC_SENT notification in wrong state (V2GMH_DIN12_STATE_RECV_EXI).

[ 2626.800] [WARN ] APL-ETH: # Unhandled Ethernet notifycode 365

[ 2733.038] [WARN ] SLAC: Unexpected message!

[ 2733.068] [WARN ] SLAC: Unexpected message!

teraterm.log

from freev2g.

Hey @nikunjp26,

The V2GDIN12 warning occurs for example when a message was not parsed completly and a new message arrives. To tell you more about this I would need more inforamtion of the situation. The ethernet message just indicates that the ethernet module has no implementation for this notify code. These messages are ok, it indicates the EVSE not in state for receiving specific SLAC messages, but it catches up after the messages.

I inspected the logs mutliple times and I just do not see any problem in the protocol messages. Do you have any sort of debug information from the vector unit? Maybe there is a hint from vector side.

Thank you,
lho

from freev2g.

Dear Iho,

We don't have any debug information for the Vector unit as this is the logs of XUV400 EV car.

Thanks

from freev2g.