The 24 Hours of Lemons Forums → Lemons Tech → open source data aquisition/display/logging project ideas
Has anyone here ever used an aftermarket TPMS tire pressure monitor?
Just daydreaming about data aquisition again...
I believe Biohazard2 does but they run the other series now.
A guy emailed me the other day after finding the Wifilapper site (or possibly finding this thread, he didn't mention how he found me), and suggested rigging this up:
Sparkfun IOIO (connects to PWM, analog, and digital inputs) connected by bluetooth to an android phone. Sparkfun sells a pile of neat analog sensors like IR sensors you could use for brake and tire temperature, or pressure sensors you could use for corner loads (maybe?), or you could just read your fuel sender wire and get fuel levels.
That'd be
-IOIO - $50
-IR Temperature sensors - 4 x $20
-Misc power stuff + soldering + wiring - $20-$40
-Android phone - get a cheap one for $100
I've ordered an IOIO, and I'm going to build in support for it in WifiLapper so that people with old cars can hopefully get fuel levels at least, and some of that other neat stuff if they want to wire it up. Hopefully it'll be another set of channels you can have WifiLapper transmit from the car to the pits.
For the guys using the IOIO to do data display - how are you hooking the IOIO to the car without losing your gauges? I got mine mostly working last night, but we want our normal dash gauges to work and also the IOIO to send data to the phone. It seems to me that we can't just splice the IOIO lines into the gauge wires since the car is running 12V and the IOIO wants 3.3V. Any ideas?
OP amp. Also most sensors are 5v and doesn't the IOIO have some 5v tolerant ports?
Problem solved: I fried the IOIO tonight through shoddy soldering. Now I don't have to worry about it 
I just found this thread and gave it a quick read-through. It's so full of win, I'm a little agog (or that could be my pre-caffienated state…).
I started out rolling my own data logger a couple of years ago with a Sparkfun breakout board for the Venus GPS, an accelerometer and an SD card. It worked well enough that I was able to throw it into a few different cars at the Loring Land Speed Races last summer and figure out why a friend in a similar car was going faster than me (answer: the rev limiter needn't be consulted every shift). Late last year I hooked up with fellow Lemons racers Autosport Labs as a beta tester for their open-source data logger called RaceCapture/Pro. It's an ARM-based box with a bunch of analog and digital/frequency inputs, a GPS module, a gyro and an accelerometer, and it logs to an SD card. I wired it up to my E30 and was able to also capture RPM, fuel rate, fuel level, coolant temp and battery voltage (which shows that my alternator's about dead).
A couple of months ago we hit on the idea of doing real-time wireless telemetry back to the pits. We grabbed a handful of the 900MHz XBees and some fancy antennas and did our first test at Sears Pointless about a month ago with ASL's Merkur XR4ti. There were some dead spots on the track, but from my couch in Boston I was able to monitor the car's position, lap times, driver, and a bunch of stats as it happened. I also saw when they got punted off the asphalt and took a brief agricultural excursion. We're refining things a bit for my race next weekend (Loudon Annoying) and will have it installed in my team's E30. I did some testing at a track day there a couple of weeks ago and it also worked very well. We've also kicked around using WiFi (tether RaceCapture to your phone for 'net connectivity) or a stand-alone GSM module to broadcast the data.
I'll be set up at NHMS with the live display on my laptop. I'm going to see if I can hook it up with DashWare and my GoPro, too! Stop by our garage spot if you're at the race; I'd love to get some more ideas. I'm racing with "Howard, Fine & Howard, EMTs" in one of those detested E30s. :-)
Holy crap, yesterday we actually transmitted a lap from a lapping car to the pits at a race track! I don't think I've ever been so excited to see a laptime appear on a PC. We're running CCWS race at Shannonville next week and I can't be more excited to maybe get some more telemetry happening. I've got 3 teams signed for beta testing, so I'm hoping to have an F1-style wall of people staring at PCs.
Lessons learned:
-Concrete walls at racetracks are often full of rebar, and interfere with wifi transmission
-Car batteries need to be absolutely full if you intend on running a power inverter off them to make your router mobile. Fortunately, Shannonville has 120V plugs near the racetrack itself as a backup.
-WifiLapper guzzles phone batteries (bluetooth, wifi, screen always on, and lots of processing). In-car power is a necessity.
-It's probably best to mount the phone higher, so that it doesn't have to transmit through doors, engines, and drivers to get to the router.
bongle, this is seriously cool!
Is there a mode to not worry about laptimes and just transmit data back to the pits? That IOIO is pretty sweet!
How do you calibrate temps, pressures, fuel levels, etc? Is it in the IOIO side or in your app? Can you connect the ioio through usb with your app?
bongle, this is seriously cool!
Is there a mode to not worry about laptimes and just transmit data back to the pits? That IOIO is pretty sweet!
How do you calibrate temps, pressures, fuel levels, etc? Is it in the IOIO side or in your app? Can you connect the ioio through usb with your app?
As I learned after I bought it, the IOIO is USB-only. The bluetooth part of it is that it is capable of using a bluetooth dongle (extra $50). The nice part about that is that the IOIO actually accepts variable 5V-15V DC (what your car puts out) and outputs stable 5V via its USB jack (thus powering your phone). It solves the "how do I keep this phone going for 7/14/24 hours?" problem.
You could totally fire up the app, turn the screen off, and just have it transmit data to the pits. This may work better for transmission, since removing the "driver has to be able to see it" constraint opens up better locations to put the phone for better wifi reception (higher up, outside the car, far away from RF-generating metal/electrical bits, etc).
Temps/pressures/fuel levels via the IOIO aren't calibrated - since fuel senders and temp sensors will all have different resistance/voltage specs, I wouldn't be able to program that stuff in - I leave it to the clever user to take the voltage readings from the sent telemetry and figure out their levels themselves. I assume if you know how to wire the IOIO to your car properly (I don't, which is/was part of the problem), figuring out that what voltage means "empty" should be pretty easy. This is certainly a bit of a weak point with the IOIO support, but since I blew mine up I won't really have an opportunity to make it better.
However, if you're using OBD2 and are lucky enough to have a car which supports the fuel level/temps/pressures OBD2 parameters, those will be displayed properly as percentages/degrees/psi/etc.
I made a video with the data we logged this weekend and the app's dashware compatibility.
http://www.youtube.com/watch?v=BLQlwvtW99w
I think the dashware bit is cool, though I've recently realized that most other laptiming apps allow you to generate video straight from the phone. Back to the grind, I suppose.
Edit: Shameless plug for my hurtin' website: http://sites.google.com/site/wifilapper
Bastards! The ioio is still cool but it would definitely be nice to know up front.
A cars electrical system is a harsh place. When the starter solenoid lets go seeing an 80v spike is quite common. There's a good possibility that's what took out the ioio.
I'm having a hard time understanding what you see back in the pits a far as pressures and temps go. Is it just voltages or do they get translated at all or are they just voltages? You could add in a function in the receiver software to 0 out pressure inputs and calibrate at say 80psi and have it draw a straight line or translate temp inputs. Temps aren't usually linear so that could get fun.
A cars electrical system is a harsh place. When the starter solenoid lets go seeing an 80v spike is quite common. There's a good possibility that's what took out the ioio.
Nope: bad solder:
Problem solved: I fried the IOIO tonight through shoddy soldering. Now I don't have to worry about it
See post 56 above.
That said, I agree with the remainder of your post. I'd love to see the pitside software developed so that each channel for the IOIO gets a popup dialog wherein you could select the voltage inputs and the title of the input (fuel sender, oil pressure, etc) and then an idiot light (and sound?) that comes on in the pits at a selected alarm voltage so that you would know when the car is at a quarter tank or if the car's getting low oil pressure in the turns, etc. And then you could even map the GPS position versus the alarm signal to confirm that you're getting low oil pressure in left hand or right hand turns or whatever.
Of course, this is easy for me to say since I have essentially zero programming ability. I mean, BBCode is about the top end of my skill set, and I have to look those up about 90% of the time...
That said, I agree with the remainder of your post. I'd love to see the pitside software developed so that each channel for the IOIO gets a popup dialog wherein you could select the voltage inputs and the title of the input (fuel sender, oil pressure, etc) and then an idiot light (and sound?) that comes on in the pits at a selected alarm voltage so that you would know when the car is at a quarter tank or if the car's getting low oil pressure in the turns, etc. And then you could even map the GPS position versus the alarm signal to confirm that you're getting low oil pressure in left hand or right hand turns or whatever.
The nicer user interface for the IOIO wouldn't be that difficult to do, it's just a matter of taking a little time, and then needing to be tested. The other thing is that it is my understanding that these sensors aren't all linear. In the heady days when my IOIO was still alive, I looked up fuel sender specs, and they were like 110ohm when full, 30ohm when half, and 5ohm when empty. So I'd have to allow the user to input some actual math, or have a fuel sender preset, but then that opens up the possibility of me supporting every sensor in the car, the thought of which makes me scared. Making a warning light for some particular voltage is easy though, I'll probably do that after my race this weekend.
Hi! this thread asking about open source data acquisition caught my eye, so I thought I'd drop in to say hello! I've been working with blalor (who posted above) on the telemetry portion of the Open Source data acquisition system we've been developing, called RaceCapture/Pro. Here's the main info page we have up:
http://autosportlabs.net/RaceCapture
What has us particularly excited about RaceCapture is that it's not just about data acquision- it also acts as a processing/control system where you can control devices on your car using a simple, on-board scripting language (we're using the language called Lua , right on board). So you can do things like turn on accessories, activate warning lights, control active aero, whatever- using simple or complex logic- without needing to write firmware code.
Also, we've designed it to be hardened for the harsh automotive electrical environment with protected inputs and outputs and power supply. @bongle, I totally get what you're dealing with on the fragile logic level inputs of generic dev boards like the IOIO, we've been burned on this too!
The system has a couple of expansion ports; one offers hardware/sensor expansion and the other is a spare serial port. We put the spare serial port to use to do real-time data telemetry to the pits, and up to the web- we tested this at Infineon Raceway as well as Loudon, New Hampshire. We're also looking at using the expansion port to do a cost-effective dash mounted display using a small android tablet, bluetooth integration to other devices, and so on.
I have to say, we've been working on it for quite some time, and we're priming for a release early this summer! If you're interested in beta testing, please drop me a line at brent @ autosportlabs.com.
Finally, I've seen a lot of great ideas on this thread. One burning question we always have is, what all things would you want to *use* the data for? I saw some good ideas like monitoring fuel consumption, lap times and so on. What else? Monitoring critical functions of the car in general? How the race is proceeding, lap counts / lap times? What about improving driver performance? Anything more? What's particularly important to you?
Thanks! Look forward to your thoughts.
Brent Picasso
I've just placed an order for the Ardurio Mega 2560, plus over a dozen related parts from at least 4 different vendors, including accelerometer, GPS, a display module, xbee shield, and xbee modules. I think the xbees are still backordered from the flood in Taiwan, so that might take a while still. I've ordered a pair of XBee Pro 900 which has a 50mw output, which supposedly should be good for at least a mile with decent antennas. If anything, I'll be learning a lot over the next few weeks.
Hey, Jimbo, did you have any luck with the XBees? We've been testing them (the 900MHz Pro) in a mesh network configuration with the telemetry stuff we've been experimenting with. We found it's really sensitive to line of sight - we carefully selected two different repeater stations locations for both Infineon, CA and Loudon, NH. At infineon we had almost 100% real-time updates regardless of where the car was on the track, except maybe a small coverage drop near the front straight (buildings obstruction). At Loudon, just about 100% coverage as well.
We have mixed feelings about the xBee modules. The system is super easy to use once you figure out their binary API; you set up the mesh network and everything just *works*. However, their advertised range leaves a bit to be desired, and is mostly explained by the meager 50mW power output. If they had something that transmitted at 100 or 250mW at least, it'd make a huge difference. Still: a few repeater nodes is all you need to get real-time coverage all over the track. It was pretty cool to see it live!
here are some pictures of the system we had going on:
xBee modules testing on the bench
With GPS connected
installed in our Merkur
Repeater node assembled, with batteries
...I've seen a lot of great ideas on this thread. One burning question we always have is, what all things would you want to *use* the data for?
Ideal for me would be x,y,z accelerometers, yaw sensor, speed input, tach input, fuel level input, a handful of inputs for temps/pressures, a few fast inputs for suspension height, some IR for tire or brake temps, 5hz+ gps, a good antenna or a non specialty antenna connector to be able to use a larger antenna. Also maybe an output or 2+ for future use. This is a pipe dream but if a lot of the guys out there had a yellow flag indicator in car each flag station could have a yellow/green transmitting "box" so all us dummies wouldnt have to rely on seeing the flags in each station but would still need to see the light on the dash. A USB or bluetooth out to an android/ipad/phone dash would be cool. A configurable dash for that or different dash setups too.
Software side would be a good GUI, Im not a programmer and DOS looking UI's never jive well with me. The more complicated/submenu buried the UI the less people will want to get into it IMHO. Check out http://www.emsefi.com/emsefi/index.php/ … mp;start=1 the "latest motorsports software", i think they have one of the best GUI's of the standalones i've used. A user configurable "dash" gauge/bar/digital displays that could be programmed/moved where you want them on screen and easily saved as default when loading. The ability to calibrate linear and non linear sensors, gear indicator, predictive lap timing, lap to lap and segment to segment comparisons, virtual best lap, a suspension setup recording spot to save setups track to track or just find the best setup, running fuel economy, fuel time left, you could possibly compare wheel speed to gps data to determine tire wear, Video, 2way radio communication.
I'd guess they would have to use their own channel or something so more than one guy could use it at the same time. If its Lemons it could be up to maybe 120 systems...
Mulry wrote:That said, I agree with the remainder of your post. I'd love to see the pitside software developed so that each channel for the IOIO gets a popup dialog wherein you could select the voltage inputs and the title of the input (fuel sender, oil pressure, etc) and then an idiot light (and sound?) that comes on in the pits at a selected alarm voltage so that you would know when the car is at a quarter tank or if the car's getting low oil pressure in the turns, etc. And then you could even map the GPS position versus the alarm signal to confirm that you're getting low oil pressure in left hand or right hand turns or whatever.
The nicer user interface for the IOIO wouldn't be that difficult to do, it's just a matter of taking a little time, and then needing to be tested. The other thing is that it is my understanding that these sensors aren't all linear. In the heady days when my IOIO was still alive, I looked up fuel sender specs, and they were like 110ohm when full, 30ohm when half, and 5ohm when empty. So I'd have to allow the user to input some actual math, or have a fuel sender preset, but then that opens up the possibility of me supporting every sensor in the car, the thought of which makes me scared. Making a warning light for some particular voltage is easy though, I'll probably do that after my race this weekend.
There are tons of different senders. The idea would be to make the IOIO UI user programmable/calibrateable. They could select linear or non linear for each sensor. Then input 2 points or calibrate every so many degrees/psi/things. Its some user setup time and figuring pull up/down values but can be done. The system doesnt need to reference anything for most of the sensors so just giving a voltage translation should do for most. For sensors it would need to reference i'd guess you'd want a calibrated range. So for fuel you could go by % or by gallon (id guess gallon would be easier math wise.) You could have a calibration section where you set the fuel capacity and a fuel level sensor read for each gallon added to calibrate. Fuel slosh would be a bit tricky to "math" out but im sure its possible. If you download the program i linked to in my post #66 in the file menu goto> calibration to get an idea of the calibration.
jbre,
That's a great big list of wants! Good stuff. Aligns well with many of the goals we've outlined with RaceCapture, especially with the configurable outputs. Also, I really think the yellow/red flag detection / indicator would be a big step towards on-track safety- a standardized technology racetracks could adopt would really help that.
On the topic of sensor calibration, on RaceCapture/Pro we've come up with 3 modes for reading analog channels - raw , simple linear scaling, and mapped value, which linearly interpolates based on a mapping between the raw and scaled values, similar to what we do with the Ignition Map for our Megajolt Ignition Controller. On the map, bin values are adjustable as well as the scaling values. Currently we're working with a 5 point map to see how effective it is.
Sample screenshot on how it's configured:
After finding about Harry's lap timer pro here, and using it at Gingerman, I wonder why anybody would use anything else (except if you are an electronics guy doing it just for fun)... That cheap app and an iPhone, and you've got more than the super expensive systems from even a couple years ago... plug in bluetooth ODB and a 5hz GPS sensor, and you just amp up the cool... Need some kind of gizmo to pull data if non_odb for car info tho...
I used Harry's lap timer on my iPhone at Gingerman and was unimpressed with the results.
It often didn't pick up the points on the lap and showed me turning a 25 minute lap instead of 12 laps in 25 minutes.
I used Harry's lap timer on my iPhone at Gingerman and was unimpressed with the results.
It often didn't pick up the points on the lap and showed me turning a 25 minute lap instead of 12 laps in 25 minutes.
That probably wasn't entirely Harry's fault - GPS can shift over time especially as a phone changes orientation, so the split points set at the start of a race may not be getting hit a few hours later once satellites have gone into and out of view. WifiLapper sets really wide start/finish lines to try to avoid this, at the probable expense of a few hundredths worth of accuracy. A couple of my test 'races' (me cycling or running around my neighbourhood) have sets of laps that'll be fully shifted 10 meters to the west of laps set on other days despite me running on the same sidewalks.
Need some kind of gizmo to pull data if non_odb for car info tho...
You could probably get a wifi arduino and emulate an ELM327 OBD2. Plug car sensors into the arduino, and then have the arduino respond to incoming commands like an OBD2 reader would. The iPhone won't know the difference :-). Check out one of my posts on a previous page for a few more details. Though it'd probably be way easier to just hook up some idiot lights to the arduino and have it light them up when things go out of bounds.
I built something similar a couple of years ago:
http://www.ianwood.com/news/story.asp?sid=36
Analog inputs, GPRS / GPS, microcontroller, accelerometer. It worked well when it worked. Average data delay was only about 5 seconds. During our team's hiatus over the past 18 months, one of my teammates absent-mindedly left the enclosure open and it was irreversibly damaged in the rain. So be it. I've been meaning to build version 2 anyway. Here's what I learned from version 1.
Comms: Public networks (GSM/CDMA) are patchy at best at many tracks due to their rural nature so not the best choice in hindsight. And unless you're using LTE, data channel setup times are slooow. The problem is the peer-to-peer options have their own issues. The big one being line-of-sight. Your antennas need a football shaped RF line-of-sight to work optimally. The further apart they are, the bigger your football! That means tall antennas! I am wondering if xBee xTend can cut it without repeaters.
GPS: Your average GPS in your phone or from a component supplier is just that, average. Lack of sensitivity and atmospheric drift will throw your results all over the track. It may be OK for a basic lap timer but even that can have issues. If you want <1m accuracy to see the line the car took through a turn, you need precision GPS. Typically very expensive but you can build homemade versions using three antennas (2 on the car, 1 fixed) for less.
Microcontroller: At the time, the MAKE controller seemed the only beefy microcontroller that wasn't for hard core engineers. Arduino wasn't powerful enough and Raspberry Pi didn't exist. The big challenge here is I/O. In a multi-function environment, you will have several analog inputs, more than one serial connection, and even a couple of digital outs.
The one other thing the old controller did was controlling the dynamic wing on the back of the car using 3 way accelerometer inputs and one of the car's window motors. I've already rebuilt that functionality using a standalone arduino for Buttonwillow.
Compliments to Bongle,
I downloaded wifilapper, installed it on a generic off line arduino phone and the dang thing just works. I'm looking forward to seeing it in action on the track. 'll work on integrating with with the android before the next event, too late for this event
Sharks. Welcome back. e28 power!
Pete.
FYI, I made WifiLapper open-source today on request by some guy from Washington. I even used git, which I think makes me a patchouli-smoking* hippy.
https://github.com/arthare/wifilapper
*I am uncertain if patchouli is meant to be smoked.
Fork it, improve it, do whatever you want with it (as long as whatever you want is allowed by the GPL).
Nelson Ledges - September 2011
The above graph was created for under $100 + an Android phone.
QSTARZ BT-818XT 10Hz GPS receiver
Trackmaster app
Custom conversion software to load data into Racelogic's Circuit Tools software
I know it's slightly different than what's being discussed here. This isn't real time telemetry but is a very nice way to acquire data for a session.
The 24 Hours of Lemons Forums → Lemons Tech → open source data aquisition/display/logging project ideas
