
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi,<div><br></div><div>what do you think about the GPS Clock?</div><div><br></div><div>Bye</div><div>Michael</div><div><br></div><div><br><div><div>Am 10.11.2013 um 14:01 schrieb Mark Webb-Johnson <<a href="mailto:mark@webb-johnson.net">mark@webb-johnson.net</a>>:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Our approach at the moment is very kludgy and not at all accurate.<div><br></div><div>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.</div><div><br></div><div>In the PIC, we have four hardware-level timers. Currently:</div><div> - Timer 0: Used to drive the main event loop</div><div> - Timer 1: Interrupt-driven, and used for LED blinking</div><div> - Timer 2: Used for short delays</div><div> - Timer 3: Unused</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;">rom char NET_CREG_CIPSTATUS[] = "AT+CREG?;+CIPSTATUS;+CSQ\r";</blockquote></div><div><br></div><div>to:</div><div><br></div><div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;">rom char NET_CREG_CIPSTATUS[] = "AT+CREG?;+CSQ;+CCLK?;+CIPSTATUS\r";</blockquote></div><div><br></div><div>Produces:</div><div><br></div><div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div>+CREG: 1,0</div><div>+CSQ: 0,0</div><div>+CCLK: “10/10/10,00:02:51+00”</div><div>ERROR</div></blockquote></div><div><br></div><div>(for my disconnected state).</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>The coding should not be too hard, but the testing might take some work.</div><div><br></div><div>Regards, Mark.</div><div><br><div><div>On 7 Nov, 2013, at 10:17 pm, Håkon Markussen <<a href="mailto:hakon.markussen@gmail.com">hakon.markussen@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div><div><div><div><div><div><div><div>Hi,<br><br></div>The car_time is incremented in the state_ticker1 (approx once every second).<br></div>However I've noticed that this is extremely inacurate <br><br>

</div>Today I started a stopwatch when parking the car, and compared it to the car_parktime in the iOS app:<br></div> - Stopwatch: 8:00 (eight hours)<br></div> - car_parktime: 6:01 (six hours and one minute<br></div>A difference of 1 hour and 59 minutes during 8 hours!<br>

<br>I wonder if this could be done in an other way? <br>E.g. by pulling the time from the GPS?<br><br></div>Best regards.<br></div>Håkon Markussen<br></div>

_______________________________________________<br>OvmsDev mailing list<br><a href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br><a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br></blockquote></div><br></div></div>_______________________________________________<br>OvmsDev mailing list<br><a href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br>http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br></blockquote></div><br></div></body></html>