Tronbike Meter (TBM) 4.0.0 Test Ride

Sunday, May 4, 2008

The Tronbike E-Meter


Travis came through with the serial analyzer and I felt compelled to tear off the fairings and tank to get access to the nasty little serial cable for what is to be the Tronbike E-Meter.

Leveraging my collection of ancient RS-232 adapters and cables, the laptop and the analyzer, I found my software was actually fine, my problems were:
  1. Laptop under Linux does not control the Keyspan USB adapter properly. It works fine under Win XP running on VMWARE on the same Linux laptop.
  2. I need a null modem on the IPAQ cable. This might be actually reversing the null function IN the cable in order to manage the Alltrax. Either case, it works.
The analyzer was a bit tricky to get right, but I found myself confirming the hex dump content and null modem/non-null-modem orientation. Plugging the wires between IPAQ and Alltrax and voila!, I was suddenly reading data bytes on the IPAQ console.

This was great news, but it led to a series of late night programming binges that continue to tonight. The UI has remained the same (see screenshot sample, ignore the numbers), but the architecture has changed now - twice. I went from separate executables for reading and display to a single forking python executable. This presented all sorts of exciting lessons in signal handling and interprocess communication in Python. The goal was to start and stop a single app to do reading and display of the data.

Attempt 2 occurred last night where all forking and multiple processes were removed, with the polling of the Alltrax now being driven by the GUI directly. No more forks, one executable, 1 process. Less IO to the disk, so it runs faster.

I also added a data logger function to record every actual use of the meter, and did so in an object-oriented fashion. During the refactoring I added more object-orientation and found it useful to manage scope and state of the system, the first O-O success story I can remember having (old Fortran hack here!).

All this fresh software was just plugged into Tronbike tonight, on its stand, and below is the first
data set from the logger:

Columns are:
  1. unix epoch time since 1970
  2. throttle position %
  3. controller temperature in C
  4. voltage (notice what happens when I flip the solenoid, goes to 63
  5. shutdown (not sure what this is)
  6. amps (bike is on stand, no load, might want this as floating point value)
  7. battery amps (calculated from amps as per Alltrax)
  8. watt-hrs in pack (calculated)
  9. projected time at current usage (calculated)
  10. percentage left in pack (calculated)
  11. time since start of run
  12. watt-hrs pack capacity (5 * 12volts * 55a-hr)
Log Snippit:

1209855312.417228 21 19 62 0 0 0 0 3299 9999 99 171.479993 3300
1209855312.917160 21 19 62 0 0 0 0 3299 9999 99 171.980005 3300
1209855313.417234 21 19 62 0 0 0 0 3299 9999 99 172.480015 3300
1209855313.937162 21 19 62 0 0 0 0 3299 9999 99 172.999987 3300
1209855314.427109 21 19 62 0 0 0 0 3299 9999 99 173.489878 3300
1209855314.927228 19 19 62 0 0 0 0 3299 9999 99 173.990005 3300
1209855315.437221 17 19 62 0 0 0 0 3299 9999 99 174.500002 3300
1209855315.977232 16 19 62 0 0 0 0 3299 9999 99 175.040012 3300
1209855316.457197 15 19 62 0 0 0 0 3299 9999 99 175.520065 3300
1209855316.977281 13 19 62 0 0 0 0 3299 9999 99 176.040042 3300
1209855317.487231 12 19 62 0 0 0 0 3299 9999 99 176.550008 3300
1209855317.987198 10 20 62 0 0 0 0 3299 9999 99 177.049960 3300
1209855318.487206 8 20 62 0 0 0 0 3299 9999 99 177.550002 3300
1209855318.987278 6 19 62 0 0 0 0 3299 9999 99 178.050053 3300
1209855319.487112 0 20 62 0 0 0 0 3299 9999 99 178.549970 3300

5 comments:

Ben_Nelson said...

Hey Todd,

Looking good on that programming.
My cycle uses a 48V Alltrax programmable. When I asked by IT friend about a "Palm-Pilot" type device that I could use for monitoring the controller, he suggested using an Ipaq. I have essencially NO guages on my cycle right now, I would love to do it up with your monitor.

I will keep up on your blog to see how this goes.

Thanks,

-Ben

http://www.evalbum.com/1133
http://web.mac.com/benhdvideoguy/iWeb/cycle/Welcome.html

santiagordgz@hotmail.com said...

Hi:

Great!...You've done it!

I have started a few days ago sniffin' serial comm to/from the controller.
Can you share the instructionset used to communicate with the controller and give us some advice on what you found, like for troubleshooting.

I'm programming a microcontroller dashboard with an LCD module to monitor/record everything you did + speed/RPM. I'm programming it for a PIC16f877 and maybe in the near future to a PIC18f4550 to allow USB data log transmision to a PC. You can get those micros and also an eeprom 1024kbit serial memory for free from microchip. this way the total cost for electronics (including hall sensor for RPM count) is about $25usd + what you spend in the mounting and enclosing itself or around $38usd if you pay for everything. When it's done I'm willing to share it (schematics, source code, documentation, etc)

It's cheaper than an iPaq as it's for a uni project and I don't have much money :p

The main idea is to build an approximated model of the whole system in order to optimize for distance, speed, or whatever the application needs.

I hope you can share that info.

Regards,
Santiago

Todd Stiers said...

Hi Santiago,

I'll get the latest version running and let you know whats up. My friend wants to do the exact same project - ie hardware. Adding the rpm/odometer would be a nice touch. I was/am looking to add BLUETOOTH and use a GPS :) Got the GPS, but have been loosing Ebay bidding wars on the iPAQs with Bluetooth.

WHAT is needed is an isolation circuit on the serial lines - apparently there is a danger of shorting out the computer/gauge during RECHARGE of the bike if its plugged in (according to Alltrax). I can say its definitely a pain to unplug the meter before recharging.

My code is in python and I basically perform a live "integration" of the "dt" over power consumed to estimate how much pack is left. I perform other range estimates expressed in "runtime", determined by overall average rate or immediate rate (have not decided which is most useful).
In adding this feature I messed up the finicky serial reading code, which was a bear to create.

I went as far as creating a CONTROLLER simulator that works over serial cables and/or via file on disk to simulate serial. Eventually I needed an ancient serial analyzer to figure out I needed a null modem (thank you Travis). I sent this back to Travis, you might ask him for it :)

Anyway, let me get this debugged before I sell it (bike is for sale). Get your class to buy it off me, its an awesome research platform and great deal.

ANOTHER cool set of hardware ideas are transforming the current RPM gauge into an Ammeter, and the fuel gauge to a voltmeter. I do python and above, so going deeper is tricky for me :)

Thanks for reading, go EV :)
-Todd

santiagordgz said...

A bike would be nice (I love Bikes) but my project is an improvement for two electric karts (it's for electrathon Mexico) and there are restrictions like having at least 3 wheels, powering from lead acid batteries...basically no Tronbikes allowed LOL. I know a kart is less fun than a bike but...what can I do?

I thought about getting a serial GPS module to record a map of the track (during the test lap), add this info to the mathematical model of the kart and use that info to give some aid to the pilot for optimizing RPM and batt during the race. I also had an ammeter I built with an ACS754 but I think it's safer to use the built in functionality of the controller. So my plan to model the kart and any subsecuent plan must wait until I can get those readings from the controller.

A way to connect and isolate the lines can be optocouplers so there´s no electric contact between the controller and the computer. If we could know if the short-circuit is to ground (demanding current to the computer port) or to V+ (injecting current to the computer port) we can wire LED's properly to avoid blowing Optocouplers (taking care of the logic level inversion).

I already have written code in C to meassure wheel RPM (a hall siwtch in the kart frame and a small magnet in the wheel), a realtime clock and a library to write to the LCD. A serial comm port is ready to download logs from the microcontroller to a PC. So far i'm downloading raw data with hyperterminal and processing it with an improvised app writen in delphi (I know having this app reading the serial port is easy but right now I lack the patience to redo this program).

santiagordgz said...

Sorry, I missed the point of my previous post.

Forgive me if I got it wrong but, have you successfully read the controller RAM via serial? I'm interested in knowing the packet structure of the protocol and the "words" used to "talk" to the controller.

I'll keep working on the Alltrax serial protocol and if I have it right, I might write a library in C for Hitech-PICC.