Race vehicle data logger.

Hi All

Has anyone taken this any further?


Regards

G.

I am new here and to the Raspberry Pi. I am building a race car for Bonneville and have a basic data logger for the engine, which I could barley afford. I need more data from other locations of components in the car, like water tank in and out and air to and from the supercharger and also exhaust. I found some 2 wire analog thermocouples but want to know if they will work with the Raspberry Pi or if you know of any that will work with it so I can record temps.

Any help would be great...

This discussion shows one major point: There is a market for a low cost data logger/system/etc, in many fields. I am not a coder, but I do see the need.

I am looking to monitor beehives (weight, temp, humidity, entry/exit counter) and make the raw data accessible via an up-link. What you all have been discussing is one short hop away from what I am looking for.

I came across this in my search: http://www.dataq.com/products/startkit/di145.html. Not sure if it would serve any of the race crowd need.

Has anyone of this crew developed a more formal requirement list, or a sensor interface doc? I know that is not the guts of the issue from the programming side, but it can drive a development process. I'd love to be involved, let me know how I can help. Thnx

You know I hadnt really thought about it that way but roger I think your right, as we all tend to get more and more into monitoring our machine data the idea of a generic data logger market for cheap is prob a real one indeed. esp now that people are monitoring everything from home security to their thermostat with data loggers and managing them from their smart phones as well as trending data in the case of thermostats.
While I havent gotten to the point of getting hardware together and attempting anything on that end, I have been developing a backbone of a splunk app (still in the ui phase at the moment as i have no data to parse) to run analytics against the log data that way all a person needs is the logs dump them onto any computer and using an open source software (when using the free license which is fine for personal non enterprise use) can view and trend their data. If your not familiar with splunk check out http://splunk4good.com which is something they did for the 2012 elections kinda a show and tell to the nation on their software. (I'm a splunk admin by day at my company so I'm certainly down to help out on that end if anyone has any log data they can send me I can work with)

Cheers,
Brandon

Brandon, this may work into something.

By the way the DexOS site is way cool, too, and may be a way to deal with data logging. But if it is already built in Splunk...

Dex, how would you deal with multiple real-time sensor streams?

Seems you need some device to interface multiple sensors. I just talked to the Dataq people, just trying to frame out how all this fits together. Being a bear of very little brain, what I think I know is this:
Sensors-->Dataq 145 aggregtor ($29) -->RaspberryPi running Splunk as a data logger, or with DexOS capture built from the ground up. But maybe Dex is talking about both the sensor aggregator and data logging in the same device.

I am researching sensors now. I know what I need, but you race folks, sailboat folks will have a different set of needs. Let's start collecting info on sensors for the following, and folks, add in as needed.
- Temp (multiple, ecoRi, Rogerw, others)
- Humidity
- Weight
- Torque
- Rotation speed/direction (multiple, ecoRi, Rogerw, others)
- Position (multiple, ecoRi, Rogerw, others)
- Flow, liquid and air at temperature (aarone's request)
- GPS position (for calling in airstrikes on your competitor's car.... Sorry, couldn't resist) (ecoRi)
- Acceleration (ecoRi, others probably)
- Video

The Dataq 145 gets power via USB, transfers a stream northbound that has to be captured by some computer, hence the place for the Pi or other system like it (Shiva, etc). It takes inputs of +/- 10v, so all sensors would need to be in this range if using this device. What I don't know is what to do with microV sensor outputs if we run across that, or whether there is any standard for this sort of thing.

EcoRi, DexOS, speak up on how you might see this progressing. Better/worse doing something with more off-the-shelf versus home-cooked? I am thinking longer term support, development, etc., but the appeal of Dex's "InstaBoot" and other points about talking directly to the hardware also make sense. I feel like a one-armed juggler...

I built a non-pi and non race datalogger using a cheap £0 ELM327 based bluetooth system

http://www.ebay.co.uk/itm/ELM327-Blueto ... 4ab974bd96

Software was PyODB http://www.obdtester.com/pyobd

Worked okay... update rate sucked though

For some funky accelerometers, you can use the 2 axis accelerometer which can interface to the Pi using I2C (4 wires and it will work) http://proto-pic.co.uk/imu-digital-comb ... 0-adxl345/

For Temperature sensors, these work a treat (1 wire digital thermometers that can be connected in parallel) http://proto-pic.co.uk/one-wire-digital ... r-ds18b20/

For fuel consumption, I used a RS Components fuel flow sender (quite expensive but worth it) to a custom board that counted the pulses although I think the Pi can do it.

Some more advanced monitoring of the fluid levels and such require some interfacing but its not difficult... the fun part was interfacing thermocouples for the cylinder head temperature and the exhaust gas temperature. ( http://proto-pic.co.uk/1048_0-phidgette ... r-4-input/ for a USB sampler)

Hi, i am coming at this from a coders point of view, i want to make DexOS (DexBasic) as useful as possible for projects like this, both hobby and commercial.
So i am busy adding the functions, that will make it possible to be used for RT data logging etc.
To this end i have open sourced the DexOS, to help speed up the process of adding more features, by letting other coders add to it or modding the code.
But i am open to requests, for new features and interfaces etc.

I have also done some work with the ELM327 chip and the pi, along with DexOS.

Dex, thank very much for your offer. Please let me know how you might want the specs. Not being a coder, I am not sure where our demarc falls, and I need to know the language you need to hear.

For instance, I would think we would the need the ability to take in 16 sensor inputs (picked out of the air, but reasonable for the race crew). Now, if they are to come into your DexOS Pi, we would need to know how they get there, how you deal with them, etc. If you need something in the middle (like the Dataq 145) and want to take input from that, then there is a different set of specs. And, rotation sensors could be only Hall sensors, or they could be someone's built board. The Pi inputs would be different, depending. Could you comment on this?

Then, once you have the data from the sensors, we need to develop a straightforward form for storage, access by higher-level programs that display or manipulate the data, or to send northbound. Being a non-programmer, I am thinking something like a .csv or .rtf type of file - accessible by most anything. But there may be a lower level database model that makes better sense. For instance, Brandon, weigh in on what Splunk could take as an input source. That is what Dex needs to support as his output.

For RichardP, many thanks! I got in touch with Proto-pic from your suggestion, and Richard Winton was kind enough to recommend places on my side of the pond with similar gear. And more generous, he offered outfits that do similar stuff they do in design. !00% kudos to Proto-pic and Mr. Winton. Many thanks! www.sparkfun.com, and www.adafruit.com were his leads.

Roger

Roger, you're right in that you need an extra interface between the Pi and the sensors since the Pi doesn't have any analogue input capability. You can use the GPIO directly but you are very limited on the number of sensors and they must all be digital.

I think a better approach might be to use a board that has analogue inputs already on - the mbed here http://mbed.org/handbook/mbed-NXP-LPC1768 has 6 of these and can be used in multiples connected together. The data can then be downloaded by ethernet or from a SD card on a breakout board.

Since it's much lower power, you could have a much longer battery life. The data processing will also be faster and easier when downloaded to something much faster after a run than on the fly on a Pi. However you wouldn't really be able to have extra interfaces like a screen connected, for example. What do you all think?

Also from my (limited) coding experience I'd save to any kind of text file with an easy to use delimiter like a tab space or a comma (.csv), it makes importing the data into most programs much simpler.

Jr, looks like this would work, but obviously not out of the box. And I don' t yet understand what it sends upstream, what the Pi (or other computer) might be getting. Need to read more...

For others, this is what already exists in code for the gizmo for what Jr suggested, stuff that might be of interest to the race crowd:

Accelerometer

LIS302 Accelerometer - Triple axis digital SPI accelerometer
ADXL345 Accelerometer - Triple axis digital accelerometer
SCA3000 Accelerometer - Triple axis digital accelerometer
Grove 3 axis Accelerometer - Triple axis digital I2C accelerometer

Sensors

GlobalSat EM-406 GPS Module
GlobalSat BR355 Serial GPS unit - using a Sparkfun RS232 breakout and a PS/2 breakout for power
ITG-3200 Gyroscope - Triple axis digital gyroscope
SRF08 Ultrasonic Ranger - I2C Ranging sensor
SRF05 Ultrasonic Ranger - Simple ranging sensor
Seeed grove ultrasonic ranger - Single wire ranging sensor
Parallax Laser Range Finder - Laser and CMOS camera with 1Hz updates and 15-122CM range
SCP1000 Pressure Sensor - SPI MEMS barometric, absolute pressure sensor
Bosch BMP085 Pressure Sensor - I2C MEMS barometric, absolute pressure sensor
Freescale MPL115A Digital Barometer - I2C MEMS barometric and temperature sensor
RHT03 Humidity and Temperature sensor - A digital humidity and temperature sensor

I didn't see anything specific for rotational or position sensors, but obviously the board has that capability once the code was written or tweaked from other sensors.

Digging a bit on a site that promotes the Arduino prototyping board, I find a list of possible suppliers that might be of interest to this group:

USA: SparkFun, Maker Store, Adafruit Industries, Little Bird Electronics, Modern Device, FunGizmos, NKC Electronics, Gravitech, RobotShop, Liquidware, Hacktronics, MakerBot Industries, Microcontroller Pros, Curious Inventor, AeroQuad, CuteDigi, EIO, Teach me to make, UltiMachine, Electrojoystick.com, Electronics is Fun, AME - After Midnight Engineering, Trossen Robotics, Jameco, Zagros Robotics, Advanced Micro Circuits Corp, iHeartEngineering, 3D Robotics, Jaycon Systems, Elexp, Abra-electronics, Reuseum, Pololu, 411 Technology Systems, Handmadecircuits, ManyLabs, Epictinker, Woodman Studios, LLC, oddWires, Siliphi LLC, Karlsson Robotic, RadioShack

Hey guys. I'm actually building the same thing.

Currently I'm using an Arduino, but since the Pi came out, I'd like to start to expand.

At the moment I inputseveral 0-5V inputs (Engine Oil Temp, Oil Pressure, Coolant Temp) and a couple interrupts (Engine RPM, Vehicle Speed Sensor). I then process them and send serial data via bluetooth to my Android device. I've written a very basic app in Android to process this information and display the values. It was working, but I've hacked the code up to do it in a better method and to enable saving data.

If you guys are interested in working with me on this, let me know. I need more developers. I can do Arduino (C) /Android (Java), but I'd need some Python guys if I start working with Pi.

kartstig@gmail.com

Howdy all,

I'd like to point you all to Loguio: http://code.google.com/p/loguino/ it's basically exactly what we're looking about for and it's already working; gps, tri axis accelerometers, temp and position sensors, etc are all currently up and running, but It's a pure logger. There is no reason that the logs cannot be passed realtime onto a pi in order to deal with wireless transmission of data, video recording, diy dash display,etc. It's based on arduino mega so there are tons of inputs and if you have a megasquirt it already will record all engine data. it seems silly to re-invent the wheel, when a solution already exists. Perhaps the talent here should focus on programming for new loguino sensors and getting a rasberry pi to interface with it.

Thoughts?

Hello.

I have just finished looking at the code of Loguino and could not find any reference to frequency based sensors like rpm sensors and axle/wheel speed sensors.

We can not capture the data from these sensors using the polling system because we might miss some data.

Has anyone added this functionality to loguino?

Or know of any other open source system that does that?

Thanks,
JC