Android Tablet as Head Unit

For some time I have been hoping to have a unified dashboard display of all the data for the EV. The sources of this data are three Atmel ATmega based devices I built in the car: the battery charger and vehicle interface each use an ATmega168 and the battery monitor uses an ATmega644. Each of these has a serial port (the 644 has two ports, but one is tied to a GPS unit,) and each has a simple serial-Bluetooth adapter connected to that port.
Via Bluetooth, I can monitor the car from my office with a simple serial terminal app, though I wrote a custom MacOSX terminal program with a few extras: auto-reconnect the bluetooth links, display the battery voltages in a bar graph, and log all the data to weekly files. At a glance I can see the charger's progress, the voltage of each battery, and the distance of the last 15 trips. I can also control the charger and change its parameters.

There is a fourth device in the car which produces serial data - the UMOC motor controller. This communicates at 38400bps and sends around 410 bytes 3 times per second. Here is an example data block from the UMOC:

ad 342 1021 1022 1021 3 516 42 182
D 11 2 -24 I 24A -28A 28A

INFO: LIMITS TO TORQUE:
ped_T -334 Pwr Svr: 1.0 Relay: ON
Id 16.2 A Mtr Temp: 1.00 Power Stage: ENABLED
Iq 16.2 A Box Temp: 1.00 Regen: ENABLED
Temp 31.6 C Dev Temp: 0.98 Err PAL: LEDPwr
Bat. 247.6 V BatV: 1.00 Last err:
Rotor -1757 rpm Speed: 1.00 FORWARD Accel

To process this data I first used an arduino, but the volume of data was too much for a 16MHz processor to handle (parse and store on SD card) much less display on even a serial LCD. Something faster was needed.

My first thought was to use an iPad, as I have experience with MacOSX programming, but it turns out to be non-trivial to connect serial data to an iOS device. First, the SPP (Serial Port Profile) is not supported by the iOS Bluetooth APIs. Third party hardware solutions allowed only 1 serial stream connected. And to top it off, I would need to pay Apple $99/year to program my own device!

I resisted an obvious option, namely Android tablets, because I did not want to invest the time to learn a whole new OS that may not be around for long (remember Palm?) But the prices dropped to where it was worth a try, and I bought a WM8650 based 7" tablet for about $80 (now going for $60 in Jan 2012.) I planned to use a IOIO for Android to interface with the car's electronics.

For some time I struggled with connecting the tablet to my PC, because I was mistaken in thinking it had a device mode. Turns out the two USB ports on the adapter, which also has an RJ45 ethernet port, are for hosting devices. Just plug in a mouse or keyboard and they work, which is great because 7" screen-based keyboards suck!

Next I wondered if I can plug in a USB-to-serial adapter. Well, not exactly. CDC-ACM devices were supported out of the box (like the new Arduino Mega) but not chipsets with proprietary interfaces like FTDI, Prolific, or WinChipHead. That last one is used in some real low cost adapters, of which I happen to have four. I have seen them on eBay for less than $2.

I figured I needed to compile a kernel module (ch341.ko) for the adapter and modify the linux boot scripts to load it at start-up. To compile the module, I need the tablet's kernel configuration, which was not available under /proc/config.gz. I had to extract the kernel from flash memory and then find the config embedded within it. This took some time, but I learned some interesting things along the way.

Trying to compile the kernel was a real adventure. First I spent time finding the tools to cross-compile as I am using MacIntel. Neither the Android NDK nor the CodeSourcery (now Mentor Graphics) tools were able to get me all the way to a compiled kernel with modules. Then I thought I would try running linux on my Mac and compile under that, but I had no install CDs, and I could not install from a HD, though I tired many permutations. I eventually used parallels to install and run Ubuntu.

Even under linux I was having trouble getting the kernel to compile. I am not a linux expert and perhaps the config used by the manufacturer was too old or new or customized. And I had issues with header files, too. In any case, I finally found a link to a bundle of compiled modules in an android forum. Shazam! - they worked with a simple 'insmod' of the ones I wanted.

I put the modules in '/lib/modules/moremodules' and modified the script file '/etc/rc.d/rc0.d/S99modules' to load them. This was added to the end of the script:

#################### insmod USB-Serial-BT ############################## MOMODULE_PATH="/lib/modules/moremodules" echo "Install USB-Serial modules" insmod $MOMODULE_PATH/ch341.ko insmod $MOMODULE_PATH/ftdi_sio.ko
insmod $MOMODULE_PATH/cp210x.ko echo "Install Bluetooth Modes"
insmod $MOMODULE_PATH/bluetooth.ko insmod $MOMODULE_PATH/btusb.ko
insmod $MOMODULE_PATH/bcm203x.ko insmod $MOMODULE_PATH/btsdio.ko
insmod $MOMODULE_PATH/hci_uart.ko insmod $MOMODULE_PATH/hci_vhci.ko
insmod $MOMODULE_PATH/btmrvl.ko insmod $MOMODULE_PATH/btmrvl_sdio.ko
echo "FINISHED with Modules -- HOORAY"

Now, connecting the adapter produced the hoped-for entry /dev/ttyUSB0, but the default permission allowed only root access. So I wrote this shell script:

#!/bin/sh
changepermissions() {
for i in /dev/ttyUSB* do
chmod +rw $i
done
}
plk=1
while [ "$plk" -ne 0 ] do
changepermissions
sleep 10
done

which checks for any ttyUSB devices and changes the permissions on them. It is launched by including the following in '/init.rc'

service changedevperms /monitorDevs.sh
user root
oneshot

After all that, I can finally start on an Android app to read and display the UMOC data. Using the serial port access code written by Cedric Priscal and looking at the graphics calls implemented in this thermometer example by Ivan Memruk, I cobbled together the android part. I recycled the data-parsing code from the arduino experiments.

It works! the 800MHz tablet has no trouble reading, parsing, and displaying the UMOC data. And I can connect multiple usb-serial adapters to centralize all the data collection in the car, after I make some optically isolating connectors for the charger and UMOC.
The biggest remaining issue is how to mount the thing. The tablet's usb/ethernet adapter is about 60x30mm, has a tiny 24 pin connector, and extends the tablet's length. I have not found any right-angle adapters, or even a simple 24 pin extension cable for this thing. Even if I can, the power is on a separate connector, so I may have to open up the table and put something new on the back. Stay tuned....

Solid State Flasher for LEDs

The flasher unit (that thing for turn signals and hazard lights) stopped working today. The issue is that I switched to LEDs for the signal lights. These draw much less current than the original incandescent bulbs. When a regular bulb has failed, the flasher unit detects the lower current draw and speeds up the flasher. This is to indicate to the the driver that a bulb is not working. This was the situation ever since I switched to LED bulbs, and it may have contributed to the flasher's failure.



After opening it up, and pricing a replacement, I decided to make a new one. I chose to use the venerable 555 driving two small transistors in parallel to switch the lights.

I made the PCB to solder directly on the base of the failed flasher unit, which I de-soldered from the original PCB. Sometimes the first time is the charm - it worked when installed.








It makes no noise (the clicking was the relay in the original flasher) and it was a little strange at first. Of course, the really odd thing is that LR put the turn signal lever on the left of the steering column - on a right hand drive vehicle!

Current Monitor for 12V battery

A rather unpleasant discovery yesterday: the car refused to 'start.' Just like a typical ICE, the car uses the 12V battery to initiate the start up, closing the relays and main contactor, which connects the main pack to the motor controller and the DC-DC converter.

But if the 12V battery is dead, then the whole thing won't start.

Why did I do it this way? It seemed simpler at first. The original 12V was already in place, and there was even space for a second one on the other side of the car. (Not enough space for one of the pack batteries - physically too big!)

Plus, I am running the battery monitor and vehicle interface 24/7 off this battery. Which is the problem. The drain (I now know) is about 550mA. This adds up! if this was drawn from the battery in an ICE car, it would die too, as the charging from short trips is not enough to replace the energy used to start the engine and the 24/7 drain.

What to do? First get a handle on the currents into and out of the battery. I had seen this post a long time ago and thought it a pretty neat creation. So I designed one with two sensors, one for the current in from the DC-DC, the other for current out to the car.

The sensors are Allegro ACS756 which make use of the hall effect and have 3kV of isolation (nice but not necessary in this application.)

For electrical integrity, the terminals have some 14ga copper wire soldered around the pads.

For physical integrity, the whole board is through bolted to a alsab of 6mm teflon from a small kitchen cutting board.

The cpu used is an Atmel ATtiny45 in a DIP. I think these things are awesome: for about $1 there are 4 analog inputs and 2 GPIOs. It reads each current sensor, and sends the data out in a PWM code to the vehicle interface (an Atmel ATMega168)

Thus I learned that those 24/7 loads are between 0.5 and 0.6 amps.

Steering Wheel Repair

As long as I had the car, the turn signals would not turn off automatically when the wheel was rotated. At first, I thought this was a Land Rover 'feature,' but checking with a friend I determined that my vehicle was misbehaving.
I set out to understand how it should work. When a signal is activated, a small plastic rectangle is pushed toward the center of the steering column. This rectangle is in the same plane as a notched plastic disk which rides on the column. The steering wheel engages this disk with a slotted sleeve. On my car, this sleeve was plastic and it was broken.

Checking on ebay, I found other steering wheels with a cast aluminum sleeve, but these had airbags and/or radio controls on them as well. So I designed a replacement to be machined from steel or aluminum.



The lowest price I was quoted was $30, which is not unreasonable for the time involved, despite the simple design. But for that price I could buy a used steering wheel if I was willing to wait for shipping. Instead, I decided to make one myself from steel sheet.




Here it is mounted on the steering wheel. It is not pretty but it works.

New Rear Springs

The 'air spring' helpers were not getting it done; just too much weight back there.

Even inflated to 180% of the recommended limit, the rear sagged.

So I ordered some heavy duty springs with a 3 inch lift from Rovertym (now RTE Welding.)

Aren't they pretty?


Before the batteries are re-installed, it rides much higher in the rear, a little like a hot rod.

Charger - Mark I

The charger is at a point where I can put it in the car. I etched a circuit board to hold the smaller components.


The larger ones - inductors, capacitors, and rectifiers - are mounted wherever they could be fit.


A computer power supply is used to drive the control circuitry.

It has a wooden enclosure sized to fit on the left front fender.


I know it ain't pretty, but it's working.

More Assembly

On top of the motor mount bridge is space to mount the UMOC motor controller and the high voltage junction box. The 'anti-vibration' mounts are slices of silicone from a tube that cured before I could finish using it.



The batteries in the lower rear box are being connected. 14ga wire is run to each battery. Initially I thought of using twenty 12V chargers, but now the wires are used to sense and record each battery's voltage.

These East Penn batteries keep peeing all over everything. In a failed attempt to control the acid, I cut up kitchen sponge/towels, soaked them in a baking soda solution, and placed the around all the filler holes. Later they all disintegrated.



It looks better when covered up.




Then the upper rear rack was installed and populated.