<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Preference here is for option #1. Keep it simple and standard.
Elegance is costing us RAM and CPU cycles, and neither appear to be
plentiful, in spite of the vastly improved platform.<br>
<br>
Greg<br>
<br>
<br>
<div class="moz-cite-prefix">Mark Webb-Johnson wrote:<br>
</div>
<blockquote type="cite"
cite="mid:D56A7A4B-18A7-4D1C-9B5C-3979FEC1D35C@webb-johnson.net">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
To put in code the two alternative approaches being considered:
<div class=""><br class="">
</div>
<blockquote style="margin: 0 0 0 40px; border: none; padding:
0px;" class="">
<div class="">enum</div>
<div class="">{</div>
<div class="">other,</div>
<div class="">kilometers,</div>
<div class="">miles,</div>
<div class="">celcius,</div>
<div class="">fahrenheit,</div>
<div class="">kpa,</div>
<div class="">psi,</div>
<div class="">percentage</div>
<div class="">} unit_t;</div>
</blockquote>
<br class="">
<div class="">
<ol class="MailOutline">
<li class="">Everything metric<br class="">
<br class="">
OvmsMetric:<br class="">
unit_t m_unit;<br class="">
unit_t GetUnit();<br class="">
std::string AsStringConverted(unit_t conversion);<br
class="">
<br class="">
</li>
<li class="">Unit with the metric<br class="">
<br class="">
OvmsMetric:<br class="">
unit_t m_unit;<br class="">
unit_t GetUnit();<br class="">
std::string AsStringConverted(unit_t conversion);<br
class="">
void SetValue(std::string value, unit_t unit);<br class="">
etc</li>
</ol>
</div>
<div class=""><br class="">
</div>
<div class="">The difference is that with [1] m_unit is always the
metric unit, and with [2] m_unit is the unit set when the value
is stored. With [1], the vehicle module will perform any
incoming conversion to metric, while with [2], the vehicle just
stores the value and unit together (with conversion being
performed, if necessary, on retrieval).</div>
<div class=""><br class="">
</div>
<div class="">The first is simpler, but does suffer from the
double conversion issue in some cases. The second avoids that,
at the expense of complexity.</div>
<div class=""><br class="">
</div>
<div class="">How we present this to apps is really irrelevant (or
the decision at least can be put off to later as that is a v3
protocol decision). For v2 protocol, we have to present as per
the v2 protocol specification.</div>
<div class=""><br class="">
</div>
<div class="">On review, I think my personal preference is really
for [2]. I understand it is more complex, but it is quite
elegant. Conversions are only done when absolutely necessary.
Let’s look at an extreme example of a vehicle producing miles
data, and an app requesting miles. With [1], the vehicle would
convert miles->km and store in the metric, then
ovms_server_v2 would convert km->miles and send it out. With
[2], the vehicles stores the (value,”miles”) in the metric, and
ovms_server_v2 reads value back out (using “miles” as a selector
for the value). If a user sets his units to “km”, and does a
“metric list”, with [2], the metric itself converts miles->km
for the display. So, [2] does complicate it, but all that
complication is hidden in the standardised metric system.</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.</div>
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 26 Oct 2017, at 9:51 AM, Mark Webb-Johnson
<<a href="mailto:mark@webb-johnson.net" class=""
moz-do-not-send="true">mark@webb-johnson.net</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8" class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode:
space; -webkit-line-break: after-white-space;" class="">
<div class="">I did a quick review of the way things
were done in OVMS v2. Some notes:</div>
<div class=""><br class="">
</div>
<div class="">The OVMS v2 protocol specified:</div>
<div class=""><br class="">
</div>
<div class="">
<ul class="MailOutline">
<li class="">Car Environment message 0x44 “D"<br
class="">
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>•
Temperature of the PEM (celcius)</div>
<div class="">
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>•
Temperature of the Motor (celcius)</div>
</div>
<div class="">
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>•
Temperature of the Battery (celcius)</div>
</div>
<div class="">
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>•
Car trip meter (in 1/10th of a distance unit)</div>
</div>
<div class="">
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>•
Car odometer (in 1/10th of a distance unit)</div>
</div>
<div class="">
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>•
Car speed (in distance units per hour)</div>
</div>
<div class="">
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>•
Ambient Temperature (in Celcius)</div>
</div>
</li>
<li class="">Car state message 0x53 “S”<br class="">
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>•
Units ("M" for miles, "K" for kilometers)<br
class="">
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>•
Ideal range<br class="">
<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>•
Estimated range</div>
</div>
</div>
</li>
<li class="">Registered parameter #2<br class="">
<span class="Apple-tab-span" style="white-space: pre;"> </span>•
Miles / Kilometer flag</li>
</ul>
</div>
<div class=""><br class="">
</div>
<div class="">The OVMS v2 net_msg code did some
conversions:</div>
<div class=""><br class="">
</div>
<div class="">
<ul class="MailOutline">
<li class="">car_tpem is always stored in Celcius,
and always sent as such</li>
<li class="">car_tmotor is always stored in Celcius,
and always sent as such</li>
<li class="">car_tbattery is always stored in
Celcius, and always sent as such</li>
<li class="">car_trip is stored in Miles, so a
KmFromMi() conversion is done if units were “K”</li>
<li class="">car_odometer is stored in Miles, so a
KmFromMi() conversion is done if units were “K”</li>
<li class="">car_speed is stored in user unit, and
sent as such</li>
<li class="">car_ambient_temp is always stored in
Celcius, and always sent as such</li>
<li class="">Units is stored as a parameter, and
sent as such</li>
<li class="">car_idealrange is stored in Miles, so a
KmFromMi() conversion is done if units were “K”</li>
<li class="">car_estrange is stored in Miles, so a
KmFromMi() conversion is done if units were “K”</li>
<li class="">tpms is stored in raw (Tesla) format,
and sent as PSI and Celcius</li>
</ul>
</div>
<div class=""><br class="">
</div>
<div class="">I did some quick checks against the OVMS
v2 vehicle_*.c code. Here are some notes:</div>
<div class=""><br class="">
</div>
<div class="">
<ul class="MailOutline">
<li class="">Kia Soul: Seems to have distances in
metric, and uses MiFromKm() when storing to car_*.
Temperatures in celcius, so no conversion
necessary.</li>
<li class="">Mitsubishi iMiev: MiFromKm() for
distances. Temperatures in celcius, so no
conversion necessary.</li>
<li class="">Tesla Roadster: Miles for distances,
Celcius for temperatures, so no conversions
necessary (surprise, surprise, as OVMS v2 car
model based on this car).</li>
<li class="">Nissan Leaf: MiFromKm() for
distances. Temperatures in celcius, so no
conversion necessary.</li>
<li class="">Twizy: MiFromKm() for
distances. Temperatures in celcius, so no
conversion necessary.</li>
<li class="">Renault Zoe: MiFromKm() for
distances. Seemingly no temperature support.</li>
</ul>
</div>
<div class=""><br class="">
</div>
<div class="">I then looked at the OBDII standard. Here
are the notes from that:</div>
<div class=""><br class="">
</div>
<div class="">
<ul class="MailOutline">
<li class="">Temperatures are stored and transmitted
in Celcius</li>
<li class="">Pressures are stored and transmitted in
Pa / kPa</li>
<li class="">Distances are stored and transmitted in
Km</li>
<li class="">Time is stored and transmitted in
Seconds</li>
</ul>
</div>
<div class=""><br class="">
</div>
<div class="">I looked at the Apps.</div>
<div class=""><br class="">
</div>
<div class="">
<ul class="MailOutline">
<li class="">Configurable for temperatures: car
chooses / celcius / fahrenheit</li>
<li class="">Configurable for distances: car chooses
/ miles / kilometers</li>
<li class="">No configuration for pressures</li>
</ul>
</div>
<div class=""><br class="">
</div>
<div class="">Overall, I would conclude:</div>
<div class=""><br class="">
</div>
<div class="">
<ul class="MailOutline">
<li class="">The OVMS v2 protocol is kind of messy,
not symmetric. It does conversions in some place,
but in others leaves it up to the App.</li>
<li class="">It seems that almost all the vehicles
use metric units</li>
<li class="">OBDII uses metric units</li>
<li class="">We need to maintain compatibility with
OVMS v2 protocol, but can do things differently
for v3 protocol</li>
</ul>
</div>
<div class=""><br class="">
</div>
<div class="">I suggest the following:</div>
<div class=""><br class="">
</div>
<div class="">
<ol class="MailOutline">
<li class="">The Metrics use metric units for their
internal storage (sic).</li>
<li class="">We add units labels to the metrics.
This can be used (a) as a nice display (SOC: 10%
vs 10), and (b) as the basis for conversion
support at the metric level.</li>
<li class="">We add units parameters to the
configuration storage (for pressure, temperature,
distance).</li>
<li class="">We make the ovms_server_v2 convert to
the v2 protocol standard</li>
</ol>
</div>
<div class=""><br class="">
</div>
<div class="">Doing it that way means that most vehicles
will store in their native format (metric) - only
Tesla Roadster will incur a Miles->KM->Miles
penalty. Using ‘float’ to some extent mitigates this.</div>
<div class=""><br class="">
</div>
<div class="">The alternative (storing the unit with the
metric, and having it passes whenever we set/read the
metric) is much more complex and seemingly only
required for one particular vehicle (ignoring the
temporary issue of v2 protocol, until we roll out v3
protocol and apps).</div>
<div class=""><br class="">
</div>
<div class="">I do think that whatever we decide, it
needs to be decided now. We are converting the vehicle
modules over, and doing this now is much simpler than
trying to re-work it later.</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.</div>
<div class=""><br class="">
</div>
<blockquote type="cite" class=""><span
style="font-family: Menlo-Regular; font-size: 14px;"
class="">Really not a fan of this, as the app may
not even know what kind of</span><br
style="font-family: Menlo-Regular; font-size: 14px;"
class="">
<span style="font-family: Menlo-Regular; font-size:
14px;" class="">vehicle is being used (an attached
HUD, for example). If there's a</span><br
style="font-family: Menlo-Regular; font-size: 14px;"
class="">
<span style="font-family: Menlo-Regular; font-size:
14px;" class="">function in the metric object that
does the conversion to make it</span><br
style="font-family: Menlo-Regular; font-size: 14px;"
class="">
<span style="font-family: Menlo-Regular; font-size:
14px;" class="">transparent, I suppose that could
work. But I'd really prefer to have</span><br
style="font-family: Menlo-Regular; font-size: 14px;"
class="">
<span style="font-family: Menlo-Regular; font-size:
14px;" class="">at least the standard metrics table
be vehicle-independent, and in</span><br
style="font-family: Menlo-Regular; font-size: 14px;"
class="">
<span style="font-family: Menlo-Regular; font-size:
14px;" class="">standard units. The OBDII spec
assumes this, and the devices all have</span><br
style="font-family: Menlo-Regular; font-size: 14px;"
class="">
<span style="font-family: Menlo-Regular; font-size:
14px;" class="">Metric / Imperial mode switches
included. For common items that may be</span><br
style="font-family: Menlo-Regular; font-size: 14px;"
class="">
<span style="font-family: Menlo-Regular; font-size:
14px;" class="">missing from a particular vehicle
(e.g. motor RPM on the Roadster), the</span><br
style="font-family: Menlo-Regular; font-size: 14px;"
class="">
<span style="font-family: Menlo-Regular; font-size:
14px;" class="">vehicle code that populates the
metrics table should derive them from</span><br
style="font-family: Menlo-Regular; font-size: 14px;"
class="">
<span style="font-family: Menlo-Regular; font-size:
14px;" class="">what is available. For the Roadster
example, motor RPM is basically</span><br
style="font-family: Menlo-Regular; font-size: 14px;"
class="">
<span style="font-family: Menlo-Regular; font-size:
14px;" class="">vehicle speed times 70, so when
receiving a speed CAN frame, both the</span><br
style="font-family: Menlo-Regular; font-size: 14px;"
class="">
<span style="font-family: Menlo-Regular; font-size:
14px;" class="">v.p.speed and v.p.rpm (new metric,
please?) would be updated.</span><br
style="font-family: Menlo-Regular; font-size: 14px;"
class="">
<br style="font-family: Menlo-Regular; font-size:
14px;" class="">
<span style="font-family: Menlo-Regular; font-size:
14px;" class="">If there are metrics that don't
apply to multiple vehicles, and don't</span><br
style="font-family: Menlo-Regular; font-size: 14px;"
class="">
<span style="font-family: Menlo-Regular; font-size:
14px;" class="">fit into the standard ones, they can
certainly be in vehicle-specific</span><br
style="font-family: Menlo-Regular; font-size: 14px;"
class="">
<span style="font-family: Menlo-Regular; font-size:
14px;" class="">units. Best to have a separate
table for them, I think, with the items</span><br
style="font-family: Menlo-Regular; font-size: 14px;"
class="">
<span style="font-family: Menlo-Regular; font-size:
14px;" class="">prefaced by the 2-letter vehicle
name. I can certainly deal with having</span><br
style="font-family: Menlo-Regular; font-size: 14px;"
class="">
<span style="font-family: Menlo-Regular; font-size:
14px;" class="">a table name as part of the PID
remapping scheme. But, please, not on a</span><br
style="font-family: Menlo-Regular; font-size: 14px;"
class="">
<span style="font-family: Menlo-Regular; font-size:
14px;" class="">per metric basis.</span><br
style="font-family: Menlo-Regular; font-size: 14px;"
class="">
<br style="font-family: Menlo-Regular; font-size:
14px;" class="">
<span style="font-family: Menlo-Regular; font-size:
14px;" class="">The vehicle-specific use can also be
aided by scripting some of the</span><br
style="font-family: Menlo-Regular; font-size: 14px;"
class="">
<span style="font-family: Menlo-Regular; font-size:
14px;" class="">conversion. Still working on how
that can be done. But again, we</span><br
style="font-family: Menlo-Regular; font-size: 14px;"
class="">
<span style="font-family: Menlo-Regular; font-size:
14px;" class="">shouldn't need to load in a whole
library of vehicle-specific scripts</span><br
style="font-family: Menlo-Regular; font-size: 14px;"
class="">
<span style="font-family: Menlo-Regular; font-size:
14px;" class="">just to handle the common parameters
(speed, SoC, etc.).</span><br style="font-family:
Menlo-Regular; font-size: 14px;" class="">
<br style="font-family: Menlo-Regular; font-size:
14px;" class="">
<span style="font-family: Menlo-Regular; font-size:
14px;" class="">My $.02,</span><br
style="font-family: Menlo-Regular; font-size: 14px;"
class="">
<br style="font-family: Menlo-Regular; font-size:
14px;" class="">
<span style="font-family: Menlo-Regular; font-size:
14px;" class="">Greg</span></blockquote>
<div class=""><font class="" face="Menlo-Regular"><span
style="font-size: 14px;" class=""><br class="">
</span></font>
<div class="">
<blockquote type="cite" class="">
<div class="">On 25 Oct 2017, at 12:26 PM, HONDA
S-2000 <<a
href="mailto:s2000@audiobanshee.com" class=""
moz-do-not-send="true">s2000@audiobanshee.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">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. :-)<br
class="">
<br class="">
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.<br class="">
<br class="">
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.<br class="">
<br class="">
Sorry to throw a jumbled set of ideas at the
problem, but I wanted to share my thoughts.<br
class="">
<br class="">
Brian<br class="">
<br class="">
<br class="">
On Oct 24, 2017, at 1:08 PM, Michael Balzer
<<a href="mailto:dexter@expeedo.de"
class="" moz-do-not-send="true">dexter@expeedo.de</a>>
wrote:<br class="">
<blockquote type="cite" class="">I've done the
int to float changes and the temperature
naming.<br class="">
<br class="">
Not sure about the best way to solve the
units problem yet, but I guess<br class="">
we can start with storing in vehicle units
and add the conversion later on.<br class="">
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
Am 24.10.2017 um 04:46 schrieb Mark
Webb-Johnson:<br class="">
<blockquote type="cite" class="">Tough
questions. Answers/comments inline.<br
class="">
<br class="">
<blockquote type="cite" class="">On 23 Oct
2017, at 9:33 PM, Michael Balzer <<a
href="mailto:dexter@expeedo.de"
class="" moz-do-not-send="true">dexter@expeedo.de</a>>
wrote:<br class="">
<br class="">
Trying to catch up…<br class="">
<br class="">
<br class="">
a) I'd love to get rid of those
km→miles→km conversions in V3.<br
class="">
<br class="">
How about introducing a metric "v.units"
instead to hold the units used<br
class="">
by the vehicle, and make conversions at
the user level if necessary?<br class="">
</blockquote>
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.<br
class="">
<br class="">
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.<br
class="">
<br class="">
In general, having this done in the module
seems to make more sense than doing it in
the apps.<br class="">
<br class="">
<blockquote type="cite" class="">b)
Regarding the standard metrics currently
defined, I'd need to<br class="">
introduce own copies again for higher
precision. I.e. SOC, SOH, speed<br
class="">
and ranges all are integers now, and
some more I'd like to be able to<br
class="">
set at higher precision.<br class="">
<br class="">
How about making all these be floats
now? I.e. everything that can<br
class="">
require more than integer precision.<br
class="">
<br class="">
The server_v2 can output the values as
integers for v2 client compatibility.<br
class="">
</blockquote>
OK.<br class="">
<br class="">
<blockquote type="cite" class="">c) I
haven't seen a recommendation on naming
vehicle specific metrics.<br class="">
My proposal: use the vehicle code as the
prefix, then try to reuse<br class="">
similar paths from the standard metrics,
adding detail as necessary.<br class="">
<br class="">
For example, the vehicle module version
on the Twizy ("RT") is<br class="">
"rt.m.version", and for the min &
max battery voltage I've got<br class="">
"rt.v.b.voltage.min" &
"rt.v.b.voltage.max".<br class="">
<br class="">
OVMS > metrics list rt.<br class="">
rt.m.version 1.0.0 Oct
23 2017 11:45:31<br class="">
rt.v.b.soc <br
class="">
rt.v.b.temp.m1 <br
class="">
rt.v.b.temp.m2 <br
class="">
rt.v.b.temp.m3 <br
class="">
rt.v.b.temp.m4 <br
class="">
rt.v.b.temp.m5 <br
class="">
rt.v.b.temp.m6 <br
class="">
rt.v.b.temp.m7 <br
class="">
rt.v.b.voltage.max 0<br
class="">
rt.v.b.voltage.min 0<br
class="">
<br class="">
That way a path component can be used to
list all related metrics:<br class="">
<br class="">
OVMS > metrics list b.voltage<br
class="">
rt.v.b.voltage.max 0<br
class="">
rt.v.b.voltage.min 0<br
class="">
v.b.voltage <br
class="">
</blockquote>
Ok, but I would suggest an ‘x.’ prefix
(seems to match many Internet standards,
such as X- headers, etc).<br class="">
<br class="">
So: x.rt.v.b.voltage.max, etc.<br class="">
<br class="">
<blockquote type="cite" class="">d) I
think most of the temperature metrics
have wrong names:<br class="">
<br class="">
v.b.temp.ambient <br
class="">
v.b.temp.battery <br
class="">
v.b.temp.charger <br
class="">
v.b.temp.motor <br
class="">
v.b.temp.pem <br
class="">
<br class="">
…as "b." should be reserved for
"battery".<br class="">
<br class="">
How about…<br class="">
<br class="">
v.e.temp<br class="">
v.b.temp<br class="">
v.c.temp<br class="">
v.m.temp<br class="">
v.i.temp<br class="">
<br class="">
…introducing "m." for motor and "i." for
inverter?<br class="">
</blockquote>
OK.<br class="">
<br class="">
<blockquote type="cite" class="">Regards,<br
class="">
Michael<br class="">
</blockquote>
</blockquote>
</blockquote>
<br class="">
_______________________________________________<br class="">
OvmsDev mailing list<br class="">
<a href="mailto:OvmsDev@lists.teslaclub.hk"
class="" moz-do-not-send="true">OvmsDev@lists.teslaclub.hk</a><br
class="">
<a
href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev"
class="" moz-do-not-send="true">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br
class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
</body>
</html>