- Details
BMS Car Deployment 2
I built up and mounted four more BMS units in CINCH and Jameco enclosures. See the blog (BMS Ready for Deployment) to review the reason for the Jameco enclosures. These are to be installed in the rear seat with the batteries there. The CAN BUS data and power cables have been made. Still working on the temperature measurement cables. All of the enclosures will be attached to a 2"x1/2" plate of plexiglass that is bent to the curve of the rear seat. Unfortunately because of where the BMS units will be mounted in the rear seat all four of the DB25 cables on the batteries will need an extension cable.
Before deploying the BMS units I tested each of them with a program that tests the functionality of the BMS. It logs the voltages measured from the BMS every 5 seconds and runs for 12 hours or more. For this test, code was created to read the CAN BUS data from the BMS unit and send that out on the USB as serial data. That is what is displayed in the screen shot of the LabView test code below.
The voltages are created by a benchtop power supply and a resistor ladder. See image below. Each resistor is a precision 1K ohm resistor and 10 are are wired in series on the barrier strip to simulate the ten cells in the battery. Nearly the exact same voltage is dropped across each resister. The difference in the cell readings shown in the screen shot above is do to the resistor precision. You can see from the screen shot that the Std Dev is less that 1mV and that is the variation of all 10 cells combined. This is the same method I used to test my BMS boards against the DC6620A BMS demo board (see BMS Bench Testing blog). For this testing, the CINCH enclosure labeled CAN BUS Reader is just a BMS PCA that has the Arduino Nano Every USB connected to the USB feedthrough so that the serial data could be read by the computer, running the LabView test program. I found looking at the BMS measurement variance in the 12 hour data that the benchtop power supply had more variation than any one BMS cell on any BMS unit. The tests showed all BMS units working very well and the measurements for any channel were very consistent.
Next steps are to finish all the cabling and mount the BMS units on the rear seat batteries. I will have to use a right-angle DB25 connector like the one shown below to connect to the batteries to give the battery cables a low profile to fit under the rear seat cushion. Link to this part.
I will also use these 12mm tee connectors with the BMS units for the rear seat batteries. Here is the link to the data sheet.
- Details
BMS Readout PCA Redesign
Update 11/20/2025
Arduino just released a new version of the Nano, the Nano-R4 based on the Renesas RA4M1 32-bit Arm® Cortex-M4 processor. The Nano-R4 is pictured below:
It has the same 256kB Flash and 32kB RAM of the Nano 33 IOT. What is unique about this board is that it has a +5V operating voltage. The I/O, including I2C is at +5V so it removes the need for logic-level shifters and I2C line drivers. It even includes a QWIIC connector, which per the specification of QWIIC, the I2C is at +3.3V, so it would also work with the 3.3V RTC and SD Card. The board has built-in logic level translators to convert the +3.3V I2C to +5V for the microprocessor. The only issue there might be: will all the code for the BMS reader compile to run on the Renesas microprocessor. Probably what I will find is that the reader program will compile for that processor, but take considerably more time to compile, just like the other non-SAMD21 Nano processors I tested.
Learn more about the Nano-R4 here.
Update: 11/26/2025
I received a sample of the Arduino Nano-R4. I found that it compiles in about the same time as the Nano-33 IOT that I am using on the BMS Reader but it takes 10% more of the amount memory in use, both program size and dynamic memory. Probably because of the additional code required to run the Renesas processor with ATMIL (SAM) code. The Nano-R4 is more of a curiosity than something I would implement. Like the ESP32 that I reviewed in a previous blog (here) it has a CAN BUS serial interface so I could eliminate the MCP2515 CAN BUS controller. But to use this feature along with the other unique features of this board I would have to design and fabricate a new PCB. Probably something I will not do, for now.
- Details
Instrument Cluster Update 3
After the crazy hot days we had at the end of June 2025, I was driving my car and wondered what the outside temperature was. Of course I could just look on my phone, but I thought it would be a great update to have the outside and or inside temperature displayed on the 7-segment display in the bottom center of the tachometer. The temperature of the inverter can already be displayed on the 7-segment, based on the CAN BUS messages from the inverter. To measure the inside or outside temperature I found another great little PCA made by Adafruit, the MCP9808, pictured below. The details can be found here. It is a precision temperature sensor and it communicates the temperature with I2C. It is more precise temperature measurement than I need (0.0625°C resolution), but it is very inexpensive and easy to use with my designs. Instead of designing a new PCB for the temperature sensor, I used the Version 2 of the BMS Reader PCA, (blog post) for a temperature reading system to use with the MCP9808. The PCA was already built up with the 12V power isolation, 5V regulated supply, CAN BUS, Arduino Nano Every and screw terminals. Because the Nano Every runs at 5V the I2C communication can be transmitted on wires to several feet without any issue or need for I2C line drivers. Also, the MCP9808 has the same pinout as the Adafruit RTC so the temperature sensor can be plugged into the Reader PCA in the same place as the RTC (shown in the photo below). The lower image below is of a Reader PCA that is wired for the CINCH enclosure, the same system I am using with the BMS systems. I also used the 12mm connectors to connect +12V, CAN BUS and the I2C connection to a sensor mounted in the engine compartment. A second sensor is mounted on the PCA like shown below and housed inside the CINCH enclosure. The PCA with the sensor is mounting inside the car next to the glovebox.
The I2C address on the MCP9808 can be set to any of the bottom three bits of the I2C address, so up to eight different addresses are available. More than one MCP9808 can be used or other I2C components on the same I2C connection can be used. The temperature of both sensors is read by the Reader PCA and then it is formatted and sent on the CAN BUS so the LEVID can read it and display either temperature on the 7-segment, shown in the bottom image.
Post Build Note: I noticed with the car just sitting in the garage with the power on, the temp sensor on the PCA inside the CINCH enclosure would show 8F - 9F higher temperature than the sensor in the engine compartment after 30 minutes. That has to be due to heating caused by the Arduino Nano Every. I installed a Breather Screw Air Vent (link) in the CINCH enclosure to help reduce that temperature increase, but that did not work. I decided to mount another MCP9808 in a small enclosure, similar to the one mounted in the engine compartment. This one would be mounted under the glove box. I also mounted a Breather Screw Air Vent on the small enclosure. The enclosure with the Breather is shown in the image below the dashboard image. After 30 min there was only a 1F difference in temperature reading.
- Details
Instrument Cluster Update 2
Since the update to the Instrument cluster I made last year (link), it has been working really well except for the Real Time Clock (RTC). The clock is part of the circuit for the 7-Segment LED display that is in the center of the Tachometer, as shown in the image below. The 7-Segment display is used to display all the electric vehicle data, like temperature, voltage, current, and RPM digitally, to complement the analog instruments. It is also used for displaying the time. The RTC is mounted on a daughter board, that is part of the Legacy Electric Vehicle Instrument Driver (LEVID). That PCA controls the startup of the car and controls all the instruments in the instrument cluster. The PCA and the daughter board with the RTC can be seen in the blog post on the instrument cluster update (link). I found that the circuit on the daughter board that was buffering the clock data has failed now for the third time, since the update. The RTC still works, but there is no communication to the processor because of the failed component. The 7-segment display can still show all the electric vehicle data, but the clock reading is wrong. The RTC communicates with I2C to the main processor on the LEVID. The processor is an ARM® Cortex®-A3 Microprocessor IC ATSAM3X8E, 32-Bit 84MHz, a 3.3V device (link). The RTC that was previously installed was a 5V device, so just like on the BMS Reader board design, the RTC required a logic-level translator (link). The particular integrated circuit that was used for the logic-level translation is what has been failing. I realized, just like on the BMS Reader that if I had a 3.3V RTC I could communicate directly to the Cortex processor. I modified the daughter board to use the same Adafruit RTC that I am using on the BMS Reader, the DS3231 (link). The modification was to jumper around where the logic level IC was mounted, so the the RTC could be directly connected to the I2C lines on the Cortex processor. An image of the RTC module can be seen below the tachometer image below.
The link to the latest update to the instrument cluster can be found (here)
- Details
BMS Car Deployment
(See latest update 5/3/2025 below)
The four BMS units mounted in the CINCH enclosure are ready to go in the car. The CANBUS data and power cables have been made. Still working on the temperature measurement cables. The CINCH units are screwed to an aluminum 1"x1" rectangular tube that was drilled and cut to fit in the trunk battery box. The tube provides clearance for the bolts used to attach it to the battery box as well as the screws used to attach the enclosures. This mounting system is a test to see how everything is going to fit together and how all the wires are going to be managed.
By mounting the BMS units inside the battery box negates the need to make the DB25 connectors any longer. The ones that are already connected to the batteries are used with a gender changer DB25 connector. Only the middle battery has to have a DB25 extension cable because that battery is wired in reverse order. I first tried to use the four 12mm wires shown above connected to each BMS in the battery box, but there is not enough room and it looked very cluttered. Plus I could not get all four wires though the hole in the side of the battery box. Using the 12mm tee connectors shown below have made the 12mm wiring more compact and only one wire has to come out to connect to all four BMS units. I need to add some cable management and strain relief to the one cable going though the side of the battery box.
This initial setup is okay for testing. The battery sense wires (orange) will have to have some kind of wire management now that they are going to be connected all the time. I might also install the screws in the DB25 connectors once everything is tested and working correctly. The 12mm cables for the temperature measurement still have to be installed.
These are the12mm tee connectors that made a cleaner installation. Here is the link to the data sheet.
Update 5/3/2025:
Installed wire management and all the temperature measurement cables. I used different 4-conductor cables for the temperature measurement. They were easier to connectorize with the 12mm connectors. I found I had to add a couple of threaded rods to hold the batteries tightly in the battery box. A while ago I had to cut the end of the box off when I added the fourth battery to the trunk box. I had a metal square tube as a strength member to hold the battery box together. I had to remove that tube where it was originally mounted. It was connected to the angle aluminum that the BMS units are attached to now. The threaded rod also makes it easy to adjust the compression on the box to hold the batteries so they don't move while driving.
