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 <http://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@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",@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@webb-johnson.net <mailto:mark@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@acm.org <mailto:casner@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... <https://www.cika.com/soporte/Information/GSMmodules/GPS-week-rollover_Simcom.pdf> <https://www.cika.com/soporte/Information/GSMmodules/GPS-week-rollover_Simcom... <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@acm.org <mailto:casner@acm.org>> wrote:
This page mentions the problem:
https://techship.com/news/gps-week-roll-over-issue-during-epoch-restart/ <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 <https://www.fasttech.com/products/1020200>) > > Stephen Casner <casner@acm.org <mailto:casner@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... <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-dow... >> >> 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@lists.openvehicles.com >> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >> > > > -- > Üdvözlettel: > Kovács Tamás
OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev