Mini-QC Rapid-Charger (RC) Project for LEAF QC Port

[valerun]

Greg & others - I have opened the doc for view access by anyone - click here: https://docs.google.com/document/d/1y-TsN_L7WQ0qMbQ_yLl0iH7qwdwd6WkHqWdD_40P8Zc/edit?usp=sharing" onclick="window.open(this.href);return false;. To answer your specific question re binary vs ASCII - could use either but we have to respect some backward compatibility constraints we have with our existing customers so it will have to be ASCII.

Gary - I have added answers to your questions. Please comment on the side of the doc so it's easier to track comments.

Thanks!
Valery.

 

[garygid]

At the moment, I do not know how to add comments
"on the side", but I will look for some way to do that.

-------

battery should not be attached here. The car should signal
before connecting the battery and wait for positive confirmation
of 'ok to connect' from QC controller. I am sure this is how it's done
in the car as otherwise it would be unsafe with any charger.

Actually, the output relay should be open most of the
time, whenever the charger is idke, or sleeping.
Certainly before and after plugging in the mini-QC cable
to the vehicle.
After Start is pressed, and one is sure that the cable
is connected (by having handshakes AND suitable
CAN communication), and we are ready to ramp the
voltage up, only then, after checking that the external
voltage is very low, and that the voltage on the internal
capacitors match. Do we need a voltage-match command,
or just read the output voltage in the status, and
do an M-command with 0 current and a matching voltage,
or make voltage "-01" mean "match the output"?

Then, who decides that it is "safe" to close the relay?

True, after we finish the un-loaded ramp voltage up and down,
like M,001,445,E to ramp up? Or, we might have to do
a series of voltages to control the ramp up rate, right?
(ramp up over perhaps 4 seconds)

Then settle and sit for a second, looking for any current,
so reporting and setting current to 0.1 amps might be
needed?

Then, a faster ramp down, with perhaps
M,001,001,E
would still leave the output relay closed, right?

Then, since we can't have the relay closed when the
battery is being connected, something like M,002,000,E
would open the relay, but not stop the charging session?

Then, after the car tells us that is OK to continue, and
we signal the car that it is OK to attach the battery,
the relay must still be open, and we wait until we read
the applied battery voltage on the output.

Then, what command would tell your charger to
match the battery voltage without drawing
any noticeable current from the battery?

If you are off by a volt, there could easily be a
"zap" of current (in or out), unless you incorporate
an in/out rush limiting resistor, switched in by
an "equalizing" relay, which you then bypass,
after equalizing, with the primary output relay.

What is your plan here?

We have not investigated the tolerance on
this settling current, we just used the diodes
that you provided, attached to the heat sink,
as appears to be suggested / required by
the described QC interface.

When using an output diode, we ramp the voltage up
quickly until we get about 0.1 amp out, and wait for the
car to request 1 amp, 3, 5, etc., rising about 20 amps
per second. These requests would probably cause a series
of M,001,427,E then M,003,427,E... commands, one every 100 ms.

We found that following this ramp of current to be
a challenge to not lag too far behind, as you can see
from the logs or graphs that we sent to you.

------
If you use E for the command terminator, do not
use E for anything else, like Echo. Do your commands
not have, or allow a new-line terminator?

Or, are un-recognized characters just ignored?

Cheers, Gary

 

[jclemens]

Updated blog with instructions on how to make 1.5mm data pins

http://erroneus.myevblog.com/2013/12/15/1-5mm-pins-for-who-knows-what

I have temporarily given up trying to create a latching device to lock down the plug while energized. I need to deliver what I have so far so we can continue with development.

I also hope to have the harness for a packet-sniffer ready for testing next week. (Actually had a test last sunday, but it failed due to bad positioning of the inlet pins... (too deep).
I had to re-print the inlet... but re-assembly is getting pushed out while I worked on some other stuff.

 

[valerun]

At the moment, I do not know how to add comments
"on the side", but I will look for some way to do that.

select an area of text you'd like to comment on and right-click on the selection. In the drop-down menu that will appear, select 'Comment'. It's much easier to track the discussion that way then here on the forum.

 

[jclemens]

I have completed the next version of the jolomo plug, it still does not have locking ability, but does have a proximity switch and strain relief.
The one shown in the below photos is going to Valery, there is a slightly different one that will go to Gary. The disassembly instructions will he the same. I have also uploaded an HD video showing the latch and trigger in action, the primary function right now is the same as J1772. (Proximity detection)
Click an image and look at the bottom of the screen for notes.

https://skydrive.live.com/redir?res...6&authkey=!AM0ZWBV1TXV6J2I&ithint=folder,.jpg

 

[jclemens]

[youtube]http://www.youtube.com/watch?v=MIBodC8yAt0[/youtube]
This video is unlisted and only people visiting this forum thread will be aware of it.

I wanted to get this done before xmas, however I can only do this on weekends so that nobody is around and in daylight. I was rained-out the previous weekend. This could have only been done in dry weather for obvious reasons. Finally got to the test yesterday.

Using ethernet cable, here is the color code I used for the plug based on:
http://www.chademo.com/pdf/interface.pdf

QC PIN	Name	Cat5e color
1		GND		Brown/White
2		SS1		Green
3		NC		Not used
4		EN		Brown (connected to proximity switch)
5		+		(HV power)
6		-		(HV power)
7		Conn chk	Blue	
8		CAN-H	Orange
9		CAN-L	Orange/White
10		SS2		Blue/White

I used the EN line (pin 4) on the proximity switch because in the event that it is triggered, the signal would not be left floating (as it would be if pin 7 was used).

The signal is put through the the normaly-closed part of the switch, if the plug is pulled (or trigger pressed) the switch will open and the signal will break. This may or may not brick your car, I didn't want to test this. (Of course I did do a continuity test on all the pins as soon as this thing was built.)

Rule 1 - DO NOT TOUCH any plug/cable when the charger is running.
Rule 2 - Do not use when there is any kind of moisture falling on the car/charger/cables (liquid or solid).
Rule 3 - Abort the charge if the temperature on the indicator reaches 50 degrees C (hot to the touch, but no risk of melting ABS plastic).
Rule 4 - Do not leave unattended. If any potential curious and uninformed people come near the car, abort the charge.
Rule 5 - DO NOT TOUCH any plug/cable when the charger is running.

Further notes:
The temperature probe which is taped to the outside of the case is in contact with the HV pin inside the inlet, it is taped on with kapton tape and has thermal grease to ensure an accurate reading. You may remove this if you are comfortable that it will not get hot while running at full power. DO NOT TOUCH IT with bare hands while charging. (I used some dry plastic to gently press the ON button when it turned itself off).
This circumvents at least 1 safety feature of the charger (the lock), use at your own risk. You may brick your car or worse. (I have the LeafSpy Pro app and can reset DTCs which should un-brick the car, but didn't need to.)
Why are the cables so short? 2 reasons, I had bought some 2AWG welding cable to test with, 2ft exactly. I didn't have a further use for it. Also I was planning on shipping it, having a longer cable would mean higher costs in cable, plus higher costs in shipping. Also the chademo plug would likely be flat on the ground.

The box housing the inlet has enough space and cat5e slack to add whatever electronics you want for actual packet sniffing. You can monitor the voltage and current of every data line if you were so inclined.

Will be shipping this to California soon. (tomorrow?) There is a much larger data pool there to pull packets from.

 

[valerun]

Joel - you're The Man! Like I mentioned in my email, your plug is a work of art.

Quick update on our side. I know things have been a bit silent but we were definitely not sitting idle ;-) Couple of things:

1. We have been able to figure out much more optimal sourcing for a number of components for our isolated 20kW unit. This will definitely result in lower pricing on the QC chargers when we start selling them

2. We have designed a 3-phase PFC version of the front-end stage (30kW) and will be testing the prototype soon. This was actually triggered by one of our new customer contracts but we plan to reuse that for the QC product. This will make a lot of people outside of US happy.

3. We have designed an 8kW version of our isolated charger. We are testing the first prototype of that in 2 weeks. It uses the same principles as our 20kW unit and is designed to fit into ~10x10x4 profile with option to be mounted on top of air heatsink or a liquid cold plate. We expect that unit to be used as an add-on onboard charger operating in parallel to stock charger and driving more power into the battery - similar to Viktor Tikhonov's mod described elsewhere. Of course, any of our isolated units will be usable with the QC controller Gary is building.

4. Finally, we've been rewriting part of our control software to incorporate more broad serial command set and a more responsive control loop. We should have the first version of this ready to be paired with Gary's QC controller in the next week or so.

Thanks,
Valery

PS. In the meantime, we have also managed to get out the first batch of our Premium JuiceBox EVSEs - with WiFI, LCD, and many other cool features. Was quite a sprint to get them out before end of year...

 

[valerun]

good day today.

The photo below is showing Leaf's battery voltage after the car has finally allowed my Due-based setup to access the battery through its QuickCharge port - 386V could be seen on the meter.

Setup:

Hardware:
Jolomo plug (AWESOME job on this, Joel!), Arduino Due, SN65HV234 CAN tranceiver on Due's CAN0 controller, 2 relays to provide +12V / GND to Jolomo plug, and a bunch of other stuff that's not yet used (80A precharge contactor, WiFi module, etc).

Software:
due_can library + ~500 lines of code.

This is not yet connected to a charger but it does issue the current ramp commands. I will plan to get it properly connected to our isolated charger in the next few days. My overall plan is to use this setup to quickly tune the charger to meet the car's absolute minimum requirements.

Thanks Gary, Joel, and Jason for various info & encouragements.

Valery.

 

[xado1]

keep on working,you all are awesome.you are watched by the german and austrian ev community.

http://www.goingelectric.de/forum/ladeequipment/mobiler-chademo-css-schnelllader-t2714.html" onclick="window.open(this.href);return false;

 

[braineo]

This project is incredible and fully support the learning curve you guys have been sharing with the world. One question, wouldn't it be possible to redirect the current back to the home in the event of power failure, making it the frugal Leaf to Home?

 

[hbleaf]

There is a safety preamble initiation phase to Chademo where the charger is acting as a voltage source and spiking on command to enable a pair of leakage and welding checks, one by charger another by vehicle. You could state in message 108h that you don't support weld detection but the leakage is still required. The tests could probably be non-existent but the charger output must satisfy Chademo spec and will be verified by any Nissan Leaf. Without this pre-amble the car will never enable the fast charge (ie contactor will not close). Charger contactor precedes the car's and the car will check that voltage is within spec before closing its contactor and initiating charge. By matching voltages current surges are prevented. This all followed by quick current ramp as requested by Leaf.

Steve

 

[reeler]

This project is incredible and fully support the learning curve you guys have been sharing with the world. One question, wouldn't it be possible to redirect the current back to the home in the event of power failure, making it the frugal Leaf to Home?

If I could get Leaf To Home capability, spending a few thousand dollars would not be an issue for one of these. Just the cost of a back-up generator plus the quick-charging capability.

 

[jclemens]

... One question, wouldn't it be possible to redirect the current back to the home in the event of power failure, making it the frugal Leaf to Home?

Right now, it is not possible, we need to make a reliable charger first. However, in the long run, yes, we hope that this can be done, however it seems that currently, the Leaf only has chademo version 0.9 loaded into the charger firmware. This does not cover dis-charging. (vehicle to grid). If the amps do not match what the car expects, it will fault-out.
I heard that the i-miev has chademo v 1.0 and can do it, but in order to discover this, we needed the packet sniffer. Gary has this now and it is up to him.
That thing was a pain in the a$$ to build. If someone else wants a packet sniffer, it won't be for free. I was motivated to do the first one, partially to see if it could be done, but also because we lost our test leaf. (I think).
It would be easier to build another packet sniffer with a chademo inlet that has been pulled from a wrecked car, and just put a 3d printed plug on it.

 

[braineo]

I'm getting my 2nd EV a iMiev - so I can be a test subject sometime in the future.

 

[valerun]

There is a safety preamble initiation phase to Chademo where the charger is acting as a voltage source and spiking on command to enable a pair of leakage and welding checks, one by charger another by vehicle. You could state in message 108h that you don't support weld detection but the leakage is still required. The tests could probably be non-existent but the charger output must satisfy Chademo spec and will be verified by any Nissan Leaf. Without this pre-amble the car will never enable the fast charge (ie contactor will not close). Charger contactor precedes the car's and the car will check that voltage is within spec before closing its contactor and initiating charge. By matching voltages current surges are prevented. This all followed by quick current ramp as requested by Leaf.

Steve

Hi Steve - there was definitely no voltage spiking and leakage test done on the 'charger' side in my no-power test and yet the vehicle closed the main contactor and started requesting current ramp...

Of course, this is just one test on one vehicle. I would be interested in learning about others' experiences doing similar tests.

Valery

 

[valerun]

Spent the last couple of days doing a complete rewrite of the main control code for our chargers.

Hardware is still Arduino Pro Mini running ATMega328P at 16Mhz.

Main functional changes:
1. PWM control is now running ~100 times faster than before
2. PWM control is done through a proper PID loop now (as opposed to a pretty crude incremental up/down adjustment by +/-1 duty step per cycle)
3. all fast processing (PWM control and ADC measurements) are now triggered by timer interrupts

Basically, it works like this (assuming US line frequency of 60Hz):
* Timer1 throws an interrupt in the middle of the pulse of a 20kHz PWM frequency (this pulse is driving gate of the PFC boost IGBTs)
* 9 times out of 10, interrupt returns immediately, no action taken
* 1/10th of the time (at 2 kHz), interrupt code actually runs
* Within interrupt code, there are 8 code segments, each running at 1/8th of the 2kHz frequency (or ~250Hz per code segment).
* One of the code segments is running a PID loop that keeps the output current at a specified target level
* All others rotate through various ADC channels triggering conversions on one at a time. Triggering mid-PWM-pulse allows for much more stable readings that are less disturbed by the 20kHz switching noise. Also, the choice of 250Hz above is deliberate so that consecutive ADC readings are always shifted ~180 degrees on the haversine frequency for rectified AC input (120Hz). The two consecutive readings are then averaged to cancel out most of the 120Hz ripple in the readings.
* ADC interrupt is picking up when conversion is complete, storing the measured values in some global variables.

Then in the main loop() code, all the relatively slow stuff runs:
* Serial comms - checking for new commands and reporting of the status - currently at ~40Hz
* Slow voltage loop that adjusts output current target when in CV part of the cycle
* Slow temperature control that adjusts output current target when needed
* Various housekeeping tasks (AH metering, etc)

Some timing values:
* interrupt runs every 500 uS - this defines amount of time available for any calculations within both Timer and ADC interrupts
* ADC conversion takes 110-120uS (measured)
* PID loop calculations take 80-90 uS

Performance [no-power test for now]:
* initial conservative PID constants allow max duty slew rate of ~50 units per cycle (or ~5% per cycle). This means duty ratio can swing from 0% to 100% in ~10ms. This should be more than sufficient for QC application with its 20A/s slew rate. In fact we will probably slow this down considerably to have more stability margin
* program now uses ~23kB of flash (out of ~30K available on a Pro Mini) and ~1.1KB of RAM (out of 2KB available)

On to power-on tests now.

V

 

[valerun]

2 days and 3 blown IGBTs (and 2 driver circuits) later, the new charger control code works.

Never thought that 'unsigned int' would do me in Due to over-wrapping of the unsigned subtraction in PID loop code, the output stage would turn full on into fully discharged caps - from time to time. Resulting in blown-up IGBTs.

Next step is mating Due controller to the charger. Both have been synced on the command syntax / timing etc so it's a matter of actual power test now.

Curiously enough, I really had a perfect occasion to use a mobile QC today. For the first time in 10 months of driving a Leaf, we run out of juice - just 1 mile away from our house. The mile-o-meter suddenly went from 10 miles left to complete car shutdown in just 2 miles which was an unpleasant surprise. Ended up walking home, towing car, etc. If I had a QC device, could have just brought in one of our converted BMWs and boost the Leaf in 5 minutes. Soon...

PS. Serial control is turning out to be a little tricky to run at 115200 bps while charger is running above a few kW. The way layout currently works, the serial wires have to pass within ~0.5" from the high-frequency power planes on the main power PCB. Dropping down to 38400 seems to largely cure the issue. Will take that into account for the isolated version layout.

Cheers,

V

 

[Levi8than]

For the first time in 10 months of driving a Leaf, we run out of juice - just 1 mile away from our house. The mile-o-meter suddenly went from 10 miles left to complete car shutdown in just 2 miles which was an unpleasant surprise.

No turtle mode, just off? If it's still stock and under warranty, I think I'd raise this issue with Nissan.
I've only got 600 miles so far in my month of ownership, but I've been pushing my battery gauge pretty low. It changes to -- somewhere around 10 miles, but I've always trusted it would get me home. I'm guessing I should start being a little more conservative if this is a likely hood.

Send me a link if you want another pair of eyes on the code. And I can make myself free pretty much any day if you need another car to test. But you've already got a leaf, so it's more of the same.

 

[valerun]

For the first time in 10 months of driving a Leaf, we run out of juice - just 1 mile away from our house. The mile-o-meter suddenly went from 10 miles left to complete car shutdown in just 2 miles which was an unpleasant surprise.

No turtle mode, just off? If it's still stock and under warranty, I think I'd raise this issue with Nissan.
I've only got 600 miles so far in my month of ownership, but I've been pushing my battery gauge pretty low. It changes to -- somewhere around 10 miles, but I've always trusted it would get me home. I'm guessing I should start being a little more conservative if this is a likely hood.

Send me a link if you want another pair of eyes on the code. And I can make myself free pretty much any day if you need another car to test. But you've already got a leaf, so it's more of the same.

Joe - more of the same is good. I just posted the charger code in our usual place - http://emotorwerks.com/VMcharger_V12P/30%20-%20Firmware/" onclick="window.open(this.href);return false; - the latest is V14 experimental. This is just hot off the press. Hardware is SmartCharge-12000 (a non-isolated 12kW PFC charger). Will send you the Due code once I confirm full system operation.

V

 

[valerun]

quick update.

Spent a good part of last 2 days on tuning PID loop, optimizing serial control code, and actual full-power testing of rapid power level changes on our 350V BMW conversion. When controlled from the PC terminal, everything works great - current output slew rates of 150A/s, <10% momentary overshoots ramping from zero, etc.

Also, connected charger to a Due running a dummy command loop as if getting commands from the Leaf and re-streaming them to the charger via Serial1 port at ~10Hz. In return, the charger streams status to the Due at ~20Hz. Confirmed charger promptly responds to commands.

Now optimizing Serial comms timing & fidelity. Shielded cable is a must. Some form of error correction is a must. If anyone has links to Serial-based libraries implementing some error correction features, please PM or post links here.

Valery