Digital Dashboard Revisited

July 17, 2011 - As I've had some idle time waiting on my wrist to get better, I've revisited the Digital Dashboard I blogged about back in Oct 2009. This time around I've reduced the scope and hopefully the cost of such a system.

Designing a digital dashboard can be a rather daunting experience, from designing the display to designing the circuits to sample the analog inputs. All in all, a lot of work for one person.

The previous design incorporated a small automotive computer or carputer and a 7in touch display running RideRunner running within a Windows environment. The analog inputs were sampled using a FusionBrain microcontroller.

The new design takes advantage of technological advancements of Google's Android OS and the number of inexpensive Android tablets. The analog sampling still uses a microcontroller but the less expensive Arduino.

The end goal of the display system is two-pronged: 1) Display state of charge information (how much of traction has been used/is available) and 2) display traction pack state of health information. SOH is what I'm using as my BMS.

The SOC information is displayed as a battery showing the percentage discharged in both grpahical and numerical form. The primary SOH informnation is displayed underneath the SOC image as two batteries, one representing the front traction pack half and another representing the rear traction pack half.

A brief word about my traction pack setup. My traction pack is comprised of 40 Thundersky 200AH LiFePO4 battery cells. I am packaging 4 cells into a single battery pack of 13.2V (3.3V/cell nominal). The front and rear halves will contain 5 battery packs each for a total of 132V or 66V each half. It is much easier to monitor 10 of something than 40. The trick is to set the threshold values such that you can determine when a singe cell is going low and thus the battery pack will change color.

Here is a snapshot of the primary display screen:





By simply touching one of the SOH batteries on screen, the secondary SOH screen can be displayed. This screen shows an array of five batteries for the front traction pack half and an array of five batteries for the rear traction pack half. Each battery shows it's voltage and is colored according to its threshold. Green means OK, orange means warning threshold met, and red means low voltage threshold has been reached. Both warning and low voltage thresholds are soft and can be altered via menu selection.

Here is a snapshot of a good secondary display screen:





Here's a shot of SOC at 20% (warning level) and the rear traction pack indicating warning threshold has been reached:





Here's a shot of SOC at 10% (near empty):





And a shot of the secondary display showing which batteries in the rear traction pack that have reached warning threshold:





Let's talk about analog sampling using the Arduino. The Arduino is a rather very elegant low-cost sampling solution. An Arduino Uno costs about $25 and its ethernet shield about $35.

Here's a shot of an Arduino Uno:



The sampling of the shunt millivoltage presented the most difficult challenge. This differential voltage needed to be amplified from 50mV to about 5V for the Arduino analog PIN to pick it up and the op amp required a very stable source voltage.

The sampling of the battery pack voltage was pretty straight forward. A simple voltage divider would suffice but I wanted to isolate the traction pack voltage too, so I opted for FusionBrain's opto isolator board previously mentioned in Oct 2009 blog. This board has four channels so I can sample four battery pack voltages with a single board.



Without going into a lot of schematic details here, I'm posting a flow diagram instead. I'll post the detail schematics later when I have finalized the design details.



One area of potential complexity is how the Arduino will communicate with the Android tablet. My current table, a $200 Chinese SuperPad, has a 10baseT connection at it's base but also supports WiFi. Unfortunately, it freezes on a daily basis and as such probably won't make a viable auto display solution. However, it will be suitable enough to resolve a number of connectivity issues as most of the newer tablets won't have a 10baseT connection but will be WiFi ready. The Arduino will communicate to the Android via UDP not TCP/IP as UDP is connectionless and if packets are dropped it really won't matter. I think the refresh rate will be somewhere about 10X a second which makes it useless for realtime RPM displays but ideal for what my goals are.

Here's my Superpad:



The state of charge gauge while on the surface looks rather simple; however, the concept can be quite complex. Do you count the amp-hours while you charge or do you simply reset to 100% after charging is complete? I'm tending to the latter as it will just be easier to implement. But the state information must be saved off when the android is powered down and the app stopped. The state information must then be restored when the Android is powered up and the app started. Thank goodness for an SQL lite implementation availble on Android; this will make saving and updating the SOC state information much simpler.

Learning how to program the Android OS has been a very steep learning curve. I attempted to learn it about 6 months when I bought the Superpad, got very frustrated, and quit. But when I sprained my wrist, I decided to give it another try and this time came away much more successful.