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