[Ovmsdev] Inaccurate car_parktime / car_time
tom at idleloop.com
Mon Nov 11 02:47:03 HKT 2013
I had the same thought, but GPS doesn¹t 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.
From: Michael Jochum <mikeljo at me.com>
Reply-To: OVMS Developers <ovmsdev at lists.teslaclub.hk>
Date: Sunday, November 10, 2013 at 10:30 AM
To: OVMS Developers <ovmsdev at lists.teslaclub.hk>
Subject: Re: [Ovmsdev] Inaccurate car_parktime / car_time
what do you think about the GPS Clock?
Am 10.11.2013 um 14:01 schrieb Mark Webb-Johnson <mark at 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 = 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 tick¹ 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 = "AT+CREG?;+CIPSTATUS;+CSQ\r";
>> rom char NET_CREG_CIPSTATUS = "AT+CREG?;+CSQ;+CCLK?;+CIPSTATUS\r";
>> +CREG: 1,0
>> +CSQ: 0,0
>> +CCLK: ³10/10/10,00:02:51+00²
> (for my disconnected state).
> The fact that the time is wrong is irrelevant. All we¹d 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 trick¹ here is that this function would need to be controlled
> by a vehicle feature bit - some cars don¹t 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åkon Markussen <hakon.markussen at gmail.com>
>> 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åkon Markussen
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
_______________________________________________ OvmsDev mailing list
OvmsDev at lists.teslaclub.hk
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OvmsDev