Open source CCS using AR7420

uhi22 · Post by **uhi22** » Thu Mar 23, 2023 6:43 am

Great hint, thanks. Yes, in the SessionSetupRequest we need to set the EVCCID with the MAC of the car. At the moment this is not implemented, need to update in the OpenV2Gx the function encodeSessionSetupRequest(), also the fsmPev.py, and provide the MAC as command line parameter from the python to the OpenV2Gx.
The funny thing is, that non of the chargers which I tested cared about this value, just worked fine with the default value

PS: Now the EVCCID should work in the SessionSetupReq.
https://github.com/uhi22/OpenV2Gx/commi ... d1ce14f6b6 and
https://github.com/uhi22/pyPLC/commit/9 ... 033f0c1d8d

celeron55 · Post by **celeron55** » Thu Mar 23, 2023 8:26 am

This truly seems like an excercise in making things as complicated as possible.

I mean, both parties already know each other by multiple different IDs (MAC, IPv6, possibly more), and variable length structural messages are already flowing between the main logic of each unit. So, what do we need now? Well, how about yet another ID? But not just any ID, it needs to be formed in a certain way of course.

I wonder what's next

uhi22 · Post by **uhi22** » Thu Mar 23, 2023 8:40 am

Yes, it seems to be a goal of the CCS standard, to make it as complicated as possible. To prevent that somebody like you and me just build their own equipment. They nearly reached it

celeron55 · Post by **celeron55** » Thu Mar 23, 2023 4:52 pm

Attempt #6, with uhi22's newest pyPLC and OpenV2Gx:
- Got all the way to "Checkpoint530: Will send ContractAuthenticationReq"
- Sent ChargeParameterDiscoveryReq, but got no response to that ("entering 99" means "timeout", I've been told.)

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 96 7F D4 31 10 00
[PEV] Checkpoint203: Received SDP response
[addressManager] charger has IP fe80:0000:0000:0000:eea2:9bff:fe27:967f
[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:967f 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] EDA_02817CA712B4
[PEV] responding (29bytes) = 01 FE 80 01 00 00 00 15 80 9A 02 00 00 00 00 00 00 00 00 11 D0 18 0A 05 F2 9C 4A D0 00
from 3 entering 4
[PEV] In state WaitForSessionSetupResponse, received (25bytes) = 01 FE 80 01 00 00 00 11 80 9A 02 33 EB C7 4A B0 99 A6 DC 91 E0 20 04 00 80
[PEV] {
"msgName": "SessionSetupRes",
"info": "17 bytes to convert",
"error": "",
"result": "",
"schema": "DIN",
"g_errn": "0",
"header.SessionID": "cfaf1d2ac2669b72",
"header.Notification_isUsed": "0",
"header.Signature_isUsed": "0",
"ResponseCode": "OK_NewSessionEstablished",
"EVSEID.bytesLen": "1",
"EVSEID": "00",
"debug": "Line538"
}
[PEV] Checkpoint506: The Evse decided for SessionId cfaf1d2ac2669b72
[PEV] Will send ServiceDiscoveryReq
[PEV] responding (21bytes) = 01 FE 80 01 00 00 00 0D 80 9A 02 33 EB C7 4A B0 99 A6 DC 91 98
from 4 entering 5
[PEV] In state WaitForServiceDiscoveryResponse, received (27bytes) = 01 FE 80 01 00 00 00 13 80 9A 02 33 EB C7 4A B0 99 A6 DC 91 A0 01 20 02 41 20 C4
[PEV] {
"msgName": "ServiceDiscoveryRes",
"info": "19 bytes to convert",
"error": "",
"result": "",
"schema": "DIN",
"g_errn": "0",
"header.SessionID": "cfaf1d2ac2669b72",
"header.Notification_isUsed": "0",
"header.Signature_isUsed": "0",
"ResponseCode": "OK",
"debug": "Line514"
}
[PEV] Will send ServicePaymentSelectionReq
[PEV] responding (24bytes) = 01 FE 80 01 00 00 00 10 80 9A 02 33 EB C7 4A B0 99 A6 DC 91 B2 00 12 80
from 5 entering 6
[PEV] In state WaitForServicePaymentSelectionResponse, received (22bytes) = 01 FE 80 01 00 00 00 0E 80 9A 02 33 EB C7 4A B0 99 A6 DC 91 C0 00
[PEV] {
"msgName": "ServicePaymentSelectionRes",
"info": "14 bytes to convert",
"error": "",
"result": "",
"schema": "DIN",
"g_errn": "0",
"header.SessionID": "cfaf1d2ac2669b72",
"header.Notification_isUsed": "0",
"header.Signature_isUsed": "0",
"ResponseCode": "OK",
"debug": "Line526"
}
[PEV] Checkpoint530: Will send ContractAuthenticationReq
[PEV] responding (21bytes) = 01 FE 80 01 00 00 00 0D 80 9A 02 33 EB C7 4A B0 99 A6 DC 90 B8
from 6 entering 7
[PEV] In state WaitForContractAuthentication, received (23bytes) = 01 FE 80 01 00 00 00 0F 80 9A 02 33 EB C7 4A B0 99 A6 DC 90 C0 00 00
[PEV] {
"msgName": "ContractAuthenticationRes",
"info": "15 bytes to convert",
"error": "",
"result": "",
"schema": "DIN",
"g_errn": "0",
"header.SessionID": "cfaf1d2ac2669b72",
"header.Notification_isUsed": "0",
"header.Signature_isUsed": "0",
"ResponseCode": "OK",
"EVSEProcessing": "Finished",
"debug": "Line430"
}
[PEV] It is Finished. Will send ChargeParameterDiscoveryReq
[PEV] responding (32bytes) = 01 FE 80 01 00 00 00 18 80 9A 02 33 EB C7 4A B0 99 A6 DC 90 71 91 40 05 00 C8 C8 23 24 70 19 00
from 7 entering 8
from 8 entering 99
[PEV] re-initializing fsmPev

celeron55 · Post by **celeron55** » Thu Mar 23, 2023 6:15 pm

Looking at the Super Secret Charger Log (tm), it looks like:

- The charger receives the ChargeParameterDiscoveryReq as it should. It is decoded as {"EVRequestedEnergyTransferType":"DC_extended","DC_EVChargeParameter":{"DC_EVStatus":{"EVErrorCode":"NO_ERROR","EVRESSSOC":20},"EVMaximumCurrentLimit":{"Multiplier":0,"Value":100},"EVMaximumVoltageLimit":{"Multiplier":0,"Value":398}}}

- It says it's charging at 20% SoC

- There's a status report which mainly seems to be saying "state = stopped" and "insulation test = not started".

- There are lots of power, sensor and derating related readings which shouldn't matter at all at this point.

- 1.0 seconds after ChargeParameterDiscoveryReq, it says "connection closed", referring to the car's IPv6 address and port and the charger calls the session as ended.

Again I can't even pretend to have any idea what's happening. Why is there no response? Why 1.0 seconds? But I'm going to guess the charger has a good reason to not be happy once again. It's definitely not telling it in a way that I would understand. What does "Multiplier":0 mean? Multiplying by 0 seems weird? What are we multiplying here? Have we missed sending a required message before this one?

uhi22 · Post by **uhi22** » Thu Mar 23, 2023 8:01 pm

The multiplier means the exponent to the base of 10, which is used to scale the physical values. E.g. value 4000 and multiplier -1 would mean 4000*10^(-1) = 400, and in best case also a unit is provided, but this is optional.

Looking back to the topic with the sessionSetup, my impression is that "your" charger is very strict, and just ignores (or crashes?) if something is not exactly as it expects. I have logs from my original Ioniq car, and compared the one from your trace with the Ioniq. Conclusion: Much room for improvements

CCSknowitall · Post by **CCSknowitall** » Thu Mar 23, 2023 8:23 pm

You’re missing EVReady: True in DC_EVStatus.

uhi22 · Post by **uhi22** » Thu Mar 23, 2023 8:26 pm

CCSknowitall · Post by **CCSknowitall** » Thu Mar 23, 2023 8:41 pm

Ok I misspoke, you might be missing EVReady entirely? Most vehicles send true but apparently some send false here. It must be set to true in cable check and beyond until end of charging. Since it’s not in the charger logs, and everything else seems to be decoded, it’s suspicious.

Really hard to work without a pcap.

celeron55 · Post by **celeron55** » Thu Mar 23, 2023 8:51 pm

Yes I need to get my sniffing set up, but then again this doesn't seem to be much of a challenge to you guys anyway...

I'm planning to visit a different charger this weekend for some comparison.

uhi22 · Post by **uhi22** » Thu Mar 23, 2023 9:01 pm

Yeah, would be great to also note the charger types, then I would add the results into the charger-test-result-page https://github.com/uhi22/pyPLC/blob/mas ... results.md

I added some of the "missing" fields, and changed the EVReady to zero, as the Ioniq does. Maybe this helps. Let me guess: We will see similar issues in the next messages, but it should not take more than a week, if we fix one message each day

This is the todays fix: https://github.com/uhi22/OpenV2Gx/commi ... 7712e2acaf

CCSknowitall · Post by **CCSknowitall** » Thu Mar 23, 2023 10:36 pm

You could run tcpdump on the interface, you don’t necessarily need a sniffer on the line.

You’ll need to set EVReady to true or 1 for cable check, pre charge, power delivery, and current demand.

uhi22 · Post by **uhi22** » Fri Mar 24, 2023 6:24 am

CCSknowitall wrote: ↑Thu Mar 23, 2023 10:36 pm You’ll need to set EVReady to true or 1 for cable check, pre charge, power delivery, and current demand.

According to what I see in the code, this is fulfilled. Only for the ChargeParameterDiscovery, we set EVReady to 0, as the Ioniq does. Means: Happy testing and good luck

celeron55 · Post by **celeron55** » Fri Mar 24, 2023 6:12 pm

Attempts #7 and #8: Neither worked to a reasonable extent.

#7: The furthest I got was Checkpoint200. SDP didn't work, which I think means the system lost the IPv6 address before SDP was reached. Nothing special there, just an endless loop of this like we've already seen:

Code: Select all

[PEVSLAC] from 16 entering 16
[PEV] initiating SDP request

#8: The furthest I got was Checkpoint170: transmitting CM_SET_KEY.REQ. Here's the log where the state machine goes from 100 to 170 and back to 100:

Code: Select all

[PEVSLAC] Checkpoint100: Sending SLAC_PARAM.REQ...
[PEVSLAC] from 2 entering 4
Checkpoint102: received SLAC_PARAM.CNF
[PEVSLAC] from 4 entering 5
[PEVSLAC] from 5 entering 6
[PEVSLAC] transmitting START_ATTEN_CHAR.IND...
[PEVSLAC] transmitting START_ATTEN_CHAR.IND...
[PEVSLAC] transmitting START_ATTEN_CHAR.IND...
[PEVSLAC] from 6 entering 7
[PEVSLAC] transmitting MNBC_SOUND.IND...
[PEVSLAC] transmitting MNBC_SOUND.IND...
[PEVSLAC] transmitting MNBC_SOUND.IND...
[PEVSLAC] transmitting MNBC_SOUND.IND...
[PEVSLAC] transmitting MNBC_SOUND.IND...
[PEVSLAC] transmitting MNBC_SOUND.IND...
[PEVSLAC] transmitting MNBC_SOUND.IND...
[PEVSLAC] transmitting MNBC_SOUND.IND...
[PEVSLAC] transmitting MNBC_SOUND.IND...
[PEVSLAC] transmitting MNBC_SOUND.IND...
[PEVSLAC] from 7 entering 8
received ATTEN_CHAR.IND
[PEVSLAC] received AttenCharInd in state 8
[addressManager] evse has MAC EC:A2:9B:27:96:7F
[PEVSLAC] number of sounds reported by the EVSE (should be 10): 10
[PEVSLAC] transmitting ATTEN_CHAR.RSP...
[PEVSLAC] from 9 entering 10
[PEVSLAC] Checkpoint150: transmitting SLAC_MATCH.REQ...
[PEVSLAC] from 10 entering 11
received SLAC_MATCH.CNF
From SlacMatchCnf, got network ID (NID) 0x5e 0xab 0x6f 0xad 0xff 0x7f 0x1 
From SlacMatchCnf, got network membership key (NMK) 0x7b 0x81 0xa6 0x20 0x8d 0x40 0x9 0x5c 0xb 0x4b 0xbf 0x94 0x8d 0xdf 0x9f 0x94 
Checkpoint170: transmitting CM_SET_KEY.REQ
[PEVSLAC] from 11 entering 12
received SET_KEY.CNF
SetKeyCnf says 1, this is formally 'rejected', but indeed ok.
[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 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) 0x5e 0xab 0x6f 0xad 0xff 0x7f 0x1 
[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
[PEVSLAC] Checking whether the pairing worked, by GET_KEY.REQ...
[PEVSLAC] from 12 entering 13
[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
[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 1(NOK)
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] No EVSE seen (yet). Still waiting for it.
[PEVSLAC] from 13 entering 12
[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 0x7b 0x81 0xa6 0x20 0x8d 0x40 0x9 0x5c 0xb 0x4b 0xbf 0x94 0x8d 0xdf 0x9f 0x94 
This is NOT 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] No EVSE seen (yet). Still waiting for it.
[PEVSLAC] from 13 entering 12
[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 0x7b 0x81 0xa6 0x20 0x8d 0x40 0x9 0x5c 0xb 0x4b 0xbf 0x94 0x8d 0xdf 0x9f 0x94 
This is NOT 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] No EVSE seen (yet). Still waiting for it.
[PEVSLAC] from 13 entering 12
[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 0x7b 0x81 0xa6 0x20 0x8d 0x40 0x9 0x5c 0xb 0x4b 0xbf 0x94 0x8d 0xdf 0x9f 0x94 
This is NOT 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] No EVSE seen (yet). Still waiting for it.
[PEVSLAC] from 13 entering 12
[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 0x7b 0x81 0xa6 0x20 0x8d 0x40 0x9 0x5c 0xb 0x4b 0xbf 0x94 0x8d 0xdf 0x9f 0x94 
This is NOT 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] No EVSE seen (yet). Still waiting for it.
[PEVSLAC] from 13 entering 12
[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 0x7b 0x81 0xa6 0x20 0x8d 0x40 0x9 0x5c 0xb 0x4b 0xbf 0x94 0x8d 0xdf 0x9f 0x94 
This is NOT the developer NMK.
From GetKeyCnf, got network ID (NID) 0x0 0x0 0x0 0x0 0x0 0x0 0x0 
[HARDWAREINTERFACE] Received unknown line: "12m00.005s: -!- iPDM56 running"
[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
[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 0x7b 0x81 0xa6 0x20 0x8d 0x40 0x9 0x5c 0xb 0x4b 0xbf 0x94 0x8d 0xdf 0x9f 0x94 
This is NOT 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] No EVSE seen (yet). Still waiting for it.
[PEVSLAC] from 13 entering 12
[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 0x7b 0x81 0xa6 0x20 0x8d 0x40 0x9 0x5c 0xb 0x4b 0xbf 0x94 0x8d 0xdf 0x9f 0x94 
This is NOT 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] No EVSE seen (yet). Still waiting for it.
[PEVSLAC] from 13 entering 12
[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 0x7b 0x81 0xa6 0x20 0x8d 0x40 0x9 0x5c 0xb 0x4b 0xbf 0x94 0x8d 0xdf 0x9f 0x94 
This is NOT 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] No EVSE seen (yet). Still waiting for it.
[PEVSLAC] We lost the connection to the EVSE modem. Back to the beginning.
[PEVSLAC] from 13 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 0x7b 0x81 0xa6 0x20 0x8d 0x40 0x9 0x5c 0xb 0x4b 0xbf 0x94 0x8d 0xdf 0x9f 0x94 
This is NOT 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] setting the default developer key...
[PEVSLAC] from 1 entering 3
received SET_KEY.CNF
SetKeyCnf says 1, this is formally 'rejected', but indeed ok.
[PEVSLAC] Assuming the modem is up again.
[PEVSLAC] from 3 entering 2
[PEVSLAC] Checkpoint100: 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
[PEVSLAC] It was sufficient time to get the answers from the modems.
[PEVSLAC] No modem connected. We assume, we run in a simulation environment.
[PEVSLAC] from 1 entering 2
[PEVSLAC] Checkpoint100: 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 0x7b 0x81 0xa6 0x20 0x8d 0x40 0x9 0x5c 0xb 0x4b 0xbf 0x94 0x8d 0xdf 0x9f 0x94 
This is NOT 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] setting the default developer key...
[PEVSLAC] from 1 entering 3
received SET_KEY.CNF
SetKeyCnf says 1, this is formally 'rejected', but indeed ok.
[PEVSLAC] Assuming the modem is up again.
[PEVSLAC] from 3 entering 2
[PEVSLAC] Checkpoint100: Sending SLAC_PARAM.REQ...

Not sure what the cause is. Maybe there's a relatively short time window from powering up the modem during which the charger has to be connected and of course pevNoGui.py has to be started in between. Not sure what the timing was here. Doing this at the public charger with payment via mobile app, monitoring via laptop and all is quite chaotic. In my setup the modem boots at the same time as the Orange Pi does, and getting the Orange Pi to a ready state probably takes almost a minute as I want to see the log in real time on my laptop also. I need to see whether I can somehow streamline this, maybe power up the modem right before starting pevNoGui.py or maybe I'll just go do it blind without the laptop.

uhi22 · Post by **uhi22** » Fri Mar 24, 2023 9:03 pm

Are you sure regarding the connection of the modem to the CP line, including the diode and resistor? In the cases #7 and #8, we have seen the charger first (SLAC was ok), but then it went away. The #8 shows, that we have set the network key to our modem, the modem restarts, has the correct new key, but does not see the chargers modem anymore (visible in the all-zero-Network-ID). This can only happen if either the line between the modems is broken, or the charger decided to turn-off everything because of wrong resistance or something. At least for #8 it is for sure not our modem what sleeps, because we see the permanent answers for the GetKey (which we use as "modem detection"). Could be also a coupling network issue, did you use a 1nF to connect the modem to the CP?

PS: To better understand what is going on physically on the line, I used a detector as described in https://github.com/uhi22/pyPLC/blob/mas ... s-detector; alternatively an oscilloscope could help to confirm the basic electrical parameters.

uhi22 · Post by **uhi22** » Sat Mar 25, 2023 9:13 am

Regarding authentication with mobile or RFID: The chargers which I tested do not care for this until the ContractAuthenticationRequest. The Checkpoint535 is reached always. There, the user must authenticate, and only then the sequence proceeds. Not sure, whether all charger behave in this way. If yes, we could eliminate the mobile from the test setup and concentrate on the first part of the sequence. If we run successfully into the ContractAuthentication loop, then it's time to use the mobile or RFID to authenticate.

Regarding chaotic test setup: Maybe it's easier for the beginning to just run the "pyPlc.py P" on the laptop, including wireshark, to make the hardware setup and the protocol stable, and to migrate this to the OrangePi in a second step. No hardware control is necessay to come until the ContractAuthentication.

celeron55 · Post by **celeron55** » Sat Mar 25, 2023 6:00 pm

I'm pretty sure this charger won't release the charging plug from its storage location until authentication has been done. However, that's an interesting suggestion for the others I might try.

CCSknowitall · Post by **CCSknowitall** » Sat Mar 25, 2023 6:07 pm

Most chargers will sit in contract authentication until you’ve authorized, yes. So you can do all your SLAC and setup verification without paying. Any charger on a network that advertises plug and charge capability by definition must set up communication before authentication as the vehicle itself is the device doing the authenticating… even though here you’re speaking DIN 70121 and not using that feature.

For CCS1 markets make sure you’re also putting voltage on proximity. Refer to J1772 for details.

I recommend the “laptop” approach. Reduce the variables.

uhi22 · Post by **uhi22** » Wed Mar 29, 2023 7:25 am

A WT32_ETH01 as controller, a TPlink TL-PA4010 rev 3.0 as modem and a WIFI_Kit_32 as display.
Running the Arduino sketch from https://github.com/uhi22/ccs32 on the WT32, and the display software from https://github.com/uhi22/SerialToOLED.
Stability issues are solved, demo-charging on EVSE-simulation from https://github.com/uhi22/pyPLC works.
Ready to hook it up to a real-world charger to see how far we can get.

uhi22 · Post by **uhi22** » Wed Mar 29, 2023 6:09 pm

First quick try on Alpitronics charger completes the SLAC, but is stuck at SDP. Analysis and fix planned.

YouTube · Post by **johu** » Wed Mar 29, 2023 6:49 pm

It seems you'll have this hacked before I even get a chance to build my chademo adapter

Anyway, TP-Link and CCS socket is ordered.

YouTube · Post by **johu** » Sat Apr 01, 2023 12:11 pm

Got the tplink today now not quite sure how to continue. In hardware.md it looks like you used the entire stack of 2 boards but in your latest post it looks like you removed the lower one without the RJ45 jack. Is that the best way to do it, completely remove the lower one and connect 1nF and 150 Ohms to the output of that little transformer (or choke)?

uhi22 · Post by **uhi22** » Sat Apr 01, 2023 5:43 pm

The single Board is from an other Variant, without the passthrough socket on the front. This is originally single board.

You can remove the second board, but loose the big elco on the supply, so this needs to be added again. And yes, the two wires from the transformer go to the 1nF and 150ohms.

asavage · Post by **asavage** » Sat Apr 01, 2023 10:10 pm

USD$12, eBay, 8 days to arrive . . .

: TL-PA4010 (without passthrough)

For a while, a couple of careers ago, I used to repair laptops for a living, but this thing does not disassemble gracefully. I leaned on it hard.

: TL-PA4010 (without passthrough)

: TL-PA4010 (without passthrough)

Well, in my other careers, I found few things can't be opened up by a judicious application of a Dremel (carbide burr, or #426 reinforced fibreglas cutoff wheel on a 420 mandrel). I sliced a couple of inches around a corner, very shallow, then pried a bit back . . .

: TL-PA4010 (without passthrough)

: TL-PA4010 (without passthrough)

That revealed where I had room for more slicing . . .

: TL-PA4010 (without passthrough)

There are cover catches, but I could not flex the sides enough to disengage them. I display these pics in case one of you wants to try to do better than I.

: TL-PA4010 (without passthrough)

: TL-PA4010 (without passthrough)

Dislodge a bit of glue . . .

: TL-PA4010 (without passthrough)

Slice off the corners, then break off the sides . . .

: TL-PA4010 (without passthrough)

asavage · Post by **asavage** » Sat Apr 01, 2023 10:16 pm

: TL-PA4010 (without passthrough)

Only had to desolder the mains wrap-around leads:

: TL-PA4010 (without passthrough)

Here's a better shot at the bits that have to be separated permanently:

: TL-PA4010 (without passthrough)

I'd continue removing the PS section, but I'll be darned if I can find my manual solder sucker -- I moved house recently, and it's not in with my solder station kit. I can find one of my automated solder removal tools but I inherited that one and I doubt its in working order, and my production desoldering set, which requires plumbing compressed air from one side of the garage to the other, is in storage 35 mi. south (and I don't really want to set it up).

Fighting the tools . . .

Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420

Re: Open source CCS using AR7420