Is this just a partial decode of V2G packet, what's the rest ?

[beadon]

Hi ! I am examining packets and finding that the V2G message for CableCheckRes seems to be only partially decoded.

Notice the difference in these 2 packets in their binary formats. I am seeing different behavior in my system when the message on the left ( nonprintable characters ) versus the right, which has printable characters "PMuX" it may be a coincidence that these are printable, but I can't see what this part of the message is signalling.

Can anyone decode the rest of the message ?

*updated image

[barsnick]

which has printable characters "PMuX" it may be a coincidence that these are printable

This is usually a coincidence, as in V2G's EXI, the data isn't byte-aligned. String objects aren't compressed though, so there's a 1 in 8 chance that they can be seen in clear text. 😉

the V2G message for CableCheckRes seems to be only partially decoded

Could you show us what both messages actually decode to in the plugin? You didn't capture that part of the display, so it's hard to understand the issue.

It would be helpful if you provided the actual PCAP, I don't know if someone can quickly inject this data into a new trace to test the plugin's behavior.

I took my time to at least extract the two EXI messages:
Left:

80980209cecac7942fbe999040000000010100

Right:

80980204c8504d7558be1b5040000000010100

The left side should decode to something like this:

MsgDef.Header.SessionID: 273b2b1e50befa66
MsgDef.Header.Signature: (not given)
CableCheckRes.ResponseCode: iso2_responseCodeType_OK
CableCheckRes.DC_EVSEStatus.NotificationMaxDelay: 0
CableCheckRes.DC_EVSEStatus.EVSENotification: iso2_EVSENotificationType_None
CableCheckRes.DC_EVSEStatus.EVSEIsolationStatus: iso2_isolationLevelType_Invalid
CableCheckRes.DC_EVSEStatus.EVSEStatusCode: iso2_DC_EVSEStatusCodeType_EVSE_IsolationMonitoringActive
CableCheckRes.EVSEProcessing: iso2_EVSEProcessingType_Ongoing

The right side should decode to something like this:

MsgDef.Header.SessionID: 13214135d562f86d
MsgDef.Header.Signature: (not given)
CableCheckRes.ResponseCode: iso2_responseCodeType_OK
CableCheckRes.DC_EVSEStatus.NotificationMaxDelay: 0
CableCheckRes.DC_EVSEStatus.EVSENotification: iso2_EVSENotificationType_None
CableCheckRes.DC_EVSEStatus.EVSEIsolationStatus: iso2_isolationLevelType_Invalid
CableCheckRes.DC_EVSEStatus.EVSEStatusCode: iso2_DC_EVSEStatusCodeType_EVSE_IsolationMonitoringActive
CableCheckRes.EVSEProcessing: iso2_EVSEProcessingType_Ongoing

The difference seems to be only in the SessionIDs.

[TGruett]

Hi,
i have injected it into a pcap an everything looks fine to me:

left packet:

right packet

Seems like only the SessionID is different, as barsnick already mentioned.

Which dsV2Gshark version are you using?

[beadon]

You are awesome. I am trying to figure out why of these captures succeeds in EV charging, and other other fails. The difference in session ID makes sense, and the coincidence with the printable / non-printable characters also makes sense.

From the traces below -
It looks like the CableCheck fails while in CPState C(2) according to the emulator. And the traces I believe confirm this, but I can't see a difference in these traces in the CableCheckRes messages to troubleshoot further, I was hopeful I was just missing something in the CableCheck.

Attached is the pair of captures :

Cablecheck errors --
CableCheck_errors_emulationMode_2024-11-13_18.09.11_eth1.ev.zip

Working EV Charging Session
working---emulationMode_2024-11-13_14.48.52_eth1.ev.zip

Plugin version ( 1.4.3 ) accoridng to Wireshark -> About

[TGruett]

I checked the messages again and they still look fine to me. The only difference I noticed between the two traces is the timing of the CableCheckRequests and -Responses. Maybe there is a timing problem on your EV side?

In the error case, the first two responses follow the request within 25-30ms, the third response takes ~100ms and afterwards the EV stops immediatly. In the good case trace, the third response takes 'only' ~80ms

[beadon]

It seems it was not the message exactly - The resolution here was during the CableCheck. A "bender" unit was checking the impedance on the lines, but was incorrectly wired to the board requesting the check completion. This meant that the board checking the cable was unable to sense a proper CableCheck and halted the progression. This was difficult to find since this as electrical in nature and there were no (?) error codes visible other than a failed cable check.

I think you can safely close this ticket.