V3 distance/speed units
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? 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. 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 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? Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Tough questions. Answers/comments inline.
On 23 Oct 2017, at 9:33 PM, Michael Balzer <dexter@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
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
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@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
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
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@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@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
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. :-)
I did a quick review of the way things were done in OVMS v2. Some notes: The OVMS v2 protocol specified: Car Environment message 0x44 “D" • Temperature of the PEM (celcius) • Temperature of the Motor (celcius) • Temperature of the Battery (celcius) • Car trip meter (in 1/10th of a distance unit) • Car odometer (in 1/10th of a distance unit) • Car speed (in distance units per hour) • Ambient Temperature (in Celcius) Car state message 0x53 “S” • Units ("M" for miles, "K" for kilometers) • Ideal range • Estimated range Registered parameter #2 • Miles / Kilometer flag The OVMS v2 net_msg code did some conversions: car_tpem is always stored in Celcius, and always sent as such car_tmotor is always stored in Celcius, and always sent as such car_tbattery is always stored in Celcius, and always sent as such car_trip is stored in Miles, so a KmFromMi() conversion is done if units were “K” car_odometer is stored in Miles, so a KmFromMi() conversion is done if units were “K” car_speed is stored in user unit, and sent as such car_ambient_temp is always stored in Celcius, and always sent as such Units is stored as a parameter, and sent as such car_idealrange is stored in Miles, so a KmFromMi() conversion is done if units were “K” car_estrange is stored in Miles, so a KmFromMi() conversion is done if units were “K” tpms is stored in raw (Tesla) format, and sent as PSI and Celcius I did some quick checks against the OVMS v2 vehicle_*.c code. Here are some notes: Kia Soul: Seems to have distances in metric, and uses MiFromKm() when storing to car_*. Temperatures in celcius, so no conversion necessary. Mitsubishi iMiev: MiFromKm() for distances. Temperatures in celcius, so no conversion necessary. Tesla Roadster: Miles for distances, Celcius for temperatures, so no conversions necessary (surprise, surprise, as OVMS v2 car model based on this car). Nissan Leaf: MiFromKm() for distances. Temperatures in celcius, so no conversion necessary. Twizy: MiFromKm() for distances. Temperatures in celcius, so no conversion necessary. Renault Zoe: MiFromKm() for distances. Seemingly no temperature support. I then looked at the OBDII standard. Here are the notes from that: Temperatures are stored and transmitted in Celcius Pressures are stored and transmitted in Pa / kPa Distances are stored and transmitted in Km Time is stored and transmitted in Seconds I looked at the Apps. Configurable for temperatures: car chooses / celcius / fahrenheit Configurable for distances: car chooses / miles / kilometers No configuration for pressures Overall, I would conclude: 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. It seems that almost all the vehicles use metric units OBDII uses metric units We need to maintain compatibility with OVMS v2 protocol, but can do things differently for v3 protocol I suggest the following: The Metrics use metric units for their internal storage (sic). 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. We add units parameters to the configuration storage (for pressure, temperature, distance). We make the ovms_server_v2 convert to the v2 protocol standard 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. 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). 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. Regards, Mark.
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
On 25 Oct 2017, at 12:26 PM, HONDA S-2000 <s2000@audiobanshee.com> 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. :-)
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@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@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
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
To put in code the two alternative approaches being considered: enum { other, kilometers, miles, celcius, fahrenheit, kpa, psi, percentage } unit_t; Everything metric OvmsMetric: unit_t m_unit; unit_t GetUnit(); std::string AsStringConverted(unit_t conversion); Unit with the metric OvmsMetric: unit_t m_unit; unit_t GetUnit(); std::string AsStringConverted(unit_t conversion); void SetValue(std::string value, unit_t unit); etc 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). The first is simpler, but does suffer from the double conversion issue in some cases. The second avoids that, at the expense of complexity. 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. 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. Regards, Mark.
On 26 Oct 2017, at 9:51 AM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
I did a quick review of the way things were done in OVMS v2. Some notes:
The OVMS v2 protocol specified:
Car Environment message 0x44 “D" • Temperature of the PEM (celcius) • Temperature of the Motor (celcius) • Temperature of the Battery (celcius) • Car trip meter (in 1/10th of a distance unit) • Car odometer (in 1/10th of a distance unit) • Car speed (in distance units per hour) • Ambient Temperature (in Celcius) Car state message 0x53 “S” • Units ("M" for miles, "K" for kilometers) • Ideal range • Estimated range Registered parameter #2 • Miles / Kilometer flag
The OVMS v2 net_msg code did some conversions:
car_tpem is always stored in Celcius, and always sent as such car_tmotor is always stored in Celcius, and always sent as such car_tbattery is always stored in Celcius, and always sent as such car_trip is stored in Miles, so a KmFromMi() conversion is done if units were “K” car_odometer is stored in Miles, so a KmFromMi() conversion is done if units were “K” car_speed is stored in user unit, and sent as such car_ambient_temp is always stored in Celcius, and always sent as such Units is stored as a parameter, and sent as such car_idealrange is stored in Miles, so a KmFromMi() conversion is done if units were “K” car_estrange is stored in Miles, so a KmFromMi() conversion is done if units were “K” tpms is stored in raw (Tesla) format, and sent as PSI and Celcius
I did some quick checks against the OVMS v2 vehicle_*.c code. Here are some notes:
Kia Soul: Seems to have distances in metric, and uses MiFromKm() when storing to car_*. Temperatures in celcius, so no conversion necessary. Mitsubishi iMiev: MiFromKm() for distances. Temperatures in celcius, so no conversion necessary. Tesla Roadster: Miles for distances, Celcius for temperatures, so no conversions necessary (surprise, surprise, as OVMS v2 car model based on this car). Nissan Leaf: MiFromKm() for distances. Temperatures in celcius, so no conversion necessary. Twizy: MiFromKm() for distances. Temperatures in celcius, so no conversion necessary. Renault Zoe: MiFromKm() for distances. Seemingly no temperature support.
I then looked at the OBDII standard. Here are the notes from that:
Temperatures are stored and transmitted in Celcius Pressures are stored and transmitted in Pa / kPa Distances are stored and transmitted in Km Time is stored and transmitted in Seconds
I looked at the Apps.
Configurable for temperatures: car chooses / celcius / fahrenheit Configurable for distances: car chooses / miles / kilometers No configuration for pressures
Overall, I would conclude:
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. It seems that almost all the vehicles use metric units OBDII uses metric units We need to maintain compatibility with OVMS v2 protocol, but can do things differently for v3 protocol
I suggest the following:
The Metrics use metric units for their internal storage (sic). 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. We add units parameters to the configuration storage (for pressure, temperature, distance). We make the ovms_server_v2 convert to the v2 protocol standard
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.
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).
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.
Regards, Mark.
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
On 25 Oct 2017, at 12:26 PM, HONDA S-2000 <s2000@audiobanshee.com <mailto:s2000@audiobanshee.com>> 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. :-)
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@expeedo.de <mailto:dexter@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@expeedo.de <mailto:dexter@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
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
Hi, Same for me #1, or even lighter than that :-) . Sources are mostly metric/SI (besides Tesla, which will be among the rare exceptions hardcoded to be to converted as early as possible)… The structure would be then: the value. Point … We’d know from the name what type of value it is air pressure/speed/rpm/linear distance/soc/whatever/... Showing human readable / l18n values should be kept on the presentation layer away from the OVMS (mobile app/intelligent cluster-hmi/etc… anywhere where processing power isn’t an issue), eventually through a crafted function on the OVMS that takes flash, not ram, though again, connecting to the shell is not the day-to-day usage imho. Yeah, I’m an SI-n*zi :) I might be missing something important that prevents simplifying metric storage but the lighter, the better. Julien, Who brought 10kg of electronics on vacation, OVMS included, but forgot his laptop charger :-/ On 26 Oct 2017 at 08:17 +0200, Greg D. <gregd2350@gmail.com>, wrote:
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.
Greg
Mark Webb-Johnson wrote:
To put in code the two alternative approaches being considered:
enum { other, kilometers, miles, celcius, fahrenheit, kpa, psi, percentage } unit_t;
1. Everything metric
OvmsMetric: unit_t m_unit; unit_t GetUnit(); std::string AsStringConverted(unit_t conversion);
2. Unit with the metric
OvmsMetric: unit_t m_unit; unit_t GetUnit(); std::string AsStringConverted(unit_t conversion); void SetValue(std::string value, unit_t unit); etc
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).
The first is simpler, but does suffer from the double conversion issue in some cases. The second avoids that, at the expense of complexity.
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.
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.
Regards, Mark.
On 26 Oct 2017, at 9:51 AM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
I did a quick review of the way things were done in OVMS v2. Some notes:
The OVMS v2 protocol specified:
• Car Environment message 0x44 “D" • Temperature of the PEM (celcius) • Temperature of the Motor (celcius) • Temperature of the Battery (celcius) • Car trip meter (in 1/10th of a distance unit) • Car odometer (in 1/10th of a distance unit) • Car speed (in distance units per hour) • Ambient Temperature (in Celcius) • Car state message 0x53 “S” • Units ("M" for miles, "K" for kilometers) • Ideal range • Estimated range • Registered parameter #2 • Miles / Kilometer flag
The OVMS v2 net_msg code did some conversions:
• car_tpem is always stored in Celcius, and always sent as such • car_tmotor is always stored in Celcius, and always sent as such • car_tbattery is always stored in Celcius, and always sent as such • car_trip is stored in Miles, so a KmFromMi() conversion is done if units were “K” • car_odometer is stored in Miles, so a KmFromMi() conversion is done if units were “K” • car_speed is stored in user unit, and sent as such • car_ambient_temp is always stored in Celcius, and always sent as such • Units is stored as a parameter, and sent as such • car_idealrange is stored in Miles, so a KmFromMi() conversion is done if units were “K” • car_estrange is stored in Miles, so a KmFromMi() conversion is done if units were “K” • tpms is stored in raw (Tesla) format, and sent as PSI and Celcius
I did some quick checks against the OVMS v2 vehicle_*.c code. Here are some notes:
• Kia Soul: Seems to have distances in metric, and uses MiFromKm() when storing to car_*. Temperatures in celcius, so no conversion necessary. • Mitsubishi iMiev: MiFromKm() for distances. Temperatures in celcius, so no conversion necessary. • Tesla Roadster: Miles for distances, Celcius for temperatures, so no conversions necessary (surprise, surprise, as OVMS v2 car model based on this car). • Nissan Leaf: MiFromKm() for distances. Temperatures in celcius, so no conversion necessary. • Twizy: MiFromKm() for distances. Temperatures in celcius, so no conversion necessary. • Renault Zoe: MiFromKm() for distances. Seemingly no temperature support.
I then looked at the OBDII standard. Here are the notes from that:
• Temperatures are stored and transmitted in Celcius • Pressures are stored and transmitted in Pa / kPa • Distances are stored and transmitted in Km • Time is stored and transmitted in Seconds
I looked at the Apps.
• Configurable for temperatures: car chooses / celcius / fahrenheit • Configurable for distances: car chooses / miles / kilometers • No configuration for pressures
Overall, I would conclude:
• 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. • It seems that almost all the vehicles use metric units • OBDII uses metric units • We need to maintain compatibility with OVMS v2 protocol, but can do things differently for v3 protocol
I suggest the following:
1. The Metrics use metric units for their internal storage (sic). 2. 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. 3. We add units parameters to the configuration storage (for pressure, temperature, distance). 4. We make the ovms_server_v2 convert to the v2 protocol standard
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.
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).
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.
Regards, Mark.
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
On 25 Oct 2017, at 12:26 PM, HONDA S-2000 <s2000@audiobanshee.com> 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. :-)
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@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@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
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I totally agree with Julien, I prefer adopting the OBDII standard units for our metrics dictionary and not add more overhead to this. If we define the units as part of our metrics dictionary specification, we do not need to store them in the values, except for generic value handling in the module. I currently can't think of a generic function in the module that really needs to be unit-aware. If (!) we find some later on, we still can add the units -- and will have a better idea of the free space left then. Regards, Michael Am 26.10.2017 um 08:30 schrieb Julien “JaXX” Banchet:
Hi,
Same for me #1, or even lighter than that :-) .
Sources are mostly metric/SI (besides Tesla, which will be among the rare exceptions hardcoded to be to converted as early as possible)… The structure would be then: the value. Point … We’d know from the name what type of value it is air pressure/speed/rpm/linear distance/soc/whatever/...
Showing human readable / l18n values should be kept on the presentation layer away from the OVMS (mobile app/intelligent cluster-hmi/etc… anywhere where processing power isn’t an issue), eventually through a crafted function on the OVMS that takes flash, not ram, though again, connecting to the shell is not the day-to-day usage imho.
Yeah, I’m an SI-n*zi :)
I might be missing something important that prevents simplifying metric storage but the lighter, the better.
Julien, Who brought 10kg of electronics on vacation, OVMS included, but forgot his laptop charger :-/
On 26 Oct 2017 at 08:17 +0200, Greg D. <gregd2350@gmail.com>, wrote:
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.
Greg
Mark Webb-Johnson wrote:
To put in code the two alternative approaches being considered:
enum { other, kilometers, miles, celcius, fahrenheit, kpa, psi, percentage } unit_t;
1. Everything metric
OvmsMetric: unit_t m_unit; unit_t GetUnit(); std::string AsStringConverted(unit_t conversion);
2. Unit with the metric
OvmsMetric: unit_t m_unit; unit_t GetUnit(); std::string AsStringConverted(unit_t conversion); void SetValue(std::string value, unit_t unit); etc
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).
The first is simpler, but does suffer from the double conversion issue in some cases. The second avoids that, at the expense of complexity.
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.
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.
Regards, Mark.
On 26 Oct 2017, at 9:51 AM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
I did a quick review of the way things were done in OVMS v2. Some notes:
The OVMS v2 protocol specified:
* Car Environment message 0x44 “D" • Temperature of the PEM (celcius) • Temperature of the Motor (celcius) • Temperature of the Battery (celcius) • Car trip meter (in 1/10th of a distance unit) • Car odometer (in 1/10th of a distance unit) • Car speed (in distance units per hour) • Ambient Temperature (in Celcius) * Car state message 0x53 “S” • Units ("M" for miles, "K" for kilometers) • Ideal range • Estimated range * Registered parameter #2 • Miles / Kilometer flag
The OVMS v2 net_msg code did some conversions:
* car_tpem is always stored in Celcius, and always sent as such * car_tmotor is always stored in Celcius, and always sent as such * car_tbattery is always stored in Celcius, and always sent as such * car_trip is stored in Miles, so a KmFromMi() conversion is done if units were “K” * car_odometer is stored in Miles, so a KmFromMi() conversion is done if units were “K” * car_speed is stored in user unit, and sent as such * car_ambient_temp is always stored in Celcius, and always sent as such * Units is stored as a parameter, and sent as such * car_idealrange is stored in Miles, so a KmFromMi() conversion is done if units were “K” * car_estrange is stored in Miles, so a KmFromMi() conversion is done if units were “K” * tpms is stored in raw (Tesla) format, and sent as PSI and Celcius
I did some quick checks against the OVMS v2 vehicle_*.c code. Here are some notes:
* Kia Soul: Seems to have distances in metric, and uses MiFromKm() when storing to car_*. Temperatures in celcius, so no conversion necessary. * Mitsubishi iMiev: MiFromKm() for distances. Temperatures in celcius, so no conversion necessary. * Tesla Roadster: Miles for distances, Celcius for temperatures, so no conversions necessary (surprise, surprise, as OVMS v2 car model based on this car). * Nissan Leaf: MiFromKm() for distances. Temperatures in celcius, so no conversion necessary. * Twizy: MiFromKm() for distances. Temperatures in celcius, so no conversion necessary. * Renault Zoe: MiFromKm() for distances. Seemingly no temperature support.
I then looked at the OBDII standard. Here are the notes from that:
* Temperatures are stored and transmitted in Celcius * Pressures are stored and transmitted in Pa / kPa * Distances are stored and transmitted in Km * Time is stored and transmitted in Seconds
I looked at the Apps.
* Configurable for temperatures: car chooses / celcius / fahrenheit * Configurable for distances: car chooses / miles / kilometers * No configuration for pressures
Overall, I would conclude:
* 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. * It seems that almost all the vehicles use metric units * OBDII uses metric units * We need to maintain compatibility with OVMS v2 protocol, but can do things differently for v3 protocol
I suggest the following:
1. The Metrics use metric units for their internal storage (sic). 2. 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. 3. We add units parameters to the configuration storage (for pressure, temperature, distance). 4. We make the ovms_server_v2 convert to the v2 protocol standard
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.
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).
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.
Regards, Mark.
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
On 25 Oct 2017, at 12:26 PM, HONDA S-2000 <s2000@audiobanshee.com <mailto:s2000@audiobanshee.com>> 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. :-)
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@expeedo.de <mailto:dexter@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@expeedo.de >> <mailto:dexter@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
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Seems to be a consensus. I’ve added this, and registered the units for the standard metrics: OVMS > metrics list v.b v.b.12v 0V v.b.cac 142.32Ah v.b.current 0A v.b.range.e 100Km v.b.range.i 124Km v.b.soc 35% v.b.soh 75% v.b.temp 31°C v.b.voltage 397V Looks good, and very clear. I”m currently working on the full Tesla Roadster vehicle support. I’m thinking of putting the standard unit conversion utility functions (KmToMiles, CelciusToFahrenheit, etc) into ovms_metrics.{h,cpp} as that seems a reasonable centralised place for that. If that is done, then I may as well extend SetValue(int value) to be SetValue(int value, metric_unit_t units = Other). In the normal case, nothing changes for the user, but the Tesla Roadster vehicle code could then call SetValue(range, Miles) and have ovms_metrics do the conversion to Kilometers. That seems a much more standardised, but still lightweight, way of doing things. That also has the advantage that in the long-run if we run into trouble with m->km->m->km style conversion issues, we could just change the implementation with ovms_metrics, without any other code changes required. I’ll try it, and see how it looks. Regards, Mark. P.S. That m->km->m->km example is not contrived, but real. Tesla roadster vehicle module receives range from car in Miles. It then has to convert to Km to put in the metric. Then, ovms_server_v2 has to convert to module units (say miles) for transmission. If the user App is then set to Kilometers, we get the final conversion back to Km. m->km->m->km. Urgh.
On 27 Oct 2017, at 1:33 AM, Michael Balzer <dexter@expeedo.de> wrote:
I totally agree with Julien, I prefer adopting the OBDII standard units for our metrics dictionary and not add more overhead to this.
If we define the units as part of our metrics dictionary specification, we do not need to store them in the values, except for generic value handling in the module. I currently can't think of a generic function in the module that really needs to be unit-aware. If (!) we find some later on, we still can add the units -- and will have a better idea of the free space left then.
Regards, Michael
Am 26.10.2017 um 08:30 schrieb Julien “JaXX” Banchet:
Hi,
Same for me #1, or even lighter than that :-) .
Sources are mostly metric/SI (besides Tesla, which will be among the rare exceptions hardcoded to be to converted as early as possible)… The structure would be then: the value. Point … We’d know from the name what type of value it is air pressure/speed/rpm/linear distance/soc/whatever/...
Showing human readable / l18n values should be kept on the presentation layer away from the OVMS (mobile app/intelligent cluster-hmi/etc… anywhere where processing power isn’t an issue), eventually through a crafted function on the OVMS that takes flash, not ram, though again, connecting to the shell is not the day-to-day usage imho.
Yeah, I’m an SI-n*zi :)
I might be missing something important that prevents simplifying metric storage but the lighter, the better.
Julien, Who brought 10kg of electronics on vacation, OVMS included, but forgot his laptop charger :-/
On 26 Oct 2017 at 08:17 +0200, Greg D. <gregd2350@gmail.com> <mailto:gregd2350@gmail.com>, wrote:
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.
Greg
Mark Webb-Johnson wrote:
To put in code the two alternative approaches being considered:
enum { other, kilometers, miles, celcius, fahrenheit, kpa, psi, percentage } unit_t;
Everything metric
OvmsMetric: unit_t m_unit; unit_t GetUnit(); std::string AsStringConverted(unit_t conversion);
Unit with the metric
OvmsMetric: unit_t m_unit; unit_t GetUnit(); std::string AsStringConverted(unit_t conversion); void SetValue(std::string value, unit_t unit); etc
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).
The first is simpler, but does suffer from the double conversion issue in some cases. The second avoids that, at the expense of complexity.
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.
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.
Regards, Mark.
On 26 Oct 2017, at 9:51 AM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
I did a quick review of the way things were done in OVMS v2. Some notes:
The OVMS v2 protocol specified:
Car Environment message 0x44 “D" • Temperature of the PEM (celcius) • Temperature of the Motor (celcius) • Temperature of the Battery (celcius) • Car trip meter (in 1/10th of a distance unit) • Car odometer (in 1/10th of a distance unit) • Car speed (in distance units per hour) • Ambient Temperature (in Celcius) Car state message 0x53 “S” • Units ("M" for miles, "K" for kilometers) • Ideal range • Estimated range Registered parameter #2 • Miles / Kilometer flag
The OVMS v2 net_msg code did some conversions:
car_tpem is always stored in Celcius, and always sent as such car_tmotor is always stored in Celcius, and always sent as such car_tbattery is always stored in Celcius, and always sent as such car_trip is stored in Miles, so a KmFromMi() conversion is done if units were “K” car_odometer is stored in Miles, so a KmFromMi() conversion is done if units were “K” car_speed is stored in user unit, and sent as such car_ambient_temp is always stored in Celcius, and always sent as such Units is stored as a parameter, and sent as such car_idealrange is stored in Miles, so a KmFromMi() conversion is done if units were “K” car_estrange is stored in Miles, so a KmFromMi() conversion is done if units were “K” tpms is stored in raw (Tesla) format, and sent as PSI and Celcius
I did some quick checks against the OVMS v2 vehicle_*.c code. Here are some notes:
Kia Soul: Seems to have distances in metric, and uses MiFromKm() when storing to car_*. Temperatures in celcius, so no conversion necessary. Mitsubishi iMiev: MiFromKm() for distances. Temperatures in celcius, so no conversion necessary. Tesla Roadster: Miles for distances, Celcius for temperatures, so no conversions necessary (surprise, surprise, as OVMS v2 car model based on this car). Nissan Leaf: MiFromKm() for distances. Temperatures in celcius, so no conversion necessary. Twizy: MiFromKm() for distances. Temperatures in celcius, so no conversion necessary. Renault Zoe: MiFromKm() for distances. Seemingly no temperature support.
I then looked at the OBDII standard. Here are the notes from that:
Temperatures are stored and transmitted in Celcius Pressures are stored and transmitted in Pa / kPa Distances are stored and transmitted in Km Time is stored and transmitted in Seconds
I looked at the Apps.
Configurable for temperatures: car chooses / celcius / fahrenheit Configurable for distances: car chooses / miles / kilometers No configuration for pressures
Overall, I would conclude:
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. It seems that almost all the vehicles use metric units OBDII uses metric units We need to maintain compatibility with OVMS v2 protocol, but can do things differently for v3 protocol
I suggest the following:
The Metrics use metric units for their internal storage (sic). 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. We add units parameters to the configuration storage (for pressure, temperature, distance). We make the ovms_server_v2 convert to the v2 protocol standard
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.
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).
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.
Regards, Mark.
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
On 25 Oct 2017, at 12:26 PM, HONDA S-2000 <s2000@audiobanshee.com <mailto:s2000@audiobanshee.com>> 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. :-)
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@expeedo.de <mailto:dexter@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@expeedo.de <mailto:dexter@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
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
participants (5)
-
Greg D. -
HONDA S-2000 -
Julien “JaXX” Banchet -
Mark Webb-Johnson -
Michael Balzer