GEVCU Control Unit
Fortunately the DMOC controller is based on the CAN communication standard used for all modern in-vehicle communication. Jack Rickard was also able to acquire a fully assembled Transit Connect from the auction and thereby was able to capture the CAN buss messages used by the DMOC for motor control. Taking that captured data, Collin Kidder was able to develop a specification for the CAN based messaging. Initially we started the development of the GEVCU on the Macchina platform offered by RechargeCar. The Macchina is based on the Arduino MEGA design. It's primary advantage is that it offered CAN bus communication in a electronically hardened design. Using the Macchina and code that Collin developed we were able to command the DMOC to spin the Siemens motor. However, It became clear early on that the processor on the Macchina was not going to be fast enough for the needs of the GEVCU. We migrated to the Arduino Due, which has a 84MHz ARM Cortex M3 processor. Although the Due has two channels of CAN, it is not designed to interface to the outside world. A CAN translation chip is required.
Working with Collin I designed a carrier card for the Due that incorporated the CAN translation chips. The carrier card also had optically isolated digital and analog inputs that where interfaced to the Due and contained a 256k EEPROM. The card was electrically hardened to help further protect the Due. The whole design including the code for the GEVCU was setup as an Open Source project. The files are maintained on Github under Collin's repository. Part of Jack's specification was that the GEVCU needed to be configured via a webpage that could be assessed with any device, i.e. laptop, tablet or phone. The first GEVCU design incorporated a wifi interface chip from a company called ConnectOne that has an embedded web server. The first design of the GEVCU was packaged in an aluminum enclosure that incorporated more electronic hardening and a unit was delivered to Jack Rickard.
Jack had a vehicle (1974 WV Thing) that he setup as a test bed for the GEVCU. This first version of the GEVCU had an Ampseal 23-pin connector that had wires hand soldered to the pcb.
During EVCCON 2013 with the help of Paulo Jorge Pires de Almeida and Celso Menaia from Portugal, the GEVCU was first able to get the WV Thing rolling on the road. At that conference the Thing and the Transit Connect were measured on a dynamometer and the Siemens motor in the Transit Connect produced 144 peak horsepower and the Thing peaked out at 90 hp
The hand soldered wires for the Ampseal 23-pin connector were considered a possible failure point so a new version of the GEVCU was designed and incorporated an Ampseal 35-pin connector directly soldered to the pcb. In this design the Arduino Due is mounted upside down and the bottom base board has the Ampseal connector, the power conditioning circuits and the digital I/O. A intermediate board has the optically isolated analog inputs.
The one issue with the GEVCU design that used the Arduion Due is that it had many pins that connected the interface board to the Arduino Due. With Paulo's input, it was decided to forgo the Arduino Due and mount the ARM chip on a board directly with all the CAN and interface circuitry. To that end we currently are on version 4.2 of the new GEVCU design from Paulo. Photos of the design are the the photogallery. The latest version has eight channels of digital output that is MOSFET driven and can accommodate up to 2A per channel and can be driven PWM. There are four channels of optically isolated analog input. The analog inputs are used to measure the throttle and brake transducer voltage levels. There also are 4 channels of optically isolated digital input. The ConnectOne Wifi chip is also used, but unfortunately we have found out recently that ConnectOne is phasing out that product. Others have joined in the code development for the GEVCU, Charles Gaplin and Michael Neuweiler and Mark Weisheimer has worked on the hardware. Michael developed the first website for the GEVCU interface and Charles further developed it. Michael has also been working to port the GEVCU code over to controlling his Brussa inverter and charger. Recently the group has split off from Jack Rickard and formed a parallel effort for the GEVCU development. See http://gevcu.org/. There also is a Google discussion group for the GEVCU development. https://groups.google.com/forum/#!forum/gevcu-development
Scott Drive SD100
Although I was one of the initial designers of the GEVCU, the combination of the GEVCU and the DMOC proved to be too unreliable. After I finished the conversion and started driving the car, several times the GEVCU will fail to operate. My experience was not unique - other GEVCU users had similar problems. Fortunately for me I was never stranded anywhere when the GEVCU failed, either in my garage or driveway. But I was concerned that I would be stranded somewhere as I was using the car for a semi daily driver. I wanted a more reliable, commercial system. Several years ago I reviewed a Scott Drive SD100 inverter at EVWest. I purchased that inverter and in 2019 I installed it in the car. It took about 4 months to install. I had to make a completely new wiring harness for the control signals, modify the plumbing for the water cooling and build a new mounting system. Initially it did not work correctly. It would turn the Siemens motor in reverse. Although with the the software GUI shown below you could change the motor direction, the software would crash every time that setup was saved. It turned out the Scott Drive needed a firmware update that I had to get from Scott Osborne in New Zealand, the maker of Scott Drive. Once that was taken care of the inverter worked as advertised. It is a 100KW inverter so it matches the Siemens motor well. It has a large number of inputs and control signals available. Just like the GEVCU it has the ability to put the motor in regeneration for braking. If you want to learn more about the SD100 and other Scott Drive inverters you can find that here.
Software GUI used to setup, calibrate and monitor the Scott Drive. If connected to a laptop during driving the performance data can be captured as shown below. Although the inverter is capable of 100KW continuously it is also capable of up to 150KW peak.
Bolt Battery Monitoring
With the use of the Bolt Battery there is no need to bottom balance the cells within the module. The batteries come from the factory perfectly balanced and the way the cells are wired, individual cells are not likely to change voltage relative to other cells in the module. Below is a screen shot of the Multicell Monitor demo software that comes with the demo BMS board. The software displays the voltage of every cell. You can see the cells are all within +/-1mV of each other. A survey of the 9 Bolt Battery modules found all 90 cells to be within +/-2mV. The software also can turn on the tuning function, which can discharge each cell individually, if needed. The board has 12 channels to measure a mulitcell battery like the Bolt Battery. But on the Bolt Battery there are only 10 cells. To use the BMS demo board the 6th and 12th connections are shorted to the adjacent inputs. This is just a consequence to the internal wiring of the ADC. All of the functions and measurements shown on this GUI are available with a Arduino sketch that Analog Devices also supplies with the BMS demo board. Analog makes a Arduino board equivalent to the Arduino Uno board called the Linduino and a shield, DC2792B that has Isolated SPI (isoSPI) communication. Up to 5 BMS demo boards can be connected via the isoSPI. The Analog Devices web page with these boards can be found here. A look at that the BMS demo board with the Linduino is shown below the screen shot. The BMS demo board can be connected via the 14 pin ribbon cable to the Linduino for demo purposes, but the way the BMS demo boards will be connected in the car is with the RJ45 connectors on the end of the board that are for the isoSPI connection. See the page on Battery Maintenance System for more details on the isoSPI connections.
Battery Maintenance System
Initially the Battery Maintenance System (BMS) will be provided by the Analog Devices DC2260A BMS Demo board which demonstrates the LTC6811-2 BMS integrated circuit. This circuit has the ability to measure 12 battery cells simultaneously and communicate via either isolated SPI or standard SPI. When using the demo board with the 14-pin ribbon cable standard SPI is used to communicate with the Linduino. If multiple BMS Demo boards are used then the isoSPI interface is used and the Linduino needs a DC2792B shield. A new circuit based on the DC2260A has been designed and the initial build started. The D2260A demo boards are somewhat expensive ($150 +S&H) plus the cost of the Linduino ($125) and DC2292B ($75) shields (9 demo boards plus 2 Linduino and 2 DC2292B). Plus an overall controlling circuit needs to be designed to take the data from the Linduinos. The new design circuit incorporates an Arduino Nano circuit and CAN BUS interface. The Nano communicates with the LTC6811-2 to read the cell voltages and then sends that data out on the CAN BUS. A much cheaper implementation and there already is a CAN BUS system in the car the controls the dashboard instruments. Probably the first 4 battery modules will be used with the DC2260A BMS demo boards and the other battery modules in the car will be monitored with my circuit design.
The screen picture below shows the Multicell Monitor GUI during the discharge process. In normal operation in the car, only cells that are at a higher voltage would be discharged. An algorithm will be written to control that process.
Top side of DC2259A BMS Demo board showing active discharge channels. When the MOSFETs are turned on to discharge a battery cell the LEDs light up. Again, 6 and 12 are not lit because they are not connected on the 10 cell battery module.
Bottom of DC2259A showing the discharge resistors. The resistors are 330 ohm so on a battery cell that varies from 3.5V to 4.1V there can only be a little more than 100mA discharge current. On a cell that is 180AH that would take a huge amount of time to fully discharge. This board is not designed for that. The design is to just trim the cell voltages so they are all the same value.
Image below shows the demonstration of the isolated SPI (isoSPI) that will be used to connect up to 5 BMS demo boards to one Linduino and a DC2792B isoSPI shield. In the car there will need to be two Linduino/DC2792B controllers for the 9 Bolt Battery modules. With the other BMS demo board shown above, the DC2259A, the board can only connect multiple boards by daisy chain SPI. Not as isolated as the isoSPI but more boards could be connected together. The iosSPI is limited to 5 boards and requires the addition DC2792B shield. The daisy chain SPI can connect more boards and does not require the shield.
A Brusa charger will be used to charge the batteries. This charger has a CAN buss control interface so it should be possible to setup the charger with the GEVCU. Usually the charger only has to be setup for a constant current setpoint voltage and a constant voltage setpoint. The charger is designed to handle the control of the current and automatically complete the charge. The charger will be connect to the charging station via a J1772 connector and plug. Below on the left is the charger and below that the J1772 connector and cable. The silver connector goes to the Brusa.
Page 2 of 2