[Ovmsdev] Time variable

Mark Webb-Johnson mark at webb-johnson.net
Thu Nov 7 14:13:37 HKT 2019


The issue is that we don’t have week numbers from the GPS (and presumably week to date is non-trivial).

We get the date/time from the NMEA RMC message, then pass it into this to convert to a julian date/time:

/**
 * utc_to_timestamp:
 *  convert GPS date & time (UTC) to timestamp
 *   date: "ddmmyy"
 *   time: "hhmmss"
 */
static unsigned long utc_to_timestamp(const char* date, const char* time)
  {
  int day, month, year, hour, minute, second;

  day = (date[0]-'0')*10 + (date[1]-'0');
  month = (date[2]-'0')*10 + (date[3]-'0');
  year = (date[4]-'0')*10 + (date[5]-'0');

  hour = (time[0]-'0')*10 + (time[1]-'0');
  minute = (time[2]-'0')*10 + (time[3]-'0');
  second = (time[4]-'0')*10 + (time[5]-'0');

  return
    (JdFromYMD(2000+year, month, day) - JDEpoch) * (24L * 3600)
      + ((hour * 60L + minute) * 60) + second;
  }

Perhaps sufficient to add 1024 * 7 * 86400 to that?

Regards, Mark.

> On 7 Nov 2019, at 1:44 PM, Stephen Casner <casner at acm.org> wrote:
> 
> Mark,
> 
> You don't need the condition "date <2019-11-03", just always add 1024
> weeks to the current time value coming from the modem.
> 
>                                                        -- Steve
> 
> On Thu, 7 Nov 2019, Mark Webb-Johnson wrote:
> 
>> Damn:
>> 
>> https://www.cika.com/soporte/Information/GSMmodules/GPS-week-rollover_Simcom.pdf <https://www.cika.com/soporte/Information/GSMmodules/GPS-week-rollover_Simcom.pdf>
>> 
>> I think we can do a fix in the SIMCOM module that if the date <2019-11-03 then offset it somehow? Any ideas?
>> 
>> Regards, Mark.
>> 
>>> On 7 Nov 2019, at 1:09 PM, Stephen Casner <casner at acm.org> wrote:
>>> 
>>> This page mentions the problem:
>>> 
>>> https://techship.com/news/gps-week-roll-over-issue-during-epoch-restart/
>>> 
>>> Quoting there:
>>> 
>>>   For the Qualcomm MDM9x15 series (4G/LTE Cat 3) and MDM6200
>>>   (3G/HSPA+) series chipsets there is a offset used, so the GPS week
>>>   roll over will occur 1054+1023 weeks since launch of the GPS, and
>>>   more precisely in beginning of November 2019 (UTC 23:59:42
>>>   November 2, 2019)
>>> 
>>>   [snip]
>>> 
>>>   3G/HSPA+ modules based on Qualcomm MDM6200 series chipsets:
>>>   Huawei EM820W / MU609 series
>>>   Telit DE910 series
>>>   Simcom SIM5320 series
>>> 
>>> This sounds like the hardware/firmware won't be fixed.  Perhaps the
>>> solution for OVMS is just to put an offset as a workaroud.  That will
>>> work for the next 1024 weeks.
>>> 
>>>                                                       -- Steve
>>> 
>>> On Wed, 6 Nov 2019, Stephen Casner wrote:
>>> 
>>>> Sorry, I did not read carefully.  The item you mentioned is just an
>>>> antenna.  The GPS implementation is in the modem module, correct?
>>>> That's where the correction is needed.
>>>> 
>>>>                                                       -- Steve
>>>> 
>>>> On Thu, 7 Nov 2019, Tamás Kovács wrote:
>>>> 
>>>>> I use a universal gps connected to ovms, not the car own gps. (
>>>>> https://www.fasttech.com/products/1020200)
>>>>> 
>>>>> Stephen Casner <casner at acm.org> ezt írta (időpont: 2019. nov. 7., Cs, 0:42):
>>>>> 
>>>>>> Tamás,
>>>>>> 
>>>>>> This looks like the GPS sensor did not handle the rollover of the
>>>>>> 10-bit week-number field in April, 2019.  So the timestamps are off by
>>>>>> 1024 * 7 * 24 * 60 * 60 seconds.  Here is the US government alert about
>>>>>> this problem:
>>>>>> 
>>>>>> 
>>>>>> https://www.us-cert.gov/sites/default/files/documents/Memorandum_on_GPS_2019.pdf
>>>>>> 
>>>>>> This problem was recently discovered for the Garmin GPS 18x LVC
>>>>>> sensors in the Tesla Roadster 2.5 (but not in the earlier 1.5 version
>>>>>> like I have, which has the older GPS 18 LVC sensor):
>>>>>> 
>>>>>> 
>>>>>> https://teslamotorsclub.com/tmc/threads/caution-annual-service-car-power-down-gps-issue.163328/
>>>>>> 
>>>>>> There is a firmware update to fix this for the GPS 18x LVC.  Perhaps
>>>>>> there is one for the GPS sensor in the Mitsubishi as well.
>>>>>> 
>>>>>>                                                       -- Steve
>>>>>> 
>>>>>> On Wed, 6 Nov 2019, Tamás Kovács wrote:
>>>>>> 
>>>>>>> I have a problem with utc time, the time is correct but the date is not
>>>>>>> valid. I use 3.2.005-99-g88cfeef9 version with modification of Mitsubishi
>>>>>>> i-MiEV.
>>>>>>> 
>>>>>>> OVMS# me li utc
>>>>>>> m.time.utc                               953756768Sec
>>>>>>> I (900675) housekeeping: 2000-03-22 21:27:06 CET (RAM: 8b=82812-86452
>>>>>> 32b=27308)
>>>>>>> I (981115) webserver: HTTP POST /api/execute
>>>>>>> I (981115) webcommand: HttpCommandStream[0x3fa32958]: 1984428 bytes
>>>>>>> free, executing: time
>>>>>>> OVMS# time
>>>>>>> Time Zone:  CET-1CEST,M3.5.0,M10.5.0/3
>>>>>>> UTC Time:   2000-03-22 20:28:27 UTC
>>>>>>> Local Time: 2000-03-22 21:28:27 CET
>>>>>>> Provider:   gsm-nmea
>>>>>>> 
>>>>>>> PROVIDER             STRATUM  UPDATE TIME
>>>>>>> *gsm-nmea                  2       0 Wed Mar 22 20:28:27 2000
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Üdvözlettel:
>>>>>>> Kovács Tamás_______________________________________________
>>>>>> OvmsDev mailing list
>>>>>> OvmsDev at lists.openvehicles.com
>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Üdvözlettel:
>>>>> Kovács Tamás
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

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


More information about the OvmsDev mailing list