Open source CCS using AR7420

[uhi22]

From my understanding the DIN is a pre-pre-version of the ISO. I have the ISO, and many things look identical, but by analysis of the openv2g I found some small but important differences. For the state transitions I have no info, just making try and error.

[uhi22]

I wonder for an embedded implementation if it's worthwhile storing pre-computed EXI blobs in a lookup table?

In first look, precomputed exi does not work, because the charger decides for a random session ID, which must be used in all messages. But the good news is, that the openv2g, which makes the exi encoding/decoding is plain C and I guess it would run even on a 8bit controller.

[catphish]

In first look, precomputed exi does not work, because the charger decides for a random session ID, which must be used in all messages. But the good news is, that the openv2g, which makes the exi encoding/decoding is plain C and I guess it would run even on a 8bit controller.

I would agree that prcomputing should be unnecessary as the binary protocol should be quite fast to generate even on basic hardware. I suspect pregenerated binary blobs would make the code harder to understand and debug too.

[uhi22]

Regarding running the exi stuff on a small controller: I made a try and just copied the DIN decoder files into an arduino sketch folder, and called the decode_dinExiDocument(). The arduino IDE says the sketch would need 93kBytes ROM and 23kBytes RAM. For the other way around, calling encode_dinExiDocument(), it needs 67kByte ROM. We also would need decode_appHandExiDocument(), so in sum I guess more than 200kByte ROM. Really crazy, that they defined such a shitty method to transfer some numbers, and call this "highly efficient and suitable for small controllers".
Conclusion: Much too much for my usually used ATmega controllers.

[johu]

Yeah many dumb decisions made in CCS design. Anyway, an ESP32 should hack it.

[catphish]

Regarding running the exi stuff on a small controller: I made a try and just copied the DIN decoder files into an arduino sketch folder, and called the decode_dinExiDocument(). The arduino IDE says the sketch would need 93kBytes ROM and 23kBytes RAM. For the other way around, calling encode_dinExiDocument(), it needs 67kByte ROM. We also would need decode_appHandExiDocument(), so in sum I guess more than 200kByte ROM. Really crazy, that they defined such a shitty method to transfer some numbers, and call this "highly efficient and suitable for small controllers".
Conclusion: Much too much for my usually used ATmega controllers.

Ah yes, I forgot about potential RAM requirements. This requirement will definitely have to be considered before thinking about porting this to a MCU, but plenty of STM32s are sufficient:
* STM32F103 (20KB RAM, no good)
* STM32F107 (64KB RAM)
* STM32L476RG (128KB RAM)

If I were going to make a start porting the controller to a microcontroller, I would probably begin with a NUCLEO-F412ZG. This STM32 dev board has 256KB of RAM and on exposes the chip's fully integrated Ethernet controller.

[uhi22]

Some small progress on the Tesla SuperCharger: SLAC and TCP connections work perfect, also with the headless Raspberry3 as controller. In contrast to the other chargers, the SuperCharger use only 8 characters session ID instead of 16. This case is not yet considered in the OpenV2Gx. At the moment the SuperCharger complains (correctly) about wrong session ID. Updates are ongoing.

[uhi22]

In cold days it's always a good idea to have a hot tea during the charging breaks. And here we go:

Version v0.6 released.

[DIYeLandCruiser]

Moin.
I just found out about this project from Johannes and I'm very excited. First of all, congratulations on this fabulous work.
I'm very interested and would love to get involved with my DIY eLand Cruiser 1978 for testing purposes at CCS charging stations. I installed 14 Tesla modules with a charging end voltage @ 350V. I use the Orion BMS and have installed CHAdeMo fully functional. So much is already available on my hardware side.
Maybe I can help..

[peternooy]

Some small progress on the Tesla SuperCharger: SLAC and TCP connections work perfect, also with the headless Raspberry3 as controller. In contrast to the other chargers, the SuperCharger use only 8 characters session ID instead of 16. This case is not yet considered in the OpenV2Gx. At the moment the SuperCharger complains (correctly) about wrong session ID. Updates are ongoing.

May be if you share the pcap file of Supercharger session, I can help have a look and see where the problem is.

[uhi22]

This is great, thanks! I added the log files here:
https://github.com/uhi22/pyPLC/blob/mas ... ecoded.txt and
https://github.com/uhi22/pyPLC/blob/mas ... ror.pcapng
One problem is my wrong handling of the SessionId. This is now (hopefully) fixed and need to be tested again. Described the issue here:
https://github.com/uhi22/pyPLC/blob/mas ... session-id
If you see other strange things I'd be happy Thanks for supporting.

[peternooy]

This is great, thanks! I added the log files here:
https://github.com/uhi22/pyPLC/blob/mas ... ecoded.txt and
https://github.com/uhi22/pyPLC/blob/mas ... ror.pcapng
One problem is my wrong handling of the SessionId. This is now (hopefully) fixed and need to be tested again. Described the issue here:
https://github.com/uhi22/pyPLC/blob/mas ... session-id
If you see other strange things I'd be happy Thanks for supporting.

Apart from wrong session ID handling, I don't see any other obvoius problem.

Code: Select all

Exi Data: 809a0237ab6fbbf7ab6fbbd198 => ServiceDiscoveryReq
<ns6:V2G_Message xmlns:ns6="urn:din:70121:2012:MsgDef" xmlns:ns5="http://www.w3.org/2000/09/xmldsig#" xmlns:ns7="urn:din:70121:2012:MsgBody" xmlns:ns2="urn:iso:15118:2:2010:AppProtocol" xmlns:ns4="urn:din:70121:2012:MsgDataTypes" xmlns:ns3="urn:din:70121:2012:MsgHeader">
  <ns6:Header>
    <ns3:SessionID>DEADBEEFDEADBEEF</ns3:SessionID>
  </ns6:Header>
  <ns6:Body>
    <ns7:ServiceDiscoveryReq/>
  </ns6:Body>
</ns6:V2G_Message>

Exi Data: 809a0101bbc01c51a0e12168484120c4 => ServiceDiscoveryRes
<ns6:V2G_Message xmlns:ns6="urn:din:70121:2012:MsgDef" xmlns:ns5="http://www.w3.org/2000/09/xmldsig#" xmlns:ns7="urn:din:70121:2012:MsgBody" xmlns:ns2="urn:iso:15118:2:2010:AppProtocol" xmlns:ns4="urn:din:70121:2012:MsgDataTypes" xmlns:ns3="urn:din:70121:2012:MsgHeader">
  <ns6:Header>
    <ns3:SessionID>06EF0071</ns3:SessionID>
  </ns6:Header>
  <ns6:Body>
    <ns7:ServiceDiscoveryRes>
      <ns7:ResponseCode>FAILED_UnknownSession</ns7:ResponseCode>
      <ns7:PaymentOptions>
        <ns4:PaymentOption>ExternalPayment</ns4:PaymentOption>
      </ns7:PaymentOptions>
      <ns7:ChargeService>
        <ns4:ServiceTag>
          <ns4:ServiceID>4660</ns4:ServiceID>
          <ns4:ServiceCategory>EVCharging</ns4:ServiceCategory>
        </ns4:ServiceTag>
        <ns4:FreeService>true</ns4:FreeService>
        <ns4:EnergyTransferType>DC_extended</ns4:EnergyTransferType>
      </ns7:ChargeService>
    </ns7:ServiceDiscoveryRes>
  </ns6:Body>
</ns6:V2G_Message>

This should be easy, fix your session ID handling and this should go away.

BTW: I'm surprise that Tesla SuperCharger keep communicating with EVCC even after it indicate wrong sesion ID in the response message, it should stop there and terminate V2G session. On EVCC side, any failed response code received from SECC should trigger session stop and terminate the ongoing session.

[uhi22]

Yes, this looks like optimized development effort. The normal case works well, the abnormal cases has "random" behavior. I guess for officially certified CCS there would be conformance tests, which would discover the deviation. But to be honest: This increases the costs, for no real benefit in real life. I like the minimum approach.

[peternooy]

Understand, one day someone will take this work to that level. We all know that conformance test help ensure product is both functional and safe to use.

On a side note, I see you focus only on DIN stack I hope you alreay provision for additional stack when DIN is done. In my prevous project adding support for aditional stack caused a lot of pain.

[uhi22]

The biggest issue regarding latest ISO stack is, that the developers of openV2G announced, that they will not publish the latest updates as open source.
But I assume the DIN is sufficient for a while. My good old Hyundai Ioniq only supports DIN, and I hope the chargers will not discontinue the support for DIN in the near future...

[johu]

Good thing they call it openV2G then :p
But given the fact that CHAdeMO is still widely available I wouldn't expect anyone dropping backward compatibility which is really just a software thing with CCS.

On another note I tried to source an AR7420 chip but it's listed only on some obscure sites. So it would mean for a "product" a modified TPLink adapter or similar would have to be supplied?

[catphish]

The biggest issue regarding latest ISO stack is, that the developers of openV2G announced, that they will not publish the latest updates as open source.

Perhaps I'm misunderstanding, but why does this matter to us? Are you not developing a new stack from scratch based on the spec?

[uhi22]

Nearly, but not fully. I rely on the open source EXI decoder/encoder. I added a command line interface, so that I can run it from the python scripts. This extension is on https://github.com/uhi22/OpenV2Gx, which I forked from https://github.com/Martin-P/OpenV2G. This in turn is a mirror of http://openv2g.sourceforge.net, where Siemens provided a really good basis. Until here it is really open source. They support DIN, ISO1 and ISO2, from which I use the DIN part only. It would be possible to also use some of the ISO, but the latest ISO15118:20 they will not support. They write: "Note: the V2G implementation for ISO 15118-20:2022 will not be available as Open Source. If you are interested in a commercial license solution, please contact us via exi.ct@siemens.com."

But I do not see this as a blocking point. I assume the chargers will support the DIN (and/or ISO1) also in the next years.

[uhi22]

On another note I tried to source an AR7420 chip but it's listed only on some obscure sites. So it would mean for a "product" a modified TPLink adapter or similar would have to be supplied?

I think for a really "mass product" the AR7420 is not the best solution. Because it provides an Ethernet port, and we need a controller which feeds this. The AR7420-approach is good for experimentation, but if everything is stable, maybe it makes sense to port the software to a more compact design e.g. with QCA7005, which can be directly connected to the controller (not sure via serial or SPI).
But for a "small series" I could imagine an original TPlink board as "daughter board". Only 8 pins need to be connected: Ground, supply, 2xPLC, 4xEthernet.

[uhi22]

Moin.
I just found out about this project from Johannes and I'm very excited. First of all, congratulations on this fabulous work.
I'm very interested and would love to get involved with my DIY eLand Cruiser 1978 for testing purposes at CCS charging stations. I installed 14 Tesla modules with a charging end voltage @ 350V. I use the Orion BMS and have installed CHAdeMo fully functional. So much is already available on my hardware side.
Maybe I can help..

Yes, this would be really great. As a first step, you could just replicate the setup which I used for the tea-time-session, and enter a senseful voltage into the script, which is some volts higher than the actual battery voltage. With this setup, it should already be possible to charge a little bit. And then it needs interfacing to your BMS, to know the charging parameters. Or, maybe even to directly integrate the EVSE side of ChaDeMo, so we would have an universal CCS to ChaDeMo adaptor.

[celeron55]

The universal CCS to CHAdeMO adapter is an interesting idea.

Usually the idea is turned down because:
- the Chademo plug is way too expensive (making the entire thing totally uneconomical),
- you need to supply 12V to the adapter from somewhere (you don't have that luxury in a generic adapter), and
- the adapter would have to house a power diode to actually conform to the CHAdeMO standard to a reasonable extent (CHAdeMO does not officially support a CCS-like charger output precharge, even though you might be able to do it if your vehicle behaves in a specific way).

However in this context we might be able to work around each of those problems.

[uhi22]

For the 12V there is in an other thread the idea from Johannes, to include a small accu into the adapter, and a small DCDC to charge it as soon as the 400V is present. I like this Idea.
A standard 500V/100A diode should be not a blocking point. Not sure about the plug. Maybe its worth to ask Alpitronics, as they are removing Chademo from the hyperchargers at the Moment

[celeron55]

If you're doing this just for your own vehicle, you could simply add a 12V outlet next to the CHAdeMO socket. Problem solved.

The diode, yes, you can just install one. It will require a heat sink, which is kind of problematic as you also want to make the thing watertight. Maybe a cast metal enclosure can also act as the heat sink? EDIT: Besides, if it's your own conversion, you can set it up to support the CCS precharge anyway so you don't need a diode.

The plug... well, I have 3D printed one, and fitted it with working terminals made from suitably sized brass stock. So it is doable, just kind of iffy. Also the design available online is not waterproof, not even close. A new one needs to be designed with proper sealing surfaces.

I wonder what kind of form factor should be aimed for. EDIT: It would be cool and cost effective to have one that you could 3D print, that would integrate the CCS socket and the CHAdeMO plug all in one, with a compartment for the electronics. The standards are playing in your favour, as both sides would be male contacts, so you only need the correct diameter rod to make them. However, this is bit far fetched.

[uhi22]

For the CCS-to-Chademo-Adapter, let's use the thread viewtopic.php?p=18351#p18351 (Re: Is it possible to make a CCS to CHAdeMO adapter?)

[CCSknowitall]

I tried looking at the alpitronics pcap where you get a failed response to a welding detection request. I am not sure what you’re doing wrong here. I have seen identical requests from real ccs vehicles. You might try setting EV ready to false and see if it doesn’t fail out. Seems like Alpitronics might have a bug.