The 24 Hours of Lemons Forums → Lemons Tech → open source data aquisition/display/logging project ideas
I found some forum posts about people trying grms radios to transmit data... Worth googling for those interested in telemetry.
I've got an android app written that I'll be releasing in a month or so that does GPS/OBD2 logging and transmission via Wifi to a windows PC each lap. You can use it by itself, or with any of the bluetooth add-ons (high-rate GPS or OBD2).
The OBD2 stuff is pretty amazing (and dirt cheap: $25 for an adapter on amazon), though only recent cars have the really golden OBD2 parameters that endurance racers would covet: fuel consumption rate and fuel level. All the cars I've tested so far have coolant temperature, so at least you'd be able to catch your engine before it blew up.
For refernce, I recieved this interesting recommendation...
Personally I'd take a look at the latest Raspberry Pi device (its about £22, or $35 usd), so it is still cheap but boasts a much much higher spec which makes it very interesting for a lot of other projects including coming equipped with 256mb's of ram, 700Mhz ARM main processor, 1080p full hd video decode, hdmi output, ethernet lan port, usb and runs Linux distro's. It also has the full set of GPIO pins to connecting it to other things such as sensors or CAN bus chip, directly from the PCB.
If you don't need so much power and are hell bent on Arduino (e.g. for easy re-use of the shields available) then I'd look towards some of the more automotive friendly arduino clones. Something like the Olimexino STM32, its more car friendly because they carefully selected all components to work reliable in INDUSTRIAL temperature range -25+85C so the board can be used directly from a car battery power and survive in the harsh temperatures. Its also got an onboard SDcard slot ideal for data logging from sensors and it has a CAN Bus chip built in so its perfect for communicating with CAN bus ecu's.
The Raspberry Pi is annoyingly unavailable (the entire first batch sold out in minutes this morning) and it's a rather more complex programming affair given you're running a full-up ARM with a full-up operating system. General IO pins are also rather limited. It's a dead no brainer for a base station with its extensive graphics capabilities and processing power, but for an in-car unit with a ton of sensors dangling off it, it's rather limited.
I've been idly curious about trying to do some GPS data logging to complement our video, preferably with a 5 Hz or better GPS antenna. In my case, all I would really care about would be pulling the data after the race and matching it up to GoPro video (an existing GoPro camera). Is this something that one of these open-type systems could be made to do relatively inexpensively (that is, compared to the cost of an Android device plus BlueTooth GPS antenna)? If I could get accelerometer data along for the ride (or for a modest additional price), I wouldn't mind having that too.
Is this something that one of these open-type systems could be made to do relatively inexpensively (that is, compared to the cost of an Android device plus BlueTooth GPS antenna)?
You can get an arduino for about $25. A GPS data logging shield another $20.
http://www.adafruit.com/products/98
The GPS module will run you another $60.
So maybe you are a bit over $100 out the door.
The interesting project (to me at least) is adding real-time predictive lap timing. Unfortunately a base Arduino doesn't have enough RAM to be practical for this purpose. The Raspberry Pi would be fine once you get a bridge to the GPS module going.
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. 
I looked at the Raspberry Pi, but like EyeMWing said expansion options are limited, no on board serial ports, no I2C, etc. Maybe a later version might include some options, but then you're still stuck writing software under Linux for it, whereas the Arduino has a fairly complete development environment that looks pretty easy to code with. Heck, they've even got a Mac version.
You should be able to do everything you highlighted for far less than outlined.
I have an Arduino in my tbird. It lives in an old Sega Dreamcast I've bungee cabled to the back of my dash.
It monitors the oil pressure, ATF temp, and coolant temp.
If the oil pressure drops below 25PSI, the ATF climbed beyond 200F, and the coolant exceeded 215F, a car horn will go off next to the driver.
The driver then has the option to spray a mist on the radiator to cool things down.
Everything worked like a charm.
The code took very little time to write. Most of my time was involved in setting up the cheapie LCD I bought that communicates to the Arduino via I2C (serial interface). My distant cousins who cranked out these POS LCDs didn't do a very good job documenting the LCD controller OR the initialization code required.
Psuedo code:
* Bring car voltage into the Arduino analog input (VREF). You will need a voltage divider circuit to bring the voltage down from car level (max 14V down to Arduino input level max 5V)
* T off one of the sensor wires going to your gauges (take coolant temp for example) and send these to more Arduino analog inputs. Ditto on the voltage divider circuit.
* SW on the Arduino compares Vin to VREF and generates a digital number.
* Compare the digital number with a lookup table.
* If the value is < the cutoff number, do something to get the driver's attention.
* Build an output circuit. You will need to read up on microcontrollers toggling relays or wuss out and just put an LED on your dash. Good luck with that doing much for your drivers.
* Arduino doesn't offer interrupts (where triggering of a condition sets off a execution of a new function in realtime vs just running inside a main loop); I just did a code loop that checks each input and paused for a sec.
Calibration Details
* You generate the lookup table by replacing the temp sensor with a variable resistor. One end goes to the gauge and arduino inputs, the other goes to ground.
* Turning the variable resistor will show you a different temp on your analog gauge.
* You then write some sample code to output via Serial or LCD the current value reported for that input.
* Figure out where you want to set your limit by looking at the gauge and update your code accordingly.
-g
PS. My monitor system worked just fine... and so did my variable wing control system (tilt sensor is cheaper than accelerometer). I blame the stupid mechanical pulleys I rigged up to the Miata motors for why our variable wings didn't last more than an hour or so.
PSS. Cheapest Arduino knockoff. Works just fine and has plenty of analog inputs
http://www.dealextreme.com/p/arduino-nano-v3-0-81877
I bought the rest of my components from Jameco.
You should be able to do everything you highlighted for far less than outlined.
I have an Arduino in my tbird. It lives in an old Sega Dreamcast I've bungee cabled to the back of my dash.
It monitors the oil pressure, ATF temp, and coolant temp.
If the oil pressure drops below 25PSI, the ATF climbed beyond 200F, and the coolant exceeded 215F, a car horn will go off next to the driver.
This is almost exactly what I want to do, and you have given me the road map. Thanks!
My addition will be to use telemetry (packet radio?) to transmit the data to the pit.
gunn wrote:You should be able to do everything you highlighted for far less than outlined.
I have an Arduino in my tbird. It lives in an old Sega Dreamcast I've bungee cabled to the back of my dash.
It monitors the oil pressure, ATF temp, and coolant temp.
If the oil pressure drops below 25PSI, the ATF climbed beyond 200F, and the coolant exceeded 215F, a car horn will go off next to the driver.This is almost exactly what I want to do, and you have given me the road map. Thanks!
My addition will be to use telemetry (packet radio?) to transmit the data to the pit.
I thought about that but nothing says "hey driver, something's @$#@%!" up like a car horn next to the driver.
Arduino wireless tech gets pricey since its very niche market (like their SD shield which steals too many of your I/O).
If I absolutely needed a wireless interface, I'd get something that would just try to maintain a wireless radio link while the Arduino did the data acquisition. Maybe something like this:
http://aircable.net/catalog/product_inf … ucts_id=70
I would want to confirm how long it takes to establish/re-establish a connection though; on a racetrack like Infineon, you'll see a serious number of drop outs when the car passes too far from the base in the pits.
You can then make a Adobe Flash based front end
http://www.arduino.cc/playground/Interfacing/Flash
For a really bad idea, why not combine this with the autonomous lemon project?
Then you can see the data come back in realtime as to why the knucklehead "failsafe" is screaming like a little girl (perhaps because the autonomous car code decided to drive off the road into the sticks).
-g
My addition will be to use telemetry (packet radio?) to transmit the data to the pit.
I'm interested to hear how you plan to implement this. I bought a pair of these radios on ebay pretty cheap for similar purposes. But I haven't had time to plan with them.
http://www.hamradio.com/detail.cfm?pid=H0-006819
Mr. Wednesday wrote:Is this something that one of these open-type systems could be made to do relatively inexpensively (that is, compared to the cost of an Android device plus BlueTooth GPS antenna)?
You can get an arduino for about $25. A GPS data logging shield another $20.
http://www.adafruit.com/products/98
The GPS module will run you another $60.
So maybe you are a bit over $100 out the door.
The only trick with that one is that the default module is SiRF-III, which I believe is only 1 Hz. Conventional wisdom seems to be that 5 Hz is better for this application. They support a 5 Hz module, but it looks like it would require doing some hardware hacking. Still, it looks like there should be something that I can cobble together.
I thought about that but nothing says "hey driver, something's @$#@%!" up like a car horn next to the driver.
The entire implementation is genius, but that last part, that's brilliant. Kudos, sir.
So close... http://www.sparkfun.com/products/10039
But: It's the same 1 Hz GPS module as the Adafruit default, and U.S. cars before ca. 2008 don't use the CAN protocol on ODB-2.
I've got an android app written that I'll be releasing in a month or so that does GPS/OBD2 logging and transmission via Wifi to a windows PC each lap. You can use it by itself, or with any of the bluetooth add-ons (high-rate GPS or OBD2).
The OBD2 stuff is pretty amazing (and dirt cheap: $25 for an adapter on amazon), though only recent cars have the really golden OBD2 parameters that endurance racers would covet: fuel consumption rate and fuel level. All the cars I've tested so far have coolant temperature, so at least you'd be able to catch your engine before it blew up.
I put it on the android market this weekend: https://play.google.com/store/apps/deta … lapperlite
The free version has half an hour of usage per day, good enough for a test session. If you find a bug or already have a better app, PM me and I'll try make it better. If you don't want to go outside to test it out, check the "test mode" box in the options menu, and it'll fake having an actual GPS.
Very interesting. I might have to find an android phone to try this. Any handshake for pre obd2 cars (like 99% of Lemons cars?) Perhaps some device that pretends to be obd2? I have an arduino running which could produce interesting data.
Very interesting. I might have to find an android phone to try this. Any handshake for pre obd2 cars (like 99% of Lemons cars?) Perhaps some device that pretends to be obd2? I have an arduino running which could produce interesting data.
I'd love to (my target market is Lemons/ChumpCar-style folks without that many computer skills), but I haven't found any solid info on what I'd have to do to interface with the pre-1996 cars. Do you know what I'd have to do, and what a user would have to do? Bluetooth serial unit and some soldering?
Even if I had to write a parser module for every old car it wouldn't be that bad - I could probably cover 50%+ of teams with 10 or fewer cars.
I forgot to include the link to my wall-of-text FAQ: https://sites.google.com/site/wifilapper/
For an android phone, I'm doing my dev work on this droid: Amazon link. You can't really beat $120 for an unlocked, brand new, fairly modern android phone. Especially up here in Canada
Could you talk to a blutooth arduino like this:
http://arduino.cc/it/Main/ArduinoBoardBluetooth ?
Could you talk to a blutooth arduino like this:
http://arduino.cc/it/Main/ArduinoBoardBluetooth ?
If you made your BT arduino device talk to WifiLapper using the ELM327 chip's protocol, it would just be "plug and play". It'd probably even work with torque or trackmaster or any other android OBD2 app. All you'd do in WifiLapper is select your arduino as the BT device to talk to, and then it'd hammer away with ELM327-formatted commands and queries.
I use a subset of the commands here:
http://elmelectronics.com/DSheets/ELM327DS.pdf
This is a fairly overkill but very complete specification for OBD2 communication:
https://docs.google.com/leaf?id=0BzoEDg … &hl=en
A high level overview of what to expect would be like this:
WifiLapper->Arduino: does the bluetooth connection magic. This is pretty painless in Android, don't know how it is in Arduino-land. I hope receiving is simple.
WifiLapper->Arduino: "atz\r" (the \r is a carriage return (0xd), not a literal '\' followed by 'r')
Arduino->WifiLapper: "ok\r>" (the only really important part here is that you respond, and end with the '>' character, which prompts WifiLapper to send the next message)
WifiLapper->Arduino: "01 00\r" (this is a query to find out what OBD2 parameters your thing supports. See a list here for what to respond with: http://en.wikipedia.org/wiki/OBD-II_PIDs. Also, this query only occurs when the user is selecting PIDs)
Arduino->WifiLapper: "41 00 ab cd ef gh\r>" (a bit-encoded integer indicating what parameters you support)
WifiLapper->Arduino: "01 05 01\r" (request for coolant temperature and only expecting 1 line back, for example)
Arduino->WifiLapper: "41 05 7b\r>" (indicates a coolant temp of 83 degrees celcius)
WifiLapper->Arduino: "01 0c\r" (request for current RPM)
Arduino->WifiLapper: "41 0c 1A F8\r>" (make sure you return the right # of bytes)
If you respond to incoming data just like an ELM327 would, and output data like I expect, then it should "just work". If you embark on an arduino-based ELM327-emulator, PM me and I'll be happy to help out.
Something I may like much better for this is the, Rasberry PI. http://www.raspberrypi.org/ Its a full blown single board computer (SBC) that you can run linux on. It has some USBs, ethernet, etc on it and might make for a very cool in car computer/data acquisition project.
EDIT: EyeMwing beat me to it.
Just popping in to see what people are typing that is going right over my head.
Someone please drop me a note when we have a Lemons grade stand alone kit that will let me get my data fix on without selling a kidney.
Thx! <3
For those guys doing logging, you should either log into a nice csv format or have a tool to convert to csv so you can interface with DashWare, which is a pretty nice gauge-overlay app. They let you set up a custom data profile so that you can customize your app's output to DashWare.
I just added DashWare support to WifiLapper's pitside app, and it only took a few hours, most of which were spent learning and buying DashWare:
http://www.youtube.com/watch?v=v6h85vrN8ck
Sorry to kind of get off topic but bongle, is that your app? How are you maintaining a wifi signal for the whole track or will it dump at say one corner?
Sorry to kind of get off topic but bongle, is that your app? How are you maintaining a wifi signal for the whole track or will it dump at say one corner?
I dumps when the phone comes in range. He suggests putting it near a slow point in the track to grab the data.
Sorry to kind of get off topic but bongle, is that your app? How are you maintaining a wifi signal for the whole track or will it dump at say one corner?
I confirm the previous post - it connects and dumps at one corner (or whenever the router is in range). If there's no Wifi available at the track, it just stores it all on the phone in a DB, and you can transfer and analyze it post-race. When you start the app, you choose a wireless network name and the IP of your pitside computer, and that's what it sends crap to.
My brother and I did our first really high-speed test this weekend, and it successfully transferred a fully-loaded 90-second lap with all the trimmings (4hz OBD2 + 10hz GPS + 30hz accelerometer) at 120km/h (75mph) to a router with stock antennas, so it could be that all you need is a router within a couple meters of the track.
It also has some SMS capability - you can text the phone, and it'll display your text if you prefix it with "wflp".
The three main reasons I went for wifi over standard data plans are these:
1) Data plans are expensive, and I'm cheap. Everyone has an old router lying around.
2) Data is not always available at racetracks, which are commonly in the middle of nowhere
3) Data dumps via data plans require a webserver running, which is more complicated/expensive than most teams have time for.
To try and be useful for the thread and not just plugging the app...
For the data-acquisition guys in this thread, here are my learnings:
1) You can connect to a stock wifi router outdoors about 150m (450ft) away
2) Being inside a car doesn't appreciably reduce that distance
3) Routers are mostly 12V, so you can probably power them trackside with a car battery (we haven't gotten that far yet)
4) There are tons of surprisingly cheap ($50 or less) directional antennas or high-power antennas you can get or even make to increase time-in-range
5) Lower wifi channels use slightly lower radio frequencies, and thus have slightly better range
The 24 Hours of Lemons Forums → Lemons Tech → open source data aquisition/display/logging project ideas