Hello, we are using the L76L-M33 in an embedded device, and since 2034 is only 8 years away, I wonder if there will be firmware updates to support the 13-bit week counter of CNAV?
Thanks!
And a second question:
What is the exact date the roll-over in 2034 will take place? Aug 6? 13?
Hi @Wettervik
Thank you for reaching out
Once the counter reaches its flip time, the module will directly use the time of the other Constellation for display. If is using only GPS, then the counter will restart from the beginning. The Module will still be able to fix position.
The exact date of the roll-over is not known, let me check with my internal team and i will get back to you
Best regards
Thank you! The fact that the module will still be able to get a fix, and therefore assumingly report speed-over-ground, is a relief!
As regards time information, this is probably easy to correct, if it falls back exactly 1024 weeks.
Another issue though: Currently, I use packet PMTK740 (send UTC to the module) to aid the module to find a fix faster. May I assume that I need to “falsify” this time by subtracting 1024 weeks after the roll-over?
Thank you!
Tomas
The UTC time in packet PMTK740 is actually convert from the GPS time. Even if GPS Time resets internally (for example, during a rollover), the module knows the correct date and time from the satellite signals and keeps the UTC time accurate. So, there is no need to falsify the UTC time
My question was worded a bit misleading, I appologize: What I meant was:
After the roll-over in August 2034, the module will think the date is somewhere in December 2014.
In order to speed up TTFF, I am now sending a packet 740 with UTC to the module which works fine.
The module does not accept a packet 740 with a date beyond 2034, even before it has a fix, I tested this already.
The question was: Will it help for TTFF, AFTER August 2034, to send a packet 740 with “UTC minus 1024 weeks”?
Hi @Wettervik
In order for me to assist you, may i know how you verified that PMTK 740 is not accepted beyond 2034.
what changes you made to simulate 2034 and beyond.
I tested this by shielding the module from any GPS signals, powering it on (it has no battery backup), and sending the 740 packet with a date later than 2034. It was not accepted, the date shown in the RMC and ZDA sentences was 1980.
Correction: It does not accept any date past 2038 (not 2034).
To be exact: Dates starting from Nov 21, 2038 are rejected. This is the date of the next GPS week rollover. (Interestingly, the module’s internal clock correctly switches over to Nov 21, 2038, after setting Nov 20, 2038, 23:59. So the internal clock works correctly beyond the GPS week rollover.)
Something is not right here:
-
Quectel release notes state Aug 2034 as a roll-over date, which allows the assumption that the firmware uses a week-offset of 800 (to overcome the 2019 rollover?)
-
What about the time between 2034 and 2038? It seems like I could help the module after Aug 2034 (until Nov 20, 2038) to cope with an internal rollover by supplying packet 740. No idea if that works, and if the module can properly deduct the week number modulo 1024 from that date. But at least the packet is not rejected.
-
After Nov 20, 2038, however, I canNOT help the module anymore - unless I deduct 1024 weeks from the then current date (which is what I meant by “falsify”).
If I would be writing a firmware for this module, I would allow the user to send ANY date through the 740 packet and deduct the roll-over period from the given date.
To limit the date one can send through packet 740 appears wrong to me.
Hi @Wettervik
Thank you for the detailed testing feedback
Can you provide more info regarding your current project? I will bring this up to my internal for further discussion.
- Project name (so we can refer to it in the future):
- Application type:
- Estimated Annual Units (for series production):
- Project timeline:
- Current status:
You can send these details through email below:
yong.huang@quectel.com
Best regards,