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
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
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
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
Tom, Michael, GPS time is extremely accurate, but once satellite coverage is lost, so is the time. 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. Reflecting on this, I actually think the following approach would be 'good enough': Use the LED interrupt to keep a track of 104.8576ms ticks per interrupt, and increment car_time appropriately. 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. 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. 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... Regards, Mark. On 11 Nov, 2013, at 2:47 am, Tom Saxton <tom@idleloop.com> wrote:
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 _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I can write a function to convert the data string to epoch seconds if needed. The USNO function you referenced earlier does the hard part of converting a date to a Julian date number. Tom From: Mark Webb-Johnson <mark@webb-johnson.net> Reply-To: OVMS Developers <ovmsdev@lists.teslaclub.hk> Date: Sunday, November 10, 2013 at 5:33 PM To: OVMS Developers <ovmsdev@lists.teslaclub.hk> Subject: Re: [Ovmsdev] Inaccurate car_parktime / car_time Tom, Michael, GPS time is extremely accurate, but once satellite coverage is lost, so is the time. 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. Reflecting on this, I actually think the following approach would be 'good enough': 1. Use the LED interrupt to keep a track of 104.8576ms ticks per interrupt, and increment car_time appropriately. 2. 3. 4. 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. 5. 6. 7. 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. 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... Regards, Mark. On 11 Nov, 2013, at 2:47 am, Tom Saxton <tom@idleloop.com> wrote:
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.hkhttp://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
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: 1) First time through, record the SIM908 time in epoch seconds, and the corresponding car_time 2) Next time through (60 seconds later) get the SIM908 time in epoch seconds and subtract the stored value 3) If the difference is between 30 and 120, change car_time to stored_car_time + diff 4) Store current SIM908 time in epoch seconds, and the newly corrected car_time 5) goto 2 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! 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. Matt Beard On 11 November 2013 01:33, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Tom, Michael,
GPS time is extremely accurate, but once satellite coverage is lost, so is the time.
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.
Reflecting on this, I actually think the following approach would be 'good enough':
1. Use the LED interrupt to keep a track of 104.8576ms ticks per interrupt, and increment car_time appropriately.
2. 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.
3. 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.
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...
Regards, Mark.
On 11 Nov, 2013, at 2:47 am, Tom Saxton <tom@idleloop.com> wrote:
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 _______________________________________________ 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
Hi, why so complicated? Remember the time/date from GSM when car gets parked. Every 60 sec. get the new Time/date from the GSM Module. Little math and you have the Parking time. If you need smaller time frames use a ticker with an offset. The offset is calculated with the difference between the GSM time an the time from the ticker. Bye Michael Am 11.11.2013 um 09:50 schrieb Matt Beard OVMS <smvo@mxf.org.uk>:
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:
1) First time through, record the SIM908 time in epoch seconds, and the corresponding car_time 2) Next time through (60 seconds later) get the SIM908 time in epoch seconds and subtract the stored value 3) If the difference is between 30 and 120, change car_time to stored_car_time + diff 4) Store current SIM908 time in epoch seconds, and the newly corrected car_time 5) goto 2
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!
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.
Matt Beard
On 11 November 2013 01:33, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Tom, Michael,
GPS time is extremely accurate, but once satellite coverage is lost, so is the time.
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.
Reflecting on this, I actually think the following approach would be 'good enough':
Use the LED interrupt to keep a track of 104.8576ms ticks per interrupt, and increment car_time appropriately.
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.
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.
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...
Regards, Mark.
On 11 Nov, 2013, at 2:47 am, Tom Saxton <tom@idleloop.com> wrote:
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 _______________________________________________ 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
Why so complicated? Firstly I don't think my proposed solution is particularly complicated. Secondly what happens if the GSM clock jumps - for example if you are parked close to two GSM cells, one with the "correct" time and one with a different time (perhaps simply running with time since cell rebooted) - you are likely to get some pretty skewed times in OVMS. Also, perhaps more likely, if you are in an area of poor GSM signal and so the SIM908 is reporting time based on up-time for several hours, then the weather changes or something else allows the module to suddenly pick up the correct time - what happens to the "time parked"? Matt On 11 November 2013 10:38, Michael Jochum <mikeljo@me.com> wrote:
Hi,
why so complicated? Remember the time/date from GSM when car gets parked. Every 60 sec. get the new Time/date from the GSM Module. Little math and you have the Parking time. If you need smaller time frames use a ticker with an offset. The offset is calculated with the difference between the GSM time an the time from the ticker.
Bye Michael
Am 11.11.2013 um 09:50 schrieb Matt Beard OVMS <smvo@mxf.org.uk>:
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:
1) First time through, record the SIM908 time in epoch seconds, and the corresponding car_time 2) Next time through (60 seconds later) get the SIM908 time in epoch seconds and subtract the stored value 3) If the difference is between 30 and 120, change car_time to stored_car_time + diff 4) Store current SIM908 time in epoch seconds, and the newly corrected car_time 5) goto 2
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!
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.
Matt Beard
On 11 November 2013 01:33, Mark Webb-Johnson <mark@webb-johnson.net>wrote:
Tom, Michael,
GPS time is extremely accurate, but once satellite coverage is lost, so is the time.
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.
Reflecting on this, I actually think the following approach would be 'good enough':
1. Use the LED interrupt to keep a track of 104.8576ms ticks per interrupt, and increment car_time appropriately.
2. 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.
3. 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.
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...
Regards, Mark.
On 11 Nov, 2013, at 2:47 am, Tom Saxton <tom@idleloop.com> wrote:
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 _______________________________________________ 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
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
It's interesting to follow the discussion, here are my comments: 1) When the car is out of satellite coverage, the car is most likely parked (or will be parked within a minute or two). When coverage is reestablished, the car is most likely driving. The point is that I think GPS can work fine as a clock for parking-time, even if the coverage is unstable. 2) Base stations (GSM/UMTS/LTE) either synchronize from a common ip-clock server when using IP as transmission, or from the ATM transmission itself when using 2Mbit-lines. You will not find two base stations in the same area with different clock. Then the mobile operator have made a poor job. Br. Håkon 2013/11/11 Matt Beard OVMS <smvo@mxf.org.uk>
Why so complicated? Firstly I don't think my proposed solution is particularly complicated. Secondly what happens if the GSM clock jumps - for example if you are parked close to two GSM cells, one with the "correct" time and one with a different time (perhaps simply running with time since cell rebooted) - you are likely to get some pretty skewed times in OVMS. Also, perhaps more likely, if you are in an area of poor GSM signal and so the SIM908 is reporting time based on up-time for several hours, then the weather changes or something else allows the module to suddenly pick up the correct time - what happens to the "time parked"?
Matt
On 11 November 2013 10:38, Michael Jochum <mikeljo@me.com> wrote:
Hi,
why so complicated? Remember the time/date from GSM when car gets parked. Every 60 sec. get the new Time/date from the GSM Module. Little math and you have the Parking time. If you need smaller time frames use a ticker with an offset. The offset is calculated with the difference between the GSM time an the time from the ticker.
Bye Michael
Am 11.11.2013 um 09:50 schrieb Matt Beard OVMS <smvo@mxf.org.uk>:
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:
1) First time through, record the SIM908 time in epoch seconds, and the corresponding car_time 2) Next time through (60 seconds later) get the SIM908 time in epoch seconds and subtract the stored value 3) If the difference is between 30 and 120, change car_time to stored_car_time + diff 4) Store current SIM908 time in epoch seconds, and the newly corrected car_time 5) goto 2
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!
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.
Matt Beard
On 11 November 2013 01:33, Mark Webb-Johnson <mark@webb-johnson.net>wrote:
Tom, Michael,
GPS time is extremely accurate, but once satellite coverage is lost, so is the time.
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.
Reflecting on this, I actually think the following approach would be 'good enough':
1. Use the LED interrupt to keep a track of 104.8576ms ticks per interrupt, and increment car_time appropriately.
2. 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.
3. 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.
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...
Regards, Mark.
On 11 Nov, 2013, at 2:47 am, Tom Saxton <tom@idleloop.com> wrote:
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 _______________________________________________ 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
_______________________________________________ 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
I don't know if I remember correctly, but once I was working with a GPS unit and I remember that if it lost the signal, the time reported by the NMEA string was still correct, but of course controlled by the internal clock and not in sync with the satellites. That's also why most GPS modules have a little backup coin cell, so at startup they already know the approximate time and they know where/what satellites they except to see. I don't know if that's the case with the SIM908, did anyone check? MG 2013/11/11 Matt Beard OVMS <smvo@mxf.org.uk>
Why so complicated? Firstly I don't think my proposed solution is particularly complicated. Secondly what happens if the GSM clock jumps - for example if you are parked close to two GSM cells, one with the "correct" time and one with a different time (perhaps simply running with time since cell rebooted) - you are likely to get some pretty skewed times in OVMS. Also, perhaps more likely, if you are in an area of poor GSM signal and so the SIM908 is reporting time based on up-time for several hours, then the weather changes or something else allows the module to suddenly pick up the correct time - what happens to the "time parked"?
Matt
On 11 November 2013 10:38, Michael Jochum <mikeljo@me.com> wrote:
Hi,
why so complicated? Remember the time/date from GSM when car gets parked. Every 60 sec. get the new Time/date from the GSM Module. Little math and you have the Parking time. If you need smaller time frames use a ticker with an offset. The offset is calculated with the difference between the GSM time an the time from the ticker.
Bye Michael
Am 11.11.2013 um 09:50 schrieb Matt Beard OVMS <smvo@mxf.org.uk>:
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:
1) First time through, record the SIM908 time in epoch seconds, and the corresponding car_time 2) Next time through (60 seconds later) get the SIM908 time in epoch seconds and subtract the stored value 3) If the difference is between 30 and 120, change car_time to stored_car_time + diff 4) Store current SIM908 time in epoch seconds, and the newly corrected car_time 5) goto 2
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!
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.
Matt Beard
On 11 November 2013 01:33, Mark Webb-Johnson <mark@webb-johnson.net>wrote:
Tom, Michael,
GPS time is extremely accurate, but once satellite coverage is lost, so is the time.
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.
Reflecting on this, I actually think the following approach would be 'good enough':
1. Use the LED interrupt to keep a track of 104.8576ms ticks per interrupt, and increment car_time appropriately.
2. 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.
3. 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.
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...
Regards, Mark.
On 11 Nov, 2013, at 2:47 am, Tom Saxton <tom@idleloop.com> wrote:
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 _______________________________________________ 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
_______________________________________________ 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
OVMS v2 hardware doesn't include a battery for the RTC. But, so long as the power is not removed from the module the RTC should be maintained. Regards, Mark. On 11 Nov, 2013, at 7:03 pm, Mastro Gippo <gipmad@gmail.com> wrote:
I don't know if I remember correctly, but once I was working with a GPS unit and I remember that if it lost the signal, the time reported by the NMEA string was still correct, but of course controlled by the internal clock and not in sync with the satellites. That's also why most GPS modules have a little backup coin cell, so at startup they already know the approximate time and they know where/what satellites they except to see. I don't know if that's the case with the SIM908, did anyone check? MG
2013/11/11 Matt Beard OVMS <smvo@mxf.org.uk>
Why so complicated? Firstly I don't think my proposed solution is particularly complicated. Secondly what happens if the GSM clock jumps - for example if you are parked close to two GSM cells, one with the "correct" time and one with a different time (perhaps simply running with time since cell rebooted) - you are likely to get some pretty skewed times in OVMS. Also, perhaps more likely, if you are in an area of poor GSM signal and so the SIM908 is reporting time based on up-time for several hours, then the weather changes or something else allows the module to suddenly pick up the correct time - what happens to the "time parked"?
Matt
On 11 November 2013 10:38, Michael Jochum <mikeljo@me.com> wrote: Hi,
why so complicated? Remember the time/date from GSM when car gets parked. Every 60 sec. get the new Time/date from the GSM Module. Little math and you have the Parking time. If you need smaller time frames use a ticker with an offset. The offset is calculated with the difference between the GSM time an the time from the ticker.
Bye Michael
Am 11.11.2013 um 09:50 schrieb Matt Beard OVMS <smvo@mxf.org.uk>:
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:
1) First time through, record the SIM908 time in epoch seconds, and the corresponding car_time 2) Next time through (60 seconds later) get the SIM908 time in epoch seconds and subtract the stored value 3) If the difference is between 30 and 120, change car_time to stored_car_time + diff 4) Store current SIM908 time in epoch seconds, and the newly corrected car_time 5) goto 2
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!
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.
Matt Beard
On 11 November 2013 01:33, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Tom, Michael,
GPS time is extremely accurate, but once satellite coverage is lost, so is the time.
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.
Reflecting on this, I actually think the following approach would be 'good enough':
Use the LED interrupt to keep a track of 104.8576ms ticks per interrupt, and increment car_time appropriately.
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.
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.
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...
Regards, Mark.
On 11 Nov, 2013, at 2:47 am, Tom Saxton <tom@idleloop.com> wrote:
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 _______________________________________________ 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
_______________________________________________ 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
Surely any adjustment issue is solved by changing the parktime any time the cartime is changed? For example, the module is plugged in so car_time starts at 0. A minute later, the car is parked, and car_parktime = car_time = 60. The car_time keeps ticking forward. Then, a few minutes later (at car_time 300), a GSM lock is obtained and the real date/time obtained. That is 1384223961, an offset of +1384223661 from car_time. So, car_parktime is adjusted +1384223661 (to be 1384223721) and car_time is adjusted +1384223661 (to be 1384223961). Before the adjustment, the car was parked 300-60 = 240 seconds ago. After the adjustment, the car was parked 1384223961-1384223721 = 240 seconds ago. While we could drop the 1 second accuracy and only update car_time once a minute, I don't think it is that hard to make it work properly to 1 second accuracy. At the moment, GSM status is only polled when the GSM carrier is obtained (READY state), and it would mean quite a few changes to also poll GSM status when no carrier lock is present (there are a lot of states surrounding that). One nice side-effect of having a good per-second accuracy car_time is the ability to time-stamp messages nicely (e.g.; sms, historical records, etc). Another is charging timers (ACC, etc). Regarding the sanity checking, I'm not sure how this solves the problem of two cell towers giving wildly different readings. How do we know which one is correct? Say one says it is 2013, and the other 2011 - which one is correct? If we 'lock' to the first one (and disregard the second correction), what if the first one was 2011? This problem is solvable if we use the GPS clock, but that may be more work than is really necessary. Regards, Mark. On 11 Nov, 2013, at 6:46 pm, Matt Beard OVMS <smvo@mxf.org.uk> wrote:
Why so complicated? Firstly I don't think my proposed solution is particularly complicated. Secondly what happens if the GSM clock jumps - for example if you are parked close to two GSM cells, one with the "correct" time and one with a different time (perhaps simply running with time since cell rebooted) - you are likely to get some pretty skewed times in OVMS. Also, perhaps more likely, if you are in an area of poor GSM signal and so the SIM908 is reporting time based on up-time for several hours, then the weather changes or something else allows the module to suddenly pick up the correct time - what happens to the "time parked"?
Matt
On 11 November 2013 10:38, Michael Jochum <mikeljo@me.com> wrote: Hi,
why so complicated? Remember the time/date from GSM when car gets parked. Every 60 sec. get the new Time/date from the GSM Module. Little math and you have the Parking time. If you need smaller time frames use a ticker with an offset. The offset is calculated with the difference between the GSM time an the time from the ticker.
Bye Michael
Am 11.11.2013 um 09:50 schrieb Matt Beard OVMS <smvo@mxf.org.uk>:
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:
1) First time through, record the SIM908 time in epoch seconds, and the corresponding car_time 2) Next time through (60 seconds later) get the SIM908 time in epoch seconds and subtract the stored value 3) If the difference is between 30 and 120, change car_time to stored_car_time + diff 4) Store current SIM908 time in epoch seconds, and the newly corrected car_time 5) goto 2
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!
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.
Matt Beard
On 11 November 2013 01:33, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Tom, Michael,
GPS time is extremely accurate, but once satellite coverage is lost, so is the time.
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.
Reflecting on this, I actually think the following approach would be 'good enough':
Use the LED interrupt to keep a track of 104.8576ms ticks per interrupt, and increment car_time appropriately.
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.
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.
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...
Regards, Mark.
On 11 Nov, 2013, at 2:47 am, Tom Saxton <tom@idleloop.com> wrote:
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 _______________________________________________ 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
_______________________________________________ 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
participants (6)
-
Håkon Markussen -
Mark Webb-Johnson -
Mastro Gippo -
Matt Beard OVMS -
Michael Jochum -
Tom Saxton