Bus Transaction is interrupted at 55 percentage

[nikunjp26]

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

Dear Team

We have used the updated 2.1.0 firmware in which you have done some modification related to retransmission/tcp socket.

Still we are facing issue with the BUS communication. Can you please look into the below two logs file and tell us what was the reason to stop session or why the session was not started? We also marked the packet connect for reference.

error_55per_suspended_ev_Commented.zip

Pass3_errors.zip

Best Regards, Nikunj Patel

[lho-stx]

Hello @nikunjp26,

I will have a look into the issue. Please allow some more time for resolving the issue.

Best regards, lho

[lho-stx]

Hey @nikunjp26,

Pass3_errors.pcapng:

In the first charging session the EVSE is failing to provide the target current of 126A to the EV, it is fluctuating around 100A. Then there is SLAC traffic from another WHITE Beet. This might be ok, but then I see framing traffic between the other WHITE Beet and the same host on the line. Normally this should not happen.

Are you using the same ethernet interface for multiple WHITE Beets? This will lead to problems when not set up correctly.

Then there are two charging sessions going on.

In both charging sessions the EV is reporting a Charging Current differential:

Frame 205365: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface \Device\NPF_{3C5B5640-4538-415E-90A3-58748D99F5AA}, id 0
Ethernet II, Src: 8Devices_34:ad:2b (c4:93:00:34:ad:2b), Dst: PhytecMe_2f:8a:81 (50:2d:f4:2f:8a:81)
Framing Protocol Header
Framing Protocol Payload
    maxVoltage: 735
    maxCurrent: 33
    ready: True
    errorCode: Charging Currentdifferential
    soc: 99
    targetVoltage: 730
    targetCurrent: 33
    chargingComlete: False

and

Frame 186420: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface \Device\NPF_{3C5B5640-4538-415E-90A3-58748D99F5AA}, id 0
Ethernet II, Src: 8Devices_34:ae:cc (c4:93:00:34:ae:cc), Dst: PhytecMe_2f:8a:81 (50:2d:f4:2f:8a:81)
Framing Protocol Header
Framing Protocol Payload
    maxVoltage: 735
    maxCurrent: 32.7
    ready: True
    errorCode: Charging Currentdifferential
    soc: 99
    targetVoltage: 729.7
    targetCurrent: 32
    chargingComlete: False

Your EVSE application is then sending the following frames to the WHITE Beets:

Frame 205370: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface \Device\NPF_{3C5B5640-4538-415E-90A3-58748D99F5AA}, id 0
Ethernet II, Src: PhytecMe_2f:8a:81 (50:2d:f4:2f:8a:81), Dst: 8Devices_34:ad:2b (c4:93:00:34:ad:2b)
Framing Protocol Header
Framing Protocol Payload
    isolationLevel: Valid
    presentVoltage: 729.5
    presentCurrent: 89.53
    maxVoltage: 1000
    maxCurrent: 126
    maxPower: 90000
    status: Emergency shutdown

and

Frame 187292: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface \Device\NPF_{3C5B5640-4538-415E-90A3-58748D99F5AA}, id 0
Ethernet II, Src: PhytecMe_2f:8a:81 (50:2d:f4:2f:8a:81), Dst: 8Devices_34:ae:cc (c4:93:00:34:ae:cc)
Framing Protocol Header
Framing Protocol Payload
    isolationLevel: Valid
    presentVoltage: 505
    presentCurrent: 28.99
    maxVoltage: 1000
    maxCurrent: 126
    maxPower: 90000
    status: Emergency shutdown

After this the EVSE is ramping down the current and is then stopping the charging session. This is true for both charging sessions. It seems either there is a hardware fault, the EVSE is not responding to the target current requests accordingly or using multiple WHITE Beets with a single host interface is causing issues. Please review this points.

error_55per_suspended_ev_Commented.pcapng:

Here again, two charging sessions. Both charging sessions are looking ok until the WHITE Beet is not responding to the Current Demand Requests anymore. It is still communicating with the host but no V2G traffic. The EV is then sending a TCP Fin, but this is also not ACK by the WHITE Beet therefore the TCP RST by the EV. After the TCP reset and the Charging stoppen notification from the WHITE Beet to the host, the host keeps updating the DC charge parameters. Do you have UART logs of this session? I do not see any obvious reason why the WHITE Beet is not answering to the V2G traffic, but your host sending DC charge parameter updates after the session was closed is not needed.

Both log files:

The EV is not ACK every packet send by the WHITE Beet directly, but sends ACK in the next Current Demand request. This leads to the retransmissions of the WHITE Beet, but should not affect operation.

So please review the following points:

• using multiple WHITE Beets with a single host interface. Please try using only a single WHITE Beet.
• check your hardware for failure in the power electronics
• check why you are not able to provide the requested target current
• please send UART log files

Best regards, lho

[nikunjp26]

Dear Team,

1. Are you using the same ethernet interface for multiple WHITE Beets? This will lead to problems when not set up correctly. We are using the single ethernet for two whitebeet module using the NETGEAR Switch in which We configured the rules that whitebeet1 and whitebeet2 package can't be communicate to each other. what setting we need to take for this?
2. Using multiple WHITE Beets with a single host interface. Please try using only a single WHITE Beet. we have two guns in charger so how this is possible to use single module for two gun? please share us the example code or document if you have.
3. Check your hardware for failure in the power electronics which hardware failure you are talking? can you please describe more?
4. Check why you are not able to provide the requested target current ok. we will check that and update for this
5. please send UART log files we don't have that and it is quite difficult for us to get those logs from the live charger. don't we have any other method to get that debug data remotely? like you send it on any port/socket or something?

Note : we are using the binary which provided by the Lukas inwhich applied the patch for the retransmission issue. so please sync with him if possible.

Best regards, Nikunj Patel

[lho-stx]

Hey @nikunjp26,

1. • 2.: We do not provide example code for this, but there are two possible solutions:
   • using a managed switch and VLANs. The WHITE Beets are connected to the switch and the host is sending the framing messages using VLANs to the switch. The switch is then forwarding the packets to one WHITE Beet only, based on the VLAN used for sending the framing message to the switch. On the host you set up different virtual network devices using the VLANs, one for each WHITE Beet. Each instance of your custom application is then using one of the virtual network devices.
   • Make sure the WHITE Beets do not see each other. In your custom application keeps track of the WHITE Beets (via e.g. MAC address) and is capable of differentiating them when sending broadcast messages etc.

2. The EVSE is reporting invalid isolation:

Frame 205413: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface \Device\NPF_{3C5B5640-4538-415E-90A3-58748D99F5AA}, id 0
Ethernet II, Src: PhytecMe_2f:8a:81 (50:2d:f4:2f:8a:81), Dst: 8Devices_34:ad:2b (c4:93:00:34:ad:2b)
Framing Protocol Header
Framing Protocol Payload
    isolationLevel: Invalid
    presentVoltage: 576.9
    presentCurrent: 23.06
    maxVoltage: 1000
    maxCurrent: 126
    maxPower: 90000
    status: Emergency shutdown

Can you review in your code why this happens as this message is send from your host application to the WHITE Beet. This is true for both charging sessions in the Pass3_errors.pcapng.

4. Looking forward for your information

5. Unfortunately this is not possible at the moment.

Please review point 1.-3. In the meantime we will have another look into the log files.

Thank you for your hint about the debug firmware, it is known that you are using this specific firmware.

Best regards, lho

[nikunjp26]

Dear Iho, We are using the 2nd method in which we have very strong parcer used and till now we didn't faced any issue. The capture log we shared with you are the captured from the Netgear switch port in which we enabled the port forwarding. Did you believe that any mismatch happened in previous logs? My meaning is the wb1 package process by 2nd gun process and wb2 package process by 1st gun process?

3. Ok we will look that

Best regards Nikunj Patel

[lho-stx]

Hey @nikunjp26,

no, if you made sure your application can handle this I see no problem.

Best regards, lho

[nikunjp26]

Dear Team,

error_55per_suspended_ev_Commented.pcapng:

Here again, two charging sessions. Both charging sessions are looking ok until the WHITE Beet is not responding to the Current Demand Requests anymore. It is still communicating with the host but no V2G traffic. The EV is then sending a TCP Fin, but this is also not ACK by the WHITE Beet therefore the TCP RST by the EV. After the TCP reset and the Charging stoppen notification from the WHITE Beet to the host, the host keeps updating the DC charge parameters. Do you have UART logs of this session? I do not see any obvious reason why the WHITE Beet is not answering to the V2G traffic, but your host sending DC charge parameter updates after the session was closed is not needed.

can you please do something for this? why whitebeet is not getting data? or can you please do something to capture the UART logs?

Best Regards, Nikunj Patel

[lho-stx]

Hey @nikunjp26,

this is still under investigation.

Regarding the UART: there may be a way, but this is not a task done in two days and needs a new firmware (if it is even possible without big changes to the code base). It would be much faster if your are soldering some wires to the WHITE Beet UART ports in the charger and connect a UART<->USB adadpter to it.

Best regards, lho

[nikunjp26]

Dear Iho,

UART and Connection is not an problem for us if the charger at our office or near area. This charger install in the bus depo where the extra supply and extra setup continuously monitoring is quite difficult where this issue comes randomly and comes 1 or 2 times in per day.

it will be good if you can just stored the log-file/data inside the module somewhere and that we can capture on one command. or you can add the extra packages on ethernet.

Best Regards,

[lho-stx]

Hey @nikunjp26,

understood, but like I said, this is not an easy task, need to check if this is possible in a feasible amount of time.

edit: I am sorry, but unfortunately adding this is not feasible at the moment. This is a major feature request. Please make sure to add the needed debug capabilities (UART and ethernet logging, additional SPI if necessary) to the hardware used for your field tests.

Best regards, lho

[lho-stx]

Hey @nikunjp26,

I am still working on this one. It is hard for me to reproduce, therefore it takes some more time then usual for me to debug this.

Best regards, lho

[nikunjp26]

Dear Iho,

We did the testing again at bus depo and able to capture the same scenario 3 times as per below tables. Please find the uart logs and wire shark data from the zip file.

EKA-Bus-session-issue.zip

We also plan to go at site on 17th June 2024 so let us know if need to do any other testing because we confirmed and checked the competitor charger's session logs and all the transaction was working fine without single time failure so there was no any issue from bus side.

*Best Regards, Nikunj Patel

[lho-stx]

Same as in #326, #327 and #323

[github-actions[bot]]

This issue has been marked as stale because it has been open for 14 days with no activity. Please update this issue or it will be closed in the next 7 days.

[github-actions[bot]]

This issue was closed because it has been inactive for 7 days since being marked as stale. If your issue still persists, feel free to reopen!