Fiat 124 Spider Forum banner

1 - 20 of 42 Posts

·
Registered
Joined
·
1,773 Posts
Discussion Starter #1
Hey Folks,

So after a discussion of how to get access to oil pressure and temperature data for the cars in various threads, I decided to explore whether it would be possible to push data from external sensors to a Raspberry Pi micro-computer and in turn have an application running on the ICE system connect to the Raspberry Pi and and display the data. After a bit of experimentation and investigation, it looks like this might work, so I'm going to track progress in this thread. Ultimately, if this works, the plan would be to provide a parts list, software and instructions for anyone else that wants to do it.

So a bit of background:

A number of people have lamented the lack of oil pressure and temperature data available from the car. Even using an OBD2 reader, this isn't available as the car only contains an binary oil pressure switch that triggers an alarm at a set point, but doesn't provide continuous data. There are, however, a couple of unused ports near the oil pump and filter that will accept pressure and temperature sensors:

73773


Adding sensors to these ports would be easy enough with them then being hooked up to individual gauges or even one of the multi-input gauge options that accept analogue inputs. However I'm not a huge fan of adding aftermarket gauges (although I do have a turbo gauge in a Cravenspeed mount currently). Instead, what I want is to do is use the infotainment screen to display the data.

As many of you know, there are a number of applications available that you can install via the Mazda All-In-One installer available from www.mazdatweaks.com that allow you to install custom applications on to the infotainment system. These include speedometer and other apps that display certain vehicle related data such as speed, rpm, GPS data etc:

73774


These applications are pretty cool, and the folks that originally developed it have created a framework that allows people to relatively easily create new applications. However, they have two main issues:

1. The vehicle performance data-points available to the infotainment system are somewhat limited and, in particular, lack things that would be of particular interest to anyone running a tuned car and / or taking their car to the track. This includes the aforementioned oil pressure and temperature, as well as things like AFR.
2. Using the application framework, the refresh rate for each data point is no faster than once per second. This makes simulating an analogue gauge pretty jerky as anyone who's used the speedometer app will have noticed.

To get around these limitations, my plan is to take the application framework and use it to create and deploy an application to display the data, but I'm going to use an alternative means of feeding the data to the application. My intention is to feed data from the sensors to a Raspberry Pi and then have the infotainment system connect to the Raspberry Pi via WiFi to receive the data to be displayed in the app. For those of you not familiar with it, the Raspberry Pi is a tiny computer capable of running a full desktop environment, but more typically used by folks building robotics, sensor systems etc. Including a case, it's about the size of a pack of cards and includes USB ports and full set of general purpose input and output pins for connecting external sensors etc. Here's mine with a USB GPS module I've been using for proof-of-concept testing:

73775


With this means of pushing data to the infotainment application, it should be possible to connect and consolidate data from multiple sensors as well as - potentially - data from a bluetooth OBD2 reader, and send it to the application in real-time as updated data becomes available rather than wait for the infotainment application to pull the data, which as I said happens no more than once a second.

So, with all this in mind, there were a number of things I needed to verify to check the viability of all this.

1. Could I figure out how to read data from sensors connected to the Pi.
2. Could I set up a service on the Raspberry Pi to push that data to a connecting client application.
3. Could I set up an application in the infotainment system that could connect to the Pi and display the data pushed to it.

So far, the answer appear to be yes to all of those. The video below shows the simple test infotainment application I've created connected to my Raspberry Pi and displaying data from the USB GPS sensor connected to it. It's showing velocity information in meters per second, but as the Pi wasn't moving at the time, there's very little being updated, but for the purposes of the test that wasn't important - the data being pushed and displayed was the point.


So - so far so good. What's next?

The main thing will to be to actually push the application out to the car and check the infotainment WiFi system doesn't cause any issues. If that works out, I'll then order an actual temperature or pressure sensor and test with that - that'll take a little bit of experimentation as the output from the sensors will be analogue whilst the Pi will want a digital input and doesn't have a built in analogue to digital signal converter, however there are boards available for it to do the conversion. Once I have the Pi receiving the signals, I'll then have to calibrate it so that data being output is correct i.e. if the oil is at 150F, that's what is reported. I'll also need to take a look at what sensor data could be picked up - I'm thinking feeding my turbo boost signal in to it should be possible as well as OBD2 data from a bluetooth reader. Finally, I'll need to do some design around the application displaying the data.

Lots of work ahead, but it's shaping up to be a fun project. Watch this space.
 

·
Registered
Joined
·
1,973 Posts
I love it when you go full on nerd. (y)
 

·
Registered
Joined
·
1,649 Posts
Hey Folks,

So after a discussion of how to get access to oil pressure and temperature data for the cars in various threads, I decided to explore whether it would be possible to push data from external sensors to a Raspberry Pi micro-computer and in turn have an application running on the ICE system connect to the Raspberry Pi and and display the data. After a bit of experimentation and investigation, it looks like this might work, so I'm going to track progress in this thread. Ultimately, if this works, the plan would be to provide a parts list, software and instructions for anyone else that wants to do it.

So a bit of background:

A number of people have lamented the lack of oil pressure and temperature data available from the car. Even using an OBD2 reader, this isn't available as the car only contains an binary oil pressure switch that triggers an alarm at a set point, but doesn't provide continuous data. There are, however, a couple of unused ports near the oil pump and filter that will accept pressure and temperature sensors:

View attachment 73773

Adding sensors to these ports would be easy enough with them then being hooked up to individual gauges or even one of the multi-input gauge options that accept analogue inputs. However I'm not a huge fan of adding aftermarket gauges (although I do have a turbo gauge in a Cravenspeed mount currently). Instead, what I want is to do is use the infotainment screen to display the data.

As many of you know, there are a number of applications available that you can install via the Mazda All-In-One installer available from www.mazdatweaks.com that allow you to install custom applications on to the infotainment system. These include speedometer and other apps that display certain vehicle related data such as speed, rpm, GPS data etc:

View attachment 73774

These applications are pretty cool, and the folks that originally developed it have created a framework that allows people to relatively easily create new applications. However, they have two main issues:

1. The vehicle performance data-points available to the infotainment system are somewhat limited and, in particular, lack things that would be of particular interest to anyone running a tuned car and / or taking their car to the track. This includes the aforementioned oil pressure and temperature, as well as things like AFR.
2. Using the application framework, the refresh rate for each data point is no faster than once per second. This makes simulating an analogue gauge pretty jerky as anyone who's used the speedometer app will have noticed.

To get around these limitations, my plan is to take the application framework and use it to create and deploy an application to display the data, but I'm going to use an alternative means of feeding the data to the application. My intention is to feed data from the sensors to a Raspberry Pi and then have the infotainment system connect to the Raspberry Pi via WiFi to receive the data to be displayed in the app. For those of you not familiar with it, the Raspberry Pi is a tiny computer capable of running a full desktop environment, but more typically used by folks building robotics, sensor systems etc. Including a case, it's about the size of a pack of cards and includes USB ports and full set of general purpose input and output pins for connecting external sensors etc. Here's mine with a USB GPS module I've been using for proof-of-concept testing:

View attachment 73775

With this means of pushing data to the infotainment application, it should be possible to connect and consolidate data from multiple sensors as well as - potentially - data from a bluetooth OBD2 reader, and send it to the application in real-time as updated data becomes available rather than wait for the infotainment application to pull the data, which as I said happens no more than once a second.

So, with all this in mind, there were a number of things I needed to verify to check the viability of all this.

1. Could I figure out how to read data from sensors connected to the Pi.
2. Could I set up a service on the Raspberry Pi to push that data to a connecting client application.
3. Could I set up an application in the infotainment system that could connect to the Pi and display the data pushed to it.

So far, the answer appear to be yes to all of those. The video below shows the simple test infotainment application I've created connected to my Raspberry Pi and displaying data from the USB GPS sensor connected to it. It's showing velocity information in meters per second, but as the Pi wasn't moving at the time, there's very little being updated, but for the purposes of the test that wasn't important - the data being pushed and displayed was the point.


So - so far so good. What's next?

The main thing will to be to actually push the application out to the car and check the infotainment WiFi system doesn't cause any issues. If that works out, I'll then order an actual temperature or pressure sensor and test with that - that'll take a little bit of experimentation as the output from the sensors will be analogue whilst the Pi will want a digital input and doesn't have a built in analogue to digital signal converter, however there are boards available for it to do the conversion. Once I have the Pi receiving the signals, I'll then have to calibrate it so that data being output is correct i.e. if the oil is at 150F, that's what is reported. I'll also need to take a look at what sensor data could be picked up - I'm thinking feeding my turbo boost signal in to it should be possible as well as OBD2 data from a bluetooth reader. Finally, I'll need to do some design around the application displaying the data.

Lots of work ahead, but it's shaping up to be a fun project. Watch this space.
Graeme...this is too cool. If you can pull this off, it will be a bonus for everyone. I agree that add-on gauges don’t blend well into our car. The infotainment screen would be great. If a split screen could be developed for multiple read outs, we could could see real data and not have to wait for a light to tell us we just fried our engine.

Dan
 

·
Registered
Joined
·
1,773 Posts
Discussion Starter #5
And use the new memory location that trez identified, which has plenty of room, and will allow those on version 70 to be able to use your new app too. I'm looking forward to see what you come up with!
Yep - I'm using the resources directory for deployment on the car - lots of room available.
 

·
Registered
Joined
·
2,192 Posts
This is so cool. Even if it doesn't work ( Blasphemy @Mike34 ) the fact you are taking your skills and knowledge and "going full nerd" - Chainringtattoo is awesome!!!!

I know this has nothing to do with what you are doing...but I liken it to when I was younger and was thinking about prime rib for dinner. I recall being sad because in my mind "To have Prime Rib, one must got to a restaurant" then it dawned on me...wait a minute...its made by a man aka chef...i'm a man aka no chef...but if he can do it...someone HAS done it...WHY CAN'T I?

the moral of the story...I make a MEAN prime rib!

LOL

[email protected] YOU SIR....MAKE A MEAN PRIME RIB! Mahalo!!! Keep up the good work.


aloha mike
 

·
Registered
Joined
·
2,192 Posts

·
Registered
Joined
·
1,773 Posts
Discussion Starter #9 (Edited)
Its AIIIIIVE...

OK - really boring video below, but the important point is the basics of the app are all working - the bit where it jumps from 0.01 to 0.00 and then back to 0.01 is the interesting bit as it shows the feed from the Raspberry Pi to the ICE app is working correctly. This is the Pi pushing GPS data, with the ICE system connected to the Pi's WiFi. I only got this working late last night so no video with the car actually moving yet as I had to get up early for a flight this morning, but this was a big step in the proof of concept process.

Couple of things that came up getting this transitioned from the ICE simulator to running in the actual car:

1. The simulator is only a very rough approximation of the the actual in-car system. In particular, the simulator appears to be built using the Chrome browser, whilst the car appears to use a (probably ancient) version of the Opera browser. This means different Javascript engines and things that worked without issue in the simulator caused problems in the car.

2. Debugging in the car is a PITA - the system is really slow connected via SSH and I haven't really figured out where debug output is going yet. Need to do some work to figure out an efficient way to work on this when I get to the point of developing out the application interface. If that is all double-dutch to you what it means is that to test the app I have to run out to the car, install the app, test it, then try to figure where the debug logs are and pull them over a glacially slow connection, go back to my computer and try to figure out the problem, make a fix then rinse and repeat. This is pretty brutal - and I will end up flattening the battery in the car at some point. I may see if I can grab a unit from a wrecked car to set up as a workbench in my office.


One thing I should have pointed out is that for you to be able to install the application to display the data in the ICE, you'll need a car either running the 56 series firmware (2017's or early 2018s) or - if you have the 59 or 70 firmware, have the ID7 patch installed. For the late 2018 cars on that come with the 59 series firmware, this will mean doing the serial cable install of the ID7 patch described at:


Because this is a pretty intimidating process for a lot of people, I've decided to create a web based interface running off the Raspberry Pi that you'll be able to use to display the data on a smartphone or tablet in addition to using the ICE screen.

Stay tuned. Next steps are to get an actual sensor hooked up and test converting an analogue signal to digital and work on displaying the data smoothly. Amazon parts shopping today.
 

·
Registered
Joined
·
2,192 Posts
yippppeeeeee!!!!


aloha mike
 

·
Registered
Joined
·
3,070 Posts
How many analog inputs are you considering? I could imagine using 4.
 

·
Registered
Joined
·
1,773 Posts
Discussion Starter #12
How many analog inputs are you considering? I could imagine using 4.
Most of the analog to digital boards available for the Pi accept up to 4 inputs so that's probably what will be the limiting factor. I'm thinking oil temperature and pressure, boost pressure plus...?

Bear in mind we should also be able to feed anything OBD2 picks up via a bluetooth connection.
 

·
Registered
Joined
·
3,070 Posts
Most of the analog to digital boards available for the Pi accept up to 4 inputs so that's probably what will be the limiting factor. I'm thinking oil temperature and pressure, boost pressure plus...?

Bear in mind we should also be able to feed anything OBD2 picks up via a bluetooth connection.
Automatic transmission fluid temp. Apparently it's available from OBD2 but no one seems to know the PID parameters for it. I've been considering adding a fluid sensor to the pan. If we could find the PID for it, that would be awesome.
 

·
Registered
Joined
·
2,192 Posts
Two things I don't understand:
1. What is MAND IN TAIWAN
2. Everything else...

All joking aside, this is awesome. Can't wait to see this working.
lol good eye

aloha mike
 

·
Registered
Joined
·
1,773 Posts
Discussion Starter #16
Parts ordered from Amazon. I ordered up the following:

1. Raspberry Pi 3 (I have a pair of Raspberry Pi 2's kicking about at home, but the 3 and 4 have built in WiFi and Bluetooth). The 4 has just been released and is quite a bit more powerful than the 3, but needs more current to run and runs hotter. The 3 will run off a standard 2.2 amp USB2 charger and is plenty for our needs.
2. A oil pressure and an oil / water / air temperature sensor.
3. Two sets of metric to 1/8 NPT adapter kits (I'm assuming the two available plugs will be metric.
4. An analog to digital signal converter for the Raspberry Pi.
5. Micro SD card for the Pi. I bought a 32GB card to leave plenty of room for logging, but in reality, 16GB will be more than enough. These things are cheap these days.
6 A case for the Pi tall enough to take both it and the signal converter board.
7. A set of brass standoffs to mount the signal converter board on the Pi.
8. A bluetooth ODBC scanner - my current one uses WiFi.

All up, this came to about $200. The only thing that might get added is a power source for the Pi. I haven't decided how I'm going to do that yet, but options will be to mount it permanently in the car - either under the dash or in the engine bay somewhere - and hard-wire power, or have it run off the 12V outlet and deal with feeding the sensor cables to that side of the car. It'll also run quite happily off a LiPo battery. Whatever, we'll probably want it to be fairly accessible in order to pull it out and update it etc.
 

·
Registered
Joined
·
1,773 Posts
Discussion Starter #17
Lots of goodies arrived today:

73887


So far I've been able to get the pressure and temperature sensors hooked up to the Pi and can read data from them. I need to do some studying up on how to calibrate the data into usable values, but the fact I'm reading them at all is a good first step for this evening. In the video, you can see the temperature data fluctuate as I hold the sensor in my hand and then let it go again. Tomorrow I'll have a crack at connecting to the bluetooth OBD2 reader.

Also starting to think about wiring harnesses to run from the sensors back to the cabin - I'm pretty sure we'll want the Pi in the cabin for ease of access and protection from weather.

73888


 

·
Registered
Joined
·
532 Posts
That's a good project I'm keeping eyes on… thanks for the effort and share Graeme!
 

·
Super Moderator
Joined
·
886 Posts
This is an amazing project. I’m full nerd with the RPi too, just haven’t figured out what I want to do with one yet.
The only thing that comes to mind is that the Pi isn’t a high-rel item, so any isolation from heat and vibration will be a worthwhile effort.
Best regards
Pete
 

·
Registered
Joined
·
1,773 Posts
Discussion Starter #20
I'm waiting on some kit to arrive to help test and calibrate the oil temp and pressure sensors, and to build out wiring harnesses for them, so while those wind their way to me, I decided to move on and see if I could get the new Pi 3 with built-in bluetooth to hook up to the cheap (~$10) OBD2 dongle I bought (my previous dongle used WiFi, but I need to RaspPi wireless to act as hotspot for the ICE to connect to, so bluetooth it is).

Like many things Raspberry Pi, just because it has something, doesn't mean it's plug and play. Getting the OBD2 dongle hooked up and communicating took some quality time with Google, but got there in the end.

The video below shows RPM data being read. @Chainringtattoo asked about the data lag. It's a little slow, but I had the refresh rate set fairly low for testing so you could read the data as it scrolls. I'm hoping to be able to smooth it out in actual use.

So far, I've identified the following data points as being available and I'm working my way through the ELM327 specs to see what else we can grab:

  • engine_load
  • coolant_temperature
  • short_term_fuel_trim_bank1
  • long_term_fuel_trim_bank1
  • long_term_fuel_trim_bank2
  • fuel_pressure
  • intake_manifold_pressure
  • engine_rpm
  • vehicle_speed
  • timing_advance
  • maf_air_flow_rate
  • throttle_position
  • runtime_since_engine_start
AFR and Intake Temps are the two I really want.


Still lots of work to turn all of this into something reliable and useable, but so far its a case of getting the time to do it. No blockers found so far.
 
1 - 20 of 42 Posts
Top