<div dir="ltr"><div><div><div><div><div><div><div><div>Can I suggest that the update from the SIM908 time has a sanity check such that a time well outside the expected range is taken as a new starting time for the updates. This will prevent an error that I have seen on some charging posts where the clock gets updated during a charge (I suspect after a reboot the first time a genuine time is received, which could be several minutes after the reboot and after your charge starts) this can give very strange times in the charger log. So, I would suggest a system similar to the following:<br>
<br></div>1) First time through, record the SIM908 time in epoch seconds, and the corresponding car_time<br></div>2) Next time through (60 seconds later) get the SIM908 time in epoch seconds and subtract the stored value<br>
</div>3) If the difference is between 30 and 120, change car_time to stored_car_time + diff<br></div>4) Store current SIM908 time in epoch seconds, and the newly corrected car_time<br></div>5) goto 2<br><br></div>There is an issue with this in that the time can jump backwards a number of seconds - which may break some code at some point!<br>
<br></div>A solution to this would be to update car_time if it moves forward, but if it moves backwards do this by setting a "stall count" that prevents the car_time being updated for that number of 1 second intervals. This could safely be a byte as step 2 above ensures we can never move backwards more than 30 seconds.<br>
<br></div>Matt Beard<br><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 11 November 2013 01:33, Mark Webb-Johnson <span dir="ltr"><<a href="mailto:mark@webb-johnson.net" target="_blank">mark@webb-johnson.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div>Tom, Michael,<div><br></div><div>GPS time is extremely accurate, but once satellite coverage is lost, so is the time.</div>
<div><br></div><div>GSM time is dependent on the carrier keeping their times accurate in their cell towers. In the past this was a problem, but not so much nowadays. However, if the GSM connectivity is lost, the clock in the SIM908 module we use keeps running - and that is a huge advantage over GPS. You can see this in my example, earlier in this email thread - the clock is shown as 10/10/10 00:02:51 even in a module without a SIM card or GSM antenna attached. I think the SIMCOM chip we use will be pretty accurate.</div>
<div><br></div><div>Reflecting on this, I actually think the following approach would be 'good enough':</div><div><br></div><div><ol><li>Use the LED interrupt to keep a track of 104.8576ms ticks per interrupt, and increment car_time appropriately.<br>
<br></li><li>Use net.c polling to get the time from the GSM module. Convert it to epoch seconds (hopefully not too hard, if we can find a simple algorithm for it). If car_time and that differs, then adjust car_time to match but ALSO adjust car_parktime by the same amount. This would be done once every 60 seconds when GSM is online.<br>
<br></li><li>Use a net_fnbits bit to control whether the above is done or not. Remove all car_time code from vehicle modules that turn this on.</li></ol></div><div><br></div><div>The only tricky bit would be the epoch seconds function. We would need to convert a GSM date/time (like “10/10/10,00:02:51+00”) into UTC number of seconds since January 1st 1970. Or, maybe microchip C includes a gmtime() function? I haven't had a chance to check...</div>
<div><br></div><div>Regards, Mark.</div><div><div class="h5"><div><br><div><div>On 11 Nov, 2013, at 2:47 am, Tom Saxton <<a href="mailto:tom@idleloop.com" target="_blank">tom@idleloop.com</a>> wrote:</div><br><blockquote type="cite">
<div style="word-wrap:break-word;font-size:14px;font-family:Calibri,sans-serif"><div>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.</div>
<div><br></div><div> Tom</div><div><br></div><span><div style="font-family:Calibri;font-size:11pt;text-align:left;border-width:1pt medium medium;border-style:solid none none;padding:3pt 0in 0in;border-top-color:rgb(181,196,223)">
<span style="font-weight:bold">From: </span> Michael Jochum <<a href="mailto:mikeljo@me.com" target="_blank">mikeljo@me.com</a>><br><span style="font-weight:bold">Reply-To: </span> OVMS Developers <<a href="mailto:ovmsdev@lists.teslaclub.hk" target="_blank">ovmsdev@lists.teslaclub.hk</a>><br>
<span style="font-weight:bold">Date: </span> Sunday, November 10, 2013 at 10:30 AM<br><span style="font-weight:bold">To: </span> OVMS Developers <<a href="mailto:ovmsdev@lists.teslaclub.hk" target="_blank">ovmsdev@lists.teslaclub.hk</a>><br>
<span style="font-weight:bold">Subject: </span> Re: [Ovmsdev] Inaccurate car_parktime / car_time<br></div><div><br></div><div><div style="word-wrap:break-word">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" target="_blank">mark@webb-johnson.net</a>>:</div>
<br><blockquote type="cite"><div style="word-wrap:break-word">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" type="cite">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" type="cite">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" type="cite"><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" target="_blank">hakon.markussen@gmail.com</a>> wrote:</div><br><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" target="_blank">OvmsDev@lists.teslaclub.hk</a><br><a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev" target="_blank">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" target="_blank">OvmsDev@lists.teslaclub.hk</a><br><a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev" target="_blank">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br>
</blockquote></div><br></div></div></div>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.teslaclub.hk" target="_blank">OvmsDev@lists.teslaclub.hk</a>
<a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev" target="_blank">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</span></div>
_______________________________________________<br>OvmsDev mailing list<br><a href="mailto:OvmsDev@lists.teslaclub.hk" target="_blank">OvmsDev@lists.teslaclub.hk</a><br><a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev" target="_blank">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br>
</blockquote></div><br></div></div></div></div><br>_______________________________________________<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" target="_blank">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br>
<br></blockquote></div><br></div>