[Ovmsdev] Miles/Kilometers Conversion

Michael Balzer dexter at expeedo.de
Wed May 15 20:20:17 HKT 2013


Mark, Tom,

cool stuff, I don't think this conversion can be done with any more 
accuracy than that :-)

In the area of 0..100 km it tends to give smaller roundtrip results than 
the old one, but I consider this to be OK, as this typically is the 
"range" area and it should be better to be -2 km off for some values 
than to be +1 km for more values.

Updated & checked in.

Regards,
Michael


Am 13.05.2013 15:11, schrieb Mark Webb-Johnson:
>
> I've committed Tom's functions for this, as well as changes to net_msg 
> and vehicle_voltampera to use the new functions.
>
> Michael: I haven't changed vehicle_twizy, as I didn't want to mess 
> with your module. The change is very simple:
>
>  1. s/KM2MI/MiFromKm/
>  2. s/MI2KM/KmFromMi/
>
>
> Once done, please remove the KM2MI and MI2KM macros from utils.h, as 
> they shouldn't be required any more.
>
> The STAT command is a good way of testing. I tried in DIAG mode, and 
> it seemed ok.
>
> Regards, Mark.
>
> P.S. Now the Android App is back in the store, I'll start the process 
> of working out a better solution for this.
>
> On 13 May, 2013, at 9:02 AM, Mark Webb-Johnson <mark at webb-johnson.net 
> <mailto:mark at webb-johnson.net>> wrote:
>
>> Michael,
>>
>> Sorry, I've been lax about this.
>>
>> I did some work with Tom, a while ago, but haven't had a chance to 
>> put it in.
>>
>> Here is the final result (of me improving, then Tom improving my 
>> improvements, then me improving Tom's improvements to my 
>> improvements, then Tom nailing it with a last set of improvements). 
>> In the end, we decided it was more important to be as accurate as we 
>> can than to try to match the car exactly. As he put it, it was an 
>> interesting problem, and I think the solution of dividing the problem 
>> into two is quite elegant - leading to extraordinary accuracy on an 
>> 8bit processor while still supporting a large range of values. I'm 
>> particularly happy about the round-trip (miles->kilometers->miles) 
>> values shown.
>>
>>     Below is an improved version of the miles-to-kilometers function with
>>     rounding to get a bit more precision, and a corresponding
>>     kilometers-to-miles function.
>>
>>     I tested both the functions with a bunch of values, converting
>>     miles to
>>     kilometers and back, using 32-bit ints representing 1/10's. It
>>     matches the
>>     odometer values you gave for your car and successfully roundtrips
>>     until
>>     300,000 miles.
>>
>>     Xcode Test results:
>>
>>     0.1 miles -> 0.2 km -> 0.1 miles
>>     1.0 miles -> 1.6 km -> 1.0 miles
>>     10.0 miles -> 16.1 km -> 10.0 miles
>>     100.0 miles -> 160.9 km -> 100.0 miles
>>     100,000.0 miles -> 160,934.4 km -> 100,000.0 miles
>>     150,000.0 miles -> 241,401.7 km -> 150,000.0 miles
>>     200,000.0 miles -> 321,868.9 km -> 200,000.0 miles
>>     299,999.9 miles -> 482,803.2 km -> 299,999.9 miles
>>     300,000.0 miles -> 482,803.3 km -> 299,999.9 miles
>>     1,000,000.0 miles -> 1,609,344.5 km -> 999,999.9 miles
>>     10,000,000.0 miles -> 16,093,444.8 km -> 9,999,999.1 miles
>>     200,000,000.0 miles -> 321,868,896.5 km -> 199,999,982.4 miles
>>     32,255.6 miles -> 51,910.4 km -> 32,255.6 miles
>>     32,285.8 miles -> 51,959.0 km -> 32,285.8 miles
>>     13,421.3 miles -> 21,599.5 km -> 13,421.3 miles
>>
>>     Code:
>>
>>     // convert miles to kilometers by multiplying by ~1.609344
>>
>>     unsigned long KmFromMi(unsigned long miles)
>>     {
>>      unsigned long high = miles >> 16;
>>      unsigned long low = miles & 0xFFFF;
>>
>>      // approximate 0.609344 with 39934/2^16
>>      // do the multiply and divide for the high and low 16 bits to
>>      // preserve precision and avoid overflow
>>      // this yields six significant digits of accuracy and doesn't
>>      // overflow until the results no longer fit in 32 bits
>>      return miles + (high * 39934) + ((low * 39934 + 0x7FFF) >> 16);
>>     }
>>
>>     // convert kilometers to miles by multiplying by ~1/1.609344
>>
>>     unsigned long MiFromKm(unsigned long km)
>>     {
>>      unsigned long high = km >> 16;
>>      unsigned long low = km & 0xFFFF;
>>
>>      // approximate 1/1.609344 with (40722 + 1/6)/2^16
>>      // do the multiply and divide for the high and low 16 bits to
>>      // preserve precision and avoid overflow
>>      // this yields six significant digits of accuracy and doesn't
>>      // overflow for any 32-bit input value.
>>      return (high * 40722) + ((low * 40722 + km/6 + 0x7FFF) >> 16);
>>     }
>>
>>     I hope this is useful. It was an interesting problem.
>>
>>        Tom
>>
>>
>> I'll put it in utils.c this evening.
>>
>> It is not a _perfect_ solution (which would be to get the readings in 
>> native format - but that needs synchronised changes to the protocol 
>> and apps to support both new and old formats), but should be a lot 
>> more accurate than what we have now.
>>
>> Regards, Mark.
>>
>> On 13 May, 2013, at 4:48 AM, Michael Balzer wrote:
>>
>>> Nikki,
>>>
>>> that's no new error, it's due to the Twizy measuring metric vs. the 
>>> OVMS car model needing miles.
>>>
>>> The kilometer to miles conversion is optimized to avoid floating 
>>> point math (the OVMS has no FPU), and the conversion is already fine 
>>> tuned to produce the least mean error in the range 0..100 km.
>>>
>>> Conversion errors get bigger the bigger the numbers get, and there's 
>>> not much we can do about this (except enabling metric values in the 
>>> car model, which is on our list).
>>>
>>> Here's your current error explained:
>>>
>>> MP-0 c200,0,0040,0000,0000,4,0,0,169252,8430,8430,8774,65,65,41,37,0
>>>
>>> 169252 is the Twizy internal odometer value meaning 1692.52 km.
>>>
>>> See utils.h for the conversion:
>>>
>>> // 1 mile = 1.609344 kilometers
>>> // smalles error approximation: mi = (km * 10 - 5) / 16 + 1
>>>
>>> So the integer conversion for 1692 results in 1058 while the real 
>>> value is 1051. That's your 7 mile offset.
>>>
>>> Regards,
>>> Michael
>>>
>>>
>>> Am 12.05.2013 21:49, schrieb Nikki Gordon-Bloomfield:
>>>> I forgot to mention...
>>>>
>>>> My Twizy is about 7 miles less on the odometer than the creek OVMS 
>>>> build says.
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On 12 May 2013, at 17:40, Michael Balzer <dexter at expeedo.de 
>>>> <mailto:dexter at expeedo.de>> wrote:
>>>>
>>>>> Nikki,
>>>>>
>>>>> I haven't had that special case, but it sounds like the RAM 
>>>>> corruption effect. I think you need to do a hard reboot, i.e. 
>>>>> switch the module off.
>>>>>
>>>>> Please read out the debug info (cmd 200) and send me all history 
>>>>> data if possible, maybe I can find something in there.
>>>>>
>>>>> Thanks,
>>>>> Michael
>>>>>
>>>>>
>>>>> Am 12.05.2013 13:26, schrieb Nikki Gordon-Bloomfield:
>>>>>> HI folks,
>>>>>>
>>>>>> Just to let you know that my Twizy is still reporting 0 percent 
>>>>>> and 0 miles, even though it is now fully charged! (At least, OVMS 
>>>>>> is!) I've rebooted it a few times, and geolocation works fine.
>>>>>>
>>>>>> Nikki.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 12 May 2013, at 12:09, Michael Jochum <mikeljo at mac.com 
>>>>>> <mailto:mikeljo at mac.com>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> i think yes.
>>>>>>> We have the Voltage(s) and Amper(s) per Motor and Battery. But 
>>>>>>> currently not used in OVMS.
>>>>>>> So we can calc the Power like DashDaq.
>>>>>>>
>>>>>>> I think these are the IDs:
>>>>>>>
>>>>>>> 7EC 432D High Voltage Battery Voltage
>>>>>>> 7EC 4356 High Voltage Battery Current
>>>>>>>
>>>>>>> 7E9432D High Voltage Battery Voltage
>>>>>>> 7E94356 High Voltage Battery Current
>>>>>>>
>>>>>>> 7E92883 Motor A DC Current
>>>>>>> 7E92884 Motor B DC Current
>>>>>>> 7E92885 Motor A DC Voltage
>>>>>>> 7E92886 Motor B DC Voltage
>>>>>>>
>>>>>>> 7E8000D Vehicle Speed Km/Hr
>>>>>>>
>>>>>>> You can see the Data for the Battery are here twice. For Filter 
>>>>>>> reasons i think it is better to use 7E9 instead 7EC.
>>>>>>>
>>>>>>>
>>>>>>> Bye
>>>>>>> Michael J.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Am 11.05.2013 um 21:05 schrieb Denis KRAUTH 
>>>>>>> <denis.krauth at wanadoo.fr <mailto:denis.krauth at wanadoo.fr>>:
>>>>>>>
>>>>>>>> Michael (J),
>>>>>>>> Is this feasible for our Amperas ?
>>>>>>>> Denis (aka Kratus).
>>>>>>>> *De :*ovmsdev-bounces at lists.teslaclub.hk 
>>>>>>>> <mailto:ovmsdev-bounces at lists.teslaclub.hk>[mailto:ovmsdev-bounces at lists.teslaclub.hk 
>>>>>>>> <mailto:bounces at lists.teslaclub.hk>]*De la part de*Michael Balzer
>>>>>>>> *Envoyé :*samedi 11 mai 2013 16:52
>>>>>>>> *À :*ovmsdev at lists.teslaclub.hk <mailto:ovmsdev at lists.teslaclub.hk>
>>>>>>>> *Objet :*Re: [Ovmsdev] Twizy firmware image V2.3.6 / 2.6.5
>>>>>>>>
>>>>>>>> Denis,
>>>>>>>>
>>>>>>>> thanks :-)
>>>>>>>>
>>>>>>>> The GPS logging feature and energy usage stats are currently 
>>>>>>>> Twizy specific.
>>>>>>>>
>>>>>>>> To move these into the framework, we need to make the energy 
>>>>>>>> usage variables part of the common car model. And of course we 
>>>>>>>> need to know how to get these values from other cars like 
>>>>>>>> Ampera...?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Michael
>>>>>>>>
>>>>>>>> Am 11.05.2013 10:17, schrieb Denis KRAUTH:
>>>>>>>>
>>>>>>>>     Wow, great !
>>>>>>>>     Can this be done on my Ampera too, or is it Twizy-specific ?
>>>>>>>>     Can FEATURE 8 2 also be applied on my 2.3.2 Ampera firmware?
>>>>>>>>     There is a Volt/Ampera ecodrive contest in a few days (June
>>>>>>>>     1^st ) and this would be really great to track the data.
>>>>>>>>     I just read your german guide, and it seems really not
>>>>>>>>     difficult.
>>>>>>>>     Hut ab!
>>>>>>>>     Denis.
>>>>>>>>     *De :*ovmsdev-bounces at lists.teslaclub.hk
>>>>>>>>     <mailto:ovmsdev-bounces at lists.teslaclub.hk>[mailto:ovmsdev-bounces at lists.teslaclub.hk]*De
>>>>>>>>     la part de*Michael Balzer
>>>>>>>>     *Envoyé :*vendredi 10 mai 2013 20:26
>>>>>>>>     *À :*'OVMS Developers'
>>>>>>>>     *Objet :*[Ovmsdev] Twizy firmware image V2.3.6 / 2.6.5
>>>>>>>>     For those avoiding self-compiling (Nikki et al), here's the
>>>>>>>>     current firmware image with Twizy extensions.
>>>>>>>>
>>>>>>>>     It makes GPS logging (RT-GPS-Log) at 5 second intervals stable.
>>>>>>>>
>>>>>>>>     To get max GPS precision be sure to activate only the GPS
>>>>>>>>     logging (w/o location streaming) by setting feature #8 to 2.
>>>>>>>>
>>>>>>>>     The ZIP also contains a guide and spreadsheet template for
>>>>>>>>     creating energy use heatmap-style GPS tracks using
>>>>>>>>     gpsvisualizer.com <http://gpsvisualizer.com/> -- the guide
>>>>>>>>     text is in german now, I can make an english version and
>>>>>>>>     add it to the repository if there is demand.
>>>>>>>>
>>>>>>>>     Here's an example result:
>>>>>>>>
>>>>>>>>     <image001.png>
>>>>>>>>
>>>>>>>>     Regards,
>>>>>>>>     Michael
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>     -- 
>>>>>>>>
>>>>>>>>     Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
>>>>>>>>
>>>>>>>>     Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>     _______________________________________________
>>>>>>>>
>>>>>>>>     OvmsDev mailing list
>>>>>>>>
>>>>>>>>     OvmsDev at lists.teslaclub.hk  <mailto:OvmsDev at lists.teslaclub.hk>
>>>>>>>>
>>>>>>>>     http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
>>>>>>>> Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
>>>>>>>> _______________________________________________
>>>>>>>> OvmsDev mailing list
>>>>>>>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>>>>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OvmsDev mailing list
>>>>>>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>>>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> OvmsDev mailing list
>>>>>> OvmsDev at lists.teslaclub.hk
>>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>>>
>>>>> -- 
>>>>> Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
>>>>> Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
>>>>> <dexter.vcf>
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>>
>>>>
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.teslaclub.hk
>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>
>>> -- 
>>> Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
>>> Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
>>> <dexter.vcf>_______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130515/ba98c1ea/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dexter.vcf
Type: text/x-vcard
Size: 206 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130515/ba98c1ea/attachment-0002.vcf>


More information about the OvmsDev mailing list