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@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 = 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@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@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