Page 20 of 20
Re: Open source CCS using AR7420
Posted: Thu Mar 27, 2025 5:01 am
by 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.
Re: Open source CCS using AR7420
Posted: Sat Mar 29, 2025 3:09 pm
by 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.
Re: Open source CCS using AR7420
Posted: Sat Mar 29, 2025 4:01 pm
by 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.
Re: Open source CCS using AR7420
Posted: Fri May 09, 2025 5:11 am
by navyareddy1234567
catphish wrote: ↑Mon Feb 21, 2022 7:43 pm
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?
Re: Open source CCS using AR7420
Posted: Fri May 09, 2025 5:45 am
by uhi22
Re: Open source CCS using AR7420
Posted: Mon May 12, 2025 1:19 pm
by 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 ?
Re: Open source CCS using AR7420
Posted: Mon May 12, 2025 4:49 pm
by 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.
Re: Open source CCS using AR7420
Posted: Tue May 13, 2025 5:38 am
by navyareddy1234567
@uhi22
without NID NMK how to communicate?
Re: Open source CCS using AR7420
Posted: Tue May 13, 2025 5:47 am
by uhi22
Re: Open source CCS using AR7420
Posted: Tue May 13, 2025 6:24 am
by navyareddy1234567
@uhi22
Actually what iam asking means without NID,NMK, SLAC and SDP how to communicate request and response in pyplc code.
Re: Open source CCS using AR7420
Posted: Tue May 13, 2025 7:49 am
by 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.
Re: Open source CCS using AR7420
Posted: Tue May 13, 2025 9:46 am
by 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.
Re: Open source CCS using AR7420
Posted: Tue May 13, 2025 5:24 pm
by 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?
Re: Open source CCS using AR7420
Posted: Wed May 14, 2025 12:47 pm
by 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.
Using redbeet
Posted: Wed Nov 05, 2025 11:05 am
by 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
Re: Open source CCS using AR7420
Posted: Wed Nov 05, 2025 5:04 pm
by 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
Re: Open source CCS using AR7420
Posted: Mon Nov 24, 2025 3:52 pm
by 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?
Re: Open source CCS using AR7420
Posted: Mon Nov 24, 2025 8:27 pm
by 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.
Re: Open source CCS using AR7420
Posted: Tue Nov 25, 2025 9:16 am
by 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
Re: Open source CCS using AR7420
Posted: Tue Nov 25, 2025 11:50 am
by uhi22
No, no voltage is reported in exi during cable check. Ask Mr Q4 to arrive with low SOC. Then precharge has something much below 400V, and cable check depending on charger has e.g. 450 or 500V.
Would be helpful to have an PLC sniffer ready but this is still on its long way.
Re: Open source CCS using AR7420
Posted: Sat Feb 21, 2026 10:01 am
by johu
Just for the record we got the Polestar 4 to close its contactors. We didn't draw any power though.
Uhi fixed a problem in OpenV2Gx
https://github.com/uhi22/OpenV2Gx/commi ... d86a159a47
Re: Open source CCS using AR7420
Posted: Fri Mar 13, 2026 5:23 pm
by razvanphp
Would TP-LINK TL-PA7017P KIT AV1000 (with gigabit ports) work for our purpose?
Also, is my understanding correct that we could use the device to sniff on both ways traffic with wireshark on the laptop in realtime? so 3 PLCs on the CP line? Thanks!
Re: Open source CCS using AR7420
Posted: Sat Mar 14, 2026 7:51 am
by uhi22
The only way to find out whether this adapter works is to try. I see the risk that the fast adapters use a different, incompatible chipset.
Using 3 PLC nodems on one CP line works, but sniffing the complete traffic does not. The sniffer only forwards the broadcast traffic (first SDP) but nothing more. Still waiting for someone who finds the configuration bit or patches the firmware to have a fully transparent switch.
Re: Open source CCS using AR7420
Posted: Sat Mar 14, 2026 9:46 pm
by razvanphp
Wait, what? That's not good, we need to fix that. Since we are working on an EVSE implementation now, we need this, so if we find it, we will open-source it.
AFAIK, the devices capable of this are VertexCom MST216D CCS Sniffer and the Vector ones, are there others?
If one has access to the ethernet frames, passing all traffic through an old network hub or an ubiquiti/managed switch with 2 port mirroring works to sniff all the packets on the laptop.