Open source CCS using AR7420

[mhpev]

So we are talking about EVSE mode, and the possibility to control the power supply. Well, this use case is at the moment not implemented at all. The existing hardwareInterface.py is handling only the PEV side.

My proposal would be:
1. Create a new module hardwareInterfaceEvse.py, to avoid confusion by mixing PEV and EVSE. (Alternatively, use and extend the existing hardwareInterface.py)
2. In fsmEvse.py, in the init function (https://github.com/uhi22/pyPLC/blob/c26 ... se.py#L365), store the reference to the hardwareInterfaceEvse. In the state functions, e.g. https://github.com/uhi22/pyPLC/blob/c26 ... se.py#L210 call something like self.hardwareInterfaceEvse.setPowerSupplyVoltage(uTarget)
3. Give the new hardwareInteraceEvse to the init of the evse state machine, in https://github.com/uhi22/pyPLC/blob/c26 ... ker.py#L44
4. In hardwareInterfaceEvse.py, handle the serial communication, similar to the Dieter or Celeron device.

Thank you @uhi22 with the detailed explanation. This is really very helpful. I will go over the proposal suggested above and see how I can replicate it plus customize it to having a backend charge device. I was also looking at the smartEVSE and the work done on that side to see if I could use it but this seems like a better option to begin with. Thx.

[marwe]

Following your discussion and the linked projects like pyPlc with great interest! Keep up the good work!

Do you guys know any difference between the AR7420 and QCA7420? (Backgroud info and test setup: I am tinkering with EVSE PLC to read a PEV SoC which works great with a QCA7005 connected via SPI and a Renault Megane but when replacing the real vehicle with a QCA7420 (Fritz AVM 510e connected via ethernet) to a Pi running pyPlc in PEV mode, I am stucking because no answer is received to the SDP init broadcast message (looks like https://github.com/uhi22/pyPLC#2022-10- ... stablished but in addition I am able to observe the GET_SW.CNF messages from both modems on the Pi using wireshark) but it seems like you had success when using a AR7420 chip.) Thanks!

[mhpev]

I've used the QCA7005 as well as QCA47420 (TPlink hack) in EVSE mode with 2 cars Chevy Bolt and Kia EV6 and has worked with issues using pyPLC package from @uhi22

Not sure what the ARXXX is Atheros? if so, may be a pre-cursor to QCA as Atheros is now part of Qualcomm...

[johu]

One thing I didn't find in uhis readme was the PIB config for EVSE so dumping it here (found here)

Code: Select all

setpib evse.pib 74 hfid "EVSE"
setpib evse.pib F4 byte 2
setpib evse.pib 1653 byte 2

Everything else is identical to PEV config. Maybe worthwhile adding to readme? https://github.com/uhi22/pyPLC/blob/master/readme.md

[uhi22]

Yeah, this documentation is "a little bit hidden": the readme of pyPLC mentions the https://github.com/qca/open-plc-utils/b ... 05s15.html, and here we find

[Edit] Added the description in the readme: https://github.com/uhi22/pyPLC#configur ... lc-adaptor

[uhi22]

In viewtopic.php?p=64714#p64714 we are discussing, how the normal end of a charging session should look like. We have
- The last currentDemandRequest and Response
- The PowerDelivery(Stop) request and response
- The reduction of the charge current to zero
- The CP line change to stateB
- Opening the contactors
- The weldingDetectionRequest and Response, maybe in a loop (until what?)
- The sessionStopRequest and response
- The connector unlocking
The list is just one possible order, others are possible, but which is intended? E.g. when does the charger change to zero current, and what timing do we need to safely open the contactor at zero current?
Any idea welcome.

[mhpev]

Hi @uhi22 - I am now trying to move further by taking your ccs32 codebase and bring it up on an ESP32 (WT32-ETH01) board similar to what you've detailed on github. I won't be using a display (is this possible to use without display and if so any specific config changes I would need in that case?) Also, once I have it working against pyPLC EVSE sim mode I would like to start implementing EVSE sim on CCS32 (It may be challenging but want to reuse your approach on it by converting python code and build on the framework you've started). My goal is to have charger emulator and test with real EVs. Any guidance or advice is appreciated.
I didn't find much installation instructions on the ccs32 side in the github repo - hence any pointers to install/bringup the PEV side would be helpful.

[uhi22]

Sure it works also without display. The display is just a listener of the serial line, so it does not matter whether it is present or not. If you connect a serial terminal, you nevertheless see the "display" messages. You could turn the message off by commenting the content of hardwareinterface_showOnDisplay.
I think you're on the right way. The hardware setup for your case is basically the same as in pev variant:https://github.com/uhi22/ccs32/blob/mas ... 1_foto.jpg
Just make sure that for the use as evse you have a modem with the evse configuration loaded. And then you need to port the evse state machine from python, and replace the pevStateMachine by it.
The ccs32 is an arduino sketch, which just requires the arduino IDE and the board support for the WT32-ETH01 installed. And from hardware point of view, I needed to connect two buttons (reset and boot mode), to be able to flash, because my board did not bring these button with it.

[mhpev]

Sure it works also without display. The display is just a listener of the serial line, so it does not matter whether it is present or not. If you connect a serial terminal, you nevertheless see the "display" messages. You could turn the message off by commenting the content of hardwareinterface_showOnDisplay.
I think you're on the right way. The hardware setup for your case is basically the same as in pev variant:https://github.com/uhi22/ccs32/blob/mas ... 1_foto.jpg
Just make sure that for the use as evse you have a modem with the evse configuration loaded. And then you need to port the evse state machine from python, and replace the pevStateMachine by it.
The ccs32 is an arduino sketch, which just requires the arduino IDE and the board support for the WT32-ETH01 installed. And from hardware point of view, I needed to connect two buttons (reset and boot mode), to be able to flash, because my board did not bring these button with it.

Thank you very much! I was able to compile and flash the board without any issues... next step connect it to TP link modem flashed as PEV (have a pyPLC setup ready so will try it out and if everything works as expected, will start converting your EVSE state machine code from Python to ino. One more thing - for EVSE mode - doesn't it need to have TCP listener v/s client in PEV mode? Or will changes to state machine side take care of that. I was thinking it may impact the tcp.ino (unless it's taken care of).

[uhi22]

Fully correct. The evse needs to listen TCP, this needs to be implemented. There is a library lwip (light weight IP) which maybe can be used. And before TCP , it needs to listen and respond to the SDP (which is UDP).

[MustafaEmbedded]

hello everyone
First of all, I would like to thank everyone who supported this project.
When I run it in Evse mode, I get stuck on the chargeparameterdiscovery section and get an output like this.
[127458ms] [EVSE] Received ChargeParameterDiscoveryReq. Extracting SoC parameters via DC
[127478ms] [EVSE] responding (55bytes) = 01 FE 80 01 00 00 00 2F 80 9A 02 00 40 80 C1 01 41 81 C2 10 80 00 48 00 40 00 00 C0 C3 20 04 0C 0E 01 40 6 0 A1 84 06 06 06 00 20 60 A1 90 02 03 03 00 50 30 30 05 10
[127481ms] [EVSE] from 4 entering 4
[SNIFFER] EXI from 49154 to 15118 (36bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 10 71 90 00 00 08 E0 40 61 10 4E 04 07 0A 8C 30 10 20 50 88 27 12 80 50 00
[SNIFFER] EXI from 15118 to 49154 (47bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 10 80 00 48 00 40 00 00 C0 C3 20 04 0C 0E 01 40 60 A1 84 06 06 06 0 0 20 60 A1 90 02 03 03 00 50 30 30 05 10
[127519ms] connection closed
[127538ms] [EVSE] re-initializing fsmEvse due to broken connection
[127539ms] [EVSE] re-initializing fsmEvse
[127539ms] Trying to reset the TCP socket
I can't get to the precharge phase

Also, I would be very happy if you could help me with the old decoder point. For example, when I want to send the evsepresentvoltagevalue and evsepresentcurrentvalue values to the vehicle in cases where I add a button and end the charge, or start charging with RFID, or power on, what should I do in this decoder part?

[uhi22]

For analyzing such an issue, where the connection is closed unintentionally, an ethernet log would be of much help. This can be made by tcpdump or wireshark. There are (at least) two potential root causes of this, which have been observed in the past:
1. On the device where the pyPLC runs, there may be some "smart" service running which closes/reactivates the ethernet because it intends to find an internet connectivity which does not exist. For pyPLC use case, such services need to be disabled. (do not remember exactly, was it network manager?)
2. Some cars may detect that they are not compatible with the charge parameters announced by pyPLC. Example here: https://github.com/uhi22/pyPLC/issues/14

Regarding the decoder questions: The evsepresentvoltage you find in these lines, where it is sent to the decoder:
msg = addV2GTPHeader(exiEncode("EDg_"+strPresentVoltage)) # EDg for Encode, Din, PreChargeResponse
and
msg = addV2GTPHeader(exiEncode("EDi_"+strPresentVoltage + "_" + strEVSEPresentCurrent + "_" + strEVSEStatus)) # EDi for Encode, Din, CurrentDemandRes
You can just the strPresentVoltage with a better value than just the simulated voltage.
Same for strEVSEPresentCurrent.
The "button to end charge" is meanwhile also implemented in pyPLC, it is in the code above in the variable strEVSEStatus. This is set to EVSE_Shutdown in case the user presses the space button in pyPLC, and is the exact reaction which an original compleo charger does when stopping on the charging. For the RFID you need to implement different answers in this line:
msg = addV2GTPHeader(exiEncode("EDl")) # EDl for Encode, Din, ContractAuthenticationResponse
where at the moment the response is hardcoded in OpenV2Gx.

[serh270]

Hi all, took over a project from a departed coworker in which I am building the vehicle side infrastructure for CCS1 charging setup. I will admit to being a complete noob to this (got this project thrust on me). I've managed to convert a AV600 to DC input but have been unable to understand how to test or interface with this board now that I've made the modification. I am also using pyplc to interface with the charger and the rest of the infrastructure. Can anybody provide information on how to verify that the AV600 is operating correctly and is properly outputting information over DC? (Sorry if this is vague, very happy to provide further information if needed and if I am able to provide it)

[uhi22]

Besides the homeplug modem, you need some "glue logic" to serve the CP line correctly. This is described here: https://github.com/uhi22/pyPLC/blob/mas ... d#dieterlv This also needs to control the two contactors which connect the CCS port to the battery.
For testing the setup, you could connect the CP and PE to a public DC charger and run pyPLC to see how far it comes.
The first hurdle is that the homeplug modem must be configured as PEV, this is described here: https://github.com/uhi22/pyPLC/tree/master#step-by-step
If you do not have public chargers in the near range, you could think of creating an "on-desk-charger" using a second homeplug modem and a second computer: https://github.com/uhi22/pyPLC/blob/mas ... t-machines

Finally, if your solution is still at the beginning, maybe it is better to NOT use the homeplug modems and pyPLC, and instead use the better embedded version: Foccci and Clara. This is available in the shop (https://openinverter.org/shop/index.php ... duct_id=79) and nevertheless offers the full flexibility of open source hardware and software.

[serh270]

Thanks for the great information! I think I'm going to purchase the CCS control board along with the esp32 interface. A few things I do not quite understand: Is the board shipped plug-and-play (software and hardware components/on-board connections).

\Does it have Clara installed and I just need to connect the esp32 interface and the charger hardware and get going through the web interface or do I have to upload Clara and do other setup tasks?

Also, is controlling the board from my own dashboard software as simple as interfacing with the board over the built-in UART interface or am I missing something here?

Lastly, Johannes Hübner's lab update with the new CCS control board and he mentioned that certain upgrades were not working properly. Does this prevent regular operation and/or are there fixes I need to implement before using the board?

Thanks so much again for the great info!

[uhi22]

Added the answers in the other thread, because off-topic here.
viewtopic.php?p=68895#p68895

[IvanPletnev]

Hello everybody! I would like to inform you that I conducted a successful charging session using PyPlc at the Chinese Tonhe charging station and an AR7420-based PLC adapter! Thank you all!

[Gabriel]

Hi guys.

I'm using two AR7420 from TPLink modem, one for emulating a PEV and other the EVSE.

After a couple of days of modens powered by 12 Volts the communication stoped. I noticed that the IC AR7420 is really hot.

I'm trying to debug here, but the comunnication between PEV and EVSE isnt working.

Testing the modens with PLC utils show they are ok. But I got this error:

pi@raspberrypi:~/myprogs/pyPLC $ chkpib2 -v original.pib
------- original.pib -------
PIB 0-0 8836 bytes
MAC 40:ED:00:9F:FD:BC
DAK A8:68:85:FA:9B:A3:D2:B1:24:6F:41:95:5E:D8:C8:E1
NMK 77:77:0F:BB:77:77:77:77:77:77:77:77:77:77:77:77
NID 01:02:03:04:05:06:07
Security level 0
NET Qualcomm Atheros Enabled Network
MFG tpver_401013_171025_901
USR tpver_401013_171025_901
CCo Auto
MDU N/A
chkpib2: pibimage2 found wrong Preferred NID in original.pib

Anyone can help?

[uhi22]

1. At room temperature, after running some minutes, my AR7420 is around 52°C (measured with infrared thermometer). Touching with the finger is okay for 10s, then it hurts. If yours is much hotter, just use a new one. Maybe killed by overvoltage or something.

2. I see no error in your original.pib. It is only saying that the NID is not the preferred one, this is the network ID which is anyway set during the initialization by pyPLC. But: Are you sure you used this "original.pib" for your experiments? This looks wrong. The CCo (Central Coordinator) is set to "Automatic". For the use with pyPLC you should have one modem configured as PEV and one as EVSE, and use the correct one for each side. So instead of the "original.pib", you should have a "pev.pib" and a "evse.pib" with the settings according to the description on github. Not sure what the checkpib tool reports for the intended patched pibs, I never used this.

[Gabriel]

I made new tests and got new info:

1. I use 5V and sometimes 12V to power the AR4720 from a TPlink adaptor. I think it is hot all the time and maybe this wasn't the problem.

2. This original.pib was downloaded from the modem after some tests with it as EVSE (I must change its name when reading). I did a few tests with a BMW i3 and a XC40 VOLVO, and after some successful connections, the modem stopped communicating with cars. I suspect that was some HW problem, but reading the .PIB after this problem and rewriting it like an EVSE and making another "checkpib" I got this reading:

PIB 0-0 8836 bytes
MAC 40:ED:00:9F:FD:BC
DAK A8:68:85:FA:9B:A3:D2:B1:24:6F:41:95:5E:D8:C8:E1
NMK 77:77:BC:B0:77:77:77:77:77:77:77:77:77:77:77:77
NID 01:02:03:04:05:06:07
Security level 0
NET Qualcomm Atheros Enabled Network
MFG tpver_401013_171025_901
USR EVSE
CCo Always
MDU N/A

The difference is that now the CCo is "Always" and not "Auto". But now the question is: Did the car change "CCo" to Auto and why?

Is there some way of configuring CCo using the pyPLC?

1. At room temperature, after running some minutes, my AR7420 is around 52°C (measured with infrared thermometer). Touching with the finger is okay for 10s, then it hurts. If yours is much hotter, just use a new one. Maybe killed by overvoltage or something.

2. I see no error in your original.pib. It is only saying that the NID is not the preferred one, this is the network ID which is anyway set during the initialization by pyPLC. But: Are you sure you used this "original.pib" for your experiments? This looks wrong. The CCo (Central Coordinator) is set to "Automatic". For the use with pyPLC you should have one modem configured as PEV and one as EVSE, and use the correct one for each side. So instead of the "original.pib", you should have a "pev.pib" and a "evse.pib" with the settings according to the description on github. Not sure what the checkpib tool reports for the intended patched pibs, I never used this.

[uhi22]

No, the coordinator setting cannot be changed by the car, and also pyPLC does not touch this. It is only changed by writing a PIB. At least I see no other way.
"Always" is the correct CCo setting for the Evse.

[pathan208]

I am now trying to excuted your ccs32 codebase and bring it up on an ESP32 (WT32-ETH01) board similar to what you've detailed on github. I have taken main CCS32.ino and then call .ino files in main CCS32.ino, and adding header files. When I compile the code, I got some errors related to Ethernet.ino file.My goal is to have charger emulator and test with real EVs. Any guidance or advice is appreciated.
I didn't find much installation instructions on the ccs32 side in the github repo - hence any pointers to install/bringup the PEV side would be helpful for research to implemented of PLC in between vehicle and charging station.

[uhi22]

Normally there should be no need to "call .ino files" and "adding header files". The arduino IDE should automatically treat the ccs32.ino as main file and show all the files in the project, without the need of calling or adding something. The only arduino-specific things need to be considered:
- the board WT32-ETH01 is installed and selected
- the folder name for the project is exactly "ccs32". The arduino IDE wants the folder name and the main ino with the same name.

[p477d343]

I went back some posts and one of the posts had this link http://www.helicopting.de/

So I compared my board with this and seems they're very similar...

compare modems.jpg

So I'll work to eliminate the AC PS side of things and see if it works. One question for the media access ports - which one is CP and which one is PE (lower right side)

Hopefully this will also help others with a newer revision of the TP 4010 modems. Any insights/advice appreciated.

Hello, I have a same board as yours(TP-PA4010). I have some problem when I try to do the hardware part. Do you remove all the crossed off unit on the board and finally work? Can I take a look at your board and see how do you wire CP and PE on the board? It would be a huge help! Thank you!

[johu]

PE and CP is connected to the small transformer. The side that goes to grid voltage