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

[valerun]

loop response now. time units on the bottom are in ~50ms increments. So you see 0-35A target ramp in ~0.2-0.25s. The step change from 35A to 30A takes ~1 50ms cycle.

The LiFePo4 pack we are testing on is the most stiff battery type - even with a 350V battery, 0.1% in duty change results in 3A current jump (this corresponds to ~0.1 Ohm internal resistance for the entire 100-cell pack). This is the source for jitter you see in the chart. Leaf battery is much softer than this (different chemistry, smaller pack capacity = higher IR). So the jitter should be lower.

Will see in the next day or two how this works with the Leaf Pack. Perhaps we can also test with a standalone Leaf pack that we have in our shop...

 

[Levi8than]

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.

Is this communication happening over standard tx/rx rs-232 style serial, or another protocol? Because rs-232 style serial only has 7 bits of data and a parity per frame. Which means detecting a parity error is possible, but not auto-correcting it.

If I'm way off base and not understanding then please teach me.

 

[davewill]

Is this communication happening over standard tx/rx rs-232 style serial, or another protocol? Because rs-232 style serial only has 7 bits of data and a parity per frame. Which means detecting a parity error is possible, but not auto-correcting it.

If I'm way off base and not understanding then please teach me.

You can do error detection and correction in the data itself. It isn't necessary to do it in the line protocol. Also, you can run async serial frames that have 8 data bits. The protocol should certainly have error detection, but, it would be better to solve the noise problem rather than rely on slow bit rates and error correction. I'd guess that he is running his serial ports at +3.3v line levels. He may have to bite the bullet and use RS-232 line drivers (+-12v) or change to something more noise resistant like CAN. The rub with using CAN is that the CHAdeMO interface would need to talk CAN two directions, to the car and to the power supply, which would best be done by having two separate CAN busses.

 

[Levi8than]

Is this communication happening over standard tx/rx rs-232 style serial, or another protocol? Because rs-232 style serial only has 7 bits of data and a parity per frame. Which means detecting a parity error is possible, but not auto-correcting it.

If I'm way off base and not understanding then please teach me.

You can do error detection and correction in the data itself. It isn't necessary to do it in the line protocol. Also, you can run async serial frames that have 8 data bits. The protocol should certainly have error detection, but, it would be better to solve the noise problem rather than rely on slow bit rates and error correction. I'd guess that he is running his serial ports at +3.3v line levels. He may have to bite the bullet and use RS-232 line drivers (+-12v) or change to something more noise resistant like CAN. The rub with using CAN is that the CHAdeMO interface would need to talk CAN two directions, to the car and to the power supply, which would best be done by having two separate CAN busses.

Maybe I'm still off base. Communication here is between the device Valery has built/is building, and the car (is it not?). Yes, we can change Valery's device. But we cannot change what the car is doing, and I haven't seen any sort of a "garbled communication received, request resend" command.

 

[davewill]

Maybe I'm still off base. Communication here is between the device Valery has built/is building, and the car (is it not?). Yes, we can change Valery's device. But we cannot change what the car is doing, and I haven't seen any sort of a "garbled communication received, request resend" command.

My understanding is that he is talking about the control channel for his DC power supply. It would be talked to by a controller for some sort of battery charger interface, which in the case of the CHAdeMO effort (a separate project also in this thread) would talk CAN to the CHAdeMO port of the car, then control the power supply accordingly.

 

[Levi8than]

Maybe I'm still off base. Communication here is between the device Valery has built/is building, and the car (is it not?). Yes, we can change Valery's device. But we cannot change what the car is doing, and I haven't seen any sort of a "garbled communication received, request resend" command.

My understanding is that he is talking about the control channel for his DC power supply. It would be talked to by a controller for some sort of battery charger interface, which in the case of the CHAdeMO effort (a separate project also in this thread) would talk CAN to the CHAdeMO port of the car, then control the power supply accordingly.

Okay. In that case, if we own both ends of the communication, yes we can overload the serial functions with some sort of a SW serial implementation an insert error-correction + retries into the protocol. That's doable.

Also +12/-12 swings would be more resistant to noise than 3.3/0, but we'd need to add a max232.

 

[valerun]

thanks guys. Good point on +/-12V swing - or differential drivers - or CAN. Unfortunately we are trying to do this without hardware mods to the existing boards if at all possible at this point. Also, things like CAN require additional firmware support on the charger side and we just don't have RAM / Flash on the charger controller for anything heavy.

Just so we are on the same page re configuration of the system - there are 3 parts:
1. Car
2. QC Controller based on Arduino Due (3.3v Atmel SAM3X8E ARM chip) - connects to car via CANbus
3. Charger with control board based on Arduino Pro Mini (5V ATMega328P chip) - connects to QC controller via Serial (with level reduction to 3.3v)

So I think we will try (in order of escalating level of effort):
1. Parity bit on (data discard on error). Packages are sent asynchronously every 50-100ms so 1 package lost is not a big deal
2. Checksum byte with data discard on error
3. Add differential drivers (SN65ALS176 is our favorite) on each end of the line. This is completely transparent to the processors (unlike CAN, etc.)

Thoughts?

V

 

[GregH]

Another good reason to have an 8bit binary protocol in addition to your ASCII setup.. At least for the critical control loop commands. You could send the same info on half as many bytes leaving plenty of space for one or two bytes per packet for error detection. The simplest to code would be an 8bit checksum.. Add the bytes of the message (just a few bytes I would assume) and present that sum on the last byte.. Then check it on the receiving side. Better error detection could be done with CRC codes but that's a bit more software as it usually requires some look up tables.
Do you have a sense of what percentage of messages are making it through uncorrupted?

 

[valerun]

Another good reason to have an 8bit binary protocol in addition to your ASCII setup.. At least for the critical control loop commands. You could send the same info on half as many bytes leaving plenty of space for one or two bytes per packet for error detection. The simplest to code would be an 8bit checksum.. Add the bytes of the message (just a few bytes I would assume) and present that sum on the last byte.. Then check it on the receiving side. Better error detection could be done with CRC codes but that's a bit more software as it usually requires some look up tables.
Do you have a sense of what percentage of messages are making it through uncorrupted?

Thanks Greg! Error rate is ~0.1-0.2% right now. This is why I think simple parity bit could work. We would still need a digital filter throwing away strong outliers. That, or checksums.

 

[valerun]

ok another good day today.

http://youtu.be/o-Oosm3yjWM" onclick="window.open(this.href);return false;

 

[Levi8than]

Thanks Greg! Error rate is ~0.1-0.2% right now. This is why I think simple parity bit could work. We would still need a digital filter throwing away strong outliers. That, or checksums.

This sounds right. Throw away parity. But of course some things will slip through parity. So add some sort of hysteresis, erroring on the side of safety, I'd imagine. The code should be able to decide what makes sense as a reasonable ramp and drop the first request that seems out of range, but of course put itself into a state where it is more likely to accept the next request. Any robot localization filter should work well here. Maybe a kalman filter or even a particle filter if you want to get fancy.

 

[Levi8than]

ok another good day today.

http://youtu.be/o-Oosm3yjWM" onclick="window.open(this.href);return false;

How wide is your smile? Great work folks.

 

[valerun]

Thanks Greg! Error rate is ~0.1-0.2% right now. This is why I think simple parity bit could work. We would still need a digital filter throwing away strong outliers. That, or checksums.

This sounds right. Throw away parity. But of course some things will slip through parity. So add some sort of hysteresis, erroring on the side of safety, I'd imagine. The code should be able to decide what makes sense as a reasonable ramp and drop the first request that seems out of range, but of course put itself into a state where it is more likely to accept the next request. Any robot localization filter should work well here. Maybe a kalman filter or even a particle filter if you want to get fancy.

We ended up doing a 2-byte checksum. Couldn't figure out how to set parity on a Due in 20 minutes of searching around so said screw it ;-) Side benefit is that we now have a very reliable error rejection. In a 1-hour session, there was not a single *accepted* error. A few discards that happened did not matter to the process.

Next things to do (some in parallel):
1. [this week] Run multiple sessions on multiple cars.
2. [this week] Ramp to 25kW using our new Single-stage chargers
3. [next week] Move to isolated version of the charger (20kW for now)
4. [Feb] Package connections & add-on QC Controller
5. [Feb] Integrate Due-based controller into the chargers directly.

In addition to the control & power hardware, we need to figure out the scalable way to produce plugs. Joel and I have been discussing some approaches. I think 3D printing is still the way to go until we hit 100+ volume. We have access to some good Stratasys equipment that we could use. I don't think we have the scalable way to produce pins, though. Joel and I went through his recipes for making pins and, while it's an amazing example of engineering creativity, it is also quite labor-intensive. Any out-of-the-box ideas on those would be welcome. E.g., did you know that power pins could be 3D printed out of brass at ~$74 apiece in volume of one?

Finally, I am having our IP lawyer review all aspects of the legal situation around this project. Example of a question we'd like a reaction to: "can one distribute the source code implementing an official version of the protocol provided the recipient can be shown to have paid for the publicly available copy of the protocol documentation". Etc.

V.

 

[jclemens]

Any out-of-the-box ideas on those would be welcome. E.g., did you know that power pins could be 3D printed out of brass at ~$74 apiece in volume of one?

I am lazy, cheap and impatient, though these traits sometimes cancel each other out. I am not sure when I started this, but I found the trigger point that got me involved. Gary and Robert originally contacted me for help when they found my chademo inlet on the thingiverse. http://www.thingiverse.com/thing:80475 This was back in April of 2013. And even before that, I was interested in this.
Why am mentioning this? It is because for the better part of a year, I have been searching, scouring, pinning, wishing for something I could buy or an off-the-shelf solution for either the plug, parts to build a plug or anything that would help, and over the last year, I have not come up with anything other than what I did... which is like starting from dirt.

Gary had some pins machined from copper and electroplated in silver. This is the only other option. (machining copper is difficult and takes special skill) I really do not think 3d printing brass is viable for an electrical connector. (it is just brass powder glued together and polished to look nice). Shapeways does not have laser sintering.

 

[Levi8than]

Joel, do you have a cad drawing of the shapes of these pins and what you're looking for? There are lots of electonics manufacturers out there that make custom pins. I've never dealt with pins anywhere near the size of 9mm before so I don't know if any of these places will have the tooling for 9mm, but it may be worth looking into it and getting a quote from a few places. It definitely won't be cheap for just a few pins, but for a few thousand, it may be affordable per pin, if we're sure of what we want, or leave room for adjustment, like threading them in or something.

 

[valerun]

Joel - here is the description of the Brass 3D printing process from Shapeways site:

----------------
Brass models are fabricated using a complex five-step process. First, the model is printed in wax using a specialized high-resolution 3D Printer. It is then put in a container where liquid plaster is poured in around it. Once the plaster sets, the wax is melted out in a furnace, and the remaining plaster becomes the mold. Molten brass is poured into this mold and set to harden. The plaster is broken away, revealing your new product. Raw Brass is briefly tumbled. Polished and Gold Plated Brass are carefully cleaned and hand polished. Gold Plated Brass goes through a final electroplating process for an outside coat of 22k gold. Please be aware that polishing and plating can wear down or fill in very fine details and edges.
---------------

So it should be as good as it gets electrically for brass (~40% of copper's conductivity - similar to Alum).

V

 

[TonyWilliams]

Finally, I am having our IP lawyer review all aspects of the legal situation around this project. Example of a question we'd like a reaction to: "can one distribute the source code implementing an official version of the protocol provided the recipient can be shown to have paid for the publicly available copy of the protocol documentation". Etc.

V.

Valery,

You might have your legal folks look at your duplicating of CHAdeMO without proper licensing or royalties paid for all the work TEPCO and others did to design the standard from scratch.

I may be duplicating the inlet end of the CHAdeMO port, but if I do, it will be done as a CHAdeMO member. I will probably have a mold built for the housing, but not sure on the pins. I'm confident that once I'm a member, sources for hardware like those pins will magically appear!

Tony

 

[valerun]

Finally, I am having our IP lawyer review all aspects of the legal situation around this project. Example of a question we'd like a reaction to: "can one distribute the source code implementing an official version of the protocol provided the recipient can be shown to have paid for the publicly available copy of the protocol documentation". Etc.

V.

Valery,

You might have your legal folks look at your duplicating of CHAdeMO without proper licensing or royalties paid for all the work TEPCO and others did to design the standard from scratch.

I may be duplicating the inlet end of the CHAdeMO port, but if I do, it will be done as a CHAdeMO member. I will probably have a mold built for the housing, but not sure on the pins. I'm confident that once I'm a member, sources for hardware like those pins will magically appear!

Tony

Thanks Tony.

We have already determined that the implementation itself is not going to be a problem considering the protocol is now public and available to everyone for a fee. It's the distribution of such implementation that needs to be figured out. Hence my question on whether having every recipient of the implementation buy a copy of the spec would help.

Alternatively we can of course become a member but that does not solve the problem of source code distribution. Or maybe it does.

Btw Want to pool resources and apply for membership together?

Lastly, who said that we have implemented the official version of the protocol?

Valery

 

[TonyWilliams]

Btw Want to pool resources and apply for membership together?

Lastly, who said that we have implemented the official version of the protocol?

Valery

I'll have to investigate the membership first before I can consider your offer.

Nobody said you used an "official" anything, which is the root of the issues that I believe your legal counsel needs to look at.

There are laws and protections around the world for intellectual property, and in my mind, that includes CHAdeMO. I could be wrong, but then I don't practice law on the internet.

 

[jclemens]

Joel, do you have a cad drawing of the shapes of these pins and what you're looking for? There are lots of electonics manufacturers out there that make custom pins. I've never dealt with pins anywhere near the size of 9mm before so I don't know if any of these places will have the tooling for 9mm, but it may be worth looking into it and getting a quote from a few places. It definitely won't be cheap for just a few pins, but for a few thousand, it may be affordable per pin, if we're sure of what we want, or leave room for adjustment, like threading them in or something.

The final diameter of the pin is nominal 9.0mm (after electroplating) the tolerance is +0.0 -0.1mm
if you can get a quote for 100 pins (50 sets), go nuts, please post the results here.

http://www.thingiverse.com/thing:121581