Chipaggedon and Winter Storms!

​Hello Electrified Miata Fans!   While the historical winter weather has interrupted some of our plans, there is plenty to do in the never ending quest to go faster using the power of electricity.  Join us on the journey this week as we dive deeper into both the BMS and kart user interface.

Last weeks goals were:
1. Investigate why the BMS values seem noisier on the mini-pack vs the main pack.
2. Integrate 120GB SSD into the system so we can store the BMS data.
3. Write BMS logging software.
4. Cut some metal for the Formula Mazda project.

Last week, we enabled code to balance the batteries, specifically the kart mini-pack.  While observing the balancing code in action, I noticed that a few of the boards in the mini-pack were reporting cell voltages that fluctuated a lot more than reality according to my meter.  What was actually happening?   I took a series of readings and calculated the standard deviation of the voltage readings to quantify the noise.
Bms Board Id,    Standard Deviation,    Standard Deviation w/o external Temp
35                   6                               5       
36                   9                              11       
37                  28                               3       
38                  27                               7        
The larger standard deviation indicates a noisier signal.  The above data showed us boards #37 & #38 had the worst noise.   I then disconnected the external temperature sensors and the external noise was decreased. To investigate further and try some potential solutions, Joe came over with his tools.   Using his oscilloscope, he found a 167Khz signal present that is generated from the raspberry Pi box.

I'm guessing the switching buck/boost power supply is noisy. Installing a capacitor on board #37's voltage reference reduced the noise, making it the quietest board out of the group.   With his mask, can we call the Joe the BMS Doctor?

We'll also consult with John Guy to see if there is a better solution for the noise problem.  There will be more capacitors on our next BMS board revision.

We have been experiencing 'Chipaggedon', for our BMS boards.  JLPCB, who produces and assembles our BMS boards,  has not had our processor in stock for 6 months. Joe has been able to get some processor chips but then has to hand solder the processors onto the board.  When contemplating doing 100 boards, Joe decided to look at  processor alternatives.   Joe has found a new processor that is faster, costs
the same, has twice the storage, fits in the same form factor and most importantly using the same power.   Joe has ordered some sample boards using this processor and will evaluate how much effort to move our current code onto this new processor.  If Joe can make this work, production of new BMS boards will be faster, since Joe won't have to solder each processor to the new boards.

With the BMS problems understood, I started working on the software. Specifically, I wanted to change the user interface, so that the interface accurately reflected the state of the system. The user interface has two primary buttons, power and headlight.

​The headlight button, when pressed,  changes from red to green and also sends the request to a software process which alters the state of a relay, allowing power to flow to the headlight, turning it on.

​The problem with this is that the user see the changes from red to green before the system gets a chance to do anything.  A more accurate method would be to wait on changing the button color until the software process that changes the state of the headlight relay tells the user interface the relay has been switched on.

This more accurately reflects the actual state of the system and also provides the user with visual feedback.

The problem is slightly more complex with the power button.   This is because the power button changes a 'project parameter'.    Project parameters are used when many processes within the system need to know when a change happens.  In this case, the power button, nearly every process would need to know when the kart is turned on or off.  Rather than wait for every process to receive and reply to the messages, we send a message back to the display indicating that all the messages have been sent.

I made all software changes, and the kart didn't work anymore!  Hmmm, what could be the problem?    Finding the trouble becomes more challenging where there  is no screen to connect directly to the Pi's where the software runs. Luckily, the system has message logging.   This is the first multi Pi computer logging test.  I found a few bugs with the logging system along the way, but found out I forgot to take a debugging statement out of the code.  When these programs got a message, they stopped, waiting for me to type 'continue' on a non-existent keyboard.    

I removed that debugging statement and was testing  when the power in my house went out!  Little did I realized that my computer was on one of the few circuits not covered by the Tesla PowerWall. Work on the kart was brought to an abrupt halt!   I'll restart testing next week after I change which circuits my computer is connected too.

Goal number 4 was to cut some metal for the Formula Mazda project.  Dave Evans obtained all the needed metal and we were itching to  start shaping raw metal into motor mounts.  Unfortunately, the weather interfered with our plans, dropping below freezing and we decided to stay safe at home. We're hoping the weather will be more cooperative next week!

Goals for next week are:
1. Finish work on user interface accuracy.
2. Add functionality to new buttons for charging the mini and main battery packs.
3. Cut some metal for the Formula Mazda project.
4. If time allows, start on the storage of BMS data.

Hope y'all are staying warm, healthy and having some fun.  Thanks for reading.