[Ovmsdev] Inaccurate car_parktime / car_time

[Michael Jochum]

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

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