I built a quasi-similar thing several years ago with intentions that it would be a generic sensor platform with a glass display. I wanted to implement a couple interesting sensors:
conduction sensors for gear box contamination
pressure
accelerometer data
resistive temperature
thermocouple temperature
pulse counter
voltage
The idea was these would get instrumented in a vehicle that was strictly mechanical, (such as an overland truck, for long trips) and add data logging to detect impending failures or issues.
The general architecture was a arduino mega with all it's analog ports and i2c ports. There was a simple FSM executing, which would collect values from pins, and format them according to an xml definition file stored on an sd card/ethernet shield, then blast out the packets via udp multicast on the wire. (yes, lazy, but it worked.)
The receiver in this case was just a prototype, my regular computer. I leveraged a kalman filtering library for signal recurrent detection of anamlous acceleration signals (the idea that bearing failures could be detected) and kept a live table updated with a mutex function for executing analysis of data.
Other small functions could extract this data at any time during runtime and generate a graphic display with pywidgets. These were analog needles, numbers, tables, and bar graphs.
Ok, so having said all this:
I haven't really heard anything about OSC until you mentioned it here, and it seems like a great replacement for all the effort that I put into pywidgets. Ultimately I abandoned the project because of the effort required to drive a UI that was robust. The data collection, messaging format, and value table processing was fairly "easy" in comparison.
There's even a python-osc library available to drive OSC complaint things, so I bet that would make it pretty easy.
tl;dr Use python - if you don't know python, it's easy to cobble together bad code that works good enough. With enough practice you can re-write it until it's better.
I think if you stick to python most of the interesting/difficult stuff already exists as importable libraries, and you'll mostly be putting together a build script to assemble libraries and gluing some data structures together. You seem super smart, and I think with some effort you could do this yourself.
Quote:
Originally Posted by Offgr1d
I know some here might be interested like I am in making a budget version Glass dash for all engine and road stats. The M11 and many other large Diesel engines have ECU that have all this data. If you have an ECU then you can get the data
Silver Leaf electronics makes a fairly reasonably priced engine data viewer for iPads / laptops. I have this, but the way you setup views and "see" the data is horrible and not very customizable.
I'm looking for a programmer to make a conversion software for the raspberry pi that takes rs232 data from ECU and Spits out OSC data in relation to PID codes.
Basically if you look at the ECU data stream it's all ascii and has PID identifiers with a value. I want to convert these values via a relationship data table to OSC values. This way you can take any engine data (such as RPM) and out put it in OSC (which is two way UDP) over wireless and display it any way you want with any layout via OSC apps on phones / tablets / iPads etc... Even multiple screens!
If your interested (PM me) and we can hash out the pi requirements.
What I want to do in the end is release the pi software as a really cheap kit with instructions.. Ideally if we could add analouge ohm sensor input to the pi, any other data could be shown on screens (such as tank levels, propane, air pressure etc)
I really think this could be used in more markets than just Bus conversions. Future addon for ODBII interface is also possible.
|