Get J1772 adapter to pop charge port door

[TonyWilliams]

Tesla Model S UMC disassembled. It's a bit difficult to disassemble because they used two plastic exterior shells and filled it with a black plastic material. There's really no air in there (or a place for water).

S2 is the switch for the transmitter that opens the Model S charge port. It is powered from the UMC with 3 volts:

 

[Fuzzylogic]

Nice!

What does S1 do?
Are you able to see what part nr they used for U1? I tried searching for a 10 pin ssop microcontroller with RF, but could not find anything.

 

[TonyWilliams]

Nice!

What does S1 do?
Are you able to see what part nr they used for U1? I tried searching for a 10 pin ssop microcontroller with RF, but could not find anything.

S1 is the switch for the J1772 proximity circuit. R1 is the 150 ohm resistor that signals the proximity pin is connected to the car. When the S1 switch is pressed (closed), the 330 ohm resistor R2 is added in series to R1, creating 480 ohms to ground (150 + 330) which signals to disconnect. Yep, that simple.

Sorry, it's common for Tesla to remove the part numbers. I will pull out the card and see what is on the other side.

 

[markb1]

S1 is the switch for the J1772 proximity circuit. R1 is the 150 ohm resistor that signals the proximity pin is connected to the car. When the S1 switch is pressed (closed), the 330 ohm resistor R2 is added in series to R1, creating 480 ohms to ground (150 + 330) which signals to disconnect. Yep, that simple.

Sorry, it's common for Tesla to remove the part numbers. I will pull out the card and see what is on the other side.

Uh... there's only one big button on the outside of the connector. I get that big button actuates both of these little buttons at the same time? Seems a little bit odd.

 

[TonyWilliams]

Uh... there's only one big button on the outside of the connector. I get that big button actuates both of these little buttons at the same time? Seems a little bit odd.

Yes, only one button. If you look at this picture of the bottom side of the button, it has two circular protrusions that actually connect to S1 and S2. The three indents in a row are to clear the solder joints on the circuit card.

 

[Fuzzylogic]

I'm 99% sure now, that U1 is a Silicon Labs Si4010.

Si4010 MCU and RF Transmitter | Silicon Labs

No crystal is required, 8051 MCU build in, can operate at 27-960Mhz.

 

[lolachampcar]

If it is SI, their development environment is dead simple to use. Perhaps I should break out the scope and wire up an antenna to see if we can duplicate the functionality.

Ok, there are a few different development kit options for frequency. Has anyone verified the frequency of operation? If so, I'll get a kit on the way.

 

[FlasherZ]

Ok, there are a few different development kit options for frequency. Has anyone verified the frequency of operation? If so, I'll get a kit on the way.

It is believed that 433.92 MHz is the correct frequency - at least that's what was determined in Europe, but it's believed to be universal.
See Open ChargePort

 

[Banahogg]

It is believed that 433.92 MHz is the correct frequency - at least that's what was determined in Europe, but it's believed to be universal.
See Open ChargePort

I was seeing ~315 MHz for US cars. The FCC document for the key (https://apps.fcc.gov/eas/GetApplicationAttachment.html?id=1725086) lists 315.026 Mhz

433 MHz is only available for ISM use in Region 1 according to wikipedia ISM band - Wikipedia, the free encyclopedia. I believe it's in a ham radio band in the US.

 

[lolachampcar]

darn, that is not one of the supported frequencies in the development kits. I'll read up on it then get a kit on the way. The code base should be small so I should not need the compiler (although I think I still have a license for it).


Update
DigiKey has a 315MHz dev. kit for a whopping $62 so it is on the way. Time to bone up on Manchester Encoding and related nerdly topics

 

[TonyWilliams]

I'm 99% sure now, that U1 is a Silicon Labs Si4010.

Si4010 MCU and RF Transmitter | Silicon Labs

No crystal is required, 8051 MCU build in, can operate at 27-960Mhz.

It's the correct voltage requirement (3.3 volts is supplied), wakes up instantly, etc. if that isn't the one, it should be!!!!

$1.76... Isn't free enterprise awesome? Digikey 336-1997-5-ND

Digikey 336-1997-5-ND

 

[Fuzzylogic]

Update
DigiKey has a 315MHz dev. kit for a whopping $62 so it is on the way. Time to bone up on Manchester Encoding and related nerdly topics

Cool! Nice to see you trying to get this to work.

I also ordered a 434Mhz fob+receiver, p/n 4010-DASKF_434.
It just came in. Only the Keyfob+ receiver + CD.
My device programmer supports the SI4010, so i can use that for programming.

Tried the obvious, seeing if the fob would open the chargeport, but no luck ;-)

 

[lolachampcar]

I ordered in the 315 dev. kit as well (fob and receiver). Please let me know if you have the receiver side and if you can get a code from the handle. With luck, we will get a receiver configured to decode the Tesla transmission thus opening the project up to any programmable fob.

 

[lolachampcar]

I've got the Si Labs 4355/4010 development system. Some of the packet work is done within the radio so I need to get a bit more information about the bit stream that people are decoding. I've looked at Fuzzylogic's PIC Assembly code and the first bits he calls a syncronize portion appear to be Silicon Labs (SL) minimum 3 byte preamble of 0x55. The next thing that SL sends in their packets is the Sync Word and the default is two bytes => 0x2D 0xD4. Here is what that would look like in both Manchester Encoded and non-encoded. Can someone tell me if they are seeing this pattern when they decode the 315 MHz OOK signal? I've also included the preamble in both straight binary and Manchester Encoded (they look the same). Does this look like the syncronize portion at the start of the packet? Do you see 12 positive pulses in the sync?

 

[lolachampcar]

Here are the relevant parts of the Si4355 (receiver) data sheet dealing with the preamble and sync word. These appear to be required elements of any packet sent by the Si4010 in the Tesla charge cable handles. Figuring out these elements at the front of the message and getting the CRC to work will allow us to properly program the Si4010 (I hope).

4.2.6. Preamble Length
A preamble is a defined simple bit sequence used to notify the receiver that a data transmission is imminent. The
length of this preamble will normally be set as short as possible to minimize power while still insuring that it will be
reliably detected given the receiver characteristics, such as duty cycling and packet error rate performance. The
Si4355 allows the preamble length to be set between 3 to 255 bytes in length with a default length of 4 bytes. The
preamble pattern for the Si4355 will always be 55h with a first bit of "0" if the packet handler capability is used.

4.2.7. Sync Word Length and Pattern
The sync word follows the preamble in the packet structure and is used to identify the start of the payload data and
to synchronize the receiver to the transmitted bit stream. The Si4355 allows for sync word lengths of 1 to 4 bytes
and the specific pattern can be set within the EZConfig program. The default is a 2 byte length 2d d4 pattern.

4.2.8. Cyclic Redundancy Check (CRC)
CRC is used to verify that no errors have occurred during transmission and the received packet has exactly the
same data as it did when transmitted. If this function is enabled in the Si4355, the last byte of transmitted data must
include the CRC generated by the transmitter. The Si4355 then performs a CRC calculation on the received packet
and compares that to the transmitted CRC. If these two values are the same, the Si4355 will set an interrupt
indicating a valid packet has been received and is waiting in the Rx FIFO. If these two CRC values differ, the
Si4355 will flag an interrupt indicating that a packet error occurred. The Si4355 uses CRC(16)-IBM: x16+x15+x2+1
with a seed of 0xFFFF.

 

[lolachampcar]

I have to take back all those bad things I said about Silicon Labs Thier development kit comes with an awesome Rf set up utility that lets you turn their receivers into a simple bit level OOK receiver/decoder with a clock output as well!

I need to qet to a quiet envioronment and use a logic analyzer to do a proper capture but the following PDF is what I managed to pull off scrolling through a scope plot. Background transmissions from something make it difficult to capture a proper plot everytime so I just have one buffer deep worth of data.

The data does not appear to be manchester encoded. I say this because the shortest and longest pulse widths are too far apart in size to allow for the mandatory ME state transitions. Using a non ME approach, I get three leading 0x55s of preamble (3 bytes is the minimum configuration for the 4010) followed by a non-standard Sync Word.

Any thoughts from those that know this Rf or encoding better than I?

 

[TonyWilliams]

I have to take back all those bad things I said about Silicon Labs Thier development kit comes with an awesome Rf set up utility that lets you turn their receivers into a simple bit level OOK receiver/decoder with a clock output as well!...

Any thoughts from those that know this Rf or encoding better than I?

Awesome work. Sadly, I have no skill in this area.

 

[Banahogg]

I have to take back all those bad things I said about Silicon Labs Thier development kit comes with an awesome Rf set up utility that lets you turn their receivers into a simple bit level OOK receiver/decoder with a clock output as well!

I need to qet to a quiet envioronment and use a logic analyzer to do a proper capture but the following PDF is what I managed to pull off scrolling through a scope plot. Background transmissions from something make it difficult to capture a proper plot everytime so I just have one buffer deep worth of data.

The data does not appear to be manchester encoded. I say this because the shortest and longest pulse widths are too far apart in size to allow for the mandatory ME state transitions. Using a non ME approach, I get three leading 0x55s of preamble (3 bytes is the minimum configuration for the 4010) followed by a non-standard Sync Word.

Any thoughts from those that know this Rf or encoding better than I?

Yeah, that's definitely not Manchester in that plot, though I can't quite figure out how I could have seen something so clearly Manchester while you're seeing straightforward OOK.

Unfortunately, I don't think I'll be able to double-check this any time soon...

 

[lolachampcar]

Tony,
Neither do I

Bana,
Thanks. Any feedback is a sanity check and is much appreciated.

 

[lolachampcar]

Here are the results using a Silicon Labs Si4355 receiver to capture the output from the Tesla charge cord (which uses a Si4010 transmitter chip). Not shown here is three bytes of 0x55 preamble the radio uses to sync up on the incomming transmission. The data displayed repeats deep into the buffer which means the transmitter sends it many times but the data payload seems to be a fully repeatable 16 bytes. The data is not Manchester Encoded.

The WDS utility that was used to do this testing will also generate the necessary settings to accomplish this with the Si4010 transmitter chip. The one on my development board is already programmed so I have more fresh parts coming in for testing. We are getting close.