-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
With J1172 (2012 edition), 90% is within the range used for AC currents: 90% is 65A. Maximum nominal value is 96% (80A), and 97% is also required to be interpreted as 80A to allow margin for measurement error.
Only values above 97% are undefined, and at that point you can't go much further before the pulse disappears altogether. So, I think that wikipedia information must be wrong.
There's still an outside chance that the PLC comms are in there and just need something different to trigger it, but it seems extremely unlikely with what we know now.
I'm curious about two things. After doing 5% PWM according to J1772, how is the digital protocol selected? Is that up to the car? Detailed in another spec? Which one?
As for supercharger proximity I guess nlc would be very interested in seeing a complete pilot signal communication with a supercharger.
Can only answer for the Tesla :
1)The EVSE provide continuous +12V (state A)
2) After connexion to the car, the car signal its presence connecting a 2.74K resistor to GND, the pilot voltage level switch to 9V
3) The EVSE detects the car and, and send the PWM to tell the car the current available (State B). But we send a 5% PWM which is not a regular PWM value because it means 3A and this current doesn't exist, it's 6A minimum (10% PWM)
4) The car see the 5% PWM and knows it needs to enter DC mode, the car apply 882r resistance to gnd to switch in state C (normally it's to say the EVSE to close its relay, but for the Tesla/supercharger it's to say "we are switching to proprietary communication over pilot signal")
5) The EVSE detects the state C and switch to a 0% PWM (continuous -12V) to free the pilot signal
6) The car send CAN frames over the pilot signal, bitrate 33.333Kbits.
Now I need to ack the CAN frame to see the next frame the car will send. I will try to do this this week end if I can find some free time. The hardware interface is ready, need to add it in my EVSE wallbox to be able to receive and Ack the CAN frame from the car.
We seen that the first byte of the message ID 0x322 is 0x00, it's probably the Vin frame number, and will permit to reconstruct the complete Vin number of the car. Vin contains 17 digits, thus I will probably receive 3 frame on message ID 0x322 with first byte value = 0x00, 0x01 and 0x02, to reconstruct the complete Vin.
Yes it will be probably mandatory to understand the Model S / Supercharger exchange, because the supercharger will probably send data to the car and with my actual test I will not able to know these data. But it will not be easy to sniff the pilot signal during a supercharger session !!!
Yes but actually in France we have no supercharger and no CHAdeMO adapter
And if someone want to try, it needs a board with CAN bus with a specific transceiver. But just on the receive, no need to be able to transmit. Thus a NPN transistor, 2 resistors and a diode are all necessary to receive frame.
That's the same schematic part I put above, between the pilot line and the CAN_Rx pin of the microcontroller.
The problem is to take the pilot signal (the ground will be easy, normally it is connected to the car frame), where to take it
- - - Updated - - -
Yes the CHAdeMO part is pretty easy to implement, now I have the exact protocol :smile:
Which pin is the pilot line and which pin do I ground to? should I expect a serial data stream (record with arduino?) or should I record with an oscilloscope or some other device?
0) Before starting, be very sure you are confident in what you are doing - 400V DC needs to be treated with considerable respect.
1) Both of the small wires are potentially of interest. It should become immediately obvious which is which when you look at the signals on them; if you want to identify them in advance, easiest way is probably
to use your J1772 adapter: pin 4 (bottom left) is CP, pin 3 (bottom middle) is GND, pin 5 (bottom right) is PP.
2) First step is to look at it with an oscilloscope and confirm the results seen by @nlc - expect to see nothing on the PP and a stream of pulses (min 30us) on CP.
But you might find:
- Pulses could be on both CP and PP (used as differential pair).
- Pulses might be -12V to +5V (as captured by @nlc), or might be just 0V/+5V on the real thing
- Or it is just possible that this CAN stuff is some debug mode and the real supercharger does use PLC signalling after all - in which case you should see
high frequency carrier (>2MHz, looking like noise) superimposed on 1kHz.
3) Having determined what you are looking at, you need to build something to capture it - you could do this by hand with an Arduino or similar, but if it is CAN there are loads of CAN monitoring tools out there already.
nlc: very nice job figuring out the transition from AC to DC signalling on the Pilot line, and the single-ended CAN bitrate. I have an AVR-CAN development board wired and programmed, ready to listen. I also have access to a SuperCharger (SC) locally. I'm under the weather currently, and could use some advice as to how to get behind the plastic sides/bottem of the trunk compartment, so as to locate the wiring we're interested in, from inside the car. Using <arg> suggestions, I'll verify the signal levels and timing on both CP and PP. If this succeeds, I should have a complete log of a SC charge session shortly. Thanks for the assistance.
Update: I found my way under the trunk protectors! The three lower pins in the
charging port connect to (lower-left pin, viewed from outside the car) a #16 AWG
purple wire, (middle) a #8 AWG green wire, and (lower-right) a #16 AWG orange wire.
These three wires are wrapped in a black cloth sheath. The two high-current pins
connect to #2 AWG shielded orange wires. The two wire sets are tie-wrapped together,
and they make their way from the charge port connector, over the inside of the
left-rear wheel well panel, and disappear (headed to the motor/charger assembly) at
the driver-side hinge of the rear seat. When the charge port is open and no cable is
connected, I measure +4.4VDC from orange to green, and +0.01VDC/424Kohm from purple to
green. I attached wiring parallel to the three signalling wires, making them available
for monitoring from inside the car. Next, some ordinary EVSE testing/verification.
Thanks to VolkerP for the photo above. Before I put my trunk back together, I should have taken a picture!
charging port connect to (lower-left pin, viewed from outside the car) a #16 AWG
purple wire, (middle) a #8 AWG green wire, and (lower-right) a #16 AWG orange wire.
These three wires are wrapped in a black cloth sheath. The two high-current pins
connect to #2 AWG shielded orange wires. The two wire sets are tie-wrapped together,
and they make their way from the charge port connector, over the inside of the
left-rear wheel well panel, and disappear (headed to the motor/charger assembly) at
the driver-side hinge of the rear seat. When the charge port is open and no cable is
connected, I measure +4.4VDC from orange to green, and +0.01VDC/424Kohm from purple to
green. I attached wiring parallel to the three signalling wires, making them available
for monitoring from inside the car. Next, some ordinary EVSE testing/verification.
Thanks to VolkerP for the photo above. Before I put my trunk back together, I should have taken a picture!
No this thread not died
Wanted to work on this last week end but unfortunately it was not possible.
Everything is ready, just need a couple of hour to try, probably saturday afternoon !
- - - Updated - - -
Thank you but I am not alone, thank too to arg who had the idea of a CAN frame
Thank you very much for you help !
First thing, for now we just want to listen, thus there is absolutely no need to connect to the PP pin (if they use it but I think they don't), because we can easily and reliably retrieve the CAN frame with CP signal only.
On your AVR-CAN, do you have direct access to the CAN_RX pin of the microcontroller ? Because to convert the CP signal to CAN_RX compatible signal level, you cannot use the habitual CAN transceiver. We just have to receive (and no need to ack the frame because the supercharger will do), thus the schematic of the interface between your AVR and CP pin is really easy :
You need to configure the bitrate to have 30us bit duration
- - - Updated - - -
Excellent !!
- - - Updated - - -
We just have to receive (and no need to ack the frame because the supercharger will do), thus the schematic of the interface between your AVR and CP pin is really easy :
You can also replace the NPN transistor with a N channel mosfet, and because they accept more than +/-12V on Vgs, you can remove the 100K resistor and the diode, thus just need 2 components (can't find a easier way !!) :
- The N channel mosfet
- The pull up resistor on CAN_RX signal
Greetings everyone.
I just want to offer some assistance if possible. My personal goal wouldn't really be aimed to a CHAdeMO adapter, since there are so few near me, but, I do think it would be neat to aim for some higher speed home charging as a long term goal for the rare occasions when it would be handy. Custom supercharger, per se. (At night, or when the house is somewhat idle, I easily have 80kW of grid power, soon to include solar, available from my home panels without any modifications or approaching any unsafe thresholds...)
I have tons of electronics and electrical gear... AVRs, FPGAs, scopes, logic analyzer, a Digikey credit line... a supercharging enabled Model S and now the latest supercharger is minutes from where I am every day.
While I'd rather not do anything permanent to the car, I'd be happy to try and sniff a charging session and provide the data if needed and possible without too many headaches. I don't think I have any AVR's handy with a CAN transceiver, but I'm sure I could fine one.
I do have a custom EVSE that I built for my Volt that I could mod to try things also.
I just want to offer some assistance if possible. My personal goal wouldn't really be aimed to a CHAdeMO adapter, since there are so few near me, but, I do think it would be neat to aim for some higher speed home charging as a long term goal for the rare occasions when it would be handy. Custom supercharger, per se. (At night, or when the house is somewhat idle, I easily have 80kW of grid power, soon to include solar, available from my home panels without any modifications or approaching any unsafe thresholds...)
I have tons of electronics and electrical gear... AVRs, FPGAs, scopes, logic analyzer, a Digikey credit line... a supercharging enabled Model S and now the latest supercharger is minutes from where I am every day.
While I'd rather not do anything permanent to the car, I'd be happy to try and sniff a charging session and provide the data if needed and possible without too many headaches. I don't think I have any AVR's handy with a CAN transceiver, but I'm sure I could fine one.
I do have a custom EVSE that I built for my Volt that I could mod to try things also.
Hello Everyone.
Background: I rummaged in my junk box, found an available Olimex AVR-CAN Development Board. The product description and schematic can be found at <https://www.olimex.com/Products/AVR/Development/AVR-CAN/>. I think this particular board came from Mouser Electronics, but I'd bet that DigiKey has them also. Not very expensive. The CPU is an Atmel AT90CAN128. I also have the AVR software development suite. From where it came I don't remember, as it was more that 4 years ago. I program in C, and I use AVRDUDE to drive a JTAG flash programmer (JTAG-ICE) to get compiled/linked code into the AVR-CAN board.
Progress: For this project as <nlc> points out, we need (1) access to the CAN transceiver receiver input pin on the CPU, and (2) the CAN bit clock rate set to 30 uSec. To do these things on this Dev Board, I first cut the trace between the MCP2551 CAN-to-CMOS receiver/driver chip receiver output pin (4) and the CPU CAN receiver input (signal labeled RD1) near the MCP2551, leaving it available for connection of the the 4-part discrete "Tesla" CP receiver at EXT2-20. Next, because the 16 MHz CPU clock frequency is too high for the internal clock divider to produce 30 uSec CAN bit times, I replaced the crystal with a 10 MHz unit. Last, I built the 4-part receiver using a 2N3904 NPN, of which I had an entire drawer full.
Now I'm editing a previous piece of CAN software to pass received CAN messages out the RS-232 port. For testing, I'm temporarily looping the CAN transmitter back into the receiver, using a serial port command to send one message to (a) watch on the scope, and (b) display what's received.
The nearest SC is about an hour away from me. I envy you <wk057> that it's minutes in your case! But I hope my situation will change shortly.
Good work, everyone!!
Background: I rummaged in my junk box, found an available Olimex AVR-CAN Development Board. The product description and schematic can be found at <https://www.olimex.com/Products/AVR/Development/AVR-CAN/>. I think this particular board came from Mouser Electronics, but I'd bet that DigiKey has them also. Not very expensive. The CPU is an Atmel AT90CAN128. I also have the AVR software development suite. From where it came I don't remember, as it was more that 4 years ago. I program in C, and I use AVRDUDE to drive a JTAG flash programmer (JTAG-ICE) to get compiled/linked code into the AVR-CAN board.
Progress: For this project as <nlc> points out, we need (1) access to the CAN transceiver receiver input pin on the CPU, and (2) the CAN bit clock rate set to 30 uSec. To do these things on this Dev Board, I first cut the trace between the MCP2551 CAN-to-CMOS receiver/driver chip receiver output pin (4) and the CPU CAN receiver input (signal labeled RD1) near the MCP2551, leaving it available for connection of the the 4-part discrete "Tesla" CP receiver at EXT2-20. Next, because the 16 MHz CPU clock frequency is too high for the internal clock divider to produce 30 uSec CAN bit times, I replaced the crystal with a 10 MHz unit. Last, I built the 4-part receiver using a 2N3904 NPN, of which I had an entire drawer full.
Now I'm editing a previous piece of CAN software to pass received CAN messages out the RS-232 port. For testing, I'm temporarily looping the CAN transmitter back into the receiver, using a serial port command to send one message to (a) watch on the scope, and (b) display what's received.
The nearest SC is about an hour away from me. I envy you <wk057> that it's minutes in your case! But I hope my situation will change shortly.
Good work, everyone!!
Similar threads
