[Ovmsdev] V3 distance/speed units

[Greg D.]

Really not a fan of this, as the app may not even know what kind of
vehicle is being used (an attached HUD, for example).  If there's a
function in the metric object that does the conversion to make it
transparent, I suppose that could work.  But I'd really prefer to have
at least the standard metrics table be vehicle-independent, and in
standard units.  The OBDII spec assumes this, and the devices all have
Metric / Imperial mode switches included.  For common items that may be
missing from a particular vehicle (e.g. motor RPM on the Roadster), the
vehicle code that populates the metrics table should derive them from
what is available.  For the Roadster example, motor RPM is basically
vehicle speed times 70, so when receiving a speed CAN frame, both the
v.p.speed and v.p.rpm (new metric, please?) would be updated.

If there are metrics that don't apply to multiple vehicles, and don't
fit into the standard ones, they can certainly be in vehicle-specific
units.  Best to have a separate table for them, I think, with the items
prefaced by the 2-letter vehicle name.  I can certainly deal with having
a table name as part of the PID remapping scheme.  But, please, not on a
per metric basis.

The vehicle-specific use can also be aided by scripting some of the
conversion.  Still working on how that can be done.  But again, we
shouldn't need to load in a whole library of vehicle-specific scripts
just to handle the common parameters (speed, SoC, etc.).

My $.02,

Greg



HONDA S-2000 wrote:
> I like the concept of storing vehicle units in the module and letting the app sort out the conversions. Theoretically, this allows for alternate app front ends that might do “something” with the additional information in the vehicle units that might be lost in translation (conversion). But, I am a nerd with a bias towards low-level details, and that might not be the best. :-)