Generic OBD2 PIDs mismatching to targetID table

General General RealDash discussion
1

Hello,

I’m trying to learn how to make custom PIDs (XML config). I’m looking into the generic OBD2 PIDs.

I cannot understand why targetIds in the generic (url) do not match to this table (url). Some of the match, some not. Is this a bug?

Example:
Vehicle Speed (64) <> 81
Fuel Level (170) <> 201

2

Another question, is it possible to use ant statistical functions in conversion attribute? Suppose I have sensor that reports fuel level. When moving, it gives wild readings, I wanted to apply a rolling average on its values. Is it possible?

3

Also, is it possible to have a button that would synchronise “calculated” fuel level with “ECU reported”?

4

All XML targetId mappings seem correct to me. There are multiple inputs for speed and fuel level to map to.

If you map your fuel level to ‘Body Electronics->Fuel Level’, RealDash has internal averaging applied.

Calculated fuel level and one received from ECU are purposefully completely separate systems. Use ‘Settings->Units & Values->Value Mapping’ to use either one.

5

Thanks for your reply.

Where can I read about your averaging function? It seems neither timed rolling average nor EWMAF (like in torque pro) do not do a good job (a good tool to analyse is here: https://www.geogebra.org/m/tb88mqrm). Do you use some sort of Kalman filter, it seems it would be logical to use it… There are a few papers related to this, e.g.: https://www.google.com/search?q=filtering+fuel+level+kalman&oq=filtering+fuel+level+kalman

I’m just thinking, wouldn’t it be more accurate if it was a hybrid approach to use both “calculated” (based on fuel flow) data and tank level sensor data. The idea is to use fuel flow with with ability to “sync” (or correct errors) from fuel tank sensor. The sync happens only once in a while, for example when engine starts (covering the case when tank is refueled). Basically in that way we can exclude noisiness of tank sensor and errors from calculations. One thing that may introduce an error is inclination of your car when you start the engine… But this could be workarounded by reading gyro sensor (and just skipping the sync if inclination angle exceeds a threshold). Or we could apply basic logic saying that like "tank level can’t go down by this much, or there was a refuel a few days ago and it is unlikely that someone adds only 3-4 littres anyway). It is just normally (I think it is a standard) all petrol station are absolutely even (no inclination), it should fairly easy to detect the fact of refueling.

Also, can you pls tell me how can I translate torque pro PID into your format? Let’s say I have (toyota fuel level sensor):
PID: 2129
Equation: ((A*50)/100)
OBD Header: 7c0

How does it get translated into your XML format? How do I know “send” attribute and where do I put the header?
Cheers.

6

Something to think about on the ecu reported fuel level. On some cars, the fuel level sender is attached to the ecu and it would be unknown if the obd output is raw level data or if it’s some sort of calculation from the level sensor. However this really wouldn’t be needed for fuel level operation. Sure there are calculations that you could used to calculate DTE, but that just seems like doing that amount of work in development and testing only gives marginal increase of accuracy. The vast majority of people are completely satisfied with the fuel level not bouncing around while driving or cornering, and are likely already accustomed to the level being off on an incline. That’s how 95%+ of cars currently act. While yes, using gyroscopes could make it MORE accurate, the though goes into if that result is worth the time and effort when the vast majority of people it’s a non issue.