- 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.
- Details
BMS Readout PCA Redesign 3
I received the new PCB and built up one assembly with the I2C driver ICs that were described in the Blog below, BMS Readout Redesign 3 (link). The PCA worked to read the RTC and SD card but failed to initialize the Rotary Encoders and the LCD did not show any text. After some checking I remembered that I had swapped the I2C lines in the PCB design to make the layout better with less crossing of data lines going to the screw terminals, but did not update the silkscreen text for each pin. Once I swapped the wires for the I2C data lines everything worked! The I2C line drivers did the job. The 7-segment display, that was being driven by the MOSFET logic level shifter also worked.
Below is an image of the New PCA, showing the I2C driver ICs (U2,U4,U8) and the MOSFET (Q1) logic level shifter circuit. I made the PCB a different color to tell the different versions apart.
I connected everything in the enclosure and ran the 9 BMS simulation test program. It worked perfectly. Now I can think about deploying the reader in the car.
Below is an image of the BMS simulation test bench setup. The BMS PCA on the right is connected to a barrier strip with a series of resisters. The circuit simulates ten battery cell voltages. It is connected to the reader via the CAN BUS wires (blue-white). I developed this test method over a year and a half ago to test the BMS PCA (link).
Add a comment
- Details
BMS Readout Redesign 3
I thought that the Texas Instruments logic-level shifter integrated circuit was going to solve the problem with the different voltage logic levels in the BMS Reader Redesign 2 (see blog below). Initially it did work, the RTC and SD card worked without any issue. Those two components are mounted on the PCA, so they are connected to the logic-level shifter via traces on the PCA. When I first did the bench test to test the Arduino Nano 33 IOT and the logic-level shifter on the new PCA, I used only one Rotary Encoder with the LCD and the PCA was on the bench. That all worked without issue and I able to run the loop test program, simulating nine BMS units, which it passed. Once I put everything in the enclosure that is when I started having problems with I2C communication. When I connected the LCD and the two Rotary Encoders, using the screw terminals I found the Encoders would not initialize. If I disconnected the LCD the Encoders would connect. The Encoders and LCD are on the I2C bus. After doing some more research on the Texas Instruments device I found that it is very sensitive to the capacitance loading of the data lines. The RTC is a I2C device, but as I said it is connected to the logic-level shifter via traces. PCA traces have much smaller capacitance compared to free hanging wires. The 7-Segment display data lines also go through the logic-level shifter and are connected to the screw terminal via wires, but Serial is a much slower communication standard and hence it is less sensitive to the connection capacitance. The problem is with I2C communication - it is high speed so it is sensitive to the capacitance of the connection. So the multiple wire connections (two Encoders and a LCD) caused the issue. The real problem stems from the logic-level shifter. It was not designed to connect to many I2C slave devices, unless they are all PCA mounted and are connected via traces that have low capacitance. The capacitance issue has long ago been identified as a problem with I2C communication. Because it was initially developed for communication between devices mounted on a PCA and connected via traces (i.e. low capacitance). But now it used to connect many external devices, via wires. Devices have been developed to solve this problem. They are called I2C line drivers and can be connected in a pattern like the schematic below, to connect many external I2C devices to one master source. This particular line driver, the PCA9617A is made by NPX Semiconductors. The data sheet can be found here, which is the source of the figure below. In the figure, all the lines on the Bus Master side would be PCA traces and on the Slave side will be the screw terminals with the wire connections. The output of the line driver can drive much higher capacitance. Each wired connection will have its own I2C line driver. These devices can also function as a logic-level shifter so it solves two problems. As shown in the figure, the driver IC also has an enable connection. This can be used to control communication by enabling only the driver for one component communication. But in my Reader design all the I2C components are queried sequentially in the code. So there is no issue with communication collisions, which can happen if multiple devices try to communicate at the same time. The issue now is that a new PCA has to be designed and built and tested.
Update: After some design considerations that I realized from working on the new schematic and PCA layout, I decided to eliminate the logic-level shifter IC. Both the RTC and the SD card will work at 3.3V so I am going to change the schematic to use those components at 3.3V and communicate with them directly from the Nano 33 IOT. The I2C line drivers will be used for the other components that are connected by wires through the screw terminals. For the Serial communication to the 7-segment display I will use the MOSFET method for logic-level shifting, like this product from Sparkfun. I can incorporate one of those MOSFET circuits in my design: a single N-MOSFET transistor with two resistors is all the is needed for one channel.
Update2: The I2C line drivers were tested on the bench and found to function perfectly. Even with connecting two rotary encoders and the LCD to one PCA9617A output!
A new PCB was designed and ordered, one that incorporates the I2C line drivers and N-MOSFET logic-level shifter circuit. The new PCB will take about a week to be fabricated and shipped.
To see the latest in the BMS Reader redesigns click here.
Add a comment
- Details
BMS Readout Redesign 2
The Arduino Nano ESP32 that I reviewed in my previous blog below (link) seemed on paper to be what I needed to solve the memory problem of my BMS Reader program. After I redesigned the BMS Reader PCA to use the ESP32 with a logic-level shifter, I found the ESP32 processor is just too different from Arduino products. Many of the libraries for the components in the BMS Reader were different and did not work the same. Although the SPI communication with the SD card reader worked, the SPI communication with the MCP2515 CANBUS integrated circuit did not and that is the primary function of the BMS Reader. After doing some more research I found Arduino makes several other Nano size processor boards.
The Nano 33 IOT with the Arm® Cortex®-M0 32-bit SAMD21 CPU, operating at 48MHz. 32KB SRAM and 256KB flash memory. The WiFi and Bluetooth® connectivity is performed with a module from u-blox, the NINA-W102, which is the same chip used on the ESP32.
The Nano 33 BLE with the 32-bit Arm® Cortex®-M4 nRF52840 CPU, operating at 64 MHz, 256KB SRAM, 1 MB flash. The Bluetooth® connectivity are performed with u-blox® NINA-B306. The module does not have WiFi capability.
The Nano RP2040. This board has a dual-core ARM® Cortex® M0 Raspberry Pi® RP2040 CPU, operating at 133MHz. It has 264KB of SRAM and the 16MB of flash memory is off-chip to give extra storage. Also uses the u-blox NINA-W102 for WiFi connectivity.
You can see the processor speed and memory increases with each of these versions. So does the cost of the module. The Nano 33 IOT is the the lowest cost and the and flash memory is 5 times more and the SRAM is also more than 5 times that of the Nano Every so it should work for replacing the Nano Every. The Nano ESP32 was even lower cost than the Nano 33 IOT. That is because the ESP32 chip is used in many WiFi applications so the price is leveraged against that large volume. Not surprising all these modules come with the ability to connect to the internet since that is where everything is going now.
All of these board processors run at 3.3V so same problem as the ESP32 communicating with the BMS Reader components. However, the new BMS Reader PCA board that I designed with the an 8-channel logic-level shifter surface-mount integrated circuit (link) works with any of these boards. Since all these Nano boards have exactly the same pinouts they are interchangeable. The code might be different for some libraries. The libraries for the Serial, I2C, SPI and CANBUS that used on the Nano Every don't necessarily work for all these boards, since they all have different microprocessors. I found with the ESP32 the compile time was significantly longer than for the Nano Every. That is because the original code for the Atmel processor has to be converted to code for the Xtensa processor and that will also be the case for the Nano 33 BLE and the Nano RP2040.
The Nano 33 IOT is nearly identical pinout and connection as the Nano Every. But there is no 5V source pin just like the ESP32. The Nano 33 IOT and ESP32 look similar because they really only differ in the main microprocessor. However, for my application that is really key. The Atmel microprocessor is the same family as all original Arduino modules so all the the libraries created for interfacing the modules to other components will work.
Update: I recently purchased a Nano 33 IOT and after some slight modification of the BMS Reader code I was able to compile and run the test program on the Nano 33 IOT. The complied code only uses 19% of the processor memory so the loop test program that I created to simulate nine BMS modules runs without any issue! The name of this board IOT is the acronym for Internet Of Things, which just means the board has the ability to connect to the internet. Because it has the same u-blox WiFi chip as the ESP32 it has both Bluetooth and WiFi connectivity. I might learn how to program the WiFi so it could be possible to view the battery voltages remotely.
Below is the new BMS Reader PCA, showing the 8-channel logic-level shifter IC from Texas Instruments (link). The resistor pads not populated are there because I did not know if pull-up resistors were needed when I designed the PCA. But I found that the Adafruit components, the Rotary Encoder and SD card reader do not have open-collector logic gates, so no pull-ups needed. The resistors that are populated are for the SPI port of the Nano 33 IOT, which do require pull-ups. The I2C pins have internal pull-ups on the Nano 33 IOT, so no external pull-ups needed. The fantastic feature of the 8-channel logic-level IC is that it works with either open-collector logic gates or push-pull logic gates. Although, according to the data sheet on the logic-level shifter, the push-pull logic gate connections are much faster, like 100X. That is not an issue for this design.
To see the latest in the BMS Reader redesigns click here
Add a comment
- Details
BMS Readout Redesign
As I was testing the BMS Reader by simulating nine BMS units I discovered a problem. At the 8th BMS reading, the last few cells would read wrong and then after two of the 9th BMS readings the program would crash. The BMS Reader requires a large program because of all the external components (Rotary encoders, SD card, LCD and 7-segment) and it exceeds a limit. For a reason too extensive to explain here, if the compiled program size exceeds 70% of the processor memory then program execution can fail. This is a problem with all Arduino processors. There is no way to add memory to the processor. The only solution is to get another processor. Arduino does make other processors with much more memory and much faster, such as the Arduino Nano ESP32 pictured below. The ESP32 has the u-blox® NORA-W106, a dual-core Xtensa® 32-bit LX7 microprocessor running up to 240MHz and 384KB of processor RAM, almost 10 times more memory than the Nano Every. The problem with all the fast processors like the Xtensa is that they are not compatible with 5V, usually they run at 3.3V or 1.8V. The ESP32 runs at 3.3V. That is an issue with components that are designed for 5V, which all the components in the reader are. Most 5V components will work with 3.3v data communication input but to communicate back to the Nano ESP32 a logic-level shifter circuit is required. That circuit does just as it sounds, it pulls the 5V down to 3.3V and it pulls the 3.3V up to 5V. The circuit can be very simple, a single N-MOSFET transistor with two resistors is all the is needed for one channel. But my reader design uses all 8 channels of data communication shown in the lower images. I found an 8-channel logic-level shifter surface-mount integrated circuit (link) that would occupy less space than the 8 transistors. But either option requires a new PCB design and fabrication. A new PCB will take about a week to be fabricated.
One other feature of the Nano ESP32 is that it has support for the 2.4 GHz Wi-Fi® band as well as Bluetooth® 5 which means there can be other ways to get the BMS data out of the reader. Another great feature of this processor is that it also has a CAN-BUS controller. That means I could eliminate the MPC2515 CAN-BUS controller from my design. It would simplify the PCB design, but that would also mean a new PCB design and a significant code change would be required. I only made a new PCB design with the logic-level shifter IC. Once I have that PCB and verify its functionality I will explore that option of creating a new PCB using the CAN-BUS on the ESP32.
The Nano ESP32 is nearly identical pinout and connection as the Nano Every. There just is no 5V pin. The VBUS pin can output 5V but only when the USB is plugged in.
To see the latest in the BMS Reader redesigns click here
Add a comment