Electric Vehicle Television - EVTV - a weekly video for custom electric car builders and conversions. Each week we review components and techniques you can use to convert any car to clean, quiet, powerful electric drive. EVTV has become THE weekly TV show for conversion shops, University build teams, design engineers, and custom electric car builders worldwide with viewers in 160 countries. Distributed on the global Amazon Cloudnet server system, each episode of EVTV brings you news, developments, the latest components, and techniques for building the future of electric vehicle transportation - in high definition video.
This week and last has been fun. We received Otmar Ehbenhoech’s 1990 Vanagon DoppelKabine and were pleasantly surprised at the straightness and condition of this very rare (in the U.S.) VW variant. We think it will make a great build and I kind of picture a yellow VW Thing and a yellow VW DOKA side by side here in the shop. We kind of plan to do an “off the shelf” build using the Siemens motor and DMOC645/GEVCU we have on hand, along with some very inexpensive Nissan Leaf cells we have coming. The “treasure chest” low amidships makes the perfect battery location and the rear engine compartment should be relatively spacious. A modern liquid heating system in the vehicle will make heat easy. Indeed the main investment and difficulty should center or rust control, paint and glass and that we will outsource.
We feature Matt Hauber/Michael Bream in this issue with a quasi serious note on fusing high voltages I thought was good and timely. That they did not make a watermelon explode no doubt puts Gallagher’s mind to rest that he’s still the king. But behind the scenes there’s more going on with the EV West team. Young Hauber is not a fan of C++ and heavy electronic theory, but he’s quite a hand with fabrication and transmissions. I can recommend his video on marrying two Netgain Warp 11′s together with a hydromatic transmission sans bell housing and torque converter. Quite good really.
But more of our interest, Hauber has a secret personal project involving a Camarro he’s been wanting to convert for himself for years that I know of. And most recently, he had a local machine shop help him put two Siemens 1PV5135 motors he got from the AZD auction together siamese fashion. What this will allow is basically a dual motor AC after the fashion of the Warp11 twins. As demonstrated by the Escalade and subsequently HPEVS, what this REALLY does is allow you to use two inverters/converters on what appears to be a single motor. And THAT allows you to double the power.
So instead of a single DMOC645 at 118kw and about 220ft lbs of torque, he’ll be able to have TWO of them going for 235kw and 440 ft-lbs of torque. Actually, the DMOC645′s are quite large for a Camarro, so he’s picked up a couple of Rinehart Motion Systems inverters for his project. So he wanted to trade them for two motors, which is asking a bit much. What we worked out was I would send him FOUR motors, for the two DMOC645′s, and he would send two of them BACK married together after the fashion of his. You see, unlike Missouri, same-motor marriages are LEGAL in Southern California.
So at some point, we should have a DUAL Siemens package to use in something or another.
We’re making some other progress (????) on the Siemens Motor front. Some are daunted by the splined shaft (which I kind of like actually) and unusual face. So after Sebastien Bourgois kind of threw us under the bus on this concept (I tried to get him to do it as he makes great adapters) we have designed basically a B face adapter for the Siemens motor. It has a little coupler that fits over the splined end and is held in place by a center bolt. But it changes it into a longer 1 1/8 inch keyed shaft just like a Netgain or HPEVS motor. And we are also making a bolt on plate that turns the motor into a B face.
Now I admit, this makes no sense at all. BUT. There are hundreds of different B face adapters out there. Randy at Canadian EV has the largest line of these but EV West does quite a few and Rebirth Auto and Brian Hall at Thunderstruck all have a line of adapters basically designed to interface the original ADC8 B face motor to various transmissions – Miatas and Toyotas and Chevy S10′s and so forth. It is kind of crazy to suggest that you buy a B face adapter for a Siemens, and then buy ANOTHER adapter for your transmission. But I thought I would have a few made up anyway.
Along the way, it has generated some CAD drawings that I know little about. But they do provide the data for the Siemens face and the coupler. And so if you knew what you were doing (I don’t) and took THOSE drawings and modified them for your flywheel and transmission, in theory it would make it easier to do adapters for the Siemens directly.
We also started shipping GEVCUs yesterday. I have 30 to start with. It will again take about a month to come up with another 30. I’ve actually had them about two weeks hardware wise, but I’ve been trying to do some last minute software changes to clean up the interface a bit, and most importantly some stuff for the VW Thing. The assclowns team had broken the serial terminal method of updating accelerator and brake stuff. They had also broken the pre-charge thing which cost me several contactors on the THING and a couple on the test bench. But we got it worked out and you can now simply enter a delay time in milliseconds and which output to use for your recharge relay, and which output to use for your contractor relay. You simply connect those outputs to the coil ground side of each relay and GEVCU will control them.
I also have a couple of howling-assed fans on the Derali heat exchangers on the THING. In town, and certainly in February, I really don’t need these fans on at all. But on the freeway, in summer, our little solar pump and AN-6 cooling system can’t keep the inverter out of current limit without the heat exchanger fans. So I wanted to be able to control those as well. So we now have a COOLFAN output you can designate and a COOLON and COOLOFF temperature that is easy to set. You would then have the fans come on when the inverter reached the COOLON temperature and stay on until it reached the COOLOFF temperature. You would set these to different temperatures to prevent cycling on and off so much. Like 120F for COOLON and 100F for COOLOFF for example. When it reaches 120F, the fans come on, and they stay on until it falls to 100F. We actually get motor stator temperature, motor rotor temperature, and inverter temperature from the DMOC645 by CAN. Inverter is the most sensitive of these and so that’s what I cool to.
So we have hardware, some basic working software, and GEVCU lives. I received an e-mail from one of the assclowns in rebellion, Michael Neumiller.. He’s actually been the most derisive and predicted of course that it could not be done, and most specifically could not be done without HIM. I guess that isn’t working out exactly as he thought so he sent an e-mail warning me of DIRE consequences to my fortune as I would be hung with hundreds of Siemens Motors. Apparently the vast body of EVTV viewers did not abandon us in favor of his GEVCU.ORG site and follow them into the void a glorious GEVCU future led by him. I tried to tell these guys this months ago. The software never was the problem.
This goes to the enormous gulf between ideas, and actual products. I’m perhaps too familiar with it. I like publishing. Not manufacturing or retail sales. At conception, I could see how GEVCU was precisely the right thing at precisely the right time. We needed a CAN opener (pun intended – I should probably change the name from GEVCU to CANopener) to access the future rain of spares from wrecked electric cars. All of them use CAN driven inverters, chargers, DC-DC converters, etc. With the GEVCU CANopener, reverse engineering these things becomes plausible, and control of them relatively easy. But you have to have a device to hook up to it in the first place and that can be coded. But I have been drowning not in software problems, but in the detritus of back and forth and BACK and forth over the wire harness order, and the size of the enclosure, and whether it was black anodized or powder coated, and the plate showing the AMPSEAL 35 pinout, and the RP-SMA pigtails connecting the wireless module to the antenna, and the antenna. And the cardboard BOX we pack all that in. And the documentation. See open source guys don’t believe in documentation. You should already know how it works if you had been contributing to the code and if you don’t like the documentation, you’re invited to write it. This has been the ongoing attitude in the open source community for decades. I have 72 e-mail messages with the Canadian assembly house that turns out to really be located in China.
In the end, you can’t hack together an afternoons code and tell them to build the hardware themselves and actually get anything done. A working prototype is one thing, and even a small run of finished boxes is another. I have to say, Paulo Almeida has been a stallion through it all. What he does easily, I do in great pain and frustration. But he’s been very patient in working through the issues with me and I think the end result is pretty good as a start.
The heart of GEVCU is all about CAN – ergo CAN opener. CAN was originally proposed by Bosche in 1987 specifically for automotive applications.
More specifically, GEVCU is designed to control three-phase AC inverters – power switching electronics designed to drive AC induction and brushless DC motors – essentially all modern motors used in OEM electric car design. These “inverters”, including those from Toyota, Nissan, General Motors, UQM, Rinehart Motion Systems, Tritium, Tesla, and many others all use sensor management devices to gather driver inputs, and communicate that information to the “inverters” via CAN bus in the form of torque or speed commands to drive the motor.
The Atmel SAM3X8E ARM Cortex-M3 CPU used in the GEVCU actually has TWO independent CAN bus controllers built IN to the chip itself. But these controllers represent HALF of the necessary hardware to perform CAN communications. They also need CAN TRANSCEIVERS – devices that actually create the transmitted pulses on the bus.
GEVCU uses two Texas Instruments ISO1050 galvanically isolated CAN transceivers that meet the specifications of the ISO11898-2 standard. The device has the logic input and output buffers separated by a silicon oxide (SiO2 ) insulation barrier that provides galvanic isolation of up to 5000 VRMS for ISO1050DW and 2500 VRMS for ISO1050DUB.
Used in conjunction with isolated power supplies, the device prevents noise currents on a data bus or other circuits from entering the local ground and interfering with or damaging sensitive circuitry.
As a CAN transceiver, the device provides differential transmit capability to the bus and differential receive capability to the Atmel CAN controller at signaling rates up to 1 megabit per second (Mbps). Designed for operation in especially harsh environments, the device features cross-wire, overvoltage and loss of ground protection from –27 V to 40 V and over-temperature shut-down, as well as –12 V to 12 V common-mode range.
We refer to the two CAN buses as CAN0 and CAN1. CAN0 has a differential transceiver output available on pins 9 (CAN 0 high) and 10 (CAN0 lo) of the AMPSEAL 35 connector. CAN1 similarly appears as CAN1 high on pin 11 and CAN1 lo on pin 12 of the AMPSEAL 35 connector.
For GEVCU end users, there is nothing you need to know about CAN. The wiring harness provided with the GEVCU already connects the GEVCU to the DMOC645 CAN bus, handles all terminating resistor issues, and has been tested repeatedly to drive the DMOC645 and Siemens motor combination. There is really nothing to configure here.
But a bit of detail is provided here to illustrate the future growth and possibilities inherent in the GEVCU device.
The details of the CAN transmission are basically handled first at the transceiver level, and then at the CAN controller. But to effectively use all the mask and filter capabilities provided by these chips, and make CAN communications easier to program, a special software library is required to do CAN. This is the DUE_CAN library available at https://github.com/collin80/due_can. This allows fairly simple C++ commands to manage CAN communications quite effectively.
The ability to manage two CAN channels separately provides enormous flexibility. Of course, it could conceivably operate two separate inverters this way, each driving a different motor for example.
More commonly, it would be used as a CAN bridge, porting data from one CANbus to another. It is not uncommon to have CAN buses operating in the same vehicle at different speeds, one at 250 kbps and one at 500 kbps for example. Using GEVCU, it is relatively trivial to port data from one to the other.
The basic and immediate design of GEVCU is to command the Azure Dynamics DMOC645 controller directly via CAN. This is a 250kbps CAN bus that is simply two wires between GEVCU and the DMOC645.
The second bus would more likely be connected to the vehicles’ Onboard Diagnostics Version II or OBDII bus. This has been required in virtually all vehicles worldwide since the late 1990s. Originally using a variety of manufacturer specific protocols, it has evolved in recent years ever more towards simply a J1939 standard CAN bus.
At the very basic level, the CAN protocol most often uses a 29 bit address and up to eight bytes of data. ANY device on the bus can transmit these packets and ALL devices on the bus can receive them. In broadest terms, the 29 bit address identifies WHICH device is sending the data, and often the specific nature or type of data it is sending. The eight data bytes then contain the data.
Using filters and masks, any specific device on the bus might set up to basically “look for” packets from another specific device, with specific data in it. It would ignore all other signals on the bus. And the software in the device would intelligently recognize not only the packet, and the eight databytes, but specifically the format and significance of every bit of the eight byte data payload.
Collision detection and priority are rather cunningly handled in the address itself.
And so we wind up with a bus, that might have two, but also might have two hundred devices, all more or less blindly sending packets and receiving packets. But by selectively filtering packets at the chip level, the receiving devices only get data they are interested in and know how to act on. The air conditioning controls on the dash have no use for inverter information generally speaking. The gear selector doesn’t need any information at all, it simply transmits lever position periodically. The variable steering device only looks for RPM from the inverter. And so it goes.
Sending devices are more less simply “announcing” data that might be of interest to others by forming the data in agreed format, and sending it with the right identifying address – more or less one assigned to that device. Note the address is NOT who it is sending it to. It’s just a message identifier showing the source device and nature of the message.
So GEVCU is completely capable of announcing drive commands from the address and in the format that is expected by the DMOC645. And it can also receive packets from the DMOC645 that contain data on inverter temperature, motor temperature, motor current, motor voltage, pack voltage, pack current, and much more.
Normally, GEVCU would get accelerator position from a hall effect pedal as an analog input. But it is not only completely possible, but has already been done, to connect the second bus to an OBDII bus and “capture” pedal position from the CAN bus signals transmitted by a CAN capable accelerator/throttle assembly. That data is then used to form drive commands going out the first CAN bus to the DMOC645.
It would be entirely feasible to program the GEVCU, using the PWM output of one of its digital outputs, to drive a vintage gas gage in a 1957 Porsche. But it is JUST as feasible with GEVCU, to put the proper address and data format together on the OBDII bus to drive the gas gage in the instrument cluster of a 2014 Porsche.
This opens up enormous flexibility. For example, there are a number of devices on the market for trivial amounts of money ($20-40) that plug into the OBDII connector under the steering wheel of a modern car that transmit data from the CAN bus over either 802.11b/g Wifi or Bluetooth wireless. And there are already multiple versions of programs for the Apple iPhone, iPad, and Android tablets as well to capture CAN data from the vehicle and display that data on attractive and highly customizable gage displays. In this way, an Apple iPad could rather easily serve as a graphic display for your electric car, displaying kWh, amperes, battery state of charge, motor rpm and current, inverter temperature, and much much more.
The implications for CAN are actually hard to get your head around. For example, conventional thinking would indicate that GEVCU is quite limited with only 4 analog inputs and 4 digital inputs, and 8 outputs. Those accustomed to Arduino having over 50 inputs and outputs would find this very limiting.
In automotive applications, an evolution has occurred that is quite fascinating and perfectly logical. Look at the wiring harness that comes with the GEVCU. It is already sufficiently complex and enormous that we have individually colored each wire AND inscribed the logical label of the wire along the wire length – encased it in nylon braid, and it is STILL quite a thing to deal with in a car. It causes a lot of wiring.
The CAN philosophy is to reduce all that to two wires. If you need more than 4 analog inputs an 4 digital inputs and 8 digital outputs, you basically need ANOTHER CAN device closer to its logical purpose.
And so you would not incorporate measurement of battery voltage and temperature and current and state of charge in GEVCU. You would more likely devote an ENTIRELY SEPARATE device, located right AT the battery, and connect it to GEVCU with precisely TWO wires, the CAN bus wires. And so basically you have two wires running through the car, connecting dozens of highly specialized devices whose only wiring is very very short and very very local to just what it is doing.
Actually you COULD use two GEVCUs. One with the GEVCU software in it, and the other with battery monitoring software in it. The CAN bus is how they would communicate.
How far can this be taken? To the extreme. On modern cars, if you look at the 4 window controls on the drivers door, you will find it is a CAN device all by itself, and it communicates with three others – the window controls in the other three doors. The Chevy Volt actually has a total of 104 microcontrollers in the vehicle, each with its own built in software and function. But they can all communicate with each other. The future of automotive technology looks like, sounds like you could check to see if any of your car windows were down, from your pocket phone, while in a building 112 miles away. Better yet, you could roll them up.
And so the real power of GEVCU, beyond giving us access to existing inverters and motors, is the two CAN bus channels. And added functionality is not so much a function of hanging more wires on GEVCU, but on intelligently designing and placing devices in the car to talk over the CAN bus. Fortunately, beyond perhaps a battery monitoring system, modern cars already have CAN for throttles, windows, door locks, radios, gas gauges, air conditioning, auxiliary fans, window washers, temperature sensors, and all of this is increasing at a logarithmic pace. If we can determine the address and commands, the open source nature of the GEVCU software will allow us to command it. Bosche actually invented CAN to REDUCE the weight and cost of copper in the wiring in an automobile. That was the original purpose of CAN. And it works.
Back to earth a bit, the GEVCU was born to drive the Azure Dynamics DMOC645 inverter and paired Siemens motor. But from the first instant of conception, we envisioned a very modular object oriented design leveraging the power of the C++ object-oriented language.
As such, a class motorController, is available. An object, inheriting from that class, is the dmocMotorController. It is actually a very small bit of program that intelligently takes concepts such as forward torque and regenerative torque, voltage, current, and temperature, and keys that to the SPECIFIC CAN messages and addresses EXPECTED by the DMOC645 already. And it intelligently knows how to recognize messages from the DMOC645, by address, and how to decode them to get actual torque, actual rpm, inverter temperature, battery pack voltage, etc.
To customize GEVCU to work with an inverter from UQM or Rinehart or Nissan Leaf, if you have the documentation defining the addresses and data formats used for those devices, it is a very doable if non-trivial programming task to add an object, much like dmocMotorController, to the motorController class. Ideally it’s a single file. Call it uqmMotorController. The SPECIFICS for any controller are confined to really a tiny part of the GEVCU software. You don’t need to know very much about how the rest of the program works, or why, to do this.
In the case of a UQM or Rinehart, these CAN data digests are actually published documents. In the case of the Nissan Leaf, it might be a little more difficult requiring some reverse engineering – basically driving a LEAF and sniffing out CAN codes on the CAN bus to the inverter. That’s how we did it for the Azure Dynamics DMOC645.
But in this way, we hope to open the door to cogently reusing the cornucopia of excellent components deriving from the salvage of many many cars developed by the OEM manufacturers. Electric motors and controllers can conceivably operate for DECADES of use. But one tree planted in just the right place 30 years ago can take out a Nissan Leaf in a split second. The Tesla Model S is such a delight to drive, and will indeed do 0-60 in a little over 4 seconds. In fact it will do 0-45 and 45 BACK to zero in less than 4 seconds if it hits the right tree. And the Model S owners are out there desperately trying to prove us right on this theory.
And so we see a future land strewn ocean to ocean with glittering motors and inverters and battery packs that are virtually brand new, lacking only a car – and a device to talk to them nicely in a language they understand – GEVCU CAN. So I’m pretty jazzed up.
I received another e-mail from viewer Jonathan Hanson pointing to an absolutely fascinating video presentation of Dr. Jeff Dahn, Dalhousie University, in Halifax Canada. Dr. Dahn is trying to work out how to make lithium batteries last longer. He’s traced almost all of the deterioration in battery capacity to parasitic reactions between the reactive elements of the cells, anode and cathode, and the electrolytes. These side reactions form the solids over the anode – the so called “passivation layer” or solid-electrolyte interphase (SEI) layer. He traces the decreased capacity to the thickening of the SEI caused by these parasitic reactions and very interestingly notes that these reactions are exacerbated by heat. The heat he refers to is 50C or even 60C but he also connects this to the TIME spent charging or discharging in the presence of such heat. He diagrams LiCoO2 cells, LiFePo4 cells, and LiMN04 cells, the latter used in the Leaf and the Volt. The Volt features temperature management and the Leaf does not.
The worst of the offenders was of course the LiMnO4 cells used in the Leaf. This sensitivity to heat did NOT show up in Nissan’s testing at 1.5C or 2.5C. They were concerned with heat during fast charging for example and it does not appear to be much of a factor. But at lower discharge levels, it rather markedly DOES. In other words, it is the TIME spent charging and discharging under heat that does the damage.
He and two graduate students came up with a novel way of measuring cycle life. They actually measure charge efficiency. If you discharge a battery, removing a certain amount of energy, how much energy do you have to put back to charge it? The ratio is the charge efficiency. For example, if you use precisely 1000 watts out of a cell, and it takes you 1020 watts to replace it, you have a charge efficiency of something less than 1.000. He found a VERY strong correlation between this charge efficiency and cycle life or loss of capacity over cycle life.
This is kind of a profound leap. Instead of hundreds or thousands of bulk cycles, you can accurately predict cycle life by measuring charge efficiency over a tiny fraction of the cycles – 10 or 20 perhaps. But to be useful, you have to measure this charge efficiency very very accurately.
A couple of graduate students, Aaron Smith and Chris Burns actually built a charger system capable of very accurately measuring the current and voltage and power into and out of the cell and so charge efficiency. Mr. Burns continues with the project while it is kind of interesting that Mr. Smith has left to work for Tesla motors. The other thing I found surprising, was that lithium cobalt chemistries, like that used in Tesla, and the newer NMC chemistries, appear to be the MOST resistant to heat as a factor of cycle life.
By being able to very accurately measure charge efficiency, and so by proxy cycle life, they can test their theory of this capacity loss being based on the parasitic reactions causing the SEI layer. Indeed, it would appear a given as they are now quite past that comparing charge efficiencies based on various electrolyte ADDITIVES that improve charge efficiency and by extension, prolong cycle life. And they have the hard data to prove it. So in effect, they have developed an advanced cycle life meter they can use to test improvements in battery chemistry on for cycle life. And the differences they are implying are immense. Like 20 fold increases in cycle life from simple electrolyte additive combinations.
The other thing that jumped out during this video I would like you to watch for. He is talking about Nissan cells which normally charge to 4.2 volts. But in the process, they graph cycle life charging to 4.1, 4.15, 4.2, 4.25 and I think 4.3v. As you get higher in voltage, cycle life decreases DRAMATICALLY. I mean turning a 2000 cycle cell into a 200 cycle cell. Recall our strategy for extending cycle life, BOTTOM BALANCE AND UNDERCHARGE. It appears the undercharge component cannot be stressed enough. I was stunned by the differences in cycle life among these really pretty close charge voltages on those particular cells.
I found it all sufficiently energizing, I can’t wait to get back to my Sendyne chip project. Recall this is a chip specifically designed to VERY VERY accurately measure currents using very small resistive value shunts. If I can get that module wired up to an Arduino Due and more accurately measure voltage and current, and drive a couple of contactors, I think we can duplicate hundreds of thousands of dollars in “accurate charge” equipment he’s amassed there for $1000 or thereabouts. Of course, he does 100 cells at a time. But we should be able to compare Nissan Leaf cells to the new NMC cells to CALB CA series to CALB SE series to the old Thundersky cells as a function of charge efficiency. And I’m sufficiently persuaded by this data that that IS a true proxy for cycle life. And so we could compare cycle life on different cells with just a few charge/discharge cycles establishing charge efficiency.
Don’t be confused by all the “new chemistry” and “glucose battery” BS literally spumming onto the network today in a huge gush. THIS guy is the real deal and this is a profound breakthrough in battery testing. It kind of only holds for current cell chemistries that exhibit this passivation layer. I don’t know that it translates to coming lithium sulphur and silicon anodes and solid polymer electrolytes. But for the current chemistries actually available, this is a huge step in battery testing and opens the door to some truly amazing advances in cycle life.
In the future, it might well be that we’ll move on in our cars to more advanced chemistries. But then that leaves the current LiFePo4 cells as the low cost “yesterday’s news”. If its cycle life were to improve 20x, it kind of automatically becomes the grid storage technology default And if we are to truly move toward renewables such as wind and solar, we will badly need such a low cost long life grid storage solution. Bravo Dr. Dahn.
The post CANopeners and Battery Life. Heat does appear to matter… appeared first on EVTV Motor Verks.