Open source CCS using AR7420

Development and discussion of fast charging systems eg Chademo , CCS etc
User avatar
uhi22
Posts: 554
Joined: Mon Mar 14, 2022 3:20 pm
Location: Ingolstadt/Germany
Has thanked: 83 times
Been thanked: 392 times

Re: Open source CCS using AR7420

Post by uhi22 »

For the log2, this is what I also observed on a compleo charger: If a load is connected during the PreCharge, the charger is not able to reach the target voltage. This makes sense, because the precharging uses assumingly a very limited current.

For the log1, the precharge is finished, we send PowerDeliveryReq, but get no response from the charger. Possible root cause ideas: We send wrong data in the PowerDeliveryReq, or the timing is wrong, or - my favorite - the switching to CP state C did not work, and the charger rejects the power delivery due to wrong CP state.
User avatar
johu
Site Admin
Posts: 5684
Joined: Thu Nov 08, 2018 10:52 pm
Location: Kassel/Germany
Has thanked: 153 times
Been thanked: 960 times
Contact:

Re: Open source CCS using AR7420

Post by johu »

Hmm, I tested CP switching with my granny cable. Not with your code but a command line python doing the same thing.
PP is not connected anywhere, could that be an issue?

Speaking of which:
Support R/D and forum on Patreon: https://patreon.com/openinverter - Subscribe on odysee: https://odysee.com/@openinverter:9
User avatar
uhi22
Posts: 554
Joined: Mon Mar 14, 2022 3:20 pm
Location: Ingolstadt/Germany
Has thanked: 83 times
Been thanked: 392 times

Re: Open source CCS using AR7420

Post by uhi22 »

No, in all my tests I did not connect the PP, and this had no negative influence.
For testing the CP circuit at home, a possibility is to connect 12V to CP via 1k resistor, and measure the voltage with multimeter. This should give 9V in idle state. And when running

Code: Select all

python hardwareinterface.py
it should change to 6V when StateC is active.
User avatar
uhi22
Posts: 554
Joined: Mon Mar 14, 2022 3:20 pm
Location: Ingolstadt/Germany
Has thanked: 83 times
Been thanked: 392 times

Re: Open source CCS using AR7420

Post by uhi22 »

Oh, just noticed that for the Compleo charger I do not have a log which confirms that the PowerDelivery works. I have an open issue in my list regarding this topic, https://github.com/uhi22/pyPLC/blob/mas ... ing-fsmpev. At the moment I do not have an idea why the compleo has a problem with this PowerDeliveryRequest. Other chargers work fine with it. Would be really great to have a full log of a successful session of an original car which uses DIN. Does in the meanwhile anybody know how to setup the homeplug adaptors into "promiscuous" mode, so that they route all homeplug traffic to the ethernet port? If this would work, it would be easy to make a trace of original car on original charger...
User avatar
uhi22
Posts: 554
Joined: Mon Mar 14, 2022 3:20 pm
Location: Ingolstadt/Germany
Has thanked: 83 times
Been thanked: 392 times

Re: Open source CCS using AR7420

Post by uhi22 »

Two good news and a bad one.

Bad news first: The PowerDeliveryRequest, which is ignored by the Compleo, seems to have a format problem. At least, the message of the Ioniq is two bytes longer than the message of the pyPlc. On first look I did not find the relevant difference in the content. The short (pyPlc, fail): 809A0201E224253E54D0BA513222800A0800. The longer (Ioniq, ok): 809A02004080C1014181C2113222000006C00000.

Good news one: The ESP32 variant successfully passed the light-bulb-demo on alpitronics charger. Used johus "screwed on wood" design :-)
image.png
Good news two: While trying to understand the PowerDeliveryRequest issue, I gave a try and pretended a precharge to my Ioniq car. Without any physical voltage applied to the DC pins, just sent a simulated rising EVSEPresentVoltage to it. And: Baaang!!! The car closed the contactors. I have let it run for several minutes, the car does not run into timeout. Good basis to try to draw energy out of the car.
image.png
image.png
mikejh
Posts: 16
Joined: Tue Feb 04, 2020 1:38 pm
Has thanked: 1 time
Been thanked: 2 times

Re: Open source CCS using AR7420

Post by mikejh »

catphish wrote: Wed Apr 05, 2023 9:55 pm Not exactly on the topic of this thread, but I just noticed that it's now possible to buy a low cost Homeplug Green PHY.

https://www.mouser.co.uk/ProductDetail/ ... c7eA%3D%3D

This thing only costs £12 and it appears to have an SPI interface that supports network comms.

Worth spinning a board?

This looks really good but do you think the NDA will be a problem for open source?
The datasheet that you get from Mouser of Digikey is just a brochure... :cry:
Attachments
image.png
image.png (6.45 KiB) Viewed 9571 times
User avatar
uhi22
Posts: 554
Joined: Mon Mar 14, 2022 3:20 pm
Location: Ingolstadt/Germany
Has thanked: 83 times
Been thanked: 392 times

Re: Open source CCS using AR7420

Post by uhi22 »

Regarding the "wrong formatted" PowerDeliveryRequest, the difference is, that the Ioniq sends three "optional" fields, and the pyPlc did not do this. Maybe these fields are not really optional, and certain chargers rely on them. I updated the EXI encoder accordingly; now the message has the same length as in the Ioniq. Here it is: https://github.com/uhi22/OpenV2Gx/commi ... d551f3e14d
User avatar
johu
Site Admin
Posts: 5684
Joined: Thu Nov 08, 2018 10:52 pm
Location: Kassel/Germany
Has thanked: 153 times
Been thanked: 960 times
Contact:

Re: Open source CCS using AR7420

Post by johu »

Going to the UK tomorrow so won't be able to test on the Compleo charger for two weeks. I do take the entire test setup with me though and maybe will have a chance to test more in the UK.
Support R/D and forum on Patreon: https://patreon.com/openinverter - Subscribe on odysee: https://odysee.com/@openinverter:9
davefiddes
Posts: 211
Joined: Mon Jan 18, 2021 12:39 pm
Location: Edinburgh, Scotland, UK
Has thanked: 14 times
Been thanked: 35 times

Re: Open source CCS using AR7420

Post by davefiddes »

Apologies in advance if this is old news but I've not seen it mentioned. During Damien's BMW i3 project we managed to get a whole bunch of PCAP captures from successful and failed charger sessions (https://github.com/damienmaguire/BMW-i3 ... n/SPI_Caps) which might be useful.

Struck me when working on that project that it would be possible to build a real-time version of my logic analyser post-processing script. Something like an STM32 or Raspberry Pi Pico with a pair of HW SPI slave ports would be able to pick up both sides of the SPI bus, pick out the PLC packets and present them as a USB Ethernet interface for capture with Wireshark. It would neatly sidestep the need for network keys and the like.
User avatar
uhi22
Posts: 554
Joined: Mon Mar 14, 2022 3:20 pm
Location: Ingolstadt/Germany
Has thanked: 83 times
Been thanked: 392 times

Re: Open source CCS using AR7420

Post by uhi22 »

Thanks, this is basically very good news :-) However, trying to open the pcap files with wireshark fails, it says "The file "efcaec23.pcap" isn't a capture file in a format Wireshark understands." Maybe I missunderstood the idea. Did I get this right, you recorded SPI traces, and converted them into pcap? Are there different kinds of pcap? Which tool can be used to view it or further convert it, to extract the EXI payloads?

Edit: Sorry, I'm silly, I tried to download the pcap from github in the browser, but this gave me a html instead of the pcap. Now cloned the repo and the pcap is fine in Wireshark. Sorry for confusion.

Edit 2: This leads to the next question: Is there a free tool for reading the pcap and interpreting the EXI content? I found "V2G Viewer Pro", but this requires a license.

Edit 3: Interpreting the pcap files is easier than expected. There is a python library "pyshark", which does the magic. I combined this to the existing decoder (pyPlc/exiConnector, using openV2Gx), and now we have a small helper to make readable data out of the pcap files. Here it is: https://github.com/uhi22/pyPLC/commit/f ... b8d643f34f
Using this, I had a look to some of the efacec files, only see "middle of the charging loop", currentDemand, with mostly around 392V and 50A, stable SOC of 24 percent. Looks like a dummy-load-charging to me :-)
User avatar
uhi22
Posts: 554
Joined: Mon Mar 14, 2022 3:20 pm
Location: Ingolstadt/Germany
Has thanked: 83 times
Been thanked: 392 times

Re: Open source CCS using AR7420

Post by uhi22 »

mikeselectricstuff wrote: Sun May 22, 2022 2:27 pm I'm told that at least one car (ID4) can be convinced to close its contactors by initiating a dummy charge session. I imagine that in principle this could work with any CCS car, but some might time out or produce some other error, e.g. when it sees power flowing out and not in.
Nearly one year later, and the status is: Yes, at least the Hyundai Ioniq model year 2016 closes the contactors. I propose to split up a new thread for this (something like "Drawing power out of CCS port"), to avoid mixing to many topics in the AR7420 thread.

Edit: Created thread: viewtopic.php?p=55785#p55785
davefiddes
Posts: 211
Joined: Mon Jan 18, 2021 12:39 pm
Location: Edinburgh, Scotland, UK
Has thanked: 14 times
Been thanked: 35 times

Re: Open source CCS using AR7420

Post by davefiddes »

uhi22 wrote: Mon Apr 17, 2023 4:03 pm Using this, I had a look to some of the efacec files, only see "middle of the charging loop", currentDemand, with mostly around 392V and 50A, stable SOC of 24 percent. Looks like a dummy-load-charging to me :-)
A lot of the captures are mid-session. I think it was tricky for Damien to juggle running his VCU software, log CAN bus traffic, run a logic analyser capture and operate the charger.

The stable SOC and fixed charge current is because the setup he had was a hybrid BMW i3 LIM doing the PLC side of CCS but the high-level control was his VCU software which had certain hard-coded behaviours. Ideally what you'd want is a complete real vehicle where you could tap the PLC SPI comms. The eternal problem of what we do is that not many people are willing to have random wires soldered to their relatively new EVs...
User avatar
uhi22
Posts: 554
Joined: Mon Mar 14, 2022 3:20 pm
Location: Ingolstadt/Germany
Has thanked: 83 times
Been thanked: 392 times

Re: Open source CCS using AR7420

Post by uhi22 »

Finally, the issue with the missing response to the PowerDeliveryRequest on the Compleo is clear. It was most likely not the format, but the timing. The charger needs nearly one second to give the response, much slower than the other chargers which I tested. The timeout was also approx one second, so it came too early. Now increased the timeout, and got to the charging loop.

Unfortunately the voltage regulation of the Compleo is very bad. It overshoots to more than 400V, and undershoots when the bulb is turned on, and finally shuts down. (Edit: The Compleo itself seems to notice that it did a bad regulation, it sets DC_EVSEStatus.EVSEStatusCode = EVSE_EmergencyShutdown when it delivered 416V instead of the demanded 230V :-) )
I saw a similar behavior on the Ionity Tritium chargers, but also saw perfect voltage stability on alpitronics and ABB. The regulation issue is just bad for the experiments with bulb or no load, it should not harm if a real battery is connected.

Version v0.7 released as basis for further tests.
User avatar
celeron55
Posts: 774
Joined: Thu Jul 04, 2019 3:04 pm
Location: Finland
Has thanked: 27 times
Been thanked: 110 times
Contact:

Re: Open source CCS using AR7420

Post by celeron55 »

Went to a 50kW Tritium Veefil with the newest pyPLC. It seemed eager to give me voltage. This is a different charger brand compared to what I was testing on previously.

The HV terminals weren't connected to anything except the inlet voltage measurement board, which was sampled every 5 seconds (search for the "inlet_voltage=" lines)

Attached are logs, this time including the pcap log. (pcap is zipped as the forum doesn't allow attaching .pcap files)

To me it looks like the charger overshot the voltage by a huge margin (as there was no load whatsoever) and then ended the session because of that. Is that correct? Thanks in advance if anyone decides to look through the logs to see whether something's still subtly wrong.

I'm going to go ahead and start plumbing the HV.
Attachments
2023-05-02_155305_tcpdump.zip
(10.89 KiB) Downloaded 44 times
2023-05-02_155305_pevNoGui.log
(250.05 KiB) Downloaded 37 times
User avatar
uhi22
Posts: 554
Joined: Mon Mar 14, 2022 3:20 pm
Location: Ingolstadt/Germany
Has thanked: 83 times
Been thanked: 392 times

Re: Open source CCS using AR7420

Post by uhi22 »

Yeah, good progress :-) We really entering the charging loop without complaints, and stay there for more than one second. Until the charger says EVSEPresentVoltage=520V, together with EVSEStatusCode=EVSE_Malfunction. This is explainable, because the car requests EVTargetVoltage=230V, and the charger overshoots massively. I observed the same behavior on Tritium HPCs and Compleo. This should disappear if a real battery is connected.

Besides this, there is an inconsistency to be solved: During the precharge, the car requests 258V precharge voltage. This may be ok, if this is the accu voltage. But in the CurrentDemandRequest, the car requests 230V. This needs to be adapted, to have a higher voltage than the actual accu voltage. A simple solution for the beginning would be to just request a senseful "80%-full-voltage", and the current limitation (10A is fine for the beginning) would do a simple constant-current-constant-voltage charging.
User avatar
celeron55
Posts: 774
Joined: Thu Jul 04, 2019 3:04 pm
Location: Finland
Has thanked: 27 times
Been thanked: 110 times
Contact:

Re: Open source CCS using AR7420

Post by celeron55 »

Good catch. The target voltage during charging obviously needs to be something between the initial voltage and the maximum charge voltage of the battery. Looks like I have the real battery voltage already set for precharge.

I'll make sure to fix that before presenting an actual battery to the charger.
User avatar
celeron55
Posts: 774
Joined: Thu Jul 04, 2019 3:04 pm
Location: Finland
Has thanked: 27 times
Been thanked: 110 times
Contact:

Re: Open source CCS using AR7420

Post by celeron55 »

It looks to me in the log the Switching PowerRelay ON line comes way too late as the charger has already overshooted the voltage by that point and changed to a failed state.

EDIT:

Ah I have the lightbulb demo on...
User avatar
celeron55
Posts: 774
Joined: Thu Jul 04, 2019 3:04 pm
Location: Finland
Has thanked: 27 times
Been thanked: 110 times
Contact:

Re: Open source CCS using AR7420

Post by celeron55 »

Well. Set up the HV, but no luck anymore at the charger. Here are the log files I got. pcaps included for every session.

2023-05-03_015107_pevNoGui.log goes the furthest and there seems to be a precharge of sorts, but the charger doesn't actually output any voltage it seems, and it reports some kind of shutdown? "EVSEStatusCode_text": "EVSE_Shutdown" Eh?

EDIT: I wonder if there is a chance my battery voltage went below the charger's supported voltage as it now was 244V instead of 256V, and this is the way the charger tells me about it? I seem to recall 250V is a common minimum voltage for CCS, altough it makes almost no sense as this Chademo-CCS combo charger is perfectly capable of supplying under 250V on the Chademo side. What else can this response mean?

I did update OpenV2Gx from some older version to the newest one in between this attempt and the one I posted where the charger seemed happy. I didn't record the previous version though. If I look at .git/objects/ it seems the previous version might have been pulled on 2023-03-24, so it probably was 4b5df391d56e15b45652605fa7ad8a7712e2acaf (fix: more fields in ChargeParameterReq). I downgraded to that version and tried once. That's 2023-05-03_021710_.zip.

EDIT: Additionally I tested the newest OpenV2Gx on the same model charger that I did my original tests a month or two ago - a Kempower satellite. That's 2023-05-03_024.zip.
Attachments
2023-05-03_024.zip
(21.67 KiB) Downloaded 35 times
2023-05-03_021710_.zip
(8.07 KiB) Downloaded 31 times
2023-05-03_01.zip
(59.16 KiB) Downloaded 30 times
User avatar
uhi22
Posts: 554
Joined: Mon Mar 14, 2022 3:20 pm
Location: Ingolstadt/Germany
Has thanked: 83 times
Been thanked: 392 times

Re: Open source CCS using AR7420

Post by uhi22 »

Had a look to the 2023-05-03_015107, and some findings:
1. Good news: In the ChargeParameterDiscoveryResponse, the charger announces that its lower voltage limit is 50V (EVSEMinimumVoltageLimit). On other chargers, I saw 200V and 150V iirc. This means, the voltage is not the issue.
2. Bad news: Also in ChargeParameterDiscoveryResponse, we get EVSEStatusCode_text = EVSE_Shutdown. Reason is not clear.
3. Bug: After the charger reported the EVSE_Shutdown, still the pyPlc tries to continue, and even after timeout of the precharge, it tries to reconnect the TCP again and again, even if no charger modem is seen. Need to implement a clear failure reaction, to make transparent, that the charge process failed, and that only removal of the plug is the next senseful action.

In the 2023-05-03_021710, the ChargeParameterDiscoveryRequest runs into timeout after one second. This worked in 2023-05-03_015107, but also here the charger needs 950ms for a response, so nearly at the end of the timeout. This leads to finding:
4. Bug: The Timeout of the ChargeParameterDiscoveryRequest needs to be increased.

In the 2023-05-03_024020, same finding: The ChargeParameterDiscoveryRequest runs into timeout after one second. Same for 2023-05-03_024225.

[Edit] Pushed two quick, untested bugfixes, one for the timeout https://github.com/uhi22/pyPLC/commit/7 ... 620d8229fd and one for the unintended reconnection attempts https://github.com/uhi22/pyPLC/commit/5 ... 3e4cce9a82

[Edit2] Checked some of the other log files. They show different things where it stops, e.g. the SLAC is successfull, we send SDP request again and again and got no SDP response. Or an other case, the SDP and protocol handshake are fine, but no reponse for the SessionSetupRequest (2023-05-03_014359). This could be an internal hang-up of the chargers state machine, or a connection problem. In the end, the pyPlc needs an improvement to show clearly that the charging failed and the user needs to pull the plug, and plug-in again, so that the charger resets all its states and is ready for a fresh session.
User avatar
celeron55
Posts: 774
Joined: Thu Jul 04, 2019 3:04 pm
Location: Finland
Has thanked: 27 times
Been thanked: 110 times
Contact:

Re: Open source CCS using AR7420

Post by celeron55 »

Updated pyPLC and here's the resulting charging session from the Kempower (log and pcap).

What happens is that the charger starts charging (Epic :mrgreen:), but my hardware integration code decides not to close the CCS contactors because there is no inlet voltage. Closing them in that state is not safe - as far as I understand CCS chargers have no output diode. Without my additional HW integration code pyPLC would have closed the contactors and possibly welded them.

It appears a pyPLC timeout occurs during WaitForCurrentDemandResponse (a bit more than 1 second?), after which pyPLC... starts to search for a modem? All the while the actual charger was apparently displaying an ongoing charging session on its screen.

[55139ms] 11:WaitForPowerDeliveryResponse entering 12:WaitForCurrentDemandResponse
[55437ms] "EVSEStatusCode_text": "EVSE_Shutdown"
^ This is probably the charger's original response to *something* and the rest is just pyPLC being silly
[55544ms] "ResponseCode": "FAILED_SequenceError"
[56694ms] [PEV] from 12:WaitForCurrentDemandResponse entering 99:SequenceTimeout
[60751ms] [CONNMGR] ConnectionLevel changed from 100 to 5
[60752ms] [ModemFinder] Starting modem search

EDIT: The charger is overshooting my requested maximum of 270V first to 290V (on the EVSE_Shutdown message) and then to 430V. Does this matter? I'm not seeing that on the inlet though. Where is that voltage going? Why is it a charger internal value?

EDIT: The charger is saying "EVSEMaximumCurrentLimit.Value": "62", which is lower than my request of 100A. Does this matter?

EDIT: Here's a possible explanation: pyPLC moves too fast from WaitForPreChargeResponse to WaitForPowerDeliveryResponse. The CCS contactor needs to be closed during the precharge, before moving to requesting power delivery. Right? Basically the issue is that pyPLC isn't waiting for my hardware to actually close the contactor. So, during the instant that pyPLC requests closing of the contactor there might be voltage at the inlet (certainly is according to the charger), but by the time the request gets to my hardware, pyPLC has already moved to power delivery and the voltage has already dropped to 0 as a result of that.

EDIT: So what pyPLC needs to do is to take into account that closing the contactor takes time - just getting the coil current up and the physical contacts moving takes tens of milliseconds, so regardless of how fast the hardware integration layer is, the precharge step has to continue a bit after the contactor is activated.
Attachments
2023-05-03_125629_.zip
(31.49 KiB) Downloaded 39 times
User avatar
uhi22
Posts: 554
Joined: Mon Mar 14, 2022 3:20 pm
Location: Ingolstadt/Germany
Has thanked: 83 times
Been thanked: 392 times

Re: Open source CCS using AR7420

Post by uhi22 »

The EVSEPresentVoltage should be the same as the physical inlet voltage. If not, I guess something is wrong with the HV wiring or measurement.

The contactor shall be closed when this sequence is reached:
[55058ms] [PEV] PreChargeResponse received.
[55059ms] [PEV] EVSEPresentVoltage 245.0V, U_Accu 246V
[55059ms] [PEV] Difference between accu voltage and inlet voltage is small. Sending PowerDeliveryReq.

Maybe this is not implemented correctly, I was focused on the lightbulb-demo only in the past. You could add the logging of the physical inlet voltage at the same place, and check, whether all three voltages (TargetVoltage, EVSEPresentVoltage, physical inlet voltage) are the same. If this is fulfilled, the end of precharging is reached, we shall close the contactors and send the PowerDeliveryReq.
User avatar
celeron55
Posts: 774
Joined: Thu Jul 04, 2019 3:04 pm
Location: Finland
Has thanked: 27 times
Been thanked: 110 times
Contact:

Re: Open source CCS using AR7420

Post by celeron55 »

Check my latest edits. I think it will make sense to you?
User avatar
uhi22
Posts: 554
Joined: Mon Mar 14, 2022 3:20 pm
Location: Ingolstadt/Germany
Has thanked: 83 times
Been thanked: 392 times

Re: Open source CCS using AR7420

Post by uhi22 »

Yes, this perfectly makes sense. Need to introduce an additional state in between.
User avatar
celeron55
Posts: 774
Joined: Thu Jul 04, 2019 3:04 pm
Location: Finland
Has thanked: 27 times
Been thanked: 110 times
Contact:

Re: Open source CCS using AR7420

Post by celeron55 »

I hacked an additional getPowerRelayConfirmation(self) to hardwareInterface and made fsmPev wait for it to return True after calling self.hardwareInterface.setPowerRelayOn() before actually sending the power delivery request and starting the move to stateWaitForPowerDeliveryResponse. The nice thing about this is I can check the inlet voltage in hardware too to make sure my contactors are happy.

But of course a simple delay state or whatever will work. Or, I guess you can just not care and hope the voltage doesn't drift between pyPLC's contactor request and the contactor actually closing. (I wouldn't.)

But anyway...

I'm charging now. On the Kempower satellite, as I'm typing this. Now I'll stop the charging process and attach the logs here.

Well, lol, stopping the charge process from the charger didn't work. I stopped it instead by forcing the CP inactive state and 0 current request from the car side, which did the trick. But there's something to look at - I expect the charger probably indicated it wanted to stop but pyPLC didn't respond.
Attachments
2023-05-03_150144_.zip
(1.05 MiB) Downloaded 89 times
User avatar
uhi22
Posts: 554
Joined: Mon Mar 14, 2022 3:20 pm
Location: Ingolstadt/Germany
Has thanked: 83 times
Been thanked: 392 times

Re: Open source CCS using AR7420

Post by uhi22 »

Yeeeeaaah, time to celebrate the first pyPlc CCS charging. Congratulations :-)
Post Reply