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: s/KM2MI/MiFromKm/ 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@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@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@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
7E9 432D High Voltage Battery Voltage 7E9 4356 High Voltage Battery Current
7E9 2883 Motor A DC Current 7E9 2884 Motor B DC Current 7E9 2885 Motor A DC Voltage 7E9 2886 Motor B DC Voltage
7E8 000D 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@wanadoo.fr>:
> Michael (J), > > Is this feasible for our Amperas ? > > Denis (aka Kratus). > > De : ovmsdev-bounces@lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] De la part de Michael Balzer > Envoyé : samedi 11 mai 2013 16:52 > À : ovmsdev@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 1st) 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@lists.teslaclub.hk [mailto:ovmsdev-bounces@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 -- 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@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@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 * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 <dexter.vcf> _______________________________________________ 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 * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26 <dexter.vcf>_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev