openinverter forum

Not sure how big an achievement it is but I managed to run https://github.com/uhi22/OpenV2Gx on linux. Just had to replace "-ansi" by "-std=c99" in the various subdir.mk and add main_commandlineinterface.* to test/subdir.mk lists

Maybe could have just installed eclipse to achieve the same

UPDATE: also runs on beaglebone

Maybe should bring some stuff to Sweden, there is a charger just 50m down the road to where we live. And it's a tiny village and the charger will sit mostly unused. Only downside: it will be mostly -20°C

EDIT: this is my post # 2^12 - sure that's a blessing

Thanks for the feedback, in the meanwhile the compile issue on linux should be fixed, I tried on two different Raspberries yesterday. Could you try again with the latest sources? Added a manual which explains how to install on Raspberry: https://github.com/uhi22/pyPLC/blob/mas ... spberry.md

https://www.goingelectric.de/wiki/CCS-T ... e-Details/ any useful information in here?

Yes, it is worth to read the references mentioned there. I collected them while I started with the CCS investigations.

Status update: On ABB charger, was able to get a TCP connection and to talk some EXI sentences with it. Details here: https://github.com/uhi22/pyPLC#2022-11- ... eryrequest

Great progress!

uhi22 wrote: ↑Mon Nov 21, 2022 6:30 am Thanks for the feedback, in the meanwhile the compile issue on linux should be fixed, I tried on two different Raspberries yesterday. Could you try again with the latest sources? Added a manual which explains how to install on Raspberry: https://github.com/uhi22/pyPLC/blob/mas ... spberry.md

yes, compiles without modifications now, great

Added some pictures of the real-world tests in https://github.com/uhi22/pyPLC/blob/mas ... ardware.md

uhi22 wrote: ↑Wed Nov 30, 2022 11:22 am Added some pictures of the real-world tests in https://github.com/uhi22/pyPLC/blob/mas ... ardware.md

That looks awesome. Do you actually have 1) a CCS vehicle 2) a CCS charger?

I'm rather hands off this project at this point, but please do post if you have any questions of difficulties with the protocol and want to talk through it.

Yeah, this is a very helpful and focused forum here, I'll keep it up-to-date with the progress on the one hand, and with the blocking points on the other hand. Thanks for the great support.

At the moment, the only really blocking point is: If I want to "sniff" the traffic between the real car and real charger, I'm able to set the key in the "sniffer" homeplug modem, and the network is formed. This is confirmed by sending a GetSoftwareVersion request, which is responded by three modems (charger, car, sniffer) correctly. So far so good. But the TCP traffic is not visible for the sniffer, I guess because it is too intelligent, it knows that the traffic is not intended for the sniffing notebook. This is a known behavior also for Ethernet switches, they learn the MAC addresses and do not forward traffic to ports which are not related to the destination MAC. I did not find a method, to configure the modem to just route everything from the RF port to the Ethernet port. That's why, the SnifferMode part of the project is stuck. Any idea welcome.

And yes, I have an CCS vehicle (Hyundai Ioniq classic model year 2016) since some years, and we have a lot of public CCS chargers in 10 minutes driving distance, with many different brands. So testing is possible, the only limit is that I do not really plan to make a hardware design which would handle the power-electric aspect. This is the point, where any contribution from interested people is highly appreciated.

Today was the first time, when I was able to get some power from an Compleo 50kW triple charger. Used a 230V light bulb as load, the TPlink as modem, an arduino for switching the CP state, and the laptop as controller. The auto-ranging multimeter was not able to deal with the 400V DC, it shows "overload". But the bulb survived the voltage. The plan was, to NOT connect the bulb during the cable check, but by mistake it was turned-on already. Later, the PreCharge tries to rise the voltage, but this aborts at around 90V. I would say: Milestone "Concept proof" is reached Time to celebrate and concentrate on the xmas holidays
PS: Version 0.4 released, see https://github.com/uhi22/pyPLC/releases/tag/v0.4

PS: Without the light bulb, the PreCharge reaches the intended 230V:

uhi22 wrote: ↑Tue Dec 13, 2022 9:11 pm Today was the first time, when I was able to get some power from an Compleo 50kW triple charger. Used a 230V light bulb as load, the TPlink as modem, an arduino for switching the CP state, and the laptop as controller. The auto-ranging multimeter was not able to deal with the 400V DC, it shows "overload". But the bulb survived the voltage. The plan was, to NOT connect the bulb during the cable check, but by mistake it was turned-on already. Later, the PreCharge tries to rise the voltage, but this aborts at around 90V.

This is absolutely amazing. Congratulations and thank you!

It's a pleasure! Thank you for initiating this thread and pointing me into the right direction

Question to the high-voltage-experienced guys: Would the small contacts of a 230V/16A-AC-relay survive the switching of 230V/0.5A DC? I'd like to control the light-bulb with relay, but I think the arc will kill the contacts

Congratulations on some excellent work

On the relay if you can find the data sheet there should be a graph showing the max switching current against DC and AC voltage. If you have a particular relay in mind let me know and I can check.

All the high voltage experienced guys have their cabinets filled with various sizes of DC contactors...

Well, do you have a 400VAC rated relay or contactor handy? That's probably the minimum I'd use. Just to get more than one use out of it.

EDIT: Of course if you're only closing the contacts after the insulation test and precharge and leave them closed until the charger stops, then I think a 230VAC relay will handle it. Most of the problem with DC happens when opening contacts, not when closing them.

uhi22 wrote: ↑Wed Dec 14, 2022 10:34 am Question to the high-voltage-experienced guys: Would the small contacts of a 230V/16A-AC-relay survive the switching of 230V/0.5A DC? I'd like to control the light-bulb with relay, but I think the arc will kill the contacts

As others have said, the contacts are switching rated. So if you close when the voltage is 0V and only open when the voltage is gone any relay could do it.

The issue is opening under load, it causes erosion due to sparking, and potentially a plasma bridge that does not extinguish due to the voltage not passing 0 like in AC application.

This is some great developments, I wish I was a bit more knowledge able in the field of computer programming instead of the lower level micro controller programming.

Well given this particular use case I think he wants to switch on at 230VDC, when the charger has precharged its output, and open at 0V after the charger has stopped. IMO that will work.

If the 230VAC relay is opened at 230VDC, you might get a long internal arc and smoke and melted plastic. Or it might work just fine. You really only know once you test it. The current will definitely stop at the end though. It's only a matter of how much black nasty melted stuff you get before it happens.

Of course it would have been a lot wiser to just ask someone to donate a contactor a long time ago.

Just as a demo, I want to use a 230V/40W bulb, and disconnect it during the CableCheck and PreCharge phase (because the charger could be angry when seeing an ohmic load in this phase). After charger is finished with the PreCharge, I'd tell him a CurrentDemand with limits 230V and 2A, and then turn-on the relay for the bulb. And ramp the voltage down by terminating the charging session, before opening the relay. Means: The relay will see the inrush of bulb (no problem I think) and will not open while current is flowing. So, my cheap chinese blue relay (is rated only 10A/250VAC, not 16A as I originally guessed) has a chance to survive. But Murphy will be with me, and the relay will open while the bulb is on. And this will most likely lead to smoke. I will try. It will be outside, and the thing was cheap, so no really loss. A transparent housing would be nice to make a video Thanks so far.

uhi22 wrote: ↑Tue Dec 13, 2022 9:11 pm Today was the first time, when I was able to get some power from an Compleo 50kW triple charger. Used a 230V light bulb as load, the TPlink as modem, an arduino for switching the CP state, and the laptop as controller. The auto-ranging multimeter was not able to deal with the 400V DC, it shows "overload". But the bulb survived the voltage. The plan was, to NOT connect the bulb during the cable check, but by mistake it was turned-on already. Later, the PreCharge tries to rise the voltage, but this aborts at around 90V.

Charger release max HV during CableCheck, so your light bulk will be light up. Precharge will normally lower the voltage according to EV request.

As for the relay, as long as you control power draw from the charger (VxI) to be within rated spec of the relay and never open contact while there still current flow this should be fine. If somehow you fail this, depending on the current it will destroy contact.

I would suggest you run the complete session till the SessionStopReq, use stop session button on EVSE (not the emergency button). This should represent normal shutdown. I will help analyze the capture file.

Forgot to mention, I see in your pcap file, the last message is PreChargeRes which contain EVSEStatusCode = EVSE_EmergencyShutdown. Not sure why your setup trigger this emergency shutdown.

Thanks for this deep review. Yes, this is one of the open questions. Maybe the charger was irritated by the connected bulb during cable check and precharge. Or maybe I had an issue with the power bank (sometimes it seems to shortly drop), and so the CP changed to B and back to C due to restart of the Arduino. Will first make my setup more reliable, before hunting potential ghosts from software side.
Stopping the session should also work from the PEV software side, if I say Powerdelivery=stop, and then SessionStopReq. I expect the charger will turn the power off, and then I can open the relay.

Added the voltage measurement for the inlet voltage, with an arduino pro mini, supplied by a 5V-to-5V-DC/DC converter, and sending this via a PC900V optocoupler to the serial-to-USB. Also added relay control with a second arduino. We see here, that the CableCheck applies 500 volts. Also the PreCharge voltage is correctly shown.

The actual questionmark is, why the charger rejects the CurrentDemandRequest with FAILED_SequenceError and EVSE_Shutdown. At the moment I did not find an obvious reason. Data in https://github.com/uhi22/pyPLC#2022-12- ... tage-works and https://github.com/uhi22/pyPLC/blob/mas ... ecoded.txt and https://github.com/uhi22/pyPLC/blob/mas ... own.pcapng

Potential root cause for the SequenceError: The meaning of PowerDeliveryReq.ReadyToChargeState is not clear. I guessed, but this could be wrong guess, because I do not have the DIN70121. Will go the trial-and-error way and test with exchanged interpretation.

After fixing the above mentioned issue, the bulb-demo-charging works on 3 of 4 charger models. Version 0.5 released.

This is such amazing groundwork.
Also cool how precise the chargers actually follow your voltage request. Wouldn't have surprised me had it popped your bulb because that's really a corner case.
I wonder for an embedded implementation if it's worthwhile storing pre-computed EXI blobs in a lookup table?

uhi22 wrote: ↑Tue Dec 20, 2022 6:40 pm Potential root cause for the SequenceError: The meaning of PowerDeliveryReq.ReadyToChargeState is not clear. I guessed, but this could be wrong guess, because I do not have the DIN70121. Will go the trial-and-error way and test with exchanged interpretation.

You do have a copy of ISO 15118-2 though, right? Is DIN70121 an older version?