[Ovmsdev] V3 distance/speed units

[HONDA S-2000]

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

Obviously, the down side is that each additional vehicle unit adds to the code in the app. My usual assumption is that there’s more room in a front end application for these sorts of things, as opposed to the embedded side. To contradict myself, though, it seems that we’re allowing for the embedded firmware to be compiled for a single vehicle, meaning that none of the code needs to carry around unused conversions.

Stepping away from my technical focus (where I might be interested in the exact vehicle units for, e.g., torque on my roadster), perhaps it would be better to design around the typical user, who will either be interested in miles or kilometers, foot-pounds or Newton-meters, and basically just English versus metric. In that case, maybe the embedded firmware could have a meta parameter to select English versus metric, and then all communications with the app would be in those units. The down side to this idea is that the embedded firmware would need to be capable of two different conversions for potentially every metric, assuming that every electric vehicle is available in multiple countries, both metric and English.

Sorry to throw a jumbled set of ideas at the problem, but I wanted to share my thoughts.

Brian


On Oct 24, 2017, at 1:08 PM, Michael Balzer <dexter at expeedo.de> wrote:
> I've done the int to float changes and the temperature naming.
> 
> Not sure about the best way to solve the units problem yet, but I guess
> we can start with storing in vehicle units and add the conversion later on.
> 
> Regards,
> Michael
> 
> Am 24.10.2017 um 04:46 schrieb Mark Webb-Johnson:
>> Tough questions. Answers/comments inline.
>> 
>>> On 23 Oct 2017, at 9:33 PM, Michael Balzer <dexter at expeedo.de> wrote:
>>> 
>>> Trying to catch up…
>>> 
>>> 
>>> a) I'd love to get rid of those km→miles→km conversions in V3.
>>> 
>>> How about introducing a metric "v.units" instead to hold the units used
>>> by the vehicle, and make conversions at the user level if necessary?
>> I don’t have a good answer for this. I thought to just store all the metrics in ‘metric’ (celcius, kilometers, etc), and let the apps deal with it (as they do now). But, as you say, that does lead to the problem of km->miles->km, etc.
>> 
>> An alternative is to store a ‘units’ with the metric, and have the metric deal with presentation conversion upon retrieval. That reduces the number of conversions.
>> 
>> In general, having this done in the module seems to make more sense than doing it in the apps.
>> 
>>> b) Regarding the standard metrics currently defined, I'd need to
>>> introduce own copies again for higher precision. I.e. SOC, SOH, speed
>>> and ranges all are integers now, and some more I'd like to be able to
>>> set at higher precision.
>>> 
>>> How about making all these be floats now? I.e. everything that can
>>> require more than integer precision.
>>> 
>>> The server_v2 can output the values as integers for v2 client compatibility.
>> OK.
>> 
>>> c) I haven't seen a recommendation on naming vehicle specific metrics.
>>> My proposal: use the vehicle code as the prefix, then try to reuse
>>> similar paths from the standard metrics, adding detail as necessary.
>>> 
>>> For example, the vehicle module version on the Twizy ("RT") is
>>> "rt.m.version", and for the min & max battery voltage I've got
>>> "rt.v.b.voltage.min" & "rt.v.b.voltage.max".
>>> 
>>> OVMS > metrics list rt.
>>> rt.m.version                   1.0.0 Oct 23 2017 11:45:31
>>> rt.v.b.soc                    
>>> rt.v.b.temp.m1                
>>> rt.v.b.temp.m2                
>>> rt.v.b.temp.m3                
>>> rt.v.b.temp.m4                
>>> rt.v.b.temp.m5                
>>> rt.v.b.temp.m6                
>>> rt.v.b.temp.m7                
>>> rt.v.b.voltage.max             0
>>> rt.v.b.voltage.min             0
>>> 
>>> That way a path component can be used to list all related metrics:
>>> 
>>> OVMS > metrics list b.voltage
>>> rt.v.b.voltage.max             0
>>> rt.v.b.voltage.min             0
>>> v.b.voltage                   
>> Ok, but I would suggest an ‘x.’ prefix (seems to match many Internet standards, such as X- headers, etc).
>> 
>> So: x.rt.v.b.voltage.max, etc.
>> 
>>> d) I think most of the temperature metrics have wrong names:
>>> 
>>> v.b.temp.ambient              
>>> v.b.temp.battery              
>>> v.b.temp.charger              
>>> v.b.temp.motor                
>>> v.b.temp.pem                  
>>> 
>>> …as "b." should be reserved for "battery".
>>> 
>>> How about…
>>> 
>>> v.e.temp
>>> v.b.temp
>>> v.c.temp
>>> v.m.temp
>>> v.i.temp
>>> 
>>> …introducing "m." for motor and "i." for inverter?
>> OK.
>> 
>>> Regards,
>>> Michael