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. :-)