Open source CCS using AR7420

[uhi22]

The Ionity, after charging for around 10s with 382V and 72A, says "EVSEStatusCode_text": "EVSE_Malfunction". The famous standard knows exactly two reasons for this status code:
1. Isolation Failure
2. "..."
Since in the same response the EVSEIsolationStatus says "Valid", this does not look like a isolation failure. So it must be "...". Great, or?

Was this at the Ionity Tritium Chargers (https://www.goingelectric.de/stromtanks ... -11/39513/) or an other charger type?

[johu]

The Ionity, after charging for around 10s with 382V and 72A, says "EVSEStatusCode_text": "EVSE_Malfunction". The famous standard knows exactly two reasons for this status code:
1. Isolation Failure
2. "..."
Since in the same response the EVSEIsolationStatus says "Valid", this does not look like a isolation failure. So it must be "...". Great, or?

Was this at the Ionity Tritium Chargers (https://www.goingelectric.de/stromtanks ... -11/39513/) or an other charger type?

Haha, great It was the Tritium chargers.

I have now removed the negative port relay and applied your patch. Result: most ABB chargers work, some don't The ones that don't probably pick up the isolation fault caused by the non-existant port relay.

I also went to the Porsche charger again and it just suddenly stops sending messages and goes red. Same behaviour with and without second relay.

Ionity Tritium chargers didn't change behaviour with one relay.

EDIT: added some pictures of my "charging window"

[asavage]

What device are folks using to perform the physical HV measurement on the vehicle? Or is everybody using the EVSE's reported value?

[uhi22]

I have no overview which projects are using which method, that's why just some guessing:

- For my light-bulb-tests (no vehicle) I used the high-voltage-Dieter (https://github.com/uhi22/pyPLC/blob/mas ... d#dieterhv)
- Celeron55 uses a serial device, I'm not sure whether this is included to his iPDM https://github.com/celeron55/ipdm56 or separate.
- Johu relies most likely on the EvsePresentVoltage for the Audi and for the Chademo-Adapter.

Would be great to have some more feedback from others, but maybe there are no.

[Bigpie]

I've not got that far yet, no socket. I was going to use EvsePresentVoltage at least initially.

[celeron55]

I'm almost certain I've mentioned it somewhere but I use one of the boards designed for the LIM, this one: viewtopic.php?t=2474

I don't particularly like or dislike it. It does work. Of course it being analog you need something in between to interface it to pyPLC.

[CCSknowitall]

There are vehicles in the market today that 100% rely on the station’s EVSE preset voltage value and essentially do no estimate of the actual charger voltage during precharge.

There’s also vehicles that do measure the inlet voltage and ignore whatever the EVSE says…

And also there are some vehicles that both monitor and verify the EVSE is saying something reasonable.

There are advantages and disadvantages to all three options, of course, and eventually it would be cool if you offered support for all three in your stack.

I prefer measuring on the vehicle side in some form. If the station is significantly off, your inrush current can be substantial… but you are not 100% obligated to do so.

[Bigpie]

Slowly slowly, moving along. My RPI now has Can Bus to the rest of the car to read off the battery voltage and SoC. Will also take limits from BMS.

Not sure why it cannot find my modem any more, but I should have a CCS socket shortly so I can head round to station and see if they talk, once fixed the missing modem.

Code: Select all

[2620ms] [HARDWAREINTERFACE] raspberrypi: Set SoC to 80 %
[2904ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
[2909ms] [ModemFinder] Starting modem search
[3337ms] [HARDWAREINTERFACE] raspberrypi: Set battery voltage to 369 V
[3478ms] [ModemFinder] Number of modems:0
[4082ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
[4087ms] [ModemFinder] Starting modem search
[4683ms] [ModemFinder] Number of modems:0
[5300ms] [CONNMGR] 9 0 0 0 0 0 0  --> 5
[5305ms] [ModemFinder] Starting modem search

[mhpev]

Hi all - you guys have been doing some fantastic work on this.
I have a used Chevy Bolt 2018 and am trying to use your codebase and pointers to emulate the EVSE component of the pyPLC project (have ordered the TPLink GreenPHY modem TL-PA4010 KIT from Ebay). I am trying to get the complete picture on what components are needed to get this setup h/w side built - my use-case is to put the pyPLC in EVSE mode and emulate the charger side and perform some of these use-cases:
1. close contactors on EV side
2. read SoC
3. put the EV in charge state
4. put the EV in (dis)charge state (more like discharge state and ability to draw power V2H type)
5. Implement a sniffer to capture the protocol messages from the EV side.

I understand the interface at protocol level but not sure how this needs to work with the rest of the elements like Arduino for PWM/CP type work and how that fits with the RPi and TPlink/QCA GreenPHY modem. I am going over the posts but there are many evolutions and schemes but I would like to go with an approach that would work without too many changes. Get the connectivity going and then focus on s/w from Pi perspective.

Also my expertise is more on s/w side - I opened up the modem housing but the board/placement of the components doesn't look similar to what is seen in some prior posts from other users. I am attaching the pics from my modem if someone could provide any guidance on how to proceed. To begin I would like to use the pyPLC processes on 2 sides (2 RPi connected to EVSE/PEV emulated sides) and get them to communicate. Once that works move to the next step with the Arduino/PWM and getting the charger to states A, B, C to keep the EV side happy (I wil more questions but first need to get started).
I have built my 2 RPi setups but waiting on completing the h/w mods as well as flashing the EVSE/PEV side of the PIB and/or f/w (if needed) to get the modems to implement the correct protocol stack at L2/LLC side.

Any help and/or pointers to get me started would be appreciated. TIA.

[johu]

Looks like you grabbed a single board variant, i.e. power supply and logic on the same board. Just find the various rails, usually 12V and 3.3V. Inject 12V and see if that fires up the 3.3V as well.

[Bigpie]

Check the cap pins when it's powered up, that's a good starting point to find 12V I found. Obvs taking safety considerations when probing.

[asavage]

Oh, goody, another variant.

It looks more-or-less like catphish's and one of mine:

TL-PA4010 (without passthrough), modified to remove AC power supply. catphish's on left, asavage's center, mhpev on right.

I think you can figure out the 1:1 correspondences for much of that, just visually. The bottom side, maybe not so much. Once the big stuff is removed (esp. the transformer), it likely doesn't matter if some small bits are left behind, the circuit won't be dragged down.

You're aware of the other thread?

Drawing power out of CCS port (V2x, inverse charging, bidirectional CCS)
viewtopic.php?t=3551

[mhpev]

Thx @johu, @asavage, and @bigpie for your prompt responses. Yes, this is the non-passthrough version I found on eBay. It's a newer version 3.x v/s the 1.x when I closely looked at from pervious pictures you folks had posted.

I will do the recommended and validate the voltage at the capacitor pins. That seems like a good starting point. Then will start eliminating the transformers next. Just to be on the safe side I also ordered a set of older variants today from eBay to be closer to the ones you folks have working (in case I bust these).

@asavage - yes, I did go through the thread for inverse charging - that is one of the goals but first things first Reading the posts I realize most of the folks are trying to implement the EV side of the interface while few including yourself were more interested in EVSE side. My focus is on this side and use the Chevy Bolt EV as the PEV (it supports CCS1 interface today). Once I get this comm working next, I want to understand the tie-in to the Arduino for the fixed voltage 1KHz PWM at 5% duty cycle and how to get that built up and integrated. The h/w instructions on the instructible seemed pretty complex to the Arduino HAT but will look at it closely. If anyone here has pointers to simplify that plus pictures on how to connect this to the PE/CP interface of the GreenPHY modem side, please provide (@uhi22 had pictures with the EV Deiter LV/HV side if I remember correctly but not with the EVSE side of the Arduino - please correct me if wrong).

Another option I was also looking at was the QCA 7000/7005 modems available prebuilt on AliExpress. They're much more expensive but seems they've done some of the work to make it easier to integrate and bring up (hopefully )

As I work thru this, I'll try to document the steps and tie some of the stuff you folks have worked on together. Lot of good info just that it's a bit scattered across the posts so a cleaned-up procedure would help... Thank you again.

[asavage]

Yeah, that's the problem with complex community projects that run over time: you can't get today's gestalt, because it doesn't exist in one place. In general, the Wiki doesn't get updated, the FAQ is always two years out of date, and enthusiam waxes/wanes, people come and go. It's the rare project that gathers enough community to self-sustain enough to get documentation updated.

How-To. Well, pretty much you have to write it yourself, unless someone will answer your individual questions.

I can't answer Qs because while I bring a lot of life experience and several diverse careers' worth of knowledge to the forum, my talents are limited. So I'm a Patreon supporter of Damien & Uwe, and I encourage where I can. I've written two reasonably extensive Wiki articles on old Tesla hardware that nobody will use -- because I needed that info for my own project and was unable to find anyone who already had the info I needed, to give it up. So I duplicated it by buying the hardware via eBay, several hundred USD worth, and then taking it all apart and snapping pics, reverse engineering what has already been reverse engineered by others who won't share.

If you can help by pulling together enough info to create recipes, that will surely be invaluable to those who follow. It's thankless work, and inevitably we burn out doing it, but the worst part is that it goes out-of-date so fast Uwe has done a great job of documentation over at his Github, and his docs are really much better than I could expect for someone who moves so fast. We have a fairly bare-bones Wiki set up for this project, but it needs fleshing out. The nice thing about a Wiki is it can, when kept current, remove much of the forum-reading that one normally has to do to get up to speed.

If the info needed to make a recipe was all in one thread instead of 3 or 4, it wouldn't be any easier to use: it still must all be read; no newbie can just drop in on the last ten posts and learn what they need. The time investment for new folks only gets worse, the longer a project runs.

And everybody wants proven recipes. Myself included.

[asavage]

I have a used Chevy Bolt 2018 [ . . . ] my use-case is to put the pyPLC in EVSE mode and emulate the charger side and perform some of these use-cases:

1. close contactors on EV side
2. read SoC
3. put the EV in charge state
4. put the EV in (dis)charge state (more like discharge state and ability to draw power V2H type)
5. Implement a sniffer to capture the protocol messages from the EV side.

I am adding CCS DCFC to an OEM EV, and the big hurdle isn't the CCS stuff at all: it's the vehicle side.

If you have a DIY EV, you have complete control and some documentation. You can redesign anything.

On an OEM EV, you usually need to leave most of the vehicle alone. You can't control the HV contactcors, you can't change the BMS, and you need to leave the vehicle integration alone -- or do enough research to spoof stuff (MiTM devices, for example). It's a lot more challenging than a clean-sheet build where you can change anything you like.

In my case, I can tell the car to be ready to Drive, the BMS brings up the HV rail, and then I can inject HVDC into the rail, and the BMS will not interfere, unless I ignore it when it broadcasts some message that shouldn't be ignored ("I'm full, stop!", "too hot", "too cold", "HV isolation event", "HVIL event", etc.). But it's very unlikely I'll be able to directly close those HV contactors myself, without the vehicle's own management doing it, because if I closed them myself, who's going to tell me when something's going wrong (the BMS won't cooperate if it wasn't put in charge at the start). Who's going to run the thermal management? The list goes on.

You can probably figure out how to obtain something like a SoC, though using a bare pack voltage is generally "good enough" for most purposes.

"Put in charge state". Yeah, that's the one that's in my "Phase Three -- Someday" category, because in my case it means my board has to emulate the existing charger's messages. Every mfgr does it differently, but in your case you probably can use the QCA700x stuff, pretending to be an EVSE, to get it to charge state.

"Put in V2H state". That's going to be interesting. The car's BMS probably has control over the HV contactors (certainly does in Teslas) and it'll have to be convinced to keep the HV rail live. In my scenario above, I tap juice from the HV rail using my own separate contactors, and I could as easily pull juice as push it -- the BMS doesn't care, because in Drive mode, current flows both ways (Drive/Regen), but in your case, the BMS is actively expecting to get juice and might not like to keep the HV contactors closed very long if the SoC isn't rising.

I think the latter is where someone is with the Hyundai? A timeout.

Anyway, lots to discover.

[mhpev]

Thank you @asavage great insights. I agree with you lot (mostly all) of this is really great work from the contributors and community. And mostly thankless. Hence I'll take my notes and add them in here or if it makes sense to merge them in @uhi22 github to fill any gaps in doc. I went through his readme specifically for the EVSE mode and things are quite clear (I'll come to know when I start integrating stuff with the vehicle).

But areas I think may be of help would be related to debugging and taking traces on the interface, etc. Also one area that I am not completely clear is the Arduino and use of the WallBox charger approach. If the requirement is to have a 5% fixed PWM duty cycle can't it be emulated using a much simpler approach than https://www.instructables.com/Arduino-E ... g-Station/ - maybe I am missing something here. But this picture seems to have lot of clarity.

I am also going over all the posts to make sure I've not missed anything (you're correct there's no easy way here )
Thanks again.

[mhpev]

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...

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.

[asavage]

One question for the media access ports - which one is CP and which one is PE (lower right side)

From what I recall, it doesn't matter: it'll work either way. The PWM hits the circuit fine whether one side is ground, or the other.

[uhi22]

Yes, the polarity of the Homeplug port does not matter.

Edit: Updated the FAQ with the question for the polarity of the homeplug modem: https://github.com/uhi22/pyPLC/blob/mas ... -is-the-cp

[mhpev]

I'm finally working on getting my setup up and running. Have one RPi 4 (EVSE) and one RPi Zw2 (PEV) and loaded up the software following the instructions from @uhi22 github.
For now I am using the RPi4B to emulate both the sides to see if there are no issues with missing libs/packages etc.

pi@evse:~ $ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether e4:5f:01:fd:f7:cd brd ff:ff:ff:ff:ff:ff
inet 192.168.15.249/24 brd 192.168.15.255 scope global dynamic noprefixroute eth0
valid_lft 517sec preferred_lft 442sec
inet6 fe80::57ef:bab4fc2c/64 scope link
valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether e4:5f:01:fd:f7:ce brd ff:ff:ff:ff:ff:ff
inet 192.168.15.248/24 brd 192.168.15.255 scope global dynamic noprefixroute wlan0
valid_lft 521sec preferred_lft 446sec
inet6 fe80::6a8d:a509140d/64 scope link
valid_lft forever preferred_lft forever
pi@evse:~ $
pi@evse:~ $ uname -a
Linux evse 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux


But somehow I'm running into an issue when running the simulators - seems like it's complaining about a missing serial conn? and missing CAN interface (not sure why those are needed?) If anyone could help get past this.

If needed I can create a virtual CAN interface - but not sure why I would need it - CHAdeMO??

[woleg]

I see you have confused pyPLC.py P as a pseudo vehicle. Not just me then…

There’s no vehicle simulator here from what I can tell. P is for translating CHAdeMO can to CCS from what I can gather.

[mhpev]

Hi @woleg not sure if I understood your response. But as you can see in the snapshot of the 2 consoles above, I've started the 2 sides EVSE and PEV in simulated modes with the arguments E S and P S respectively. Also from the first line of execution of the command the process says running in simulated mode. Hence I couldn't understand your response. I'll read thru the code and see if there's a way to disable these checks, I could also fake the interface if needed but didn't understand why they would be needed if simulating both sides to go thru the comm messaging. Appreciate you taking the time to go over.

[woleg]

I am probably wrong on that.

Found this from last year.

> The project is designed to play both roles, EVSE and car. To work on the project, I just open two console windows on the same machine, start in the first window the EVSE with "python pyPlc.py E" and in the second the PEV with "python pyPlc.py P", and see how they talk to each other. So to say the "poor mans simulation". Next level would be, to use two different machines, and connect them via the homeplug modems. And the final level would be to also add the electronics for handling of the 12V PWM. These two "enhanced simulation levels" I do not use at the moment. Just concentrating for now to get the high-level communication as good as necessary, and to try it out with real car (was successful until the precharge) and with a real charger (coming soon). And then to compare the recordings from the real-life-sessions with the simulation and improve both sides of the project.

I did try this out (with unconnected can and UART interfaces to stop the program complaining) but didn’t get much further. Having entered at this stage rather than the beginning it was all rather confusing.

Maybe a YouTube video of two RPi and TP-Link units working would help newcomers.

[uhi22]

If it says that it expects CAN, then the ChaDeMo is enabled in the ini file. Just change this setting. And If you do not have serial devices, then remove the Dieter or Celeron devices from the ini.

[Bigpie]

Cant quite tell for the photos the arrangement of the capacitor and resistor for the CP line. Does the type of cap matter? Got my CCS socket so just about ready to do a little test without HV at first.