experience with CG5317 and OpenV2G so far

Development and discussion of fast charging systems eg Chademo , CCS etc
Post Reply
majbthrd
Posts: 2
Joined: Mon Sep 15, 2025 10:42 pm
Been thanked: 1 time

experience with CG5317 and OpenV2G so far

Post by majbthrd »

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).
majbthrd
Posts: 2
Joined: Mon Sep 15, 2025 10:42 pm
Been thanked: 1 time

Re: experience with CG5317 and OpenV2G so far

Post by majbthrd »

For completeness (and it case it helps someone else), I posted the source code here:

https://github.com/majbthrd/V2Gredux

The values in parameters.h can be adjusted, such as the EVSEMaximumVoltageLimit used in the ChargeParameterDiscoveryRes message.
User avatar
johu
Site Admin
Posts: 7182
Joined: Thu Nov 08, 2018 10:52 pm
Location: Kassel/Germany
Has thanked: 552 times
Been thanked: 1914 times
Contact:

Re: experience with CG5317 and OpenV2G so far

Post by johu »

Much appreciated.
You can check if OpenV2Gx hosted on uhi22 github suits as a submodule
Support R/D and forum on Patreon: https://patreon.com/openinverter - Subscribe on odysee: https://odysee.com/@openinverter:9
Post Reply