[Ovmsdev] Inaccurate car_parktime / car_time

Mon Nov 11 19:02:18 HKT 2013

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 at 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 at 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 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':
>>>
>>>
>>>    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 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
>>
>>
>>
>> _______________________________________________
>> 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/a91a871b/attachment.htm>