openinverter forum

Who want to help me make CCS rich man EVSE and car side?
I buyed all standards protocol to make this.

Laugh at me but I just found out what GreenPHY is: https://de.wikipedia.org/wiki/HomePlug# ... g_GreenPHY
It is said to be compatible with "Homeplug AV2". So buying a cheap powerline adapter would already let you tap into the communication physically. I know there's a few projects here that work on re-purposing existing CCS controllers. But how cool would it be to have an openinverter CCS controller?

I'm not uttering guaranties but I'm curious to say the least.

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

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.

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

-Matt

johu wrote: ↑Sat Jan 09, 2021 8:38 pm EDIT: is there any problem in using the docs you bought to create an open source product?

If they are legitimate IEC documents then they will be licensed to named users only as detailed at the bottom of every page (see attachment). I would recommend contacting the IEC and reviewing the license before using the documents for development because they take copyright very seriously.

That said, lots useful CCS documents are available for free from CharIn;

https://www.charinev.org/index.php?id=170

mdrobnak wrote: ↑Sat Jan 09, 2021 10:14 pm 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.

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

Hmm, was hoping the PLC adapter would just handle the key stuff? EXI... well at least it's a standard so likely someone developed a lib for it - first result http://exip.sourceforge.net/ (last updated 2014, well).
Like said I'm just curious, if it gets too ugly I'll back off.

Yes the legalities are probably strict. But then source code is covered by free speech and it wouldn't be a commercial product. I don't think anyone ever managed to challenge that (see for example youtube-dl).

This might be a dumb question, but would it possible to implement CCS DC charging (DIN SPEC 70121) using an open source ISO 15118 implementation?
e.g. https://v2g-clarity.com/rise-v2g/

I may have got this wrong, but I thought CCS DC is just a subset of ISO 15118 (which covers the forthcoming Plug & Charge standard)...

That is an option. We talked about it in another thread. It's in Java.

You also need IPv6.

-Matt

johu wrote: ↑Sat Jan 09, 2021 8:38 pm Laugh at me but I just found out what GreenPHY is: https://de.wikipedia.org/wiki/HomePlug# ... g_GreenPHY
It is said to be compatible with "Homeplug AV2". So buying a cheap powerline adapter would already let you tap into the communication physically. I know there's a few projects here that work on re-purposing existing CCS controllers. But how cool would it be to have an openinverter CCS controller?

I'm not uttering guaranties but I'm curious to say the least.

"Compatible with" could mean forwards/backwards comaptible in a way that may or may not allow a homeplug device to talk CCS.
A while ago I bought a Homeplug powerline networking device to look at - can't immediately find it but pretty sure it used a different greenphy chip to that found in CCS implementations.
Being from Quallcom, all data on the chips is unobtanium.

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

No - the only issue would be re-publishing the documents as-is. Using them to write code that you then publish would be no problem at all.
Even just re-writing the same information ( lists of commands etc.) would be OK.

mikeselectricstuff wrote: ↑Mon Jan 11, 2021 12:52 pm Even just re-writing the same information ( lists of commands etc.) would be OK.

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

https://www.iec.ch/webstore/custserv/pdf/Licence.pdf

"It's complicated"
http://his.diva-portal.org/smash/get/di ... TEXT01.pdf

You can absolutely implement IEC standards in open source software. Section 6.1 (p.60) of the linked document explains the steps you have to go through. The first step is that "someone" has to purchase a copy of the standard. Once that's done, "someone" can implement the standard in open source software - as long as there are no patents involved.

The problem for us (as far as I understand it) is that open source software is usually developed by a loose and evolving group of individual volunteers, not "someone". Unfortunately, the IEC rules don't permit you to share the purchased copy of the standard among that group of individuals.

clanger9 wrote: ↑Tue Jan 12, 2021 6:57 pm The problem for us (as far as I understand it) is that open source software is usually developed by a loose and evolving group of individual volunteers, not "someone". Unfortunately, the IEC rules don't permit you to share the purchased copy of the standard among that group of individuals.

Correct... which is why I said in a previous post "I would recommend contacting the IEC" so that we understand their constraints on open source development. After all, we are not the first to do this

It's important to remember that both Damien and Johannes have rightly complained about people violating their copyright by removing silkscreen from board designs. As a forum we need to be more professional in our approach. Respecting copyrights is something most of us do everyday as developers and business managers even when we're developing open source solutions.

100% this.

It's too easy to work around the rules, steal stuff, use hooky copies of standards, etc.
Let's do this properly...

Agreed. That said, since there is an open source implementation in Java it seems that the standard has already made its way into the open source world (MIT license).
So, if at all we (or I), would just be porting that code over to C++. At this point I'm not even sure this is feasible from a technical view.

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

New Electric Ireland wrote: ↑Tue Jan 12, 2021 6:18 pm

mikeselectricstuff wrote: ↑Mon Jan 11, 2021 12:52 pm Even just re-writing the same information ( lists of commands etc.) would be OK.

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

https://www.iec.ch/webstore/custserv/pdf/Licence.pdf

But that only applies to the actual documents as delivered (All clauses refer to "the publication"), same as copyright on a printed book. They only own the actual publication, not the information or concepts expressed within it.

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

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.

I found a green phy bridge only on the site you linked: https://www.codico.com/de/yellow-beet-p-1-1-pev-module . Just 42€

The QCA7000 driver is well written, as you would expect from a linux module.

Easiest start would probably be a BeagleBone to check if any communication can be established. Anyone have a CCS EV side socket left over?

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

mikeselectricstuff wrote: ↑Tue Jan 12, 2021 11:05 pm 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.

If you read my first post you'll see my concern is that we keep our projects legal on Open Inverter. Lots CCS information sources exist including CharIn and open source drivers so we do not need to violate IEC copyright nor publicise questionable workarounds on a public forum.

Jack Bauer wrote: ↑Wed Jan 13, 2021 1:11 pm Got you covered on the socket.

I recognise that socket... happy another New Electric donation is proving useful

johu wrote: ↑Wed Jan 13, 2021 10:43 am I found a green phy bridge only on the site you linked: https://www.codico.com/de/yellow-beet-p-1-1-pev-module . Just 42€

The QCA7000 driver is well written, as you would expect from a linux module.

Easiest start would probably be a BeagleBone to check if any communication can be established. Anyone have a CCS EV side socket left over?

I try to order this module many time and this store refuse to send.
If any one can buy it let me know.

Also lg have controller with SDK, chademo and CCS
https://www.google.com/url?sa=i&url=htt ... AdAAAAABAD
http://www.lginnotek.co.kr/en/itk_produ ... ontroller/
Based on AUTOSAR free OS.
AUTOSAR OS available on github, but without drivers and protocols.

New Electric Ireland wrote: ↑Wed Jan 13, 2021 1:50 pm

mikeselectricstuff wrote: ↑Tue Jan 12, 2021 11:05 pm 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.

If you read my first post you'll see my concern is that we keep our projects legal on Open Inverter. Lots CCS information sources exist including CharIn and open source drivers so we do not need to violate IEC copyright nor publicise questionable workarounds on a public forum.

Full protocol already placed by many project V2G CCS. If you we write new project on diffrent lanrage and hardware, we can't broke license.
But read paper of protocol can help to make this much faster!

Jack Bauer wrote: ↑Wed Jan 13, 2021 1:11 pm 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

I still think a better use for our resources would be to focus on one of the commercially available OEM solutions like the Kona controller which can be purchased new for $248 and second hand for $50;

viewtopic.php?f=17&t=1195#p19502

I know it's not as sexy as developing something from scratch but it reduces the burden on those of us who end up supporting end users

v-proto wrote: ↑Wed Jan 13, 2021 2:00 pm 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.

v-proto wrote: ↑Wed Jan 13, 2021 1:53 pm I try to order this module many time and this store refuse to send.

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?

New Electric Ireland wrote: ↑Wed Jan 13, 2021 2:01 pm

Jack Bauer wrote: ↑Wed Jan 13, 2021 1:11 pm 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

I still think a better use for our resources would be to focus on one of the commercially available OEM solutions like the Kona controller which can be purchased new for $248 and second hand for $50;

viewtopic.php?f=17&t=1195#p19502

I know it's not as sexy as developing something from scratch but it reduces the burden on those of us who end up supporting end users

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