Open source CCS using AR7420

[asavage]

It must be nice to have a CCS EVSE so close that you could make multiple visits/day.

To reach my nearest DCFC (of ANY variety) requires a drive of 29 mi. (47 km)/45 minutes

Once there, however, there's a CCS EVSE within 100 mi. (160 km) for at least 1200 mi. (1900 km), all the way to at least Los Angeles, which is why I want to add CCS to my EV: short range but also short charge sessions make long-distance trips possible. I'll be able to charge at 50kw nominal, that's been tested on my pack.

I took ONE long trip with only J-1772 charging, and it was: drive 90 minutes, charge for 5 hours . . . x11 charge sessions. I'm not doing that again.

I have a 10kw OBC, and my home EVSE is provisioned for 1-ph 240v/40A output (50A circuit) = 9.6kw, but 98% of public L2 EVSEs in US are provisioned for 6-7kw I didn't know that, when I took off for my trip. That added 1.5 hours to every charge session, those wimpy L2 EVSEs.

[johu]

Can't complain:

The closest one is like 2 km away, the furthest maybe 10 (I live in the upper right corner). These are all CCS.

[johu]

Progress

I did see some voltage on the power pins, 250V for a few seconds and soldering iron got warm. Not sure if I saw precharge or actual power. I have no port relays, maybe that's why it doesn't continue?

[uhi22]

Also the cable check applies voltage (500V?), so it's a good idea to NOT connect a load during this. And the precharge, at least what I saw on a compleo, drives a limited current, means also here it's better to NOT connect a load during this. You could turn-on an LED or something, when the charging loop starts (the Relay-output in the software), and hot-plug your load if in the charging loop.

Update regarding the ESP32 variant: Fixed some bugs regarding NeighborSolicitation, which the alpitronics insisted on, and now I come into the charging loop and got voltage. https://github.com/uhi22/ccs32

[johu]

Update regarding the ESP32 variant: Fixed some bugs regarding NeighborSolicitation, which the alpitronics insisted on, and now I come into the charging loop and got voltage. https://github.com/uhi22/ccs32

Wow you're killing it. Coding faster than I can obtain necessary parts

Also the cable check applies voltage (500V?), so it's a good idea to NOT connect a load during this. And the precharge, at least what I saw on a compleo, drives a limited current, means also here it's better to NOT connect a load during this. You could turn-on an LED or something, when the charging loop starts (the Relay-output in the software), and hot-plug your load if in the charging loop.

Oh ok. It was just a 100W soldering iron but still... I also did a run with no load connected but not sure if I logged that. Attached file maybe with or without load

[uhi22]

Both logs from today are stopping at the same step. The PreCharge is "finished" with EVSEPresentVoltage.Value": "0", and the PowerDeliveryReq runs into timeout without any response. My impression is, that very fast "finished" PreCharge is confusing the charger, so it stops talking to us. We should give the charger the time, until it really provided the intended voltage (either hardware-measured, or from EVSEPresentVoltage, or even just waiting 5 seconds inrush).

[asavage]

Congratulations on setting up your Patreon account! I'm in.

[uhi22]

Thanks all for supporting this project in sense of ideas, tests, hints and money.

[johu]

I'm in as well.
Are you receiving the charger output voltage yet? Where in the code could I send it back as "measured" port voltage?

[uhi22]

Now implemented: It can be configured by USE_EVSEPRESENTVOLTAGE_FOR_PRECHARGE_END and USE_PHYSICAL_INLET_VOLTAGE_DURING_CHARGELOOP which of the voltages (physically measured or reported from the charger) is used to show-up on the display and to detect the end-of-precharge.
https://github.com/uhi22/pyPLC/commit/f ... d5578b281f

Edit: The default is now: Rely on the chargers reported voltage. This means, the light-bulb-or-kettle-demo should work without physical inlet voltage measurement.

[johu]

Nice! Will be away a few days, so will retry next week.

edit: video removed, see below

[uhi22]

Nice Video I did not get the point how you switch the CP. The points in time, when we need to turn it from B to C and vice versa are well specified and at least the first is implemented in the script. Not sure whether the charger is angry if we omit this. I'd recommend a digital output of the beaglebone to control the CP state.

[catphish]

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?

[johu]

Nice Video I did not get the point how you switch the CP. The points in time, when we need to turn it from B to C and vice versa are well specified and at least the first is implemented in the script. Not sure whether the charger is angry if we omit this. I'd recommend a digital output of the beaglebone to control the CP state.

ok, should be an easy fix. I just randomly turned it on after plugging in. Sometimes I'd forgotten and it was still on. Didn't have an influence.

Worth spinning a board?

Definitely. LQFP is reasonably easy to hand solder. So that + ESP32 on a board.

[evMacGyver]

Worth spinning a board?

Yes, interested! And really great work with this all of you! Was there some signal level metering limitations on AR7420 or is it after all capable to act as EVSE against "real" vehicle?

I have AR7420 and my plan is to test it against LIM as EVSE, just have not started yet. At least if we handle control of LIM it should be plausible also for non-standard V2H use. I could use board like this and make car able to swap with LIM for testing purposes also, in that case voltage feedback what LIM receives is already isolated mA current signal - so it should work simply by adding resistor to ground in front of analog input.

Video by Johannes, those bolts on CCS plug.. don't really know should I smile or cry

[catphish]

Was there some signal level metering limitations on AR7420 or is it after all capable to act as EVSE against "real" vehicle?

I don't believe the AR7420 supports signal metering at all. You can implement an EVSE but when I did this I couldn't get it to measure the signal so I had to send fake signal levels. This works fine as long as you are only installing one EVSE in the vicinity.

[Pete9008]

Nice! Will be away a few days, so will retry next week.

And early forum release:
video deleted

Really don't want to be negative as there is some great work going on here but please, please, please don't do stuff like that with the bolts! I stopped contributing to this thread a while ago, despite it being of interest, because some of the safety practises were a little dubious but the exposed, uninsulated bolts on a charger lead balanced in the back of the car in a public place is just too much not to comment on.

I know you might feel comfortable with the risks and I might even have occasionally done similar things with mains voltage in the past but never with DC, never in a public place and never in a way that encourages others to do the same. The likelihood of an accident may be low but the potential consequences are just too high.

Sorry to be a pain but if this is the attitude to electrical safety that this forum promotes I'm going to have to stop participating

[johu]

Pete, I take your criticism seriously. While I'm perfectly comfortable with what I did as I was standing next to the experiment at all times and the bolts were firmly seated, I do understand that showing this publicly might encourage less experienced people to take risks they don't understand.

So as a consequence I have removed the video here (it is still visible for patrons or whoever saved the link) and I will make a new video once my CCS socket has arrived.

EDIT: if anyone in the charger industry saw the video this might have adverse consequences as well.

[Pete9008]

Glad you have taken the video down here but a little disappointed by the rest of your response. It's OK because I was comfortable with it and have experience isn't a good reason for cutting corners on safety. You have a lot of influence here and it is very easy for your approach to electrical safety to be seen as the norm and accepted as standard practise by others. A simple slip, trip or fall with those exposed conductors (not that unlikely while simultaneously driving the laptop, controlling the charger and videoing with trailing cable present) could have led to a nasty accident.

It's always worth thinking about redundancy when doing something potentially hazardous. Thinking it's fine because I won't touch it has no redundancy. Adding something as simple as reducing the exposed bolt length and a couple of layers of insulating tape (while still avoiding touching it when live!) is quick and easy and adds another layer of safety. With that extra layer a trip or a fall, even if you landed on the terminals, would hopefully be OK. Obviously the ideal would be a proper connector with insulated terminations but I'm trying to be realistic here!

It's entirely up to you what precautions you feel are appropriate but for anything you share please bear in mind how it could influence others.

Right, I'll try to stop putting a dampener on this thread now, sorry about that.

[asavage]

I posted some info on a Plug-n-Charge alternative, in use by EVgo and Fastned, with MAC address implications:

viewtopic.php?p=55416#p55416

[Bigpie]

Getting in on the action with a TP-Link AV500. Board different to other's documented but has the AR7240 on there. Now running from 12V from the points in the photo

I think I've done the configuration step too.

[uhi22]

This looks good. Looking forward to some test results, no matter whether success or fail. :⁠-⁠)

[johu]

I've started modifying hardwareInterface.py for use with BeagleBone and later will receive various info via chademos CAN.

See here if interested: https://github.com/jsphuebner/pyPLC/tree/beaglebone

[uhi22]

Added ini file, to configure various things, e.g. whether the digital outputs are connected to "dieter" or GPIO. Tried to integrate the beaglebone-related changes accordingly. Just set

Code: Select all

digital_output_device = beaglebone

and

Code: Select all

display_via_serial = no

in pyPlc.ini. This concept helps to maintain a common source for different variants. I do not have a beaglebone, and also did not run tests on the raspberry, so do not expect too much for the moment, it's just a draft.

[johu]

Very nice, I prefer unified code as well.

Here are the results from todays run. Now CP line is actually controlled by the script. In the first log no load was connected, in the second a 6W LED lamp was connected. Both didn't get past precharge, the second one for the obvious reason that the target voltage couldn't be reached.

The second one gets no response on the PowerDeliveryReq

Video coming, this time with augmented HV safety