python, i2c bus, a2d convertion, embedded, pre odb2, android, GPS, telemetry

If the above mentioned are not a foreign language, drop me a DM. I'm re-visiting a project from a few years back to produce a direct splice into loom system of reading sensor data on pre odb2 (mems2j) for diagnosis and performance telemetry. Plan is to roll out a simple kit to direct monitor ECU io usinig off the shelf components with Bluetooth out and an android app for display / diags

Apologies to those who have no idea what I'm talking about, nothing to see here, move on now...

You have my undivided attention, this is Raspberry Pi stuff isn't it. Getting 2j to speak to a torque type app cost effectively would be landmark stuff. Mike

This is indeed the plan. A few years back I used an Arduino mega to read the analogue (0_5v) values from TPS, MAP, oilntemp, air temp, coolant temp, lamda etc upstream of the ECU, and combined with 3axis accelerometer and GPS data to create a data stream to SD card for examination of my hill climb events.

What I plan is a read of all analogue sensor data and output states data (Iacv steps data etc) with additional timestamp and GPS data that can be used for both diagnosis and also saved at 100mS intervals with graphic playback via Android app, ideally with a protocol gateway option that will allow existing OBD2 Software to read the value set too....

Ambitious, but I believe it can be done

Similar idea to a www.pscan.eu

talkingcars wrote: Similar idea to a www.pscan.eu

Not quite. The pscan box reads only the data which comes out of the diagnostic port. I have been chatting to them recently about the idea of a protocol gateway to convert the output of the pscan box to ELM so that you can use any of the existing software with it. And it looks as though that might be a direction the go in the future but at present they don't have a specific timeframe for that.

What I'm looking at is much simpler and cheaper to implement (probably about £20 -£30) and much more hackable. Rather than plugging into the diagnostic port and doing battle with the complexities of rovers variant on what I believe is a modified KW2000 protocol, the bit of kit I'm working on reads the direct analogue data from the sensors before the ECU hears about them.

This has both advantages and drawbacks, but on balance comes out on top, because it's cheap, easy for people to understand, and potentially allows for some sensor data to be spoofed for test purposes ie feeding say a different lambda or air temp value into the ECU to what the sensor is currently reading.

Basically I'm looking at using a RaspberryPi zero and off the shelf multi channel analogue input board physically close to the ECU for direct tap into the loom at the ECU chatting over i2c bus with a simple 3 wire connection. Add to that a GPS module and three axis accelerometer board also using i2c bus and you have something thats actually quite useful. eg ability to grab realtime sensor data with gps location and relative acceleration/ deceleration data (handy if you want to know if under sustained cornering on track if you are suffering oil starvation etc)


This pi zero its self can drive a fairly reasonable oled display or touch screen, but I feel most people would prefer to just use a phone or tablet to avoid having to fit lots of additional hardware in the cockpit. So will use a simple android based app to poll the pi zero over wifi or bluetooth. And this also opens up the possibility of sending telemetry to a remote laptop again useful in a sports situation.

As commented the eventual goal is to provide a Bluetooth output in ELM format so that any of the existing software out there can be used, but that's going to need quite a bit of work so will be a second phase project.

What I hope to do is to put together a series of how-to for both the hardware side, and a series of programming guides so that people will have the opportunity to learn how the systems work and to explore further developments.

The project will be released under open source licence to encourage wider participation, as it lends itself not only to the pre obd k16 (mg, lotus, caterham etc) but also a wide range of vehicles with no diagnostic system.

Er,
Beam me up Scotty!!

You should be on the starship enterprise, whats wrong with a bit of wire with a bulb on the end?

Gosh, my brain hurts

Great idea though and good luck with this project, failing this you can always go on work at power stations with John ( John and Sue)

davidgv1 wrote: whats wrong with a bit of wire with a bulb on the end?

Well, in a way, thats what this project is! Reading and interpreting the data that comes out of the ECU is very complex, but reading the raw analogue voltages from the various sensors upstream of the ecu is just like using a test meter or even a bulb and seeing how bright it is.

Pretty much all of the sensors give a simple variable voltage out in the range 0-5 volts. you just need a very simple bit of maths to convert that voltage to something understandable eg: oil temp, throttle position etc

It sounds complicated, but really isnt. Most children in computer science classes these days will be taught how to read an analogue value voltage using either a raspberry pi or a bbc microbit computer. It can be done using a single line of code.And in essence thats the core of this project, just some very easy to understand code and off the shelf hardware that just plugs together.

You could quite literally do all aspects of this project using just the things in the photo Ive just added, total cost off ebay - a shade over £15, and use the snap together coding system that does with the microbit, equivalent of perhaps 20 lines of code thanks to some useful code libs and inbuilt functions, but I am aiming for something a little more elegant with a bit more scope.

Let me give you a simple example:

Have a look at

http://www.tom-seven.stillgame.ch/wiki/doku.php?id=tps_throttle_position_sensor

And the associated sensor data values

http://www.tom-seven.stillgame.ch/wiki/doku.php?id=tp-logic

Initially this looks a little complicated, but all that is actually going on is that if you measure the voltage going to pin12 on the black connector of you ECU, when the throttle is at the idle position you would expect around 0.56v and foot to the floor you would expect to see around 4.4v

If you connected up a simple single board computer like the BBC micro bit to read the voltage going to pin 12 on your ECU (NB this won't work as-is because the microbit maximum analogue input voltage is 3.3v)

And used a simple block of code (see attached image at the bottom of this post) the microbit would continuously read the voltage from the sensor going into its analogue input pin and send it out over usb to a laptop or whatever you happen to have connected. A continuous stream of data that tells you how open the throttle is for any given moment.

Ok, it's just a raw value at that point, but it's a trivial matter to convert that to say a percentage....

Add a few more inputs, a few more blocks of code and already you have a useful data logger

Now as I've said, a) that won't work in the real world because the sensor max voltage out on the car is a little too high, and b) we need to do something with the output data to graph it in order for it to be useful, but it really isn't a lot more complex than that. Temperatures, Manifold pressure, lambda sensor etc all can be read the same way.

Not sure if these are of any use to you

MEMS Analyser

MEMS Diag

I had a play with MEMS Diag a while ago. It uses an easily available OBD2 cable and Android software to read the ECU on MEMS1.9 (pre OBD2 version). It also allows setting of some parameters to 'tune' the ECU but I haven't played all that much with them TBH.

I watch your progress with great interest :broon: :broon: :broon: :broon: :broon: :broon:


Edit: On reading your thread completely, these are probably not of use as you seem to be wanting to intercept the raw sensor outputs before they even reach the ECU. Anyway, I'm still interested :yesnod: :yesnod: :yesnod: :yesnod: :yesnod:

I saw this a while back, but didn't do anything with it because it didn't look as though it would work with mems2j which is on the pre obd versions of the vvc.

I will have another look.

As commented, the system I'm looking at entirely bypasses the ECU, reading direct from the sensors, so while not as comprehensive in the data it can collect, and not able to read or clear fault codes, can give an accurate picture of what each sensor value is, and thus highlight any failure or out of spec reading that way.

g7nbp wrote: I saw this a while back, but didn't do anything with it because it didn't look as though it would work with mems2j which is on the pre obd versions of the vvc.

I will have another look.

As commented, the system I'm looking at entirely bypasses the ECU, reading direct from the sensors, so while not as comprehensive in the data it can collect, and not able to read or clear fault codes, can give an accurate picture of what each sensor value is, and thus highlight any failure or out of spec reading that way.

Looks like we crossed over in our responses :lol: :lol:

I have used MEMSDiag to read MEMS 1.9 so assume it would read MEMS 2J as well. It needs a 'special' cable

- FTDI-based (FT232) 12V K-Line cable, commonly known as VAG-cable/VAG-KKL. These cables are widely available on ebay etc. Make sure it's build using the FTDI USB chip, perhaps PL2303 should also work but I haven't been able to test it. Avoid products based on CH340 chipset (reason being, there's one missing but crucial function not yet implemented in the driver)

to quote the MEMSDiag blog.

Have you managed to find any reference values yet. I have the pscan set up as well and though I find it quite useful, not knowing the reference values makes it a bit less useful than it could be. I did start constructing a spreadsheet of values for my VVC and now 1.8MPI but there's nothing to say that my car is running the 'correct' values of course

Please correct me if I'm adrift: as you have said this system will give you a window on what's going on up stream of the ECU allow you to view sensor outputs & the information on Toms pages is a shortcut to a lot of the required parameters. However unlike the Pscan your unit won't display a fault code or specifics such as MPG, unless of course you can integrate those values within the Pi software. I am fortunate as I have access to a diagnostic unit which reads 2j, however to have a Pi talking to an Android 'phone in the car is very attractive. I assume you're basing it around the Pi zero w.