[Ovmsdev] Inaccurate car_parktime / car_time

Mon Nov 11 10:38:35 HKT 2013

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 at webb-johnson.net>
Reply-To:  OVMS Developers <ovmsdev at lists.teslaclub.hk>
Date:  Sunday, November 10, 2013 at 5:33 PM
To:  OVMS Developers <ovmsdev at 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 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.hkhttp://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/20131110/6eca9ece/attachment.htm>