It can. It's a raw reading, and is useless in the real world, without interpolation.

Can one of you EEs explain to me why Torque calls these channels PIDs? Does it stand for something other than Proportional Integral Derivative? I keep seeing people use PID for things other than feedback loops and I'm not sure where it's coming from.

Jake

Sorry if this is a thread jack but this is the only active thread on AIM that I see on the forum. Just installed my MXS and when I connect the USB cable to my Surface 3 nothing happens in Race Studio 3 - says no device detected. Is there something special I need to do?

*EDIT* Manually installed the USB drivers from the AIM folder and re-connected all plugs - it now works!

Anyone find a way to display the following:
- Display AFR as a calculation of LAMBDA?
- Use a warning light when a DTC has triggered?
- Display boost as a differential between barometric pressure and MAP?

Regarding the math channels, I'd reach out to Aim tech support directly. It's theoretically possible, but when I tried to have our MXL2 do some onboard corrections for the IR temp sensors, I discovered a bug in the math channels. Linear corrections were spitting out random gibberish, and they were able to reproduce it.

DTCs would require more CAN integration, and that's something that's going to have to come directly from Aim. Lots of people have been asking for it, so I'm sure it's on their radar. I imagine it's a tough nut to crack, so it's going to take a while to make sure it's complete and something they can sell as a product.

Are you saying that the readings fed over the OBD2 Canbus for oil temp, water temp and intake air temp are not accurate and need to have a "correcting factor" applied to them?


If so, how is the correcting factor determined?

Sorry to necro an old thread, but it's one of the top results when searchig for the fuel level PID for our cars, and now that I found more data I realized the thread is misleading.

I logged the standard OBD PID for the fuel level and the custom OBD PID 0x2129 during the recent track day at Buttonwillow.

It very much looks like 0x2129 is interpolated.
In fact, having looked at my data over a few track sessions, I haven't found any issues with that data. Basically the fuel level is just constant when I'm parked, drops fairly linearly over time when I'm on the track, and stays constant after as I come back to the paddock and do my cool down.

Having that evidence, I feel like the 0x2129 can be very much trusted at the track.
I wouldn't rely on it being precise up to +-1 liter, so don't try using it to estimate how many miles you have till the next gas station... but it looks more than good enough to estimate the average fuel burndown rate.

Here's how the data looks like.
Yellow — standard PID, green — 0x2129, cyan line — lat G's.

https://i.imgur.com/FBrRzI6.png

https://i.imgur.com/mxo9h2p.png

https://i.imgur.com/DRG2GV6.png

Well, that is a nice find, it gives me some hope that I can run a Haltech IC7 and have a working fuel level.

The stock cluster has some kind of formula involving the level sensor and amount of fuel injected to derive a displayed value, if fuel injected amount is not supplied then the car will be bone dry at an apparent 1/3rd tank on the cluster. This applies to Gen 1, I know nothing about Gen 2.

You can do two things. stick the OEM cluster in the back or something and then hace the IC7 mounted infront of it. Or two, you can hook up the fuel level sensor directly to the IC7. But it wont be as fancy to give you a accurate reading like the OEM. Yeah OEM use both fuel injection timing and a average of the level sensor to determine the real level. without the injection Pulse with the oem cluster would have a funky operation that at 1/4th tank the gas would be actually empty. But this isnt a issue if you hook up the IC7 directly to the sensor. As long as it had a good algorithm for averaging the sensor input reading.