CCS EVSE and Car side

[v-proto]

But read paper of protocol can help to make this much faster!

Of course but whatever we do must be legal if we want Open Inverter to survive.

True

[New Electric Ireland]

On this controller you can't change his one configuration. I think!

AFAIK we know very little about the Kona part. Importantly this is only one of four pieces of CCS hardware that have threads on Open Inverter. My point is that designing hardware/software from the ground up is often a very poor use of limited resources.

Obviously, if this is a hobby then you can invest time on anything because you don't have any customers. However, if you wish to convert more than a few vehicles you need to think more like a professional organisation where you have customers who have real world requirements like a reliable car.

[v-proto]

On this controller you can't change his one configuration. I think!

AFAIK we know very little about the Kona part. Importantly this is only one of four pieces of CCS hardware that have threads on Open Inverter. My point is that designing hardware/software from the ground up is often a very poor use of limited resources.

Obviously, if this is a hobby then you can invest time on anything because you don't have any customers. However, if you wish to convert more than a few vehicles you need to think more like a professional organisation where you have customers who have real world requirements like a reliable car.

Read rule of Autosar os.
They are full open source with many commercial protocol.

[johu]

My point is that designing hardware/software from the ground up is often a very poor use of limited resources.

From a purely economical view point this is probably true. But don't forget that intrinsic motivation will convert "time spent procrastinating" to "time spent on a project". See next quote.

Got you covered on the socket. One thing I've learned over the years working with Johannes is the more complex and hardware intense the system seems to be , the more likely he is to solve it with an stm32f1 , a few resistors and caps and some lines of code

Thats exactly the point. I have a deep seated repudiation for mystification. openinverter vs. mystery haha

Hmm so at this point the endeavour has already drawn too much attention for my taste, I'll wait for a bit of fade-away and MIGHT eventually stick my head up. Not blaming anyone as I got that ball rolling.

[johu]

You keep making me split topics not a problem. It is now here: viewtopic.php?f=14&t=1343

[New Electric Ireland]

You keep making me split topics not a problem. It is now here: viewtopic.php?f=14&t=1343

Thanks... It's a shame the "VCU Change Discussion" didn't happen before

Anyway, back to trying to keep the CCS development legal

[mikeselectricstuff]

Someone could, for example, write a document encapsulating the same information, e.g. substituting code for a flowchart, renaming symbolic names etc.

In order to do this you would need access to a registered document and this would result in a violation of the "otherwise exploit" IEC license restriction.

I disagree - if you look at the wording and context it seems clear to me that they are only talking about the actual published document, not the information within it. "..otherwise exploit.." is clearly intended to simply cover anything not explicitly covered by "lend, lease..." etc. If they intended it to be more restrictive they would have been more explicit.

YOU may not lend, lease, reproduce, distribute or otherwise exploit, whether commercially or not, the IEC Publication(s) to which this Licence Agreement relates

[darko31]

While recently researching for CCS solutions (work related) besides QCA7000 GreenPHY, I've also stumbled upon these guys
https://store.advantics.fr/charge-contr ... r-ccs.html

and they use Mediatek's GreenPHY
https://www.charinev.org/news/news-deta ... lications/

with a custom communication stack.

Previous versions of their Charge controller used QCA7000 but they ditched it because it's obsolete and for lack of support from Qualcomm (IIRC, company and team that created QCA7000 were bought and dissolved in the meantime by Qualcomm).

[v-proto]

Can you place name of chips from mediatek?

[darko31]

Can you place name of chips from mediatek?

Sorry, couldn't find more info. Looks like people, presumably only companies, can get it only by contacting Mediatek.

For further information on GreenPHY products of Opens external link in new windowMediaTek or MediaTek’s partners, please contact MediaTek.

MediaTek contact:

Alex Chen
E-Mail: xiaopeng.chen(at)mediatek.com

Also, forgot to mention, Advantics has this CCS/Chademo controller.
https://advantics.fr/ccs-chademo-controller/

[v-proto]

Can you place name of chips from mediatek?

Sorry, couldn't find more info. Looks like people, presumably only companies, can get it only by contacting Mediatek.

For further information on GreenPHY products of Opens external link in new windowMediaTek or MediaTek’s partners, please contact MediaTek.

MediaTek contact:

Alex Chen
E-Mail: xiaopeng.chen(at)mediatek.com

Also, forgot to mention, Advantics has this CCS/Chademo controller.
https://advantics.fr/ccs-chademo-controller/

Mediatek not know about they have plc chip.

[v-proto]

OpenV2G write by simens on C.
With GNU licence.
https://github.com/mhei/OpenV2G
Support for 15118-2-2016 (ISO2) besides 15118-2-2013 (ISO1) and DIN

[v-proto]

https://www.st.com/resource/en/datasheet/st7580.pdf
PLC on chip from ST

[Landswellsong]

Hey there, registered in order to write here. I've got a small team and we're starting an open source (sw/hw) version of this, car side. Mostly aimed at retrofitting combo to older EVs and converted cars, so there's a bunch of extras like CP/PP rerouting in order to intercept the J1772 signal before the stock charger etc. Currently there's nothing to show, but when we do have something I'll post the link in this thread, maybe you could find it useful or even contribute [provided you have your own ISO's and QCA's ]

I also dug quite a bit into the protocols and CharIN so there's quite a bit of comments I can do in this thread.

To literally everyone, the author of RiseV2G has quite a good knowledge base, a few webinars and a [paid] book: https://v2g-clarity.com/rise-v2g/ Do check it out, at least for the crypto-related matters.

https://www.st.com/resource/en/datasheet/st7580.pdf
PLC on chip from ST

You need GreenPHY specifically. They are "somewhat" compatible with HomeAV, but I think not quite, in particular there's a SLAC protocol in order to pair the car to the correct station regardless of the crosstalk between the stations. ST's module for the automotive application is ST2100.

OpenV2G write by simens on C.
With GNU licence.
https://github.com/mhei/OpenV2G
Support for 15118-2-2016 (ISO2) besides 15118-2-2013 (ISO1) and DIN

We plan to use this. Note it's a fork, so it may not be up to date, check out: http://openv2g.sourceforge.net/
Also note they won't implement ISO 15118-20 as open source when it's available (is it?), therefore you won't have V2G. They do implement 15118-2 and DIN version though.

They're focused on B2B not end users. Over the last three years we've been around this loop several times and always come back to the understanding that reusing existing OEM hardware is the way forward. No different from an Inverter or Charger today... why would anyone build their own?

In addition to what was said in this thread, check this company too: https://in-tech-smartcharging.com/
They sell QCA7000/7005 chips with various degrees of peripherals including really self contained solutions along with an SDK. They are also the maintainers of the Linux kernel module. For the smaller boards at least they kind of want volume deals, but I think you can order as little as 20. We're in talks with them about getting a pair for development.

On C have full drive for chip PLC
https://github.com/qca/qca7000
UART/SPI drivers for Qualcomm Atheros QCA7000 serial-to-powerline bridge chip. This version is specific to Linux 2.6.35 and Freescale iMX28 CPU.

https://github.com/devolo/dlan-greenphy-sdk
The devolo dLAN Green PHY module is ideal for installation in all IoT-devices. Includes QCA7000 chipset and LPC1758 host processor.

This module is mainlined. I'm still waiting for my chips to play with them, but my current understanding is I can even use them on my host machine with a USB to spidev tool.

Got you covered on the socket. One thing I've learned over the years working with Johannes is the more complex and hardware intense the system seems to be , the more likely he is to solve it with an stm32f1 , a few resistors and caps and some lines of code

Oh no you won't. J1772 is made intentionally easy in order so it can be implemented with a pair of resistors, but ISO 15118 is a different beast, it has a layered architecture with multiple stacks used. We do plan to implement it in a microcontroller (because let's face it, going Linux for car side is wasteful and above all not that challenging to begin with), but then again you'll need IPv6 at the very least and even TLS which is optional but still you better have it.

I wouldn't even consider this a "project", more of an experiment whether you can hook up an STM32 to a generic PLC adapter and run CCS. Or even establish any communication. Childs play. There is enough solutions for CCS already

Again, I may be wrong, but I think "a generic PLC adapter" won't work, you need GreenPHY specifically. For QCA there's even a configuration switch between SECC and EVCC sides, but its NDA'd by Atheros/Qualcomm. The company I mentioned above pre-flashes those settings as separate products because they can't share the details with their own customers.

Technically, yes..But practically there's the issue of key exchange which I have not been able to understand. But the standards are very similar.

One you're past PLC (which is also an open standard, but you should really be insane to try implementing it in hardware for one off projects), encryption is optional. It's only required by more advanced features like Plug and Charge, but what you know, the PKI infrastructure is just getting traction and there's no way older EVs even have any root certificates for that, so I may be wrong, but I do think most current CCS cars are using plaintext TCP/UDP versions for now. The key exchange isn't terribly complicated, it's TLS with ECDH / ECDSA. The real meat is the PKI and the management of the certificates on the devices involved. But again, this isn't terribly important at the moment.

Besides, do you want to implement this horrible XML that's not XML protocol? (EXI - Efficient XML something) It's..bad.

There are open source implementations for that. In fact the Siemens implementation has one, and RiseV2G uses a third party one.

EDIT: is there any problem in using the docs you bought to create an open source product?

Those documents are open standards. The copyright applies for the documents themselves, not the ideas they describe, since the standard is royalty-free to use. As a matter of fact, several national governments have a scheme where they republish ISO standards under national standard hierarchy so depending on where you live and what languages you speak you may get one for cheap. We in Ukraine actually can have ChaDeMo for free even, surely meaning the protocol, not the certification which ChaDeMo requires.

Being from Quallcom, all data on the chips is unobtanium.

The kernel driver has quite a bit of information. The in-tech-smartcharging company also provides a PDF on their product page with the communication commands for both SPI and UART modes (sans the NDA'd configurations which I mentioned above).

[johu]

Wow, that is super detailed info. And actually quite encouraging. Well, I'll let you do the heavy lifting I would be interested to actually run it on the stm32f1. The ESP8266 chips run a full IPv4 stack and https, not sure if there is an IPv6 stack for them. And esp8266 isn't to resourceful either. At first it sounds intimidating but usually in the process you find out that a) there is a library and/or b) you only need a small subset of the layers in question.

EDIT: there is ipv6 for esp8266. https://github.com/esp8266/Arduino/blob ... 6/IPv6.ino

[clanger9]

This is fantastic info. Thank you Landswellsong!

[Landswellsong]

Wow, that is super detailed info. And actually quite encouraging. Well, I'll let you do the heavy lifting I would be interested to actually run it on the stm32f1. The ESP8266 chips run a full IPv4 stack and https, not sure if there is an IPv6 stack for them. And esp8266 isn't to resourceful either. At first it sounds intimidating but usually in the process you find out that a) there is a library and/or b) you only need a small subset of the layers in question.

EDIT: there is ipv6 for esp8266. https://github.com/esp8266/Arduino/blob ... 6/IPv6.ino

The link uses the lwIP library. I also think it's one of the best lightweight ones, otherwise you'd need to carve out bits of ContTiki-ng I guess. There are a few Arduino-core implementations, most notably EtherSia, but it has limited features because it's targeting smaller Arduinos.

The problem isn't as much with IPv6 as the underlying two layers. I've not managed to find any open implementations of any GreenPHY module for microcontrollers so currently the plan is to basically port the kernel module. I'll try to abstract it as much as possible from actual hardware though, it seems like a good library to have anyway.

The aforementioned company also sells a complete package module with CAN and everything: https://in-tech-smartcharging.com/produ ... lc-stamp-1 That's way too much closed source and getting vendor locked to my taste so we're not going to use that one, but if someone needs a module to bootstrap CCS as soon as possible without going Linux, I'd recommend that one.