[Ovmsdev] Inaccurate car_parktime / car_time

[Tom Saxton]

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.

   Tom

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

Hi,

what do you think about the GPS Clock?

Bye
Michael


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";
> 
> to:
> 
>> rom char NET_CREG_CIPSTATUS[] = "AT+CREG?;+CSQ;+CCLK?;+CIPSTATUS\r";
> 
> Produces:
> 
>> +CREG: 1,0
>> +CSQ: 0,0
>> +CCLK: ³10/10/10,00:02:51+00²
>> ERROR
> 
> (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>
> 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åkon Markussen
>> _______________________________________________
>> OvmsDev mailing list
>> 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

_______________________________________________ OvmsDev mailing list
OvmsDev at lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20131110/4716e123/attachment.htm>