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!