Open source CCS using AR7420

Development and discussion of fast charging systems eg Chademo , CCS etc
Post Reply
User avatar
uhi22
Posts: 554
Joined: Mon Mar 14, 2022 3:20 pm
Location: Ingolstadt/Germany
Has thanked: 83 times
Been thanked: 392 times

Re: Open source CCS using AR7420

Post by uhi22 »

Besides the Python variant for Raspberry and Notebook, I was searching for a more compact variant. I found the ESP32-based WT32-ETH01, which is perfectly supported by Arduino IDE, starts up very fast and draws much less current than a Raspberry. I gave a try and was able to do some basic HomePlug communication, reading out the software versions of the connected tpLink modems. This looks quite promising. Of course, the porting of the existing python solution to C is some effort, but I think it's well invested time if we think into the direction that finally it may run on any controller which has a C compiler...
image.png
Stored the first experimental sources here: https://github.com/uhi22/ccs32
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: Open source CCS using AR7420

Post by catphish »

uhi22 wrote: Sat Mar 11, 2023 9:44 pm I found the ESP32-based WT32-ETH01, which is perfectly supported by Arduino IDE, starts up very fast and draws much less current than a Raspberry.
I definitely like this! It means writing a whole embedded implementation of the EXI comunication stack though I guess.
User avatar
uhi22
Posts: 554
Joined: Mon Mar 14, 2022 3:20 pm
Location: Ingolstadt/Germany
Has thanked: 83 times
Been thanked: 392 times

Re: Open source CCS using AR7420

Post by uhi22 »

Well, the preconditions for this activity are quite good:
- For the homeplug ethernet stuff and the SLAC state machine, the python code was written in a way that it was easy portable from python to C. This is finished, SLAC is working (at least with simulated EVSE on the other end).
- For the SDP.UDP.IPv6: also here the python is a good basis. Porting is nearly finished.
- For the TCP.IPv6: That's the harder part, need to find either an existing TCP or, as an exercise, re-invent the wheel and create a (minimal) TCP. Does not look too complicated.
- For the EXI decoder/encoder: The code from https://github.com/Martin-P/OpenV2G is normal C code, it compiles in the Arduino IDE. No need anymore for the complicated command line interface which I created in https://github.com/uhi22/OpenV2Gx to make it usable from Python.
- The PEV charging state machine can be easyly ported from python to C.
- The hardware-interface does not need to use serial communication and a second controller to switch the StateC and the relay, it can just use two digital output pins of the WT32-ETH01. Easy doing.
Summarized: Yes, some effort, but no real hurdles.
User avatar
johu
Site Admin
Posts: 5684
Joined: Thu Nov 08, 2018 10:52 pm
Location: Kassel/Germany
Has thanked: 153 times
Been thanked: 960 times
Contact:

Re: Open source CCS using AR7420

Post by johu »

Pure awesomeness :)

I think I will build a CCS to CHAdeMO adapter at some point. Will just send an extra CAN message with the battery voltage to handle precharging. That way there can be a straight through connection on the power pins.
Easiest power supply should be from the cigarette lighter, at least for bootstrapping.
Support R/D and forum on Patreon: https://patreon.com/openinverter - Subscribe on odysee: https://odysee.com/@openinverter:9
User avatar
lsh3rd
Posts: 67
Joined: Thu Aug 19, 2021 12:30 am
Location: Atlanta, GA USA
Has thanked: 58 times
Been thanked: 35 times

Re: Open source CCS using AR7420

Post by lsh3rd »

uhi22 wrote: Thu Mar 16, 2023 8:12 am - For the TCP.IPv6: That's the harder part, need to find either an existing TCP or, as an exercise, re-invent the wheel and create a (minimal) TCP. Does not look too complicated.
Take a look at Lightweight IP (lwIP): https://en.wikipedia.org/wiki/LwIP
User avatar
celeron55
Posts: 774
Joined: Thu Jul 04, 2019 3:04 pm
Location: Finland
Has thanked: 27 times
Been thanked: 110 times
Contact:

Re: Open source CCS using AR7420

Post by celeron55 »

I'm going to attempt installing a version of the Python implementation on my car. Wish me luck. I've so far crammed all the logic boards I need inside this enclosure.

I still need to port all the stuff onto this. The Python code and OpenV2Gx should run easily, but I'll have to redo the hardware integration. Then I'll have to somehow cram the CCS connector, CCS contactors and high voltage connections into the car which doesn't really have room for them.

I expect this to be become obsolete in a couple of months as the esp32 C implementation is made, but I am likely to end up having the world's first open source CCS equipped vehicle, no matter how crude this is. :mrgreen:
Attachments
20230316_211201.jpg
User avatar
uhi22
Posts: 554
Joined: Mon Mar 14, 2022 3:20 pm
Location: Ingolstadt/Germany
Has thanked: 83 times
Been thanked: 392 times

Re: Open source CCS using AR7420

Post by uhi22 »

Really great :-) What controller board is this? And where did you find this housing/connector/PCB assembly?
User avatar
celeron55
Posts: 774
Joined: Thu Jul 04, 2019 3:04 pm
Location: Finland
Has thanked: 27 times
Been thanked: 110 times
Contact:

Re: Open source CCS using AR7420

Post by celeron55 »

The base board is my https://github.com/celeron55/ipdm56 (I do have a pile of them for sale if someone wants one, but haven't had time to post about that yet)

This is a helpful but not a plug and play board for this purpose. I have done quite some customization by hand for this, mainly removing resistors to reroute the PP and CP lines onto the breadboard and to get the UART to connect to the Orange Pi instead of external USB. Also added a more powerful 5V regulator. With these customizations, the AVR is acting as a host processor for the Linux board, being able to power it up and down based on PP/CP/CAN status, but the Linux board can still flash the AVR on the fly.

It uses the same chinese enclosure as Damien's ZombieVerter.

The Linux board is Orange Pi Zero
User avatar
asavage
Posts: 328
Joined: Sat May 14, 2022 10:57 pm
Location: Oak Harbor, Washington, USA
Has thanked: 269 times
Been thanked: 103 times
Contact:

Re: Open source CCS using AR7420

Post by asavage »

celeron55 wrote: Fri Mar 17, 2023 1:40 am It uses the same chinese enclosure as Damien's ZombieVerter.
https://openinverter.org/wiki/ZombieVerter_VCU#The_enclosure_kit_links
Al Savage
2014 RAV4 EV
NissanDiesel
User avatar
celeron55
Posts: 774
Joined: Thu Jul 04, 2019 3:04 pm
Location: Finland
Has thanked: 27 times
Been thanked: 110 times
Contact:

Re: Open source CCS using AR7420

Post by celeron55 »

I went to a charger and connected a standalone test rig in the boot.

I'm getting the error:

Code: Select all

[PEV] initiating SDP request
[addressManager] ERROR: invalid length of IPv6 string. Expected be 16 bytes, means 32 hex characters. Found 9
I need to expand the logging to actually tell me the address so that I can see what's wrong.

Not sure whether I can reproduce this without actually trying to charge at the charger. However, this is promising as it is well into the initialization process, appearing to be step 20 in the pyPLC README example flow.

EDIT: I even have the log from the charger. Looks to me like the charger is getting the correct message, but it can't send the response to the car because the car is including the wrong source address, as the car is unable to decode its own IPv6 address. Makes sense.
User avatar
uhi22
Posts: 554
Joined: Mon Mar 14, 2022 3:20 pm
Location: Ingolstadt/Germany
Has thanked: 83 times
Been thanked: 392 times

Re: Open source CCS using AR7420

Post by uhi22 »

At the start of the log file, the addressManager should show all link-local IPv6 addresses, which he detected. What is shown there? Seems we have a problem in interpreting the result of

Code: Select all

subprocess.run(["ifconfig"]...)
, which is used in addressManager function

Code: Select all

findLinkLocalIpv6Address
.

BTW: If you see the chance, to make a log from the charger for "good case" with a real car, this could help to understand the issue with the failed weldingDetection/SessionStop.
User avatar
celeron55
Posts: 774
Joined: Thu Jul 04, 2019 3:04 pm
Location: Finland
Has thanked: 27 times
Been thanked: 110 times
Contact:

Re: Open source CCS using AR7420

Post by celeron55 »

It's saying:

Code: Select all

[addressManager] Found 0 link-local IPv6 addresses.
However I just realized I have another log where it does find a link-local IPv6 address. This is the furthest it gets:

Code: Select all

[PEVSLAC] from 1 entering 2
[PEVSLAC] Sending SLAC_PARAM.REQ...
[PEVSLAC] from 2 entering 4
[PEVSLAC] Timeout while waiting for SLAC_PARAM.CNF
[PEVSLAC] from 4 entering 0
[PEVSLAC] searching for modems, transmitting GET_KEY.REQ...
[PEVSLAC] from 0 entering 1
received GET_KEY.CNF
Modem #1 has 90:9A:4A:5B:61:92 and result code is 0(OK)
The local modem has key 0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x8 0x9 0xa 0xb 0xc 0xd 0xe 0xf 0x10 
This is the developer NMK.
From GetKeyCnf, got network ID (NID) 0x0 0x0 0x0 0x0 0x0 0x0 0x0 
[PEVSLAC] It was sufficient time to get the answers from the modems.
[PEVSLAC] from 1 entering 2
It never gets to this line:

Code: Select all

received SLAC_PARAM.CNF
or anything that would come after it, which the other attempt did, but that attempt didn't have the local IPv6 address. So, in the example flow, that attempt only got to 7.
User avatar
uhi22
Posts: 554
Joined: Mon Mar 14, 2022 3:20 pm
Location: Ingolstadt/Germany
Has thanked: 83 times
Been thanked: 392 times

Re: Open source CCS using AR7420

Post by uhi22 »

So we see multiple issues:
- The local IPv6 address is not always retrievable using the "ifconfig" command. You could try locally (without any charger, maybe without and with modem connected to the ethernet) what "ifconfig" on the command line tells us.
- The missing SLAC_PARAM.CNF points to a missing connection to the charger. Normally the charger should send this response, if we have our modem and the 2k7 resistor on the CP line.

For better orientation and knowledge sharing, today I added numbered checkpoints to the example flow chapter in the readme.md, and also added the same checkpoint number to the code, so that they appear in the log (at the moment only a few important, not yet all details). This makes it more easy to discuss how far the sequence is running, and to sort the thoughts into the right direction.
Using these checkpoint numbers, your two current issues are:

- Checkpoint100 is reached, but not Checkpoint101. The charger does not send a SlacParamResponse.
- Sometimes the Checkpoint100 and 101 are fine, but it stops at Checkpoint200, because no valid link-local IPv6 address could be found at the start of the python script.
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: Open source CCS using AR7420

Post by catphish »

uhi22 wrote: Mon Mar 20, 2023 8:50 pm So we see multiple issues:
- The local IPv6 address is not always retrievable using the "ifconfig" command. You could try locally (without any charger, maybe without and with modem connected to the ethernet) what "ifconfig" on the command line tells us.
ifconfig is very deprecated and often fails to show IPs. If at all possible, use the "ip addr" command from iproute2.
User avatar
celeron55
Posts: 774
Joined: Thu Jul 04, 2019 3:04 pm
Location: Finland
Has thanked: 27 times
Been thanked: 110 times
Contact:

Re: Open source CCS using AR7420

Post by celeron55 »

Did a third and fourth test, with no changes whatsoever.

Third test failed with no link-local IPv6 address again. Then I added sys.exit(1) to fsmPev.py to quit when there's no address so that I don't accidentally do that ever again.

Fourth test got me to SDP again:

Code: Select all

[PEVSLAC] SDP was not done yet. Now we start it.
[PEVSLAC] from 15 entering 16
[PEV] initiating SDP request
[PEVSLAC] from 16 entering 16
[PEV] initiating SDP request
[PEVSLAC] from 16 entering 16
[PEV] initiating SDP request
[PEVSLAC] from 16 entering 16
...
[PEV] initiating SDP request
[PEVSLAC] from 16 entering 16
[PEV] initiating SDP request
[PEVSLAC] from 16 entering 16
[PEVSLAC] ERROR: Did not receive SDP response. Starting from the beginning.
[PEVSLAC] from 16 entering 0
So it's sending something hopefully valid now. I don't have a packet sniffer running so not sure what.

I was given the charger log again. Let's hope I can get it in the future also, but I can't count on that.

(Sorry, had to remove the charger logs from being public)

Nothing wrong on the charger side, but pyPLC receives nothing.

fe80::9bc5:305c:fc41:d268 matches the link-local address that pyPLC prints at startup. However, I'm starting to think the address can change after startup by the time SDP is attempted. Maybe it should be checked again then? Thoughts?

The network interface didn't have any IPv6 address when I ran ifconfig after the session, so my suspicion is that if the address was re-checked when SDP was initiated, the interface wouldn't have had any address, or it might have had a different address.
User avatar
asavage
Posts: 328
Joined: Sat May 14, 2022 10:57 pm
Location: Oak Harbor, Washington, USA
Has thanked: 269 times
Been thanked: 103 times
Contact:

Re: Open source CCS using AR7420

Post by asavage »

celeron55 wrote: Tue Mar 21, 2023 7:02 pm The network interface didn't have any IPv6 address when I ran ifconfig after the session . . .
This is very much not my wheelhouse, but from the light reading I did, prompted by Charlie's post above, I think I learned that one of the reasons that ipconfig (circa 1999) is out of favour is specifically because it does not deal reliably with IPv6. iproute2's 'ip' command replaces ifconfig. Handy cheat sheet (one of many available) is at https://access.redhat.com/sites/default/files/attachments/rh_ip_command_cheatsheet_1214_jcs_print.pdf


partial of 'ip' command cheat sheet
partial of 'ip' command cheat sheet
This is linux-specific (ie Windoze, Unix, etc. still largely seem to prefer ipconfig). I'm sure someone more knowledgeable will come by and correct my misapprehension any minute. Cunninham's Law and all . . .
Al Savage
2014 RAV4 EV
NissanDiesel
User avatar
CCSknowitall
Posts: 105
Joined: Fri Jun 04, 2021 1:47 pm
Has thanked: 1 time
Been thanked: 28 times

Re: Open source CCS using AR7420

Post by CCSknowitall »

You guys are going from state C back to state B after power delivery request (the second one), prior to sending welding detection, right? If you are still in state C when sending welding, that could certainly throw a wrench into the charger’s state machine, although not technically a sequence error.
User avatar
uhi22
Posts: 554
Joined: Mon Mar 14, 2022 3:20 pm
Location: Ingolstadt/Germany
Has thanked: 83 times
Been thanked: 392 times

Re: Open source CCS using AR7420

Post by uhi22 »

celeron55 wrote: Tue Mar 21, 2023 7:02 pm
Nothing wrong on the charger side, but pyPLC receives nothing.

fe80::9bc5:305c:fc41:d268 matches the link-local address that pyPLC prints at startup. However, I'm starting to think the address can change after startup by the time SDP is attempted. Maybe it should be checked again then? Thoughts?

The network interface didn't have any IPv6 address when I ran ifconfig after the session, so my suspicion is that if the address was re-checked when SDP was initiated, the interface wouldn't have had any address, or it might have had a different address.
Found out two issues in the implementation:
1. When the modem is not connected or not powered, the ip addr does not report an IPv6 for the ethernet. But, the pyPlc uses the deprecated ifconfig, and wrongly uses the IPv6 address of the WLAN interface. This is for sure wrong.
2. Similar for the MAC. If we have multiple interfaces, the pyPlc may take the wrong one. It chose the WLAN MAC in my case, instead of the Ethernet MAC. This leads to the fact, that the low-level-communication (HomePlug, SDP) uses the wrong MAC as source address. Could be an explanation, when the SDP did not work. The charger will sent the SDP response to the WLAN MAC, but the ethernet driver of the car sorts this out, because it is neigther a broadcast MAC nor the physical MAC of the Ethernet. In the end the SDP response does not reach the pyPlc.

I pushed an update, with the following improvements: use "ip addr" instead of ifconfig. Filter out the other interfaces, only take real ethernet related addresses. And stop the script, if no IPv6 address is found.

https://github.com/uhi22/pyPLC/commit/9 ... 27d328b841
User avatar
celeron55
Posts: 774
Joined: Thu Jul 04, 2019 3:04 pm
Location: Finland
Has thanked: 27 times
Been thanked: 110 times
Contact:

Re: Open source CCS using AR7420

Post by celeron55 »

More about attempt #4.

This was fsmPev's opinion about addresses at startup:

Code: Select all

[addressManager] we have local MAC 02:81:7C:A7:12:B4.
[addressManager] we have local MAC 12:81:7C:A7:12:B4.
[addressManager] Found 1 link-local IPv6 addresses.
fe80::9bc5:305c:fc41:d268
[addressManager] Local IPv6 is fe80::9bc5:305c:fc41:d268
[addressManager] Found 1 link-local IPv6 addresses.
fe80::9bc5:305c:fc41:d268
[addressManager] Local IPv6 is fe80::9bc5:305c:fc41:d268
[addressManager] will give local MAC 12:81:7C:A7:12:B4
[addressManager] will give local MAC 12:81:7C:A7:12:B4
pyPlcIpv6 started with ownMac 12:81:7C:A7:12:B4
[addressManager] will give local MAC 12:81:7C:A7:12:B4
udplog started with ownMac 12:81:7C:A7:12:B4
sniffer created at eth0
This was the ifconfig I ran after the session:

Code: Select all

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 02:81:7c:a7:12:b4  txqueuelen 1000  (Ethernet)
        RX packets 161  bytes 45610 (44.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1408  bytes 140076 (136.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 47  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 48  bytes 3888 (3.7 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 48  bytes 3888 (3.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 12:81:7c:a7:12:b4  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
MAC: It used wlan0's MAC address, which was of course completely wrong. (fact)

IPv6: It was probably using eth0's IPv6 address, which then disappeared during the session. (my guess) The WLAN interface wasn't connected to anything at the time and definitely didn't have an IPv6 address so it couldn't have been the source for the address.

The new pyPLC commit (97ec82cef5) likely will fix the MAC issue.

However, I'm doubtful whether it's able to fix the disappearing IPv6 address issue. Would it make sense to forcibly set the address on the interface before doing SDP?

Well I guess the SDP issue could have been related solely to the MAC. I don't fully understand how it works anyway. I guess I'll test and see.
User avatar
uhi22
Posts: 554
Joined: Mon Mar 14, 2022 3:20 pm
Location: Ingolstadt/Germany
Has thanked: 83 times
Been thanked: 392 times

Re: Open source CCS using AR7420

Post by uhi22 »

celeron55 wrote: Wed Mar 22, 2023 9:55 am Would it make sense to forcibly set the address on the interface before doing SDP?
I see no way of "forcing" the address assignment. The IP address is calculated by the operating system, and is available and stable as long as a physical connection of the ethernet is present. At least this is what I have seen in the tests. So the issue, that the IP address is "gone" means, that the communication to the modem is lost. I have seen such topics also during my tests, that after around one or two minutes of inactivity the modem seems to decide to go to sleep, and so the ethernet link is away, and the linux "forgets" the IPv6. This topic with the (assumed) modem sleep is not fully clear, in most cases I do not observe this problem. Maybe also a power supply topic.
User avatar
celeron55
Posts: 774
Joined: Thu Jul 04, 2019 3:04 pm
Location: Finland
Has thanked: 27 times
Been thanked: 110 times
Contact:

Re: Open source CCS using AR7420

Post by celeron55 »

Attempt #5. Got past SDP this time:

Code: Select all

[PEV] initiating SDP request
[PEVSLAC] from 16 entering 16
V2GTP (28bytes) = 01 FE 90 01 00 00 00 14 FE 80 00 00 00 00 00 00 EE A2 9B FF FE 27 A4 0E D4 31 10 00
[PEV] Checkpoint203: Received SDP response
[addressManager] charger has IP fe80:0000:0000:0000:eea2:9bff:fe27:a40e
[addressManager] charger has TCP port 54321
[PEVSLAC] Now we know the chargers IP.
[PLCWORKER] Network is established, ready for TCP.
[PEV] re-initializing fsmPev
[HARDWAREINTERFACE] Setting CP line into state B.
[HARDWAREINTERFACE] Switching PowerRelay OFF.
[HARDWAREINTERFACE] Switching Relay2 OFF.
[PEVSLAC] from 16 entering 12
[HARDWAREINTERFACE] << CP state confirmed
[HARDWAREINTERFACE] << Contactor state confirmed
[PEV] Checkpoint301: connecting
TCP connecting to fe80:0000:0000:0000:eea2:9bff:fe27:a40e port 54321...
[PEV] connected
from 1 entering 2
[PEV] Checkpoint400: Sending the initial SupportedApplicationProtocolReq
from 2 entering 3
[PEV] In state WaitForSupportedApplicationProtocolResponse, received (12bytes) = 01 FE 80 01 00 00 00 04 80 40 00 40
[PEV] {
"msgName": "supportedAppProtocolRes",
"info": "4 bytes to convert",
"error": "",
"result": "ResponseCode 0, SchemaID_isUsed 1, SchemaID 1",
"schema": "appHandshake",
"debug": ""
}
[PEV] Checkpoint403: Schema negotiated. And Checkpoint500: Will send SessionSetupReq
[PEV] responding (23bytes) = 01 FE 80 01 00 00 00 0F 80 9A 02 00 00 00 00 00 00 00 00 11 D0 00 00
from 3 entering 4
from 4 entering 99
[PEV] re-initializing fsmPev
[HARDWAREINTERFACE] Setting CP line into state B.
[HARDWAREINTERFACE] Switching PowerRelay OFF.
[HARDWAREINTERFACE] Switching Relay2 OFF.
[HARDWAREINTERFACE] << CP state confirmed
[HARDWAREINTERFACE] << Contactor state confirmed
[PEV] Checkpoint301: connecting
TCP connecting to fe80:0000:0000:0000:eea2:9bff:fe27:a40e port 54321...
[PEV] connected
from 1 entering 2
[PEV] Checkpoint400: Sending the initial SupportedApplicationProtocolReq
from 2 entering 3
from 3 entering 99
[PEV] re-initializing fsmPev
[HARDWAREINTERFACE] Setting CP line into state B.
[HARDWAREINTERFACE] Switching PowerRelay OFF.
[HARDWAREINTERFACE] Switching Relay2 OFF.
[HARDWAREINTERFACE] << CP state confirmed
[HARDWAREINTERFACE] << Contactor state confirmed
[PEV] Checkpoint301: connecting
TCP connecting to fe80:0000:0000:0000:eea2:9bff:fe27:a40e port 54321...
[PEV] connected
from 1 entering 2
[PEV] Checkpoint400: Sending the initial SupportedApplicationProtocolReq
from 2 entering 3
from 3 entering 99
[PEV] re-initializing fsmPev
[HARDWAREINTERFACE] Setting CP line into state B.
[HARDWAREINTERFACE] Switching PowerRelay OFF.
[HARDWAREINTERFACE] Switching Relay2 OFF.
[HARDWAREINTERFACE] << CP state confirmed
[HARDWAREINTERFACE] << Contactor state confirmed
[PEV] Checkpoint301: connecting
TCP connecting to fe80:0000:0000:0000:eea2:9bff:fe27:a40e port 54321...
[PEV] connected
from 1 entering 2
[PEV] Checkpoint400: Sending the initial SupportedApplicationProtocolReq
from 2 entering 3
from 3 entering 99
[PEV] re-initializing fsmPev
[HARDWAREINTERFACE] Setting CP line into state B.
[HARDWAREINTERFACE] Switching PowerRelay OFF.
[HARDWAREINTERFACE] Switching Relay2 OFF.
[HARDWAREINTERFACE] << CP state confirmed
[HARDWAREINTERFACE] << Contactor state confirmed
[PEV] Checkpoint301: connecting
TCP connecting to fe80:0000:0000:0000:eea2:9bff:fe27:a40e port 54321...
TCP connection failed[Errno 111] Connection refused
[PEV] Connection failed. Will try again.
[PEV] re-initializing fsmPev
[HARDWAREINTERFACE] Setting CP line into state B.
[HARDWAREINTERFACE] Switching PowerRelay OFF.
[HARDWAREINTERFACE] Switching Relay2 OFF.
[HARDWAREINTERFACE] << CP state confirmed
[HARDWAREINTERFACE] << Contactor state confirmed
[PEVSLAC] Checking whether the pairing worked, by GET_KEY.REQ...
[PEVSLAC] from 12 entering 13
received GET_KEY.CNF
Modem #1 has 90:9A:4A:5B:61:92 and result code is 0(OK)
The local modem has key 0x1 0xdd 0x97 0x33 0xae 0xe4 0x33 0x74 0xce 0xb1 0x2d 0x81 0x45 0x4 0xd3 0x7
This is NOT the developer NMK.
From GetKeyCnf, got network ID (NID) 0x8f 0x54 0xb0 0x82 0x3f 0xbb 0x8
received GET_KEY.CNF
Modem #2 has EC:A2:9B:27:A4:0E and result code is 1(NOK)
Info: NOK is normal for remote modems.
From GetKeyCnf, got network ID (NID) 0x8f 0x54 0xb0 0x82 0x3f 0xbb 0x8
[PEVSLAC] It was sufficient time to get the answers from the modems.
[PEVSLAC] EVSE is up, pairing successful.
[PEVSLAC] Requesting SW versions from the modems...
[PEVSLAC] from 13 entering 14
[SNIFFER] received GET_SW.CNF
[SNIFFER] For 90:9A:4A:5B:61:92 the software version is MAC-QCA7420-1.3.1.2141-00-20160428-CS
[SNIFFER] received GET_SW.CNF
[SNIFFER] For EC:A2:9B:27:A4:0E the software version is MAC-QCA7005-1.2.5.3207-00-20180927-CS
[PEV] Checkpoint301: connecting
TCP connecting to fe80:0000:0000:0000:eea2:9bff:fe27:a40e port 54321...
TCP connection failed[Errno 111] Connection refused
[PEV] Connection failed. Will try again.
[PEV] re-initializing fsmPev
[HARDWAREINTERFACE] Setting CP line into state B.
[HARDWAREINTERFACE] Switching PowerRelay OFF.
[HARDWAREINTERFACE] Switching Relay2 OFF.
[PEVSLAC] It was sufficient time to get the SW versions from the modems.
[PEVSLAC] from 14 entering 15 
[HARDWAREINTERFACE] << CP state confirmed
[HARDWAREINTERFACE] << Contactor state confirmed
[PEVSLAC] from 15 entering 12
[PEV] Checkpoint301: connecting
TCP connecting to fe80:0000:0000:0000:eea2:9bff:fe27:a40e port 54321...
TCP connection failed[Errno 111] Connection refused
[PEV] Connection failed. Will try again.
[PEV] re-initializing fsmPev
[HARDWAREINTERFACE] Setting CP line into state B.
[HARDWAREINTERFACE] Switching PowerRelay OFF.
[HARDWAREINTERFACE] Switching Relay2 OFF.
[HARDWAREINTERFACE] << CP state confirmed
[HARDWAREINTERFACE] << Contactor state confirmed
[PEV] Checkpoint301: connecting
TCP connecting to fe80:0000:0000:0000:eea2:9bff:fe27:a40e port 54321...
TCP connection failed[Errno 111] Connection refused
[PEV] Connection failed. Will try again.
[PEV] re-initializing fsmPev
[HARDWAREINTERFACE] Setting CP line into state B.
[HARDWAREINTERFACE] Switching PowerRelay OFF.
[HARDWAREINTERFACE] Switching Relay2 OFF.
[HARDWAREINTERFACE] << CP state confirmed
[HARDWAREINTERFACE] << Contactor state confirmed
[PEV] Checkpoint301: connecting
TCP connecting to fe80:0000:0000:0000:eea2:9bff:fe27:a40e port 54321...
TCP connection failed[Errno 111] Connection refused
[PEV] Connection failed. Will try again.
[PEV] re-initializing fsmPev
[HARDWAREINTERFACE] Setting CP line into state B.
[HARDWAREINTERFACE] Switching PowerRelay OFF.
[HARDWAREINTERFACE] Switching Relay2 OFF.
[HARDWAREINTERFACE] << CP state confirmed
[HARDWAREINTERFACE] << Contactor state confirmed
[PEV] Checkpoint301: connecting
TCP connecting to fe80:0000:0000:0000:eea2:9bff:fe27:a40e port 54321...
TCP connection failed[Errno 111] Connection refused
[PEV] Connection failed. Will try again. 
[PEV] re-initializing fsmPev
[HARDWAREINTERFACE] Setting CP line into state B.
[HARDWAREINTERFACE] Switching PowerRelay OFF.
[HARDWAREINTERFACE] Switching Relay2 OFF.
[HARDWAREINTERFACE] << CP state confirmed
[HARDWAREINTERFACE] << Contactor state confirmed
[PEV] Checkpoint301: connecting
TCP connecting to fe80:0000:0000:0000:eea2:9bff:fe27:a40e port 54321...
TCP connection failed[Errno 111] Connection refused
[PEV] Connection failed. Will try again.
[PEV] re-initializing fsmPev
[HARDWAREINTERFACE] Setting CP line into state B.
[HARDWAREINTERFACE] Switching PowerRelay OFF.
[HARDWAREINTERFACE] Switching Relay2 OFF.
[HARDWAREINTERFACE] << CP state confirmed
[HARDWAREINTERFACE] << Contactor state confirmed
[PEV] Checkpoint301: connecting
TCP connecting to fe80:0000:0000:0000:eea2:9bff:fe27:a40e port 54321...
TCP connection failed[Errno 111] Connection refused
[PEV] Connection failed. Will try again. 
[PEV] re-initializing fsmPev
[HARDWAREINTERFACE] Setting CP line into state B.
[HARDWAREINTERFACE] Switching PowerRelay OFF.
[HARDWAREINTERFACE] Switching Relay2 OFF.
[HARDWAREINTERFACE] << CP state confirmed
[HARDWAREINTERFACE] << Contactor state confirmed
[PEV] Checkpoint301: connecting
TCP connecting to fe80:0000:0000:0000:eea2:9bff:fe27:a40e port 54321...
TCP connection failed[Errno 111] Connection refused
[PEV] Connection failed. Will try again.
[PEV] re-initializing fsmPev
[HARDWAREINTERFACE] Setting CP line into state B.
[HARDWAREINTERFACE] Switching PowerRelay OFF.
[HARDWAREINTERFACE] Switching Relay2 OFF.
[HARDWAREINTERFACE] << CP state confirmed
[HARDWAREINTERFACE] << Contactor state confirmed
[HARDWAREINTERFACE] << inlet_voltage=-8
[PEV] Checkpoint301: connecting
TCP connecting to fe80:0000:0000:0000:eea2:9bff:fe27:a40e port 54321...
[PEV] connected
from 1 entering 2
[PEV] Checkpoint400: Sending the initial SupportedApplicationProtocolReq
from 2 entering 3
[PEV] In state WaitForSupportedApplicationProtocolResponse, received (12bytes) = 01 FE 80 01 00 00 00 04 80 40 00 40
[PEV] {
"msgName": "supportedAppProtocolRes",
"info": "4 bytes to convert",
"error": "",
"result": "ResponseCode 0, SchemaID_isUsed 1, SchemaID 1",
"schema": "appHandshake",
"debug": ""
}
[PEV] Checkpoint403: Schema negotiated. And Checkpoint500: Will send SessionSetupReq
[PEV] responding (23bytes) = 01 FE 80 01 00 00 00 0F 80 9A 02 00 00 00 00 00 00 00 00 11 D0 00 00
from 3 entering 4
[HARDWAREINTERFACE] << inlet_voltage=-9
from 4 entering 99
[PEV] re-initializing fsmPev
[HARDWAREINTERFACE] Setting CP line into state B.
[HARDWAREINTERFACE] Switching PowerRelay OFF.
[HARDWAREINTERFACE] Switching Relay2 OFF.
[HARDWAREINTERFACE] << CP state confirmed
[HARDWAREINTERFACE] << Contactor state confirmed
[PEVSLAC] Checking whether the pairing worked, by GET_KEY.REQ...
[PEVSLAC] from 12 entering 13
received GET_KEY.CNF
Modem #1 has 90:9A:4A:5B:61:92 and result code is 0(OK)
The local modem has key 0x1 0xdd 0x97 0x33 0xae 0xe4 0x33 0x74 0xce 0xb1 0x2d 0x81 0x45 0x4 0xd3 0x7
This is NOT the developer NMK.
From GetKeyCnf, got network ID (NID) 0x8f 0x54 0xb0 0x82 0x3f 0xbb 0x8
[PEVSLAC] It was sufficient time to get the answers from the modems.
[PEVSLAC] No EVSE seen (yet). Still waiting for it.
[PEVSLAC] from 13 entering 12
[PEV] Checkpoint301: connecting
TCP connecting to fe80:0000:0000:0000:eea2:9bff:fe27:a40e port 54321...
TCP connection failedtimed out
[PEV] Connection failed. Will try again.
[PEV] re-initializing fsmPev
[HARDWAREINTERFACE] Setting CP line into state B.
[HARDWAREINTERFACE] Switching PowerRelay OFF.
[HARDWAREINTERFACE] Switching Relay2 OFF.
[HARDWAREINTERFACE] << CP state confirmed
[HARDWAREINTERFACE] << Contactor state confirmed
[PEVSLAC] Checking whether the pairing worked, by GET_KEY.REQ...
[PEVSLAC] from 12 entering 13
received GET_KEY.CNF
Modem #1 has 90:9A:4A:5B:61:92 and result code is 0(OK)
The local modem has key 0x1 0xdd 0x97 0x33 0xae 0xe4 0x33 0x74 0xce 0xb1 0x2d 0x81 0x45 0x4 0xd3 0x7
This is NOT the developer NMK.
From GetKeyCnf, got network ID (NID) 0x8f 0x54 0xb0 0x82 0x3f 0xbb 0x8
[PEV] Checkpoint301: connecting
TCP connecting to fe80:0000:0000:0000:eea2:9bff:fe27:a40e port 54321...
TCP connection failedtimed out
[PEV] Connection failed. Will try again.
[PEV] re-initializing fsmPev
[HARDWAREINTERFACE] Setting CP line into state B.
[HARDWAREINTERFACE] Switching PowerRelay OFF.
[HARDWAREINTERFACE] Switching Relay2 OFF.
[HARDWAREINTERFACE] << CP state confirmed
[HARDWAREINTERFACE] << Contactor state confirmed
[PEVSLAC] It was sufficient time to get the answers from the modems.
[PEVSLAC] No EVSE seen (yet). Still waiting for it.
[PEVSLAC] from 13 entering 12
[PEV] Checkpoint301: connecting
TCP connecting to fe80:0000:0000:0000:eea2:9bff:fe27:a40e port 54321...
TCP connection failedtimed out
It sends SessionSetupReq (Checkpoint500) and then... goes back to sending SupportedApplicationProtocolReq. What's going on?
User avatar
catphish
Posts: 954
Joined: Fri Oct 08, 2021 11:02 pm
Location: Dorset, UK
Has thanked: 93 times
Been thanked: 179 times

Re: Open source CCS using AR7420

Post by catphish »

I just had a look at the code here and I have a couple of suggestions on the IP address side of things since I have a fair bit of experience with Linux networking:
1) Consider passing the interface name when starting the application, or configure it. This piece of information is essential. Filtering in the first interface called "eth" might work for the Pi, but I think it's reasonable to make this configurable.
2) You can probably dramatically simplify the process for fetching the addresses. Consider the following commands, with easily parsed output:

Code: Select all

charlie@charlie-ThinkPad-T14:~$ ip --brief -6 link show dev wlp0s20f3
wlp0s20f3        UP             e0:d4:e8:ba:d7:4a <BROADCAST,MULTICAST,UP,LOWER_UP> 
charlie@charlie-ThinkPad-T14:~$ ip --brief -6 address show dev wlp0s20f3
wlp0s20f3        UP             2001:470:1f09:123::99/64 fe80::de87:e22e:919c:ae8a/64 
Next, I'm really not sure why you need the local MAC and IP address, but perhaps you don't really need them at all? Consider the following flow instead:
1) Get a hardware identifier using uuid.getnode() - This may not be the MAC address of your interface, but if you're using it as an identifier in an upper layer protocol, it likely doesn't matter.
2) Initially don't worry about the local IP address. Instead just blinding send multicast requests to the desired interface and wait for replies. If and when the replies arrive, they will contain your IP address (that the OS automatically selected) anyway.
3) If you don't get a reply, just keep trying, once you have a local address and you're connected to something, you should get a reply.

As an example, here's the (ruby) code I use to discover an EVSE. Note that the only piece of information required is the interface name. When a reply arrives, the IP can easily be derived from the metadata attached to the reply.

Code: Select all

require 'socket'
datagram = [1, 0xFE, 0x9000, 2, 0x10, 0x00].pack('ccnNcc')
socket = UDPSocket.new(Socket::AF_INET6)
socket.send(datagram, 0, 'ff02::1%enp0s31f6', 15118)
message, server = socket.recvfrom(1500)
Sorry if I'm way off the mark and you need this data for some other purpose, but thought I'd mention this in case it makes things simpler, more reliable, and more portable across operating systems.
User avatar
uhi22
Posts: 554
Joined: Mon Mar 14, 2022 3:20 pm
Location: Ingolstadt/Germany
Has thanked: 83 times
Been thanked: 392 times

Re: Open source CCS using AR7420

Post by uhi22 »

celeron55 wrote: Wed Mar 22, 2023 6:58 pm It sends SessionSetupReq (Checkpoint500) and then... goes back to sending SupportedApplicationProtocolReq. What's going on?
The transition to state 99 means: We run into timeout, and then try to re-start. The really good news is, that the SLAC, SDP and TCP works, and the first EXI messages are exchanged. Congratulations :-)
The question is, why after sending the SessionSetupRequest, we do not get a response. I checked the EXI data from the request, it is identical to the SessionSetupReq which I successfully tested on Alpitronics and ABB chargers. Of course, still it may be not fully correct, and your charger may ignore it. Or it sends a response, and we ignore it because of unknown reason. A pcap file would be very helpful.
User avatar
celeron55
Posts: 774
Joined: Thu Jul 04, 2019 3:04 pm
Location: Finland
Has thanked: 27 times
Been thanked: 110 times
Contact:

Re: Open source CCS using AR7420

Post by celeron55 »

I've been handed a bit of a slap on the wrist about sharing the charger logs here, so I'll have to try to make sense of the charger log myself (still discussing attempt #5):

- The charger is receiving the SessionSetupRequest as 01fe80010000000f809a02000000000000000011d00000, length 23
- It then says "EVCCID (MAC address):" (yes, no value) and {"EVCCID":{"type":"Buffer","data":[]}}. Is it parsing something? I have no idea.
- I'm not sure at all why there's no response. There's no good reason as far as I can see.
- After multiple seconds there's a warning: "Buffer() is deprecated due to security and usability issues", however I'm not sure whether this is in communication to the car or whether it's in the internal communication of the charger itself. There's a weird backtrace also related to an error "TypeError: Cannot read properties of null (reading 'join')", multiple seconds after SessionSetupRequest.
User avatar
CCSknowitall
Posts: 105
Joined: Fri Jun 04, 2021 1:47 pm
Has thanked: 1 time
Been thanked: 28 times

Re: Open source CCS using AR7420

Post by CCSknowitall »

EVCCID should be equivalent to MAC minus the normal colons between digits.

If your EVCCID is blank, I could see that messing up some chargers. The charger is expecting something there.

If you could get pcaps of sessions I could be more helpful. :)

If you want to quickly check, throw 010000000002 in there as a placeholder.
Post Reply