[Ovmsdev] Time variable
Tamás Kovács
kommykt at gmail.com
Fri Nov 8 00:42:35 HKT 2019
Resolv the problem.
Mark Webb-Johnson <mark at webb-johnson.net> ezt írta (időpont: 2019. nov. 7.,
Cs, 7:41):
>
> Tamás, I’ve committed this fix to our simcom driver (relatively easy as we
> only support SIM5360 currently). It is on api.openvehicles.com OTA as:
>
> 3.2.005-102-g1a4364f
>
>
> Please try and let us know if it resolves this for you.
>
> Regards, Mark.
>
> P.S. Thanks for noticing and raising this so quickly.
>
> On 7 Nov 2019, at 2:27 PM, Mark Webb-Johnson <mark at webb-johnson.net>
> wrote:
>
> Like this (experiment):
>
> $ ./t.pl
> UTC original = Wed Mar 22 20:28:27 2000
> UTC adjusted = Wed Nov 6 20:28:27 2019
>
> $ cat t.pl
> #!/usr/bin/perl
>
> use POSIX qw(strftime);
> use Time::Local;
>
> my @original = (27,28,20,22,3-1,2000-1900,0);
>
> print "UTC original = ", strftime("%a %b %e %H:%M:%S %Y", at original),"\n";
> my $jdt = timegm(@original);
> my $ajdt = $jdt + (1024 * 7 * 86400);
>
> my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = gmtime($ajdt);
> print "UTC adjusted = ", strftime("%a %b %e %H:%M:%S
> %Y",($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst)),"\n";
>
>
> @Tamás: Does the above adjustment show the correct date/time (Wed Nov 6
> 20:28:27 2019 UTC)?
>
> Regards, Mark.
>
> On 7 Nov 2019, at 2:13 PM, Mark Webb-Johnson <mark at webb-johnson.net>
> wrote:
>
>
> 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
>
>
>
> _______________________________________________
> 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
>
--
Üdvözlettel:
Kovács Tamás
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20191107/8a38a669/attachment.html>
More information about the OvmsDev
mailing list