Open source CCS using AR7420

[CCSknowitall]

I believe your Tesla is switching to single wire CAN mode as it is not receiving your SLAC request. Tesla's are "impatient" in that they will try (and give up) within only a few hundred milliseconds of seeing 5% PWM. If you're not ready, do a steady 9V (state B1), and only turn on your 5% oscillator once you for sure know your modem is ready.

[PLSee]

Here is the pcap file. I don't know how to generate the .log files.
How do I know the modem is ready? I'm waiting until pyplc is in the "modem isrestarting" phase and see the "nPacketsReceived" counter increase.
Then I plug the connector into the car.

[uhi22]

The pcap looks good. PyPLC sets the key, and the modem gives positive response. The next step should be, that the car sends a slac_param request. But this is not visible in the log.
I assume the car is not happy with the voltage on the CP, or the PP resistance. I'd propose to modify the test setup that it provides static 12V on CP, so the car can pull this to static 9V, and to turn on the 5% PWM as soon as the EVSE sees the 9V.

[navyareddy1234567]

I've tested using two of these boards - one simulating the EVSE and one simulating the EV. The AR7420 does not appear to be capable of signal attenuation measurement, so I've had to fake the signal levels on the EVSE side, but this isn't a problem for this project. SLAC negotiation completes successfully and a network is formed. Definitely need to try this against a real EVSE before diving into the higher layer protocols.

PXL_20220221_143416054.jpg

how to fake signal levels?

[uhi22]

https://github.com/uhi22/pyPLC/blob/c5e ... ug.py#L471

[navyareddy1234567]

@uhi22
with an TPLink/AR7420 on the other side as EVSE. This means, I see good chances that your adapter should work.
tplink version 6.0 is working or not and TPlink version 6.0 is AR7420 ?

[uhi22]

All we know about V6 is here: https://github.com/uhi22/pyPLC/blob/mas ... a4010p-v60
This means: No, this version does not work. But we will be sure only if you one on the desk to check it. Maybe there are more different versions.

[navyareddy1234567]

@uhi22
without NID NMK how to communicate?

[uhi22]

https://github.com/uhi22/pyPLC/tree/mas ... ample-flow
NMK and NID in Checkpoints 1, 155, 160, 170.

[navyareddy1234567]

@uhi22
Actually what iam asking means without NID,NMK, SLAC and SDP how to communicate request and response in pyplc code.

[uhi22]

The SLAC is necessary to pair the modems of the charging station and the car. Without SLAC, no high-level communication is possible.
Maybe you want to describe your use case, this could shorten the guessing game.

[navyareddy1234567]

@uhi22
In pyplchomeplug.py file this topics are there like NID,NMK,SLAC,SDP after completion of this process it was going to protocols like supported applicationprotocol and sessionsetup like that so now what iam asking means i want to skip that NID,NMK,SLAC,SDP process. I want to add one log file you can see and tell that how to do.

[uhi22]

Describe your setup.
Explain why you want to remove SLAC, NMK, NID, SDP.
How do you want to pair the modems without SLAC?
How shall the IP addresses be known without SDP?
Do you also want to remove TCP?

[navyareddy1234567]

@uhi22
I want to skip that SLAC process how to skip i don't know please check the code and help me it's an emergency skipping of SLAC process.

[Danuja]

Hi. I am new to pyPlc. Currently I am using redbeet pev and a DUT evse. I am struck at cable check stage. I will attach my log below.
https://github.com/Danuja004/pyPlc-logs/issues/1

[uhi22]

The log shows, that the EVSE responds the first cable check request with "pending", so it wants an other round, this is fine. The EV sends the second cable check request, and then the EVSE is dead. It does not even send a TCP ACK anymore.
This is a quite "hard" behavior (I would call it even "wrong"). In case of a failed cable check, the EVSE should at least send the related response code.
You should check what's going on inside the EVSE.

Edit: Two known root causes of such an behavior may be:
1. The EV does not switch to state C, so the EVSE rejects the cable check. Discussed here: https://github.com/uhi22/pyPLC/issues/3 ... 2522376970
2. Broken connection due to network manager, discussed here: https://github.com/uhi22/pyPLC/blob/mas ... ernet-port

[johu]

I did another test with the Audi Q4 (aka MEB) yesterday but again didn't get past cable check. It simply stops communicating

Code: Select all

starting in EVSE_MODE
press Ctrl-C to exit
initializing pyPlcWorker
[addressManager] we have local MAC 12:69:B0:BD:08:2C.
[addressManager] Found 1 link-local IPv6 addresses.
fe80::1069:b0ff:febd:82c
[addressManager] Local IPv6 is fe80::1069:b0ff:febd:82c
Linux interface is eth1
[addressManager] will give local MAC 12:69:B0:BD:08:2C
[addressManager] will give local MAC 12:69:B0:BD:08:2C
pyPlcIpv6 started with ownMac 12:69:B0:BD:08:2C
[addressManager] will give local MAC 12:69:B0:BD:08:2C
udplog started with ownMac 12:69:B0:BD:08:2C
logging to UDP Syslog is disabled
sniffer created at eth1
[addressManager] pev has MAC <censored>
[addressManager] pev has IP fe80:0000:0000:0000:027d:faff:fe07:d715
V2GTP (10bytes) = 01 FE 90 00 00 00 00 02 10 00 
Ok, this was a valid SDP request. We are the SECC. Sending SDP response.
SDP payload (20bytes) = FE 80 00 00 00 00 00 00 10 69 B0 FF FE BD 08 2C 3B 0E 10 00 
V2Gframe (28bytes) = 01 FE 90 01 00 00 00 14 FE 80 00 00 00 00 00 00 10 69 B0 FF FE BD 08 2C 3B 0E 10 00 
[SNIFFER] EXI from 49155 to 15118 (68bytes) = 80 00 DB AB 93 71 D3 23 4B 71 D1 B9 81 89 91 89 D1 91 81 89 91 D2 6B 9B 3A 23 2B 30 02 00 00 04 04 01 D7 57 26 E3 A6 97 36 F3 A3 13 53 13 13 83 A3 23 A3 23 03 13 33 A4 D7 36 74 46 56 60 04 00 00 00 00 80 
[SNIFFER] EXI from 15118 to 49155 (4bytes) = 80 40 00 40 
[SNIFFER] EXI from 49155 to 15118 (14bytes) = 80 9A 00 40 11 D0 18 01 F7 E8 1F 5C 54 00 
[SNIFFER] EXI from 15118 to 49155 (23bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 11 E0 20 1D 69 68 C0 C0 C0 C0 C0 80 
[SNIFFER] EXI from 49155 to 15118 (13bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 11 98 
[SNIFFER] EXI from 15118 to 49155 (19bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 11 A0 01 20 02 41 00 C4 
[SNIFFER] EXI from 49155 to 15118 (16bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 11 B2 00 12 80 
[SNIFFER] EXI from 15118 to 49155 (14bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 11 C0 00 
[SNIFFER] EXI from 49155 to 15118 (13bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 10 B8 
[SNIFFER] EXI from 15118 to 49155 (15bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 10 C0 02 00 
[SNIFFER] EXI from 49155 to 15118 (13bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 10 B8 
[SNIFFER] EXI from 15118 to 49155 (15bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 10 C0 00 00 
Received SoC status from ChargeParameterDiscoveryReq.
    Current SoC 60% 
    Full SoC 0%
    Energy capacity 27000 Wh 
    Energy request 53000 Wh 
    EVCCID 007dfa07d715 

[SNIFFER] EXI from 49155 to 15118 (31bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 10 71 90 40 0F 00 80 C2 20 9C 44 0A 14 44 01 18 48 5A 14 90 
[SNIFFER] EXI from 15118 to 49155 (55bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 10 80 00 00 00 00 00 00 10 64 2A 80 04 00 00 0C 0C 32 00 40 C0 E0 14 06 0A 18 40 60 60 60 02 06 0A 19 00 20 30 30 05 03 03 00 51 00 
Received SoC status from CableCheckReq.
    Current SoC 60% 
    Full SoC -1%
    Energy capacity 27000 Wh 
    Energy request -1 Wh 
    EVCCID 007dfa07d715 

[SNIFFER] EXI from 49155 to 15118 (16bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 10 11 40 0F 00 
[SNIFFER] EXI from 15118 to 49155 (18bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 10 20 02 00 00 00 80 
[SNIFFER] EXI from 49155 to 15118 (16bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 10 11 40 0F 00 
Received SoC status from CableCheckReq.
    Current SoC 60% 
    Full SoC -1%
    Energy capacity 27000 Wh 
    Energy request -1 Wh 
    EVCCID 007dfa07d715 

[SNIFFER] EXI from 15118 to 49155 (18bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 10 20 02 00 00 00 80 
Received SoC status from CableCheckReq.
    Current SoC 60% 
    Full SoC -1%
    Energy capacity 27000 Wh 
    Energy request -1 Wh 
    EVCCID 007dfa07d715 

[SNIFFER] EXI from 49155 to 15118 (16bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 10 11 40 0F 00 
[SNIFFER] EXI from 15118 to 49155 (18bytes) = 80 9A 02 00 40 80 C1 01 41 81 C2 10 20 02 00 00 00 00 

The PWM should now conform to the standard so I wonder does it also expect some voltage on the power pins during CableCheck?

[uhi22]

You could check this hypothesis by connecting the Q4 to a public charger with just CP, PP and PE, and measure the DC voltage on charger side to find out whether it ends in cablecheck or precharge or even reaches the currentdemand.

[johu]

Yeah but then how do I know? The chargers don't display the exact state they're in.
I hope next time Mr. Q4 has more time, then I can also try applying some voltage during CableCheck

Edit: Does CableCheck report any voltage via EXI? Doesn't look like it in the source but maybe I missed it