Return-Path: Received: from network-box.com ([unix socket]) by nbmailhq5 (Cyrus v2.3.16-Fedora-RPM-2.3.16-6_5.nb5.0.2) with LMTPA; Tue, 12 Nov 2013 10:56:20 +0800 X-Sieve: CMU Sieve 2.3 Received: from nbmailhk1.network-box.com (unknown [10.8.18.9]) by network-box.com (Postfix) with ESMTP id 908FB2100198 for ; Tue, 12 Nov 2013 10:56:20 +0800 (HKT) Received: from nbmailscanhq1.network-box.com (unknown [10.12.18.180]) by nbmailhk1.network-box.com (Postfix) with ESMTP id 75D2C780EA for ; Tue, 12 Nov 2013 10:56:20 +0800 (HKT) Received: (qmail 14725 invoked from network); 12 Nov 2013 02:56:17 -0000 X-NetworkBox-HamSign: 0101;OUT;nbmailscanhq1;82cf1f3ff2e50a83bcb201fc3d743859; Received: from unknown (HELO markhk2.network-box.com) (10.12.18.80) by 10.12.18.180 with SMTP; 12 Nov 2013 02:56:16 -0000 Received: from [127.0.0.1] (markhk2 [127.0.0.1]) by markhk2.network-box.com (Postfix) with ESMTP id AEDCE80052; Tue, 12 Nov 2013 10:56:16 +0800 (HKT) X-Original-To: ovmsdev@lists.teslaclub.hk Delivered-To: ovmsdev@lists.teslaclub.hk Received: from nbmailscanhq1.network-box.com (unknown [10.12.18.180]) by markhk2.network-box.com (Postfix) with ESMTP id A6A5480052 for ; Tue, 12 Nov 2013 10:56:15 +0800 (HKT) Received: (qmail 14661 invoked from network); 12 Nov 2013 02:56:15 -0000 X-NetworkBox-HamSign: 0101; OUT; nbmailscanhq1; 29cce9ac4b01677513d17401e7b377be; Received: from unknown (HELO nbitphk1.network-box.com) (10.254.50.14) by 10.12.18.180 with SMTP; 12 Nov 2013 02:56:15 -0000 Received: (qmail 18501 invoked from network); 12 Nov 2013 02:56:15 -0000 Received: from unknown (HELO ?10.8.2.100?) (10.8.2.100) by 10.8.2.62 with SMTP; 12 Nov 2013 02:56:15 -0000 From: Mark Webb-Johnson Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) Date: Tue, 12 Nov 2013 10:56:15 +0800 References: <59BE8415-F816-4BD9-9EAD-FCD64C0CCAF1@webb-johnson.net> To: OVMS Developers In-Reply-To: X-Mailer: Apple Mail (2.1812) X-NetworkBox-BounceSign-nbhqhk: 0101;16021;67f4b49d X-Scanned-By-nbmailscanhq1: Virus scan performed by network-box X-Scanned-By-nbmailscanhq1: Scanner file id is nbmailscanhq1-1384224975.440-14656-000 X-Scanned-By-nbmailscanhq1: No known viruses found in message (received+scanned in 0.04/0.05 secs) X-Scanned-By-nbmailscanhq1: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Spam-Status: No Subject: Re: [Ovmsdev] Inaccurate car_parktime / car_time X-BeenThere: ovmsdev@lists.teslaclub.hk X-Mailman-Version: 2.1.11 Precedence: list Reply-To: OVMS Developers List-Id: OVMS Developers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0377878180137418127==" Sender: ovmsdev-bounces@lists.teslaclub.hk Errors-To: ovmsdev-bounces@lists.teslaclub.hk X-NetworkBox-BounceSign-nbhqhk: 0101;16021;67f4b49d X-Scanned-By-nbmailscanhq1: Virus scan performed by network-box X-Scanned-By-nbmailscanhq1: Scanner file id is nbmailscanhq1-1384224976.808-14689-000 X-Scanned-By-nbmailscanhq1: No known viruses found in message (received+scanned in 0.08/0.26 secs) X-Scanned-By-nbmailscanhq1: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 --===============0377878180137418127== Content-Type: multipart/alternative; boundary="Apple-Mail=_4F9D3CC2-7F14-44BE-96E3-01C1B6CC2C98" --Apple-Mail=_4F9D3CC2-7F14-44BE-96E3-01C1B6CC2C98 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Surely any adjustment issue is solved by changing the parktime any time = the cartime is changed? For example, the module is plugged in so car_time starts at 0. A minute = later, the car is parked, and car_parktime =3D car_time =3D 60. The = car_time keeps ticking forward. Then, a few minutes later (at car_time = 300), a GSM lock is obtained and the real date/time obtained. That is = 1384223961, an offset of +1384223661 from car_time. So, car_parktime is = adjusted +1384223661 (to be 1384223721) and car_time is adjusted = +1384223661 (to be 1384223961). Before the adjustment, the car was = parked 300-60 =3D 240 seconds ago. After the adjustment, the car was = parked 1384223961-1384223721 =3D 240 seconds ago. While we could drop the 1 second accuracy and only update car_time once = a minute, I don't think it is that hard to make it work properly to 1 = second accuracy. At the moment, GSM status is only polled when the GSM = carrier is obtained (READY state), and it would mean quite a few changes = to also poll GSM status when no carrier lock is present (there are a lot = of states surrounding that). One nice side-effect of having a good per-second accuracy car_time is = the ability to time-stamp messages nicely (e.g.; sms, historical = records, etc). Another is charging timers (ACC, etc). Regarding the sanity checking, I'm not sure how this solves the problem = of two cell towers giving wildly different readings. How do we know = which one is correct? Say one says it is 2013, and the other 2011 - = which one is correct? If we 'lock' to the first one (and disregard the = second correction), what if the first one was 2011? This problem is = solvable if we use the GPS clock, but that may be more work than is = really necessary. Regards, Mark. On 11 Nov, 2013, at 6:46 pm, Matt Beard OVMS wrote: >=20 > Why so complicated? Firstly I don't think my proposed solution is = particularly complicated. Secondly what happens if the GSM clock jumps - = for example if you are parked close to two GSM cells, one with the = "correct" time and one with a different time (perhaps simply running = with time since cell rebooted) - you are likely to get some pretty = skewed times in OVMS. Also, perhaps more likely, if you are in an area = of poor GSM signal and so the SIM908 is reporting time based on up-time = for several hours, then the weather changes or something else allows the = module to suddenly pick up the correct time - what happens to the "time = parked"? >=20 > Matt >=20 >=20 >=20 > On 11 November 2013 10:38, Michael Jochum wrote: > Hi, >=20 > why so complicated? > Remember the time/date from GSM when car gets parked. > Every 60 sec. get the new Time/date from the GSM Module. > Little math and you have the Parking time. > If you need smaller time frames use a ticker with an offset. The = offset is calculated with the difference between the GSM time an the = time from the ticker. >=20 > Bye > Michael >=20 >=20 > Am 11.11.2013 um 09:50 schrieb Matt Beard OVMS : >=20 >> Can I suggest that the update from the SIM908 time has a sanity check = such that a time well outside the expected range is taken as a new = starting time for the updates. This will prevent an error that I have = seen on some charging posts where the clock gets updated during a charge = (I suspect after a reboot the first time a genuine time is received, = which could be several minutes after the reboot and after your charge = starts) this can give very strange times in the charger log. So, I would = suggest a system similar to the following: >>=20 >> 1) First time through, record the SIM908 time in epoch seconds, and = the corresponding car_time >> 2) Next time through (60 seconds later) get the SIM908 time in epoch = seconds and subtract the stored value >> 3) If the difference is between 30 and 120, change car_time to = stored_car_time + diff >> 4) Store current SIM908 time in epoch seconds, and the newly = corrected car_time >> 5) goto 2 >>=20 >> There is an issue with this in that the time can jump backwards a = number of seconds - which may break some code at some point! >>=20 >> A solution to this would be to update car_time if it moves forward, = but if it moves backwards do this by setting a "stall count" that = prevents the car_time being updated for that number of 1 second = intervals. This could safely be a byte as step 2 above ensures we can = never move backwards more than 30 seconds. >>=20 >> Matt Beard >>=20 >>=20 >>=20 >> On 11 November 2013 01:33, Mark Webb-Johnson = wrote: >>=20 >> Tom, Michael, >>=20 >> GPS time is extremely accurate, but once satellite coverage is lost, = so is the time. >>=20 >> GSM time is dependent on the carrier keeping their times accurate in = their cell towers. In the past this was a problem, but not so much = nowadays. However, if the GSM connectivity is lost, the clock in the = SIM908 module we use keeps running - and that is a huge advantage over = GPS. You can see this in my example, earlier in this email thread - the = clock is shown as 10/10/10 00:02:51 even in a module without a SIM card = or GSM antenna attached. I think the SIMCOM chip we use will be pretty = accurate. >>=20 >> Reflecting on this, I actually think the following approach would be = 'good enough': >>=20 >> Use the LED interrupt to keep a track of 104.8576ms ticks per = interrupt, and increment car_time appropriately. >>=20 >> Use net.c polling to get the time from the GSM module. Convert it to = epoch seconds (hopefully not too hard, if we can find a simple algorithm = for it). If car_time and that differs, then adjust car_time to match but = ALSO adjust car_parktime by the same amount. This would be done once = every 60 seconds when GSM is online. >>=20 >> Use a net_fnbits bit to control whether the above is done or not. = Remove all car_time code from vehicle modules that turn this on. >>=20 >> The only tricky bit would be the epoch seconds function. We would = need to convert a GSM date/time (like =9310/10/10,00:02:51+00=94) into = UTC number of seconds since January 1st 1970. Or, maybe microchip C = includes a gmtime() function? I haven't had a chance to check... >>=20 >> Regards, Mark. >>=20 >> On 11 Nov, 2013, at 2:47 am, Tom Saxton wrote: >>=20 >>> I had the same thought, but GPS doesn=92t work when the car is in a = garage, an important case for a parking timer. Cell coverage seems to be = much more penetrating than GPS. >>>=20 >>> Tom >>>=20 >>> From: Michael Jochum >>> Reply-To: OVMS Developers >>> Date: Sunday, November 10, 2013 at 10:30 AM >>> To: OVMS Developers >>> Subject: Re: [Ovmsdev] Inaccurate car_parktime / car_time >>>=20 >>> Hi, >>>=20 >>> what do you think about the GPS Clock? >>>=20 >>> Bye >>> Michael >>>=20 >>>=20 >>> Am 10.11.2013 um 14:01 schrieb Mark Webb-Johnson = : >>>=20 >>>> Our approach at the moment is very kludgy and not at all accurate. >>>>=20 >>>> For the cars without internal support for a timer, we increment = car_time on a ticker() call, which is approximately once per second, but = not in delay loops. It is really just intended to give a very = approximate 1 second ticker, not a clock-accurate timer. >>>>=20 >>>> In the PIC, we have four hardware-level timers. Currently: >>>> - Timer 0: Used to drive the main event loop >>>> - Timer 1: Interrupt-driven, and used for LED blinking >>>> - Timer 2: Used for short delays >>>> - Timer 3: Unused >>>>=20 >>>> I suspect that a better approach would be the Timer 1 we currently = have. That runs off the FOSC/4 (20Mhz/4 =3D 5MHz) and uses a 1:8 = pre-scaler, so the internal timer works at 625,000 ticks per second. = With a 16 bit value, it will overflow (interrupt) 9.53674 times per = second. By my calculations, that means each =91tick=92 is approximately = 104.8576ms. It would be fairly trivial to keep a counter there, and = drive car_time from that. I am just not sure how accurate that = oscillator is (particularly as temperature changes) - but I suspect that = it would be good enough for what we need. >>>>=20 >>>> Alternatively, or additionally, the GSM modem has a clock which can = be polled by AT+CCLK. It would not be hard to do that in the net.c code = (probably where we normally poll for status once a minute) and adjust = car_time as necessary there. For example, changing net.c: >>>>=20 >>>>> rom char NET_CREG_CIPSTATUS[] =3D "AT+CREG?;+CIPSTATUS;+CSQ\r"; >>>>=20 >>>>=20 >>>> to: >>>>=20 >>>>> rom char NET_CREG_CIPSTATUS[] =3D = "AT+CREG?;+CSQ;+CCLK?;+CIPSTATUS\r"; >>>>=20 >>>>=20 >>>> Produces: >>>>=20 >>>>> +CREG: 1,0 >>>>> +CSQ: 0,0 >>>>> +CCLK: =9310/10/10,00:02:51+00=94 >>>>> ERROR >>>>=20 >>>>=20 >>>> (for my disconnected state). >>>>=20 >>>> The fact that the time is wrong is irrelevant. All we=92d need it = to do is look at the GSM module time and look for drift against = car_time. We would need to protect against large changes (as the module = gets a GSM connection, there may be a very large jump as the timezone = and other things get set correctly). >>>>=20 >>>> The only other =91trick=92 here is that this function would need to = be controlled by a vehicle feature bit - some cars don=92t need it. >>>>=20 >>>> The coding should not be too hard, but the testing might take some = work. >>>>=20 >>>> Regards, Mark. >>>>=20 >>>> On 7 Nov, 2013, at 10:17 pm, H=E5kon Markussen = wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>> The car_time is incremented in the state_ticker1 (approx once = every second). >>>>> However I've noticed that this is extremely inacurate=20 >>>>>=20 >>>>> Today I started a stopwatch when parking the car, and compared it = to the car_parktime in the iOS app: >>>>> - Stopwatch: 8:00 (eight hours) >>>>> - car_parktime: 6:01 (six hours and one minute >>>>> A difference of 1 hour and 59 minutes during 8 hours! >>>>>=20 >>>>> I wonder if this could be done in an other way?=20 >>>>> E.g. by pulling the time from the GPS? >>>>>=20 >>>>> Best regards. >>>>> H=E5kon Markussen >>>>> _______________________________________________ >>>>> OvmsDev mailing list >>>>> OvmsDev@lists.teslaclub.hk >>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev >>>>=20 >>>> _______________________________________________ >>>> OvmsDev mailing list >>>> OvmsDev@lists.teslaclub.hk >>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev >>>=20 >>> _______________________________________________ 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 >>=20 >>=20 >> _______________________________________________ >> OvmsDev mailing list >> OvmsDev@lists.teslaclub.hk >> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev >>=20 >>=20 >> _______________________________________________ >> OvmsDev mailing list >> OvmsDev@lists.teslaclub.hk >> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev >=20 >=20 > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.teslaclub.hk > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev >=20 >=20 > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.teslaclub.hk > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev --Apple-Mail=_4F9D3CC2-7F14-44BE-96E3-01C1B6CC2C98 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Surely any adjustment issue is solved = by changing the parktime any time the cartime is = changed?

For example, the module is plugged in so = car_time starts at 0. A minute later, the car is parked, and = car_parktime =3D car_time =3D 60. The car_time keeps ticking forward. = Then, a few minutes later (at car_time 300), a GSM lock is obtained and = the real date/time obtained. That is 1384223961, an offset of = +1384223661 from car_time. So, car_parktime is adjusted +1384223661 (to = be 1384223721) and car_time is adjusted +1384223661 (to = be 1384223961). Before the adjustment, the car was parked 300-60 =3D = 240 seconds ago. After the adjustment, the car was = parked 1384223961-1384223721 =3D 240 seconds = ago.

While we could drop the 1 second accuracy = and only update car_time once a minute, I don't think it is that hard to = make it work properly to 1 second accuracy. At the moment, GSM status is = only polled when the GSM carrier is obtained (READY state), and it would = mean quite a few changes to also poll GSM status when no carrier lock is = present (there are a lot of states surrounding = that).

One nice side-effect of having a good = per-second accuracy car_time is the ability to time-stamp messages = nicely (e.g.; sms, historical records, etc). Another is charging timers = (ACC, etc).

Regarding the sanity checking, I'm = not sure how this solves the problem of two cell towers giving wildly = different readings. How do we know which one is correct? Say one says it = is 2013, and the other 2011 - which one is correct? If we 'lock' to the = first one (and disregard the second correction), what if the first one = was 2011? This problem is solvable if we use the GPS clock, but that may = be more work than is really necessary.

Regards, = Mark.

On 11 Nov, 2013, at 6:46 pm, Matt Beard = OVMS <smvo@mxf.org.uk> = wrote:


Why so complicated? Firstly I = don't think my proposed solution is particularly complicated. Secondly = what happens if the GSM clock jumps - for example if you are parked = close to two GSM cells, one with the "correct" time and one with a = different time (perhaps simply running with time since cell rebooted) - = you are likely to get some pretty skewed times in OVMS. Also, perhaps = more likely, if you are in an area of poor GSM signal and so the SIM908 = is reporting time based on up-time for several hours, then the weather = changes or something else allows the module to suddenly pick up the = correct time - what happens to the "time parked"?

Matt



On 11 November 2013 10:38, Michael Jochum <mikeljo@me.com> wrote:
Hi,

why so = complicated?
Remember the time/date from GSM when car gets = parked.
Every 60 sec. get the new Time/date from the GSM = Module.
Little math and you have the Parking = time.
If you need smaller time frames use a ticker with an = offset. The offset is calculated with the difference between the GSM = time an the time from the ticker.
=

Bye
Michael


Am 11.11.2013 um 09:50 schrieb Matt Beard OVMS <smvo@mxf.org.uk>:

Can I suggest that = the update from the SIM908 time has a sanity check such that a time well = outside the expected range is taken as a new starting time for the = updates. This will prevent an error that I have seen on some charging = posts where the clock gets updated during a charge (I suspect after a = reboot the first time a genuine time is received, which could be several = minutes after the reboot and after your charge starts) this can give = very strange times in the charger log. So, I would suggest a system = similar to the following:

1) First time through, record the SIM908 time in epoch = seconds, and the corresponding car_time
2) Next time through = (60 seconds later) get the SIM908 time in epoch seconds and subtract the = stored value
3) If the difference is between 30 and 120, change car_time to = stored_car_time + diff
4) Store current SIM908 time in epoch = seconds, and the newly corrected car_time
5) goto = 2

There is an issue with this in that the time can jump = backwards a number of seconds - which may break some code at some = point!

A solution to this would be to update car_time if it moves = forward, but if it moves backwards do this by setting a "stall count" = that prevents the car_time being updated for that number of 1 second = intervals. This could safely be a byte as step 2 above ensures we can = never move backwards more than 30 seconds.

Matt Beard



On 11 November 2013 01:33, Mark Webb-Johnson <mark@webb-johnson.net> wrote:

Tom, = Michael,

GPS time is extremely accurate, but once = satellite coverage is lost, so is the time.

GSM time is dependent on the carrier keeping their = times accurate in their cell towers. In the past this was a problem, but = not so much nowadays. However, if the GSM connectivity is lost, the = clock in the SIM908 module we use keeps running - and that is a huge = advantage over GPS. You can see this in my example, earlier in this = email thread - the clock is shown as 10/10/10 00:02:51 even in a module = without a SIM card or GSM antenna attached. I think the SIMCOM chip we = use will be pretty accurate.

Reflecting on this, I actually think the following = approach would be 'good enough':

  1. Use = the LED interrupt to keep a track of 104.8576ms ticks per = interrupt, and increment car_time appropriately.

  2. Use net.c polling to get the time from the GSM module. = Convert it to epoch seconds (hopefully not too hard, if we can find a = simple algorithm for it). If car_time and that differs, then adjust = car_time to match but ALSO adjust car_parktime by the same amount. This = would be done once every 60 seconds when GSM is online.

  3. Use a net_fnbits bit to control whether the above is = done or not. Remove all car_time code from vehicle modules that turn = this on.

The only tricky bit would be = the epoch seconds function. We would need to convert a GSM date/time = (like =9310/10/10,00:02:51+00=94) into UTC number of seconds since = January 1st 1970. Or, maybe microchip C includes a gmtime() function? I = haven't had a chance to check...

Regards, Mark.

On 11 Nov, = 2013, at 2:47 am, Tom Saxton <tom@idleloop.com> wrote:

I had the same thought, but GPS doesn=92t work when the car is = in a garage, an important case for a parking timer. Cell coverage seems = to be much more penetrating than GPS.

   Tom

From: Michael Jochum <mikeljo@me.com>
Reply-To: OVMS Developers <ovmsdev@lists.teslaclub.hk>
Date: Sunday, November 10, 2013 = at 10:30 AM
To: OVMS = Developers <ovmsdev@lists.teslaclub.hk>
Subject: Re: [Ovmsdev] = Inaccurate car_parktime / car_time

Hi,

what do you think = about the GPS Clock?
=

Bye
Michael


Am 10.11.2013 um 14:01 schrieb Mark Webb-Johnson <mark@webb-johnson.net>:

Our = approach at the moment is very kludgy and not at all = accurate.

For the cars without internal support for a = timer, we increment car_time on a ticker() call, which is approximately = once per second, but not in delay loops. It is really just intended to = give a very approximate 1 second ticker, not a clock-accurate = timer.

In the PIC, we have four hardware-level timers. = Currently:
 - Timer 0: Used to drive the main event = loop
 - Timer 1: Interrupt-driven, and used for LED = blinking
 - Timer 2: Used for short delays
 - Timer 3: Unused

I suspect that a = better approach would be the Timer 1 we currently have. That runs off = the FOSC/4 (20Mhz/4 =3D 5MHz) and uses a 1:8 pre-scaler, so the internal = timer works at 625,000 ticks per second. With a 16 bit value, it = will overflow (interrupt) 9.53674 times per second. By my = calculations, that means each =91tick=92 is approximately 104.8576ms. It = would be fairly trivial to keep a counter there, and drive car_time from = that. I am just not sure how accurate that oscillator is (particularly = as temperature changes) - but I suspect that it would be good enough for = what we need.

Alternatively, or additionally, the GSM modem has a = clock which can be polled by AT+CCLK. It would not be hard to do that in = the net.c code (probably where we normally poll for status once a = minute) and adjust car_time as necessary there. For example, changing = net.c:

rom char = NET_CREG_CIPSTATUS[] =3D = "AT+CREG?;+CIPSTATUS;+CSQ\r";

to:

rom char = NET_CREG_CIPSTATUS[] =3D = "AT+CREG?;+CSQ;+CCLK?;+CIPSTATUS\r";

Produces:

+CREG: = 1,0
+CSQ: 0,0
+CCLK: = =9310/10/10,00:02:51+00=94
ERROR
(for my disconnected state).

The fact that the = time is wrong is irrelevant. All we=92d need it to do is look at the GSM = module time and look for drift against car_time. We would need to = protect against large changes (as the module gets a GSM connection, = there may be a very large jump as the timezone and other things get set = correctly).

The only other =91trick=92 here is that this = function would need to be controlled by a vehicle feature bit - some = cars don=92t need it.

The coding should not be = too hard, but the testing might take some work.

Regards, Mark.

On 7 Nov, = 2013, at 10:17 pm, H=E5kon Markussen <hakon.markussen@gmail.com> = wrote:

Hi,

The = car_time is incremented in the state_ticker1 (approx once every = second).
However I've noticed that this is extremely inacurate =

Today I started a stopwatch when parking the car, and compared it = to the car_parktime in the iOS app:
 - Stopwatch: 8:00 = (eight hours)
 - car_parktime: 6:01 (six hours and one = minute
A difference of 1 hour and 59 minutes during 8 = hours!

I wonder if this could be done in an other way?
E.g. by pulling = the time from the GPS?

Best regards.
H=E5kon = Markussen
_______________________________________________
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
_______________________________________________
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 =


_______________________= ________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk<= br> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________
OvmsDev mailing = list
OvmsDev@lists.teslaclub.hk<= br>http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

= --Apple-Mail=_4F9D3CC2-7F14-44BE-96E3-01C1B6CC2C98-- --===============0377878180137418127== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev --===============0377878180137418127==--