Open source CCS using AR7420

[celeron55]

Shows my crappy SoC calculation a bit too well! I have some fixes to it underway. I don't have much time for focusing on that now though. Anyway, graphs are nice.

[celeron55]

2023-05-12_152_kempower_m.zip

(1.44 MiB) Downloaded 323 times

- The original Kempower
- On the first attempt charging didn't start, but on the second attempt it charged fine. I wonder what the issue was on the first attempt, haven't had time to look yet.

2023-05-12_163352_tesla_k.zip

(1.67 MiB) Downloaded 401 times

- Multi-minute Tesla V2 Supercharger session. No problems anymore. This would be thanks to not sending DHCP requests anymore, maybe.

2023-05-12_170340_alpitronic_k.zip

(501.99 KiB) Downloaded 363 times

- Well this is just an Alpitronic. Another similar unit worked previously but this works too.

2023-05-12_174912_siemens_k.zip

(603.24 KiB) Downloaded 369 times

- This is the Siemens with the built-in home cinema display. It worked this time. I think the coupling network changes fixed this one.

2023-05-12_181852_abb_h.zip

(416.95 KiB) Downloaded 342 times

- This is the first time ABB CCS worked. I think this also is thanks to the coupling network changes.

[uhi22]

Hm, strange. The first, failed attempt on the Kempower says: "CableCheck lasted too long. 31 Giving up.". The charger correctly responds to the cableCheck requests, and says "Ongoing" all the time, also with the correct "EVSE_IsolationMonitoringActive". Seems it really wants to check the cable intensively, for more than 30s. The pyPlc gives up. Just found, that (at least for ISO) the allowed time to report "ongoing" is 55s, and the specified timeout 60s. Means: The charger is in spec, if it would need 55s for cableCheck. I will increase the timeout.

[Edit] Done: https://github.com/uhi22/pyPLC/commit/0 ... 6774f7344a

[johu]

Can't add anything productive, just want to say: pure awesomeness

[uhi22]

For the ones who like statistics (like me ), extended the pcapConverter to measure the times for cableCheck and precharge.
The winner is clearly the Tesla, they just know that waiting for power makes a bad feeling

Code: Select all

# statistics for ../temp\2022-12-21_ABB_HPC_with_bulb_chargeOk.pcapng
e8:eb:1b:1a:e4:7e;Microchip (maybe ABB);timeForCableCheck;14.819;timeForPreCharge; 9.616
# statistics for ../temp\2022-12-21_westpark_alpi_charge_ok_with_bulb.pcapng
1a:a9:8e:f0:dd:66;Alpitronic;timeForCableCheck;15.658;timeForPreCharge; 8.872
# statistics for ../temp\2023-05-11_205813_tcpdump.pcap
ec:a2:9b:3a:fc:af;Kempower;timeForCableCheck;9.797;timeForPreCharge; 2.161
# statistics for ../temp\2023-05-12_152818_tcpdump.pcap
ec:a2:9b:27:a4:0e;Kempower;timeForCableCheck;14.507;timeForPreCharge; 2.297
# statistics for ../temp\2023-05-12_163352_tcpdump.pcap
dc:44:27:1f:c1:db;Tesla;timeForCableCheck;4.842;timeForPreCharge; 2.078
# statistics for ../temp\2023-05-12_170340_tcpdump.pcap
ce:25:1a:63:5c:45;Alpitronic;timeForCableCheck;14.564;timeForPreCharge; 1.876
# statistics for ../temp\2023-05-12_174912_tcpdump.pcap
18:d7:93:b0:1e:af;(maybe Siemens);timeForCableCheck;17.390;timeForPreCharge; 3.840
# statistics for ../temp/to_decode\2023-04-19_compleo_pyPlc_lightbulb_failedBadRegulation.pcapng
80:1f:12:e8:e6:47;Microchip (maybe Compleo);timeForCableCheck;9.937;timeForPreCharge; 3.853
80:1f:12:e8:e6:47;Microchip (maybe Compleo);timeForCableCheck;10.499;timeForPreCharge; 3.142
# statistics for ../temp/to_decode\2023-05-12_181852_tcpdump.pcap
68:27:19:90:11:b6;Microchip (maybe ABB);timeForCableCheck;16.447;timeForPreCharge; 3.749

[celeron55]

As always, when you add Tesla to the equation you start asking whether the others are even trying. I really like the combo of Tesla + an open standard.

[uhi22]

Added now celerons starter script, which makes the perfect pairs of pcap and log per session, also updated a little bit the "how to install on raspberry". Added the auto-terminination of the script also when the TCP connection breaks, so that I do not need hardware-plug-detection. Now have on the raspberry nice per-session-logs as celeron proposed.
Needed to modify the starter.sh, because the Raspberry seems to have the NetworkManager off. Also pathes are hardcoded. Is there a chance to make such things configurable?

[celeron55]

It might make sense to just use paths relative to the script file location. Do this at the beginning of the script:

Code: Select all

dir="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"

And then just use paths like "$dir"/log/$date"_pevNoGui.log

Then the paths will be correct even if the script is called without first using "cd" to the script location. Or even more simply one could just do

Code: Select all

cd "$( dirname "${BASH_SOURCE[0]}" )"

at the beginning of the script and then the working directory will be the script's directory.

EDIT: BTW, set -euv makes it so that
- e: any failing statement exits the script with status 1,
- u: this was some sort of thing about undefined variables or something
- v: this prints the script itself as it's being executed
I use this often as it makes error handling and debugging easier.

[celeron55]

2023-05-14_150855_circontrol_r.zip

(23.95 KiB) Downloaded 364 times

- Circontrol 50kW CCS+Chademo combo unit works now.

2023-05-14_15_delta_r.zip

(62.72 KiB) Downloaded 274 times

- This is a 100kW Delta charger (Delta SLIM 100 seems to match what it looked like)
- It communicates but wouldn't start charging
- It is a dual CCS unit and I tried both CCS plugs
- Information on the display of the unit didn't seem useful. It literally said "Oops!" or something like that, and that seemed to not even be in sync with anything that was happening on the CCS comms.
- I have no idea if the unit actually works or not
- I adjusted some timeout between attempts but it did not help

[CCSknowitall]

In your Delta pcap, the second attempt looks like the station responded with failed negotiation… why, I have no idea, but your logs show accepted and moving onto the next step. You should exit out here instead of continuing.

First attempt my only guess is part of the charger state machine got messed up with how long the SLAC process was taking. You seem to go back and forth a ton checking/setting the key. These messages are not common with regular EVCCs in my experience.

[uhi22]

In your Delta pcap, the second attempt looks like the station responded with failed negotiation… why, I have no idea, but your logs show accepted and moving onto the next step. You should exit out here instead of continuing.

Are you referring to 2023-05-14_151512_tcpdump? Here I see that the charger sends ContractAuthenticationResponse with

Code: Select all

"ResponseCode": "OK",
"EVSEProcessing": "Ongoing"

This looks like the normal case, when the user did not yet present the RFID card. That's why the pyPlc repeats the request, and does not get a response anymore. So from this understanding, the charger makes the fault, because it does not send any response. Maybe not all data is correctly decoded, so do you see more, especially a hint in the ContractAuthenticationResponse that there went something wrong and we have to abort? In the pcap we see, that the TCP connection is broken at this time, the pyPlc sends the request, but the TCP does not get an ACK from the chargers TCP, and so the TCP retries the request without success. Finally the pev state machine runs into timeout.

(Also in 2023-05-14_151655_tcpdump the same issue: Charger responds two times correctly with ContractAuthenticationRes, but does not answer further requests.)

[uhi22]

Finished some automated tests regarding the reaction in case of errors. Version 0.8 released: https://github.com/uhi22/pyPLC#2023-05-22-v08-released

[grgumxlm]

I got a single Devolo Powerline 200+ MT2710 in preparation for viewtopic.php?p=54814#p54814 . I dont have a CCS capable car.
I used the Devolo software to reset to factory defaults like recommended here https://www.goingelectric.de/wiki/CCS-T ... e-Details/ . The firmware Version of the Devolo MT2710 reported by the Devolo software is 4.4.0.05 . I have seen version 4.4.0.5 as latest firmware update for other Devolo 200Mbit devices. So i expect to be the latest one Devolo released for this device series.

The Atheros Chip is AR6400-AC30. The PCB have 81790F and E173761 written on it.

The pictures are dual-licensed CC-BY-SA 4.0 and GPL V3.0 and can be used here (MT2710 is unlisted at the moment there) https://github.com/uhi22/pyPLC/blob/mas ... ardware.md

My first goal is to reproduce this setup:
viewtopic.php?p=53848#p53848
In the setup the TP-Link is been used. Is there a special reason why?

[uhi22]

The only reason is, that catphish started the investigations with this type of adaptor, and found out, that it is perfectly what we need. Maybe other adaptors with other chips than the AR7420 work as well, but we do not know. I just made a test with the Devolo dLAN 200 AVplus, which contains an INT6400A1G, with software INT6000-MAC-4-4-4405-00-4497-20101201-FINAL-B and unchanged parametrization. This worked perfect here as pev, with an TPLink/AR7420 on the other side as EVSE. This means, I see good chances that your adapter should work.

[gan2887]

great project this is. hats off to all of u. especially uhi22 and celeron55.
Hi @uhi22 , could u help show me directly the EVSE circuit described as "and the poti on left border to select 5% PWM." in your https://github.com/uhi22/pyPLC/blob/mas ... vseMode.md ?

I just could not wrap my head around which part of the circuit is this at https://www.instructables.com/Arduino-E ... ng-Station

And the code sketch below is looking for a +6Vdc square wave in State C?
This State Cwill be initiated by the car after EVSE responded with a 1kHz PWM in State B?

if (nAdcPoti<512) {
/* left side -> digital communication, 5% PWM */
I_Lade_Soll_A = -1;
} else {
deltaI = nAdcPoti-512; /* right side of poti, scaled 0 to 511 */
deltaI/=51; /* right side of poti, scaled 0 to 10 */
I_Lade_Soll_A = 5 + deltaI; /* minimum value 5A, maximum 15A */
}

Many thanks!

[uhi22]

Ohh, yes. That's really bad documented. The Poti is an add-on from my side, it is not contained in the original https://www.instructables.com/Arduino-E ... ng-Station. It is just a poti between 5V and ground, connected to analog input A2.

The snipped you posted is the poti evaluation, not the stateC evaluation. The poti evaluation is used to distinguish the cases "digital communication" (which leads to 5% PWM) and "analog communication" (where the target current is coded as PWM ratio. The I_Lade_Soll_A is the target charging current in ampere, for the analog case.)

The transition from stateB (PWM between +9V and -12V) to stateC (PWM between +6V and -12V) is done by the car, when it requests power. In an analog EVSE for AC charging, the EVSE would detect this and use it for closing the big AC relay. In the DC case, at the moment this information is not used by pyPLC. I just have the LED on the EVSE, which changes from yellow to blue, but no other purpose of this detection.

[gan2887]

Thanks uhi22 for your reply. If that's case, i hv below questions: I'm trying to emulate as a DC EVSE.
1. In the arduino code snippet, i can define my own voltage (and obviously the cct to go with it) to trigger the code to send out 5% PWM?
2. A2 is not connected to any type 2 pins? eg. CP
3. At which State do you send out the 5% PWM? I can see your code only do this in State B or C, am I correct?
Thanks.

Ohh, yes. That's really bad documented. The Poti is an add-on from my side, it is not contained in the original https://www.instructables.com/Arduino-E ... ng-Station. It is just a poti between 5V and ground, connected to analog input A2.

The snipped you posted is the poti evaluation, not the stateC evaluation. The poti evaluation is used to distinguish the cases "digital communication" (which leads to 5% PWM) and "analog communication" (where the target current is coded as PWM ratio. The I_Lade_Soll_A is the target charging current in ampere, for the analog case.)

The transition from stateB (PWM between +9V and -12V) to stateC (PWM between +6V and -12V) is done by the car, when it requests power. In an analog EVSE for AC charging, the EVSE would detect this and use it for closing the big AC relay. In the DC case, at the moment this information is not used by pyPLC. I just have the LED on the EVSE, which changes from yellow to blue, but no other purpose of this detection.

[uhi22]

1. For just having always a DC EVSE, you can set nAdcPoti=0 before the code block above. This should lead to the 5%.
2. Exactly. A2 is just a Poti in my EVSE, where the user can select between DC EVSE (left side of the poti range) or select the current for AC EVSE (right side of the poti range).
3. The 5% PWM starts, when the EVSE detects 9V on the CP line. This is the point, when the connector is plugged into the car, and the resistor on car side pulls the originally 12V down to 9V. Or in other words, it is the point where StateA changes to StateB. That's the same point in time as for the AC EVSE, only the PWM width is different.

[gan2887]

I hope the below are my last few questions to clarify
I plan to hack a GBT DCFC to convert it to a CCS2 plug. Starting with a 15-20kW model.
The electronics I'm planning to make are
a. the SECC side resistor-voltage control to respond to the EVCC as well as the PLC DC comm (sort of a front end of the DCFC)
b. the bridging controller to control the DC-DC converter that came with the GBT DCFC.
The motivation of this project: GBT DCFC is almost half the price of CCS2 DCFC at the same power ratings buying from China. Due to this and the situation in my country, owning and running an EV with CCS2 port is actually much more expensive than going petrol, especially traveling inter-state. And also due to this high pricing of CCS2 DCFC, there are very few along the inter-state highway which results in a longer travel time because of queues at the DCFC.

The last few questions I seek clarifications:
Q1. In the mod of the TP-PA4010, which component is connected to CP and PE respectively? the 1nF and 150ohm.
Q2. When the CP is in 1kHz 5% PWM, how is this waveform signal sync up by the TP-PA4010 RF port modded above?
Q3. Wonder if the SECC in the DCFC needs to have your DieterHV to switch ON the HV relay contactors to make the connection to the EVCC side DC+- pins?

If I'm successful in this project, let's see if I have time to document my journey in another board thread.
So that perhaps somebody can mass produce this using much cheaper chipsets that will support finally owning and running a CCS2 EV can be affordable.
Many thanks again for your very prompt replies.

[uhi22]

For Q1: Between the CP and the PE, there is the series of tree components: The 1nF, the 150ohm, and the secondary coil of the RF transformer. The order does not matter, also the polarity not. This means, to remove all parts on the TPlink which are connected to the secondary coil of the RF transformer, and connect the 1n and 150ohms to it.

For Q2: There is no sync between the 1kHz PWM and the homeplug traffic. In worst case, the PWM edges may disturb the homeplug packets. It may make sense to add a kind of low-pass filter at the output of the square wave. I have no real experiences in this direction, I just added a serial L, but not sure whether it is really needed.

For Q3: Regarding the power-relay in the charger, I have no experiences. Basically it needs the possibility to avoid voltage on the plug, not sure whether this needs a relay. What it definitely needs is some circuits to fulfill the cable check and the precharge. I do not have details regarding this.

[Bigpie]

Is anyone working on something like a Raspberry Pi shield/Hat type for the CP, contactor control locking actuator etc? Don't want to repeat efforts

Also looking at HV measuring MAX22530 looks to be useful as it's pretty integrated with an SPI interface.

[peternooy]

For Q3: Regarding the power-relay in the charger, I have no experiences. Basically it needs the possibility to avoid voltage on the plug, not sure whether this needs a relay. What it definitely needs is some circuits to fulfill the cable check and the precharge. I do not have details regarding this.

A DC contactor or power diode is normally used for this, it will
- protect the chatger from harmfull external voltage
- able to perform welding detection if requested

[Bigpie]

Done a bit of work on my prototype, the Pi hat has CP control and contactor control, the pi's GPIOs working nicely.

Not got a CCS socket yet, but next up, I need to get my head around MAX22530 for isolated SPI voltage measuring.

[uhi22]

Nice The experience shows, that the voltage measurement is overrated, it also works without, by just relying on the EVSEPresentVoltage which is reported by the charger. Your setup looks like quite ready for the light-bulb-demo

[Bigpie]

Maybe I'll do without in that case. Once I get a CCS socket I'll post some logs. As I'm not using any serial devices I've got the console on serial so I don't have to setup WiFi away from home