- 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 be used 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: 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. 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!
Link to BMS Reader Redesign 2.
Add a comment
- Details
BMS Readout Redesign 2
The Arduino Nano ESP32 that I reviewed in my previous blog below 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.
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 3.3V up to 5V and pulls the 5V down to 3.3V. 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.
Add a comment
- Details
Instrument Cluster Update
I recently removed the instrument cluster in the car because the digital display in the center of the tachometer was not working. Neither were the small instrument gauges, the SOC gauge and the Temperature gauge. Only the tachometer was working. I made a video over 9 years ago showing how I spoofed the instrument cluster to make all the gauges work. Video here. In addition to getting the gauges working again I also wanted to replace the speedometer. Last year I acquired several 120MPH speedometers on Ebay. The 80MPH speedometer that the car came with has always bothered me because the car is capable of moving much faster than 80MPH. The problem with the 120MPH speedometers were that they all had over 190k miles on the odometer. That could possibly be a problem when the car is inspected next time. The state records the odometer reading - mostly for insurance purposes. My 80MPH speedometer odometer only has 52K miles on it. I found a vendor that could do two operations on the speedometer. One was to reset the odometer to the value shown on the 80MPH speedometer odometer. The speedometer repair shop also calibrated the speedometer to work in my car. The 120MPH speedometers were used in European 320i BMWs that had a 4-speed manual transmission and a different rear-end gearing. Without modification the 120MH speedometer would ready about 15% faster. To use the120MPH speedometer with my rear-end gearing and have the correct speed shown on the speedometer a different gear was installed in the speedometer. The last step was to check the calibration.
When I took the instrument cluster out of the dashboard I found several loose wires. One was for the 7-segment digital display in the Tachometer. I have had problems with the 7-segment display getting easily damaged, but that was not the case with this display, I found another problem. I put the instrument cluster on the bench and replicated the wiring harness inside the car. I connected my LEVID (Legacy Electric Vehicle Instrument Driver) controller PCB and another GEVCU (Generalized Electric Vehicle Control Unit) PCB that I loaded with a test program. The test program replicated the CAN BUS messages in a continuous loop that come from the various components in the car like the Scott Drive controller and the current shunt. Below is an image of the testbench layout. The LEVID includes a Real Time Clock (RTC) and an isolation/driver circuit to output the serial data to the 7-segment display. I found that the isolation IC was damaged and that was what prevented the 7-segment display from working. I replace the IC and reset the RTC. The clock function now works on the 7-segment display as well as to display any of the instrument gauge data digitally.
The image below shows the cluster being tested with the CAN BUS data. All the instruments move and the 7-segment display shows the digital value of the tachometer. The tachometer is also new. The design with multiple colors came on later models of the 320i. That newer tachometer came with one of the instrument clusters I acquired that had a 120MPH speedometer. Shown is one of those 120MPH speedometers with the high mileage. When I sent the 120MPH speedometer to the shop for modifications I sent it in an instrument cluster that had a front plastic bezel that had no cracks or imperfections. As part of their service the speedometer shop polished the plastic bezel on that instrument cluster. The image below is my old instrument cluster that showed cracking on the bottom edge.
Shown
Shown below is the updated instrument cluster installed in the dashboard of the car. The SOC and Temperature gauges as well as the 7-segment display are all working and responding to inputs from the car. You can see how clear the view of the instruments is with the polished front bezel.
Add a comment
- Details
BMS Readout Deployment
I designed an updated version of the BMS PCB, one that has connections to handle all the modules that are part of this system. During the time I waiting for the PCB to be fabricated I realized that all the Adafruit modules could be connected with the Stemma QT/Qwiic connector system. These are a connector specifically for I2C communication. Just 4 wires, ground, +5v, SDA and SCL and they come preassembled in all kinds of configurations (link). Using this system, I reduced the number of wire connections to the PCA that were required. I connected the two rotary encoders and the LCD with the Stemma QT cables. On the new PCA by using the Stemma QT connector system I only need one 4-wire connection to the PCA. The enclosure for the BMS Reader is the same Jameco enclosure I am using for some of the BMS modules (see the blog below BMS Ready for Deployment). I machined the Jameco enclosure to fit the LCD, 7-segment display and the rotary switches. You can see the enclosure, PCA and all the connections inside the enclosure in the photos below. I now have two rotary encoders because I found that was easier in code to have one to select the cells in the battery and one to select the battery module to read. The enclosure has the same 12mm 4-pin connector that I have on all the BMS modules for power and CAN BUS. I also added a USB feedthrough because although, all the battery cell measurements will be saved on the MicroSD card, I will eventually want to get all the data into my computer. With the USB feedthrough I can do that without taking the enclosure apart, which is what I would have to do if I wanted to read the MicroSD card. It would have to be removed to be read by the computer.
Add a comment