experience with CG5317 and OpenV2G so far
Posted: Tue Sep 16, 2025 12:34 am
Right or wrong, I went down the path of buying the Lumissil CG5317 eval kit and signing an NDA to get technical information.
My original aspiration was a CG5317-based sniffer with USB interface (I contributed the original RNDIS/ECM virtual Ethernet implementation for the TinyUSB open-source effort), but I haven't yet come up with a working way of getting the CG5317 to sniff traffic after the NMK has been observed.
I have some design decision niggles with the way the eval kit cripples its usefulness for developers, but I can't yet fault the chip's intended usage for EV and EVSE roles.
My original sniffer interest necessitated decent sensitivity, and signal sensitivity of the chip seems good... although I don't know what comparable performance with the Qualcomm/Atheros part would be. Even with 6dB of attenuation built-in to the eval board PCB, there was no packet loss at 80dB of attenuation between the eval boards (~92dBm at receiver), and some packet loss was present at 90dB (~102dB at receiver) between the eval boards. Even with completely the wrong frequency band antenna on the end of a 6 meter coax cable, I was able to see traffic when within ~0.5 meter of the charging cable at a commercial DC fast charger.
It was proving impractical to drive to a DC fast charger each time I wanted to collect data, so I started down the path of implementing an ISO stack so I could sniff traffic seen on my own EV. What Lumissil provides is exceedingly basic; their binary-only executable just oversees the HomePlug SLAC handshake and that's basically it.
So, I wrote my own SDP and then did a basic ISO 15118-2 implementation using the "ISO1" library code from OpenV2G. Yes, I realize that I was reinventing the wheel given uhi22's pyplc, but I don't understand Python but do understand C. Writing code also forced me to learn more about the ISO protocol.
I'm at a point now where my EV (Hyundai) will handshake and sequence through to PowerDelivery, at which point I provide a response code ask it to stop, and then it does a WeldingDetection and then SessionStop and the car finishes the "charge" without incident. It is hardly a complete EVSE implementation, but it is enough to keep the car happy.
The Hyundai is an "800VDC" vehicle, so I was particularly interested to see how it negotiates charging parameters on lower voltage chargers. Here are my two data points: If the EVSE communicates 900VDC max in ChargeParameterDiscoveryRes, the vehicle asks for the actual battery voltage (I'm presuming this based on the number) in PreChargeReq. If the EVSE communicates 400VDC max in ChargeParameterDiscoveryRes, the vehicle makes a 360.0VDC PreChargeReq (surely to feed its motor-windings-based boost converter).
My original aspiration was a CG5317-based sniffer with USB interface (I contributed the original RNDIS/ECM virtual Ethernet implementation for the TinyUSB open-source effort), but I haven't yet come up with a working way of getting the CG5317 to sniff traffic after the NMK has been observed.
I have some design decision niggles with the way the eval kit cripples its usefulness for developers, but I can't yet fault the chip's intended usage for EV and EVSE roles.
My original sniffer interest necessitated decent sensitivity, and signal sensitivity of the chip seems good... although I don't know what comparable performance with the Qualcomm/Atheros part would be. Even with 6dB of attenuation built-in to the eval board PCB, there was no packet loss at 80dB of attenuation between the eval boards (~92dBm at receiver), and some packet loss was present at 90dB (~102dB at receiver) between the eval boards. Even with completely the wrong frequency band antenna on the end of a 6 meter coax cable, I was able to see traffic when within ~0.5 meter of the charging cable at a commercial DC fast charger.
It was proving impractical to drive to a DC fast charger each time I wanted to collect data, so I started down the path of implementing an ISO stack so I could sniff traffic seen on my own EV. What Lumissil provides is exceedingly basic; their binary-only executable just oversees the HomePlug SLAC handshake and that's basically it.
So, I wrote my own SDP and then did a basic ISO 15118-2 implementation using the "ISO1" library code from OpenV2G. Yes, I realize that I was reinventing the wheel given uhi22's pyplc, but I don't understand Python but do understand C. Writing code also forced me to learn more about the ISO protocol.
I'm at a point now where my EV (Hyundai) will handshake and sequence through to PowerDelivery, at which point I provide a response code ask it to stop, and then it does a WeldingDetection and then SessionStop and the car finishes the "charge" without incident. It is hardly a complete EVSE implementation, but it is enough to keep the car happy.
The Hyundai is an "800VDC" vehicle, so I was particularly interested to see how it negotiates charging parameters on lower voltage chargers. Here are my two data points: If the EVSE communicates 900VDC max in ChargeParameterDiscoveryRes, the vehicle asks for the actual battery voltage (I'm presuming this based on the number) in PreChargeReq. If the EVSE communicates 400VDC max in ChargeParameterDiscoveryRes, the vehicle makes a 360.0VDC PreChargeReq (surely to feed its motor-windings-based boost converter).