RomRaider

Talking to Dale today I found out there's no provision for alternate scaling units in the EcuFlash definition spec. I've quickly whipped up a model to discuss.

The current definitions could stay intact with no changes. A new scaling.xml would be created for converting between units, and wouldn't look at the actual data from the ecu at all. In my example below, manifold pressure would first be converted to bar as in the ecu def. Then, before displaying to the user, converted from bar to psi (if they've selected "standard" measurements in user settings):



That could sit in the in the definition as it does today. Then we add a new scaling.xml that has something like this:



In this case:
- the variable name will be changed from AtmosphericPressure(bar) to just Atmospheric Pressure
- 2 scaling types exist for any table listing AtmosphericPressure(bar) as their scaling type
- alt scaling types are metric (units: bar) and standard (units: psi)
- as stated, the altscaling type is converting from the previously scaled value, NOT byte value

This will allow one set of conversions to be applied to every ecu type, not just similar types. It'll make the code a bit tougher up front but it's manageable, doesn't break compatibility with EcuFlash, maintaining the ecu defs should be a lot easier, and the conversions will apply to the logger as well.. To be clear, these conversions are basically only happen superficially.

Now, improve my xml. It might be better to add both scaling types as altscaling elements, for clarity..?



Edit: I think I like this 2nd way better. Makes the original a lot less ambiguous.

I like this idea... no more swapping files to change units. Then the table windows could have a Units menu.

Consider removing "(bar)" from the name of the scaling in the definition XML, and add a units="bar" attribute instead. That could be used to look up alternate units from a list of conversions, like:

<conversions>
<conversion from="bar" to="psi" expression="x*14.7"/>
...etc...
</conversion>

This looks much better but requires old definition files to be recompiled.

I like the second version and if we keep the scales in a separate XML then we can override the values defined in an EcuFlash style def without breaking them for EcuFlash.

Not to be to picky but the pressure in the 32bit ECU is in mmHg (or Torr).

From the logger.xml def:
And I think the storagetype in this example should be removed from this scale as it's not important when converting once loaded into the java table.

U Sure?
Glad my diesel uses SI units internally.
Everything kPa, MPa, °C, K, kg, g, kg/h, kph etc.
Isn't SSM supposed to be valid for all models and therefore petrol SSM original output should be SI, too?

I am to confirm that the first Subaru JDM 32 bit ecu definitely uses mmHg float digits for atmospheric pressure.

SSM itself returns row 8 or 16 bit data and there is nothing SI specific. SI/Standard metrics is used later for data interpretation by diagnostic tools.

The last means that it does not matter what scaling (if ever) is used for internal logger\tuning data transfer\storage\presentation.
And the logger\tuner tool may just save SSM or internal ecu data format that will be interpreted later in user specified metrics.

Well no, to be fair, since just recently we had never seen a diesel ROM before. And I noted that the MAF scaling in it is in kg/hour rather than the petro g/sec.
So you maybe correct in that multiple units are used. For sure the temperatures are Celsius and speed is kph. I don't think that SI units are adhered to strictly as pressure would then be in pascal (Pa).
But as noted, as long as the logger/editor software respects the ECU's base units, the displayed values to the user can be anything they wish upon correct conversion.

Ok, internal ROM/RAM units may differ but SSM output can't just be raw - you gotta know what it means otherwise one couldn't convert it to anything. I wasn't aware SSM output units depend on market!?
Now if I were to query SSM2 byte @ 0x00000D (Manifold Absolute Pressure) for ex., what unit would I get on a USDM petrol car?
On all EDM diesels I've seen it means kPa.

SSM output is RAW data.
And should be converted to user-applicable data - SI, Standard, IndustryStandard, etc.
Much of them has the same value/conversion rules as OBDII requests.

As far as MAP readings are concerned they are returned as 8 bit unsigned integer 1 kPa per unit. This is the same SSM parameter for diesel\petrol ecu's.

Many other are not SI\Standard unit related - 16 unsigned int for EngineSpeed is returned in 1\4 RevPerMinite units, FuelCorrections as (128+100X(%))/128 8 bit integer and so on.

And there is no reason to convert RAW SSM data for storage. Anyway it should be (re)converted later for interpretation\visualization according to user preference.

OK so back on topic, we were discussing how to handle representing the table data from the ROM when displayed to the user in the Editor.

Did we come to a consensus of how to handle user defined presentation?

Not really. Here's the latest:


This doesn't address what we're converting from, how to convert back (back in the day I worked for a long time to figure out a way around this with no luck. Apparently Colby couldn't figure it out either, hence toexpr and frexpr in the defs), and has a storagetype attribute we don't need since we're just converting from whatever unit the metadata defines. My revision:

If we don't refactor current ecu definitions:


If we do:


Functionally identical but the 2nd example involves reworking ecu defs to be less ambiguous.

This may be a topic for a different discussion, but the reason there ended up being identical scaling elements of identical type (with different conversion expressions) in the current ecu defs I think was an oversight. Rather than 16BITBASE.xml having AtmosphericPressure(bar) and AtmosphericPressure(bar)1 etc, my original intention was to create an intermediate definition. So, for example:

16BITBASE.xml:


Then all ecu types that use that conversion would include 16BITBASE. For those that don't would include:

16BITBASETYPE2.xml

Yes I think to need to have a from and to for each conversion type and keep track of which is in use so you can convert to the next selected type.
So, for that we need (for example pressure):

• conversion from the ECU data stored to user selected type
• psi to Pa
• psi to bar
• bar to Pa
• bar to psi
• Pa to bar
• Pa to psi

Does that make sense?

Check here for what I tried to do in the Dyno tab.

Can we call it "Imperial" and not "Standard"?

I'd like the ability to change some units independent of others. Give the user a preferences page that lists types with multiple choice units per type. IIRC this is how Hondata did things.


example:
Pressure (PSI)(Pa)(bar)(Kg/mm)(Sensor Volts)
Fuel Mixture (AFR)(Lamda)(FAR)
Speed (KPH)(MPH)
Mass Airflow (g/sec)(Kg/Hr)(Sensor Volts)
Temperature (DegC)(DegF)(K)

Perhaps one of the choices could be a user defined conversion formula from the base units.

Each table should then display the active units.

Just don't use "Standard" as a label for a collection of units.

Agreed. Imperial instead of standard. And yes, I definitely agree it would be best to be able to choose per scaling type in addition to a "default" system.

Is there any benefit to choosing per table? ie, I want to see psi in the target boost table, but kPa in ... uh, some other table. I don't see much value in it and don't particularly want to code for it, but I thought I'd throw it out there. If there's enough demand I can do it.

Yes per table.
Note the Logger let's you change type per item when logging.