Open source CCS using AR7420

[uhi22]

And on Windows?

[johu]

On what?

https://mosquitto.org/download/

I assume the Windows Python distro comes with pip?

Code: Select all

pip install paho-mqtt

I guess it's also possible to launch a broker in pyPLC itself if it finds there isn't one running. Likewise pyPLC could launch the hardware microservice. But yeah lets see how many more we end up with. If it's many a microservice would be less painful to add than hacking about in hardwareInterface.py. But we already have that option now anyway.

[nickom44]

Hi All,

I have bought 2 x TL-PA4010P (UK) devices but it looks like TP link has switched IC's over to unicom semi.

Has anyone had any experience with these?

Main processor is MSE 1060 and the transformer interface is MSEX231.

Regards
Nick

[uhi22]

Could you share a photo of the name plate, please? There was a similar finding some time ago, cannot find it at the moment.

[nickom44]

Could you share a photo of the name plate, please? There was a similar finding some time ago, cannot find it at the moment.

[nickom44]

Close up of the 2 ICs

Here you go

[uhi22]

So for the moment the conclusion is: The version 6 of the TL PA4010 does not fit our needs.
Nevertheless it would be interesting whether it still talks to the Qualcomm tool, or whether it has other possibilities to configure.

[nickom44]

Hi all,


So I tried this on a known device with the atheros processor. and I get this.

Before this works though, I need to

sudo ip link set eth1 down
then
sudo ip link set eth1 up

then enter:
~/open-plc-utils-master $ plcstat -t -i eth1

P/L NET TEI ------ MAC ------ ------ BDA ------ TX RX CHIPSET FIRMWARE
LOC CCO 001 C0:4A:00:C6:D8:4C 3C:18:A0:0D:2A:48 n/a n/a QCA7420 MAC-QCA7420-1.1.0.844-01-20120919-FINAL

When I try this on the unicomsemi equipped plug i get nothing returned:

~/open-plc-utils-master $ sudo ip link set eth1 down
~/open-plc-utils-master $ sudo ip link set eth1 up
~/open-plc-utils-master $ plcstat -t -i eth1
~/open-plc-utils-master $

[uhi22]

Summary: The version 6 of the TL-PA4010 does not fit our needs. It is not configurable via the Qualcom open-plc-utils.
Added this hint to the description on github, https://github.com/uhi22/pyPLC/blob/mas ... a4010p-v60
Thanks for the investigation.

[mackoffgrid]

Wanting to join in on this experiment I bought the Australian TL-PL4010 version 4.
It appears to have the same chip set as the UK version 6.

[nagyapi]

Could you share a photo of the name plate, please? There was a similar finding some time ago, cannot find it at the moment.

Hi,

yes, I have mentioned this problem in the issues on pyPLC github. So the EU version (V6) comes with Vertexcom (unicomsemi) MSE 1060 chip. You cannot find any information about these chip, becuse it is designed for a specific customer (maybe this is TP-Link) and NDA is required to get more information. I stopped the process here, I haven't signed any NDA.
But it would be interesting to check how can we communicate with this module.

[Ashtray1987]

Hi Everyone,

I am new to this forum, I found it when trying to research equipment for diagnosing PLC communications on EVs.

I have a TL-PA4010 and I would like to sniff and log the PLC between a real EV and EVSE.

Am I correct that I could just modify the 4010 to run off a DC circuit, put the appropriate capacitor and resistor combination between CP and PE and the 4010 will route all traffic to the RJ45 socket?

Would I then be able to sniff all packets using Wireshark? Of course encrypted packets I wouldn't be able to see. I mainly just want to see the core charging sequence (current demand, current response etc.)

Are there any other mods that I would need to perform in order to be able to do this?

Also, regarding the resistor/capacitor mod, could I just use something like a 60Mhz oscilloscope probe in x10 mode?

Thank you very much!
Ash

[uhi22]

Hi and welcome.

It is more difficult. I just added the topic into the FAQ, https://github.com/uhi22/pyPLC#q9-can-i ... -tl-pa4010

The osci probe should work for the physical connection.

[Ashtray1987]

Thank you for the feedback.

Are you aware of this product from Vector?

https://www.vector.com/us/en/products/p ... e/vh5110a/#

It uses an inductive coupler, a hardware interface and Vector CANoe to analyse PLC communication.

I wonder how this is able to interpret the frames, since the hardware setup is quite similar. How do you think it is able to handle the encryption?

Thanks
Ashley

[uhi22]

Yes, we have seen this (on the papers). The "encryption" on homeplug layer is not the problem. The device sees the SLAC message which contains the key, and immediately applies this key, so it can join the AVLN. This works with pyPLC and with the Vector tool. The difference is, that the modem in the Vector tool is able to route all the traffic to the host. The TPLink only routes the broadcast traffic.
In best case, there would be configuration option in the TPlink to route all traffic. We do not know. If someone has the VH5110A and a screw driver, this could be very helpful.

Link to the discussion: viewtopic.php?p=41063#p41063
Link to the (3 years old) collection including the vector tool: https://www.goingelectric.de/wiki/CCS-T ... e-Details/

[Ashtray1987]

My understanding is that the VH5110A is a licensed version of the following hardware;

http://www.bplus.com.tw/Adapter/MST216D-D01D.html

Some quite detailed info on there

[uhi22]

Very good. Do we see any chance to find documentation of the vertexcom PLC chip, and samples?

[PLSee]

Hi all,

I'm making my first experiments with pyPLC in EVSE mode using a converted TP Link PLC modem with an AR7420.
My goal is to talk to my Tesla Model 3 from 2019 and eventually make it close its contactors.

Unfortunately, I'm stuck at an early stage: I'm unable to get any communication over PLC to the car.
In pyPLC this is at the "modem isrestarting" message. The log is attached.

My current hardware setup is an Arduino constantly outputting a 1kHz 5% PWM square via a TL072 op amp that is configured to output +/-12V via the 1k resistor. The rest is the same as found in the hardware docs of the pyPLC github.
I verified the setup using an oscilloscope (without the connection to the car) and it looks good to me. The only thing I don't know is the amplitude of the modem signal. It seems to be around +/- 2V in my case.

I also did the EVSE configuration of the modem via the open plc tools.

The only idea I have left currently is to check the signal with the oscilloscope while being connected to the car. But I doubt that it will look bad.

Thanks for anyone who has an idea.

Code: Select all

python pyPlc.py E
starting in EvseMode
initializing pyPlcWorker
[addressManager] we have local MAC 14:F6:D8:BB:88:8E. Todo: find this out dynamically.
[addressManager] Found 5 link-local IPv6 addresses.
fe80::de57:6fca:5ba:a314%66
fe80::b6f3:a9c8:4c79:ab10%17
fe80::a3c2:1b26:800c:476d%23
fe80::65af:b3a2:ff69:a058%22
fe80::436c:a443:cf45:f246%20
[addressManager] Warning: Multiple Ipv6 addresses were found. If you have multiple network adaptors, try to disconnect the not relevant ones.
[addressManager] Using the first detected, fe80::de57:6fca:5ba:a314%66
[addressManager] Local IPv6 is fe80::de57:6fca:5ba:a314%66
The configured windows interface name is \Device\NPF_{E2C1E23F-B70C-4B73-AC00-2FB11C784848}
This interface is in pcap eth7
[addressManager] will give local MAC 14:F6:D8:BB:88:8E
[addressManager] will give local MAC 14:F6:D8:BB:88:8E
pyPlcIpv6 started with ownMac 14:F6:D8:BB:88:8E
[addressManager] will give local MAC 14:F6:D8:BB:88:8E
udplog started with ownMac 14:F6:D8:BB:88:8E
logging to UDP Syslog is enabled
sniffer created at eth7
[720ms] [HARDWAREINTERFACE] Auto detection of serial ports. Available serial ports:
[729ms] [HARDWAREINTERFACE]  1: COM3                 'Standardmäßgige Seriell-über-Bluetooth-Verbindung (COM3)'
[729ms] [HARDWAREINTERFACE]  2: COM4                 'Standardmäßgige Seriell-über-Bluetooth-Verbindung (COM4)'
[730ms] [HARDWAREINTERFACE]  3: COM5                 'Standardmäßgige Seriell-über-Bluetooth-Verbindung (COM5)'
[730ms] [HARDWAREINTERFACE]  4: COM6                 'Standardmäßgige Seriell-über-Bluetooth-Verbindung (COM6)'
[731ms] [HARDWAREINTERFACE] ok, we take the first port, COM3
[5919ms] [HARDWAREINTERFACE] ERROR: Could not open serial port.
[5951ms] [pyPlcWorker] Software version v0.9-99-g7611009
[5952ms] [EVSE] initializing fsmEvse
[5987ms] pyPlcTcpSocket listening on port 15118
[5987ms] Hostname is DESKTOP-DDT4U9T
[Testsuite]  received syslog packet: Test message to verify the syslog. pyPlcHomeplug.py is in the init function.
[Testsuite]  received syslog packet: [HARDWAREINTERFACE] Auto detection of serial ports. Available serial ports:
[Testsuite]  received syslog packet: [HARDWAREINTERFACE]  1: COM3                 'Standardmäßgige Seriell-über-Bluetooth-Verbindung (CO
[Testsuite]  received syslog packet: [HARDWAREINTERFACE]  2: COM4                 'Standardmäßgige Seriell-über-Bluetooth-Verbindung (CO
[Testsuite]  received syslog packet: [HARDWAREINTERFACE]  3: COM5                 'Standardmäßgige Seriell-über-Bluetooth-Verbindung (CO
[Testsuite]  received syslog packet: [HARDWAREINTERFACE]  4: COM6                 'Standardmäßgige Seriell-über-Bluetooth-Verbindung (CO
[Testsuite]  received syslog packet: [HARDWAREINTERFACE] ok, we take the first port, COM3
[Testsuite]  received syslog packet: [HARDWAREINTERFACE] ERROR: Could not open serial port.
[Testsuite]  received syslog packet: pyPlcWorker init
[Testsuite]  received syslog packet: [pyPlcWorker] Software version v0.9-99-g7611009
[Testsuite]  received syslog packet: [EVSE] initializing fsmEvse
[Testsuite]  received syslog packet: pyPlcTcpSocket listening on port 15118
[Testsuite]  received syslog packet: Hostname is DESKTOP-DDT4U9T
[6042ms] NID is (7bytes) = 01 02 BE 0B 1F 32 07
[6046ms] transmitting SET_KEY.REQ, to configure the EVSE modem with random NMK (16bytes) = 77 77 FB D1 55 AD 46 77 77 77 77 77 77 77 77 77
[Testsuite]  received syslog packet: NID is (7bytes) = 01 02 BE 0B 1F 32 07
[Testsuite]  received syslog packet: transmitting SET_KEY.REQ, to configure the EVSE modem with random NMK (16bytes) = 77 77 FB D1 55 AD
[6094ms] received SET_KEY.CNF
[6096ms] SetKeyCnf says 1, this is formally 'rejected', but indeed ok.
[Testsuite]  received syslog packet: received SET_KEY.CNF
[Testsuite]  received syslog packet: SetKeyCnf says 1, this is formally 'rejected', but indeed ok.

[lewurm]

Welcome PLSee!

I don't see anything obvious, just some thoughts:

• please share the pcap file, it's richer in details

• did you check the service menu of your tesla? sometimes error messages give clues what could be wrong

• did you patch the EVSE bits accordingly?

• what exact plc modem are you using?

• do you observe state B (voltage pulled down to 9V) being entered on the arduino when the car is connected via CP?

[uhi22]

Hi and welcome. Not sure whether the TL072 is fast enough to provide the 5% PWM and the full +/-12V. Could you share scope pictures? 2V RF is perfect. As far as I remember the modem stops sending coordinator packets after some time (a minute?), so make sure to restart the modem before plugging into the car.

[PLSee]

Thanks for your responses.
In the meantime, I found a hilarious mistake: I bought a CCS plug from aliexpress and it had the pin labels for CP and PP swapped.
There really is nothing to rely on!

I fixed the wiring but the error persists. Will continue tomorrow with the oscilloscope connected to the car and check if the signal is there.

[uhi22]

To confirm the PP, measure the voltage between PP and ground. This should sit at around 4V unloaded and drop a little bit when the 1k5 PP resistor is added.

[PLSee]

I dug a little deeper and the pins were indeed swapped, so this is fixed now.
I hooked up the oscilloscope to CP and found multiple voltage states after plugging in the charger.
See the attached video. The forum doesn't let me attach mp4 files. So just rename "video.txt" to "video.mp4".
I'm not sure if this is correct behavior.

The car gives me the following error code in service mode wich lets me believe that it is now a pure PLC error:

I'm using a TL-PA4010 AV600 EU/3.0. I did all the EVSE patching.

[lewurm]

I can't quite make out the y-axis in the video, but it's weird to me that it jumps between three voltages (I assume 12V, 9V, 6V?).

Once you plug in, you should see 9V aka. state B immediately. Then the PLC communication starts and quite some communication should happen until you see a transition to 6V aka. state C right before cable check. On my setup that takes around 2200ms.

Can you share a pcap of that session?

That attenuation of 255 (=0xff) is a bit weird, as pyPLC is sending a hardcoded value of 9. https://github.com/uhi22/pyPLC/blob/761 ... #L471-L474

[uhi22]

The y-axis is 5V per division. The state A (+12V and -12V) look good (*), also the state B (+9V and -12V). But later it looks strange:
The intervals where the PWM is between -4V and +4V is out of spec. Normally the negative always shall be -12V. Could this be a supply issue of the opamp? Could you scope the output of the opamp on a second channel? To see whether it delivers always +12V and -12V?

(*) An other detail: Normally, if the plug is not plugged-in, the CP shall have static +12V (State A). The PWM shall start as soon as the EVSE sees that the +12V changes to +9V. It is not clear, how picky the car is in this detail. My miniEVSE uses static 12V in state A.