[Ovmsdev] Inaccurate car_parktime / car_time

[Mark Webb-Johnson]

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

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