Magneti Marelli L8/P8 datastream decoding
#1
15000
Thread Starter
Magneti Marelli L8/P8 datastream decoding
Quick summary of where I'm at:
So far I've got the basic pectel serial datastream working - I can connect to the ECU, ask for several types of sensor, and get the raw byte values back. I have found though, that the serial baud rate is extremely low, so the amount of samples we can get per second from the ecu is really limited. I'm calculating around 60-65 samples/sec, best case scenario, when we only get single-byte sensor readings (most are single bytes, but rpm and injector duration are 16bit, so need two reads and take up almost twice the amount of time).
I've gotten this far with a serial port monitor and a copy of the Fiat P8 documentation from the author of the Fiat Coupe serial datastream monitor (same P8 ecu hardware as the Escort Cosworth)
The Fiat docs that list the control codes for the various sensors are all wrong (fortunately I've got all the main ones for the L8 worked out now) and the Fiat/Lancia formula for translating the raw data into real world values is a 50/50 mix of correct/incorrect.
Here's a basic version of the sensor reading code from today:
For example, the formula for converting TPS, battery voltage and injector duration is the same on Fiat/Lancia and Cossie, but temperature, MAP and others are completely wrong.
The other things I'm missing are any way to decipher the two status codes that are returned from the ECU to indicate faults, and to detect Lambda sensor status or open/closed loop mode. In the IAW logger I've not seen any way to see what my O2 sensor is up to.
Does anyone have any information on how the data in the Cossie version of the L8/P8 ecu get translated to real world numbers?
I'm more than happy to share everything that I've found so far; it is all publicly available on Github: https://github.com/megatron-uk/PyCosworth
My ultimate aim is a dash mounted realtime display - rpm, boost, tps, temperature... and, I hope, gear position sensor (if I can fabricate one), not just in a numeric form, but in various visualisations, with peak indicators, etc. Here's a really early example of what it will look like:
I've reached out to RP Labs to see if they can supply a copy of the translation formulae, but was wondering if anyone else had any more data to share?
- mk1 Escort with full Cosworth conversion (4x4 motor, L8, uprated T3, greens, etc)
- Pretty much complete, waiting for MOT for road use
- MSD 320bhp chip, wasted spark, closed loop
- IAW software from RP Labs - works great, picked up several faults and let me correct them
- I now want to build a digital dashboard and datalogger - NOT using a laptop
So far I've got the basic pectel serial datastream working - I can connect to the ECU, ask for several types of sensor, and get the raw byte values back. I have found though, that the serial baud rate is extremely low, so the amount of samples we can get per second from the ecu is really limited. I'm calculating around 60-65 samples/sec, best case scenario, when we only get single-byte sensor readings (most are single bytes, but rpm and injector duration are 16bit, so need two reads and take up almost twice the amount of time).
I've gotten this far with a serial port monitor and a copy of the Fiat P8 documentation from the author of the Fiat Coupe serial datastream monitor (same P8 ecu hardware as the Escort Cosworth)
The Fiat docs that list the control codes for the various sensors are all wrong (fortunately I've got all the main ones for the L8 worked out now) and the Fiat/Lancia formula for translating the raw data into real world values is a 50/50 mix of correct/incorrect.
Here's a basic version of the sensor reading code from today:
For example, the formula for converting TPS, battery voltage and injector duration is the same on Fiat/Lancia and Cossie, but temperature, MAP and others are completely wrong.
The other things I'm missing are any way to decipher the two status codes that are returned from the ECU to indicate faults, and to detect Lambda sensor status or open/closed loop mode. In the IAW logger I've not seen any way to see what my O2 sensor is up to.
Does anyone have any information on how the data in the Cossie version of the L8/P8 ecu get translated to real world numbers?
I'm more than happy to share everything that I've found so far; it is all publicly available on Github: https://github.com/megatron-uk/PyCosworth
My ultimate aim is a dash mounted realtime display - rpm, boost, tps, temperature... and, I hope, gear position sensor (if I can fabricate one), not just in a numeric form, but in various visualisations, with peak indicators, etc. Here's a really early example of what it will look like:
I've reached out to RP Labs to see if they can supply a copy of the translation formulae, but was wondering if anyone else had any more data to share?
#2
15000
Thread Starter
I have all of the 'normal' sensor points decoded, thanks to RP Lab who provided the Pectel calculations to get the real world numbers, compare to the Fiat calculations which gave me completely bonkers numbers (the 16000rpm in the original video, for example!).
Have the main control screen pretty much complete now:
... and here's a demo of the data logging function in action:
Still would like to get information on decoding the two status bytes that are sent from the ECU which indicate sensor errors and faults, as well as any Lambda (and current fuelling mode data) sensor readings, if at all possible. It's possible by reading live memory of the running ECU, but I've no information on how to do that, and it's taking the project in a different direction than I wanted to go (not interesting in live tuning or anything like that).
Plenty of readers of this thread, no-one has any more information to contribute?
Have the main control screen pretty much complete now:
... and here's a demo of the data logging function in action:
Still would like to get information on decoding the two status bytes that are sent from the ECU which indicate sensor errors and faults, as well as any Lambda (and current fuelling mode data) sensor readings, if at all possible. It's possible by reading live memory of the running ECU, but I've no information on how to do that, and it's taking the project in a different direction than I wanted to go (not interesting in live tuning or anything like that).
Plenty of readers of this thread, no-one has any more information to contribute?
#5
15000
Thread Starter
I think almost all of the sensor data is now being decoded properly. At the very least I see sensible values for them
Here's a session from today with my mk1 Escort running - showing the real time visualisation features - I activate logging at the start and then load up the csv file in a spreadsheet at the end. Code is running on my laptop here, but the exact same codebase runs on the Pi and uses the miniature LCD screens, I just emulate them here on the laptop:
Some observations:
Yes, my engine needs a damn good tune. The idle is still not quite right.
My TPS reading jumps about from time to time. I've read other people sometimes have problems with these, so it could be that I need to replace it.
MAP sensor readings don't correspond to my Stack electronic gauges. So that needs chasing up.
Refresh rate could do with being improved - it's ok for most slower changing sensors, but TPS and RPS show the limitation of the current screen speed. I'll need to decrease the sleep time between each image frame being generated.
Here's a session from today with my mk1 Escort running - showing the real time visualisation features - I activate logging at the start and then load up the csv file in a spreadsheet at the end. Code is running on my laptop here, but the exact same codebase runs on the Pi and uses the miniature LCD screens, I just emulate them here on the laptop:
Some observations:
Yes, my engine needs a damn good tune. The idle is still not quite right.
My TPS reading jumps about from time to time. I've read other people sometimes have problems with these, so it could be that I need to replace it.
MAP sensor readings don't correspond to my Stack electronic gauges. So that needs chasing up.
Refresh rate could do with being improved - it's ok for most slower changing sensors, but TPS and RPS show the limitation of the current screen speed. I'll need to decrease the sleep time between each image frame being generated.
Last edited by megatron-uk; 11-02-2018 at 03:44 PM.
Thread
Thread Starter
Forum
Replies
Last Post
nickrp
Technical help Q & A
5
10-03-2014 10:39 AM
Ollie MK5 Turbo
Ford RS Cosworth Parts for Sale
1
18-10-2010 01:17 PM
Slackbladder
General Car Related Discussion.
4
15-07-2009 11:10 AM