[Ovmsdev] Time variable

Stephen Casner casner at acm.org
Thu Nov 7 13:44:40 HKT 2019


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
>
>


More information about the OvmsDev mailing list