Tesla Wall Connector load sharing protocol

[robertvg]

Not what I am seeing. I see 26A and 6A to the other car. The hpwc seems to measure the actual current going to each car

Even more interesting.
Wasn't the charging limited in the 330i at that moment ? (don't know the (im)possibilities of that car)
How would it decide to split the available Amps 26/6 for your Tesla and the 330i?
I can imagine it would distribute the power at a certain ratio between two Tesla's as theoretically these cars could communicate the SoC to the HPWC as @davewill claims above but afaik only Zoe's can communicate this (by iso15118)

 

[widodh]

Even more interesting.
Wasn't the charging limited in the 330i at that moment ? (don't know the (im)possibilities of that car)
How would it decide to split the available Amps 26/6 for your Tesla and the 330i?
I can imagine it would distribute the power at a certain ratio between two Tesla's as theoretically these cars could communicate the SoC to the HPWC as @davewill claims above but afaik only Zoe's can communicate this (by iso15118)

Also happens with other cars.

It checks the amount of current the car is drawing and adjusts the pilot signal based on that? In don’t know exactly.

 

[cbutters]

Here is some load sharing data between a Model X and a BMW i3 charging at the same time on a 40 amp circuit. They load share pretty efficiently together, the problem is when only the tesla is actually charging, the charge rate drops to ~34 amps, when the i3 stays connected. If I then disconnect the i3 (and the JDapter), the tesla then uses the full 40 amps.

 

[widodh]

That is probably because 6A is the minimum current a EVSE can deliver. There is nu such thing as saying that a charge is completed to the EVSE.

So 6A is reserved in case the i3 asks for it.

 

[TheNoOne]

Hi guys, I think I found kind of a "checksum", there is a sum of all bytes at the end (bits>7 cut off) e.g.:

c0 fb e2 03 5d 5f 00 00 00 00 00 00 00 00 a1 c0 fe
e2+03+5d+5f=1(a1)

c0 fc e1 03 5d 39 00 00 00 00 00 00 00 00 7a c0 fe
e1+03+5d+39=1(7a)

These are two reset messages from my EU 3-phase wall connector (also saw that the reset messages end with c0 fe instad only c0).
Also found out that every four hours there are idle message repeated three times from the master, e.g.:

c0 fc 1d 00 00 00 00 00 00 00 00 00 00 00 1d c0
("checksum" is 1d because all zeros in between)

Greetings,
TheNoOne

 

[widodh]

Great find! Can you tell me how you are sniffing this traffic? What kind of hardware and software do you use?

 

[TheNoOne]

Sure, the hardware I connected is an etherrape (lochraster.org - etherrape project page) I had lying around running ethersex (Feature List/en – Old Ethersex) with YPort enabled. My wall connector is some 20 meters away from my apartment and I use powerlan adapters (IEEE1901) to get ethernet there. Currently the software is only a small php script which outputs all data in hex from the yport server/wall connector but I'm planing to do a kind of "charging log" by saving start and end time into a database.

If you want I can also duplicate my setup and upload schematics+software using a RaspberryPi and a LTC485 (LTC485 - Low Power RS485 Interface Transceiver - Linear Technology), thats basically all you need.

 

[widodh]

Sure, the hardware I connected is an etherrape (lochraster.org - etherrape project page) I had lying around running ethersex (Feature List/en – Old Ethersex) with YPort enabled. My wall connector is some 20 meters away from my apartment and I use powerlan adapters (IEEE1901) to get ethernet there. Currently the software is only a small php script which outputs all data in hex from the yport server/wall connector but I'm planing to do a kind of "charging log" by saving start and end time into a database.

If you want I can also duplicate my setup and upload schematics+software using a RaspberryPi and a LTC485 (LTC485 - Low Power RS485 Interface Transceiver - Linear Technology), thats basically all you need.

Something with a Pi would be great indeed. My connectors are outside our office. With a Pi on WiFi I could sniff the traffic while it does loadbalancing and see if I can find something in there.

 

[K-MTG]

Something with a Pi would be great indeed. My connectors are outside our office. With a Pi on WiFi I could sniff the traffic while it does loadbalancing and see if I can find something in there.

Interested in this...maybe a video tour of the setup? Since I also have a non Tesla it would be nice to setup some load ballencing when my 3 comes in...3 electric cars charging

 

[TheNoOne]

There are several options to get RS485 on a Pi:

• RS422 / RS485 Shield for Raspberry Pi (probably a good option because its isolated)
  
• search for "rs485 ftdi" on Amazon for an USB adapter (probably the cheapest option)
• use a single tranceiver chip e.g. LTC485 or MAX485 or similar with the Pi's built-in UART (soldering required)

 

[widodh]

Yes, I think I'll go for a USB version so I can easily run some Python code on my laptop and sniff the traffic.

I haven't worked much with RS485 before so it's new to me. Mainly been doing RS232 but that shouldn't differ that much.

 

[TheNoOne]

Ok cool, I'll also grab a usb adapter and try connecting it with my wall connector+Pi, so there's no soldering to do.

RS485 is nearly identical to RS232, main difference: its half-duplex, the transceiver has to be switched to either receiving or transmitting mode. Despite that there are no other flowcontrol lines (CTS/DTR). But for sniffing you only need receiving mode so just set your serial port to 9600 8n1 and watch the traffic.

 

[Erik100]

Fastned (public fast charge stations in the Netherlands) announced charging without rfid/app etc. Recognition of the car is part of the CCS fast charge protocol. The car sends a unique identifier!

Can this be done with the regular charge protocol? Does that contain a unique identifier?

 

[widodh]

Fastned (public fast charge stations in the Netherlands) announced charging without rfid/app etc. Recognition of the car is part of the CCS fast charge protocol. The car sends a unique identifier!

Can this be done with the regular charge protocol? Does that contain a unique identifier?

No, the basic J1772 protocol doesn't do anything like that.

There are some extensions on the J1772 protocol, but I'm not that familiar with those. Don't know if they include a VIN and such.

This protocol between the HPWCs is something which is done without the car sharing any information.

 

[davewill]

No, the basic J1772 protocol doesn't do anything like that.

There are some extensions on the J1772 protocol, but I'm not that familiar with those. Don't know if they include a VIN and such.

This protocol between the HPWCs is something which is done without the car sharing any information.

It would be more accurate to say that it WORKS without the car sharing any information. There's been reason to believe that the cooperating wall connectors DO get charge level info from Tesla vehicles, although no proof. The Superchargers definitely have a CAN connection to the car over the same connector.

 

[MP3Mike]

There's been reason to believe that the cooperating wall connectors DO get charge level info from Tesla vehicles, although no proof.

I think there has been proof, as someone plugged two Teslas: in one at ~80% the other at ~20% and the majority of the power was directed to the lower SOC vehicle rather than being split 50/50.

 

[scaesare]

It would be more accurate to say that it WORKS without the car sharing any information. There's been reason to believe that the cooperating wall connectors DO get charge level info from Tesla vehicles, although no proof. The Superchargers definitely have a CAN connection to the car over the same connector.

And a log of a supercharging session has revealed the car does send it's VIN to the superchargers.

Although nothing I've seen says they this is done for a HPWC...

 

[TheNoOne]

Small side project, I captured the charge port open signal from my eu wall connector.
Its transmitted on 443.920 MHz using I belive OOK+Manchester.
For each button press the message is repeated ten times (looking at three of those in the first screenshot).

The full messages only decoded with OOK (no Manchester) is:

101010101010101010101010100010101100101100110010110011001100110011001011010011010010110101001010110100110100110010101011010010110001010110010110011001011001100110011001100101101001101001011010100101011010011010011001010101101001011000101011001011001100101100110011001100110010110100110100101101010010101101001101001100101010110100101

Inside the message there are three manchester code violations (100). If you cut the message there you get preamble, 12 decoded bits all ones and three repeated messages, 50 decoded bits.

without Manchester decoding:

101010101010101010101010 100
0101011001011001100101100110011001100110010110100110100101101010010101101001101001100101010110100101 100
0101011001011001100101100110011001100110010110100110100101101010010101101001101001100101010110100101 100
0101011001011001100101100110011001100110010110100110100101101010010101101001101001100101010110100101

with Manchester decoding:

111111111111 1?
00010010100101010101001101100111000110110100001100 1?
00010010100101010101001101100111000110110100001100 1?
00010010100101010101001101100111000110110100001100

It should be possible to emulate the signal using rpitx but I didn't find a to generate OOK yet (Best way to send OOK? · Issue #85 · F5OEO/rpitx · GitHub).

Greetings,
TheNoOne

 

[swaltner]

On a quick search, I didn't find it, but there was a thread here where someone here built/sold key fobs that could open the charging door. The idea was that they could be used for people using J1772 chargers to get some of the convenience of the Tesla EVSEs. Initial designs transmitted with a little too much power and could open every charge port within a rather large area.

 

[TheNoOne]

If someone with a Model S/X/3 + RaspberryPi + small wire on GPIO18 (Pin 12) wants to try my generated RF file I'd like to know if it works

sudo rpitx -i chargeport.txt -m RF -f 433920