Re: CCS EVSE and Car side
Posted: Wed Jan 13, 2021 2:15 pm
TrueNew Electric Ireland wrote: ↑Wed Jan 13, 2021 2:04 pmOf course but whatever we do must be legal if we want Open Inverter to survive.
TrueNew Electric Ireland wrote: ↑Wed Jan 13, 2021 2:04 pmOf course but whatever we do must be legal if we want Open Inverter to survive.
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.
Read rule of Autosar os.New Electric Ireland wrote: ↑Wed Jan 13, 2021 2:20 pmAFAIK 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.
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.New Electric Ireland wrote: ↑Wed Jan 13, 2021 2:20 pm My point is that designing hardware/software from the ground up is often a very poor use of limited resources.
Thats exactly the point. I have a deep seated repudiation for mystification. openinverter vs. mystery hahaJack Bauer wrote: ↑Wed Jan 13, 2021 1:11 pm 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
Thanks... It's a shame the "VCU Change Discussion" didn't happen beforejohu wrote: ↑Wed Jan 13, 2021 7:03 pm You keep making me split topics not a problem. It is now here: viewtopic.php?f=14&t=1343
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.New Electric Ireland wrote: ↑Wed Jan 13, 2021 1:50 pmIn 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.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.
YOU may not lend, lease, reproduce, distribute or otherwise exploit, whether commercially or not, the IEC Publication(s) to which this Licence Agreement relates
Sorry, couldn't find more info. Looks like people, presumably only companies, can get it only by contacting Mediatek.
Also, forgot to mention, Advantics has this CCS/Chademo controller.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
Mediatek not know about they have plc chip.darko31 wrote: ↑Sat Jan 16, 2021 9:58 pmSorry, couldn't find more info. Looks like people, presumably only companies, can get it only by contacting Mediatek.
Also, forgot to mention, Advantics has this CCS/Chademo controller.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
https://advantics.fr/ccs-chademo-controller/
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.v-proto wrote: ↑Fri Jan 22, 2021 11:22 am https://www.st.com/resource/en/datasheet/st7580.pdf
PLC on chip from ST
We plan to use this. Note it's a fork, so it may not be up to date, check out: http://openv2g.sourceforge.net/v-proto wrote: ↑Wed Jan 20, 2021 11:29 pm 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
In addition to what was said in this thread, check this company too: https://in-tech-smartcharging.com/New Electric Ireland wrote: ↑Wed Jan 13, 2021 2:08 pm 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?
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.v-proto wrote: ↑Wed Jan 13, 2021 10:12 am 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.
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.Jack Bauer wrote: ↑Wed Jan 13, 2021 1:11 pm 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
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.
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.
There are open source implementations for that. In fact the Siemens implementation has one, and RiseV2G uses a third party one.Besides, do you want to implement this horrible XML that's not XML protocol? (EXI - Efficient XML something) It's..bad.
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.
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).mikeselectricstuff wrote: ↑Mon Jan 11, 2021 12:52 pm Being from Quallcom, all data on the chips is unobtanium.
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.johu wrote: ↑Sat Jan 23, 2021 1:59 pm 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