Supercharger protocol for diy CHAdeMO adapter

[arg]

A supplementary detail, you will see on screenshoot that it seems the Tesla can force a level 1 on the pilot signal when the EVSE send -12V, but it cannot force a 0 level when the EVSE send +12V (during the 5% duty cycle ON level).

Thus I can see the 5% ON time from EVSE with +12V perturbates the Model S signal because it cannot force a 0 level. Thus I think when the DC session begins (before the modulation the Tesla asks for charging so we can detect the Tesla begins its session), we probably need to force the signal pilot PWM to 0% (-12V), to not perturbate the Tesla signal and be able to receive it correctly. In this case the pilot signal maybe work as an half duplex serial port. This would be a clean and beautiful way to change the pilot signal behavior and do bidirectional data communication :smile:

This seems a bit odd.

You would expect the modulation to be AC-coupled into the pilot, and the EVSE is supposed to present a symmetrical 1K impedance. Have you perhaps got some ESD protection on the output of your EVSE that's clipping the positive excursions?

I'm also not convinced by your 0% plan - if the pilot is permanently driven low, then the EVSE can't detect the pilot becoming disconnected. It seems unlikely that they would have dropped this secondary safety feature.

 

[nlc]

This seems a bit odd.

You would expect the modulation to be AC-coupled into the pilot, and the EVSE is supposed to present a symmetrical 1K impedance. Have you perhaps got some ESD protection on the output of your EVSE that's clipping the positive excursions?

It's the case, my EVSE present a 1K symetrical impedance. I have a ESD protection but at higher level, and it not clip signal. And I perfectly see the data burst modulation of my HomePlug GreenPhy hardware. Really, the Tesla doesn't send a Homeplug PLC modulation at all !!

I'm also not convinced by your 0% plan - if the pilot is permanently driven low, then the EVSE can't detect the pilot becoming disconnected. It seems unlikely that they would have dropped this secondary safety feature.

You are right, but don't forget in this case the EVSE is not a standard EVSE, it's a supercharger. A real EVSE never send a 0% PWM, but when sending a 5% PWM, we tell the Model S we are a DC charging station (thus a supercharger), and in this case send a 0% duty cycle is not a problem because a digital communication takes place between the supercharger and Model S (easy to detect a deconnection)
I think I am on the right way because when sending a 5% PWM, the Model S is asking for charge (thus close the relay in a standard EVSE), and there is no reason to do that at this stage !! In my opinion, this is the way the Model S is asking to the supercharger to switch to digital communication. 2 second after the Model S asked for charging, it begins to send data on the pilot signal. The 2 seconds delay really seems to be the delay for the supercharger to detect the ask for charge and "mute" the pilot signal, and switch it to digital communication

- - - Updated - - -

Here some capture of the signal, sorry for poor quality, the day was sunny today !!

The higher signal lever is the 5% PWM from the EVSE. We can see on capture 1/2 on some EVSE 5% PWM pulse that the Model S was sending a zero just before, but is truncated by the EVSE pulse. It's why I am almost sure that when the Model S detects the 5% PWM and asks for charge, we need to switch to digital communication and let the pilot signal to -12V.

The shortest -12V pulse sent by the Model S is 32us, the communication is probably just an half duplex UART with a 31250 baud rate

 

[nlc]

Just finished modified my EVSE firmware to switch in Tesla mode when the Model S asks for charge after it detects the 5% PWM. Thus in this mode I switch to 0% PWM and I stop to read the pilot signal status to not switch to error.
Doing that I will be able to trigger my oscilloscope on the very first data sent by the model S, and I will be able to see if this is an uart communication looking for valid byte (start bit, 7/8/9 data bit, stop bit) in the data frame.
If yes, will be able to connect the pilot signal on my computer, already have a linux software to do non standard baudrate.

 

[arg]

I
You are right, but don't forget in this case the EVSE is not a standard EVSE, it's a supercharger. A real EVSE never send a 0% PWM, but when sending a 5% PWM, we tell the Model S we are a DC charging station (thus a supercharger), and in this case send a 0% duty cycle is not a problem because a digital communication takes place between the supercharger and Model S (easy to detect a deconnection)

Detecting disconnection through the high-level protocol would be too slow, but I suppose there is still the Proximity pin as well.

I think I am on the right way because when sending a 5% PWM, the Model S is asking for charge (thus close the relay in a standard EVSE), and there is no reason to do that at this stage !! In my opinion, this is the way the Model S is asking to the supercharger to switch to digital communication. 2 second after the Model S asked for charging, it begins to send data on the pilot signal. The 2 seconds delay really seems to be the delay for the supercharger to detect the ask for charge and "mute" the pilot signal, and switch it to digital communication

Certainly the J1772-DC calls for the digital communication to be established in state B (+9V on positive pilot), only advancing to state C (+6V) after the initial negotiation. So there's something else going on here.

 

[nlc]

Detecting disconnection through the high-level protocol would be too slow, but I suppose there is still the Proximity pin as well.

Physical disconnection is not possible, cable is locked in the car :wink:
The Model S will never release the cable if current is flowing and the closing negociation is not finished

Certainly the J1772-DC calls for the digital communication to be established in state B (+9V on positive pilot), only advancing to state C (+6V) after the initial negotiation.

No, there is no communication initiated in state B from the Tesla, in fact it doesn't stay in state B :
- State A, the car pull the signal pilot to 9V to tell "I am here" (pilot signal is 100% PWM)
- State B, I send the 5% PWM, and immediately the Model S pull the pilot to 6V to initiate state C
- 2 seconds later, it begins to send the data signal you can see above, and which are absolutely not J1772-DC signaling

So there's something else going on here.

Why ? In fact there is absolutely no reason they wanted to respect this J1772-DC "standard", why should they do ? Supercharger are just for Tesla, and Tesla is not natively designed to connect on CCS/Combo1/Combo2 charger stations. Thus no need to implement this very heavy and complicated J1772-DC protocol to only send a current consign to a DC charger station.

 

[stopcrazypp]

So this basically confirms Tesla is using something proprietary at this point. I expected that given it also prevents the situation where someone makes their own adapter to J1772-DC and tries to use a superchargers station that way.

 

[arg]

Certainly the J1772-DC calls for the digital communication to be established in state B (+9V on positive pilot), only advancing to state C (+6V) after the initial negotiation. So there's something else going on here.

Why ? In fact there is absolutely no reason they wanted to respect this J1772-DC "standard", why should they do ? Supercharger are just for Tesla, and Tesla is not natively designed to connect on CCS/Combo1/Combo2 charger stations. Thus no need to implement this very heavy and complicated J1772-DC protocol to only send a current consign to a DC charger station.

I was agreeing with you! "this isn't J1772-DC, it's something else".

 

[matbl]

Just a quick thought. Isn't greenphy plc modulated on the phy layer with carriers between 2 and 30 MHz? So measuring with an oscilloscope wont't give you much, I think you need a spectrum analyzer if you want to properly analyze the signal...

 

[nlc]

I was agreeing with you! "this isn't J1772-DC, it's something else".

Oups, sorry I misunderstood your message :redface:

- - - Updated - - -

Just a quick thought. Isn't greenphy plc modulated on the phy layer with carriers between 2 and 30 MHz? So measuring with an oscilloscope wont't give you much, I think you need a spectrum analyzer if you want to properly analyze the signal...

When I tried to synchronize with my HomePlug Hardware, the data sent by my hardware were very easy to see, even with oscilloscope. It look like noise bursts.

Do another test today, it works exactly how I expected yesterday :smile:
After presenting the 5% PWM, the Model S asks for charge, thus I don't close the relay but I switch the pilot signal to 0% (fixed -12V), and after a small delay, the Model S try to engage the communication. Now without the PWM signal from my EVSE, it was easy to set the trigger on the oscilloscope to capture frames.

In fact, the Model S send multiple time the same data frame, it looks like this :

Zoom on the frame, the begin (between the dotted line)

and the end

I counted 103 bits, each bit is exactly 30us length.
Unfortunately, it seems it's not uart, start + 8 bits + stop or start + 8 bits + parity + stop doesn't work, at a moment the stop bit is not good

For those interested to look, the bit values are :

1100110111011110111110111110111001010101001101011010110101100101111100110011011011011111001000001110001

Or probably the inverse if +12V is level 0 as rs232 levels

 

[arg]

For those interested to look, the bit values are :

1100110111011110111110111110111001010101001101011010110101100101111100110011011011011111001000001110001

It looks a lot like the negative side of a CAN bus:

Invert your bits:
0011001000100001000001000001000110101010110010100101001010011010000011001100100100100000110111110001110

Remove stuffing bits after runs of 5:
001100100010000100000000000001101010101100101001010010100110100000110011001001001000001011111001110

Split up into the CAN fields:
0 start bit
01100100010 Identifier
0 RTR bit
001000 Control field (length = 8)
00000000 Byte 0
00110101 Byte 1
01011001 Byte 2
01001010 Byte 3
01010011 Byte 4
01000001 Byte 5
10011001 Byte 6
00100100 Byte 7
000101111100111 CRC
0 ACK


I don't have an easy way to check the CRC field which would really give a strong clue, but all the field sizes seem to line up.


If it is CAN, then either they are using the PP for the other wire, or else they have just used a proprietary single-ended driver in place of standard differential CAN drivers. Can you easily get a probe onto the PP in your setup?

 

[TonyWilliams]

Awesome work, guys!!!

It looks a lot like the negative side of a CAN bus:

Invert your bits:
0011001000100001000001000001000110101010110010100101001010011010000011001100100100100000110111110001110

Remove stuffing bits after runs of 5:
001100100010000100000000000001101010101100101001010010100110100000110011001001001000001011111001110

Split up into the CAN fields:
0 start bit
01100100010 Identifier
0 RTR bit
001000 Control field (length = 8)
00000000 Byte 0
00110101 Byte 1
01011001 Byte 2
01001010 Byte 3
01010011 Byte 4
01000001 Byte 5
10011001 Byte 6
00100100 Byte 7
000101111100111 CRC
0 ACK


I don't have an easy way to check the CRC field which would really give a strong clue, but all the field sizes seem to line up.


If it is CAN, then either they are using the PP for the other wire, or else they have just used a proprietary single-ended driver in place of standard differential CAN drivers. Can you easily get a probe onto the PP in your setup?

 

[nlc]

It looks a lot like the negative side of a CAN bus:

Yes, you made a small mistake, but it seems to work !!

Original bit stream :
1100110111011110111110111110111001010101001101011010110101100101111100110011011011011111001000001110001
Inverted, with bit stuffing in bold :
0011001000100001000001000001000110101010110010100101001010011010000011001100100100100000110111110001110

Frame without bit stuffing (you forgot to delete one stuffing bit). Bit in bold at the end are recessives bits because the data line is free (-12V)

0011001000100001000000000000011010101011001010010100101001101000001001100100100100000101111100111011111...

Thus :

0 START
01100100010 ID
0 RTR
001000 DLC= 8 byte
00000000 byte 1
00110101 byte 2
01011001 byte 3
01001010 byte 4
01010011 byte 5
01000001 byte 6
00110010 byte 7
01001000 byte 8
001011111001110 CRC (15 bits)
1 Delimiter (recessive)
1 ACK (recessive because no device Acked the frame with a dominant bit)
1 Delimiter
111... End of frame end bus idle

:smile:

I try to verify the CRC, I come back :tongue:

- - - Updated - - -

IT WORKS !!! :biggrin:

char* frame = "00110010001000010000000000000110101010110010100101001010011010000010011001001001000001011111001110";
u16 crc_value;


void crcAddBit ( u16 *crc, u16 bit )
{ u16 crc_next;
  crc_next = bit ^ ((*crc >> 14) & 1);
  (*crc) <<= 1;
  if ( crc_next == 1 )
      *crc = (*crc ^ 0x4599) & 0x7fff;
}



int main (int argc, char **argv)
{
 int i;
 int ret;

 crc_value = 0;

 for ( i=0 ; i<strlen( frame ) ; i++ )
 { crcAddBit( &crc_value, frame[i]=='1'?TRUE:FALSE );
 }

 printf( "CRC Result : %04x (%s)\n", crc_value, crc_value==0?"OK":"KO" );
 return 0;
}

CRC Result : 0000 (OK)

 

[nlc]

Thus in this data frame, the Model S sends these 8 bytes to the charger with CAN identifier 0x322 :

0x00
0x35 --> 5
0x59 --> Y
0x4A --> J
0x53 --> S
0x41 --> A
0x32 --> 2
0x48 --> H

Hum, it's the beginning of my VIN :scared:

 

[Johan]

Thus in this data frame, the Model S sends these 8 bytes to the charger with CAN identifier 0x322 :

0x00
0x35 --> 5
0x59 --> Y
0x4A --> J
0x53 --> S
0x41 --> A
0x32 --> 2
0x48 --> H

Hum, it's the begin of my VIN :scared:

That's cool. Works well with the fact that you need to enable SC to be able to charge on a supercharger as well as with the Chademo adapter.

 

[nlc]

Yes you are right, but enable SC is not just a software thing, they probably also install specific hardware to be able to route the power pin of the charge port directly to the battery pack.

Now I need to ack this CAN message to see next messages...

 

[arg]

Yes you are right, but enable SC is not just a software thing, they probably also install specific hardware to be able to route the power pin of the charge port directly to the battery pack.

Originally, that was supposed to be the case - the extra $2000 paid for the supercharging hardware - but a few months after production started they announced that all cars were built with supercharging hardware and the upgrade for non-supercharge cars is simply a case of enabling it.

If you look at the bottom of the 'design studio' page on the Tesla site, it says:

In some cases, Tesla will temporarily enable Supercharging on non-Supercharging equipped vehicles to permit pickup from a Tesla location.

 

[nlc]

Interesting !!

- - - Updated - - -

The CAN "transceiver" will be very easy, just 2 transistors and some passive components added to original schematic :

When my PWM will be 0%, the CAN_TX can send dominant bit (level 0), and it will send a +12V on the pilot line. And +12V on pilot line will force à level 0 on the CAN_RX pin.

Just tried on a board with CAN equipped to send the exact same frame as the Model S, that's OK I found how to configure the CAN to have 30us bits :smile:

 

[arg]

The CAN "transceiver" will be very easy, just 2 transistors and some passive components added to original schematic :

Are you sure it's really single-ended, and not using the PP pin for the other side of a conventional differential CAN? I would try to get a probe on PP to make sure, before spending time to build up this hardware.

Also, I wonder if the recessive state is supposed to be 0V rather than -12V.

 

[nlc]

Actually from the scope capture I can conclude the recessive state is "floating", the -12V comes from the 0% PWM and 1K impedance.

I don't think the Proximity signal is used, I can verify but I need to open the type 2 plug to get the signal.

 

[widodh]

Actually from the scope capture I can conclude the recessive state is "floating", the -12V comes from the 0% PWM and 1K impedance.

I don't think the Proximity signal is used, I can verify but I need to open the type 2 plug to get the signal.

I most cases PP is only used for deciding how much current the cable can take in AC modus.