[Ovmsdev] Inaccurate car_parktime / car_time

Mon Nov 11 18:38:01 HKT 2013

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 at 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 at 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 at 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 at me.com>
>> Reply-To: OVMS Developers <ovmsdev at lists.teslaclub.hk>
>> Date: Sunday, November 10, 2013 at 10:30 AM
>> To: OVMS Developers <ovmsdev at 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 at 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 at gmail.com> wrote:
>>> 
>>>> Hi,
>>>> 
>>>> The car_time is incremented in the state_ticker1 (approx once every second).
>>>> However I've noticed that this is extremely inacurate 
>>>> 
>>>> Today I started a stopwatch when parking the car, and compared it to the car_parktime in the iOS app:
>>>>  - Stopwatch: 8:00 (eight hours)
>>>>  - car_parktime: 6:01 (six hours and one minute
>>>> A difference of 1 hour and 59 minutes during 8 hours!
>>>> 
>>>> I wonder if this could be done in an other way? 
>>>> E.g. by pulling the time from the GPS?
>>>> 
>>>> Best regards.
>>>> Håkon Markussen
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.teslaclub.hk
>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>> 
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>> 
>> _______________________________________________ OvmsDev mailing list OvmsDev at lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> 
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> 
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

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