GPS STOPPING OPERATION APRIL 6TH 2019

[P4PCommander]

Should I Be Concerned?
Because this it is the second time the GPS week rollover will occur, many receiver manufacturers have prepared for it, and newer receivers will continue to operate without issue.
You should be concerned, though, if either of the following applies:

• Receiver has been fielded for more than 10-15 years without firmware updates
• Receiver is a core component of a critical timing system – ask yourself – what is the impact to my system if the GPS receiver stopped operating or put out wrong GPS or UTC information

In these cases, we want to verify that an issue will not occur. At a minimum, we recommend consulting your receiver manufacturer to confirm that the issue has been fully tested and will not occur. Many manufacturers have already issued compliance statements, and we expect them to continue to do so over the next year, up until the event occurs. To be sure that your system will not experience any failures related to this issue, it is possible to test for this event using a GPS/GNSS simulator. The requirements for the simulator are.... We need to find out if DJI has prepared for this!! THIS IS A VERY SERIOUS SITUATION.....I KNOW OUR MILITARY IS VERY CONCERNED ABOUT THIS BECAUSE OF OLDER EQUIPMENT!!!! MISSLES, ROCKET'S ETC.....

 

[N017RW]

Your title is alarmist and flat-out incorrect.

The issue is handled at the GPS Engine level (in bold text). DJI has no control over it.

ublox, the vendor of the engine says this below:
(at it's website here: http://ultran.ru/sites/default/files/u-bloxm8-v15_receiverdescriptionprotocolspec_public.pdf)

Week Number Rollover GPS Time is a continuous counting time scale beginning at the January 5, 1980 to January 6, 1980 midnight. It is split into two parts: a time of week measured in seconds from midnight Sat/Sun and a week number. The time of week is transmitted in an unambiguous manner by the satellites, but only the bottom 10 bits of the week number are transmitted. This means that a receiver will see a week number count that goes up steadily until it reaches 1023 after which it will "roll over" back to zero, before steadily going up again. Such a week rollover will occur approx. every 20 years. The last week rollover occurred in 1999 and the next one will be in 2019. It is up to the GPS receiver to correctly handle such the ambiguity of the transmitted week numbers and the associated rollovers.

u-blox GNSS receivers solve this problem by assuming that all week numbers must be at least as large as a reference rollover week number. This reference rollover week number is hard-coded into the firmware at compile time and is normally set a few weeks before the s/w is completed, but it can be overridden by the wknRollover field of the UBX-CFG-NAVX5 message to any value the user wishes. The following example illustrates how this works: Assume that the reference rollover week number set in the firmware at compile time is 1524 (which corresponds to a week in calendar year 2009, but would be transmitted by the satellites as 500). In this case, if the receiver sees transmissions containing week numbers in the range 500 ... 1023, these will be interpreted as week numbers 1524 ... 2027 (CY 2009 ... 2019), whereas transmissions with week numbers from 0 to 499 are interpreted as week numbers 2028 ... 2526 (CY 2019 ... 2029).

BeiDou and Galileo have similar representations of time, but transmit sufficient bits for the week number not to be ambiguous for the forseeable future. GLONASS has a different structure, but again transmits sufficient information to avoid any rollover during the expected lifetime of the system.

Bottom Line- The oldest DJI product is is about 6 years old and manufacturers are well aware of this and taken the steps necessary.

No Worries!!!

Cheers.

 

[wa5tef]

Your title is alarmist and flat-out incorrect.

The issue is handled at the GPS Engine level (in bold text). DJI has no control over it.

ublox, the vendor of the engine says this below:
(at it's website here: http://ultran.ru/sites/default/files/u-bloxm8-v15_receiverdescriptionprotocolspec_public.pdf)

Week Number Rollover GPS Time is a continuous counting time scale beginning at the January 5, 1980 to January 6, 1980 midnight. It is split into two parts: a time of week measured in seconds from midnight Sat/Sun and a week number. The time of week is transmitted in an unambiguous manner by the satellites, but only the bottom 10 bits of the week number are transmitted. This means that a receiver will see a week number count that goes up steadily until it reaches 1023 after which it will "roll over" back to zero, before steadily going up again. Such a week rollover will occur approx. every 20 years. The last week rollover occurred in 1999 and the next one will be in 2019. It is up to the GPS receiver to correctly handle such the ambiguity of the transmitted week numbers and the associated rollovers.

u-blox GNSS receivers solve this problem by assuming that all week numbers must be at least as large as a reference rollover week number. This reference rollover week number is hard-coded into the firmware at compile time and is normally set a few weeks before the s/w is completed, but it can be overridden by the wknRollover field of the UBX-CFG-NAVX5 message to any value the user wishes. The following example illustrates how this works: Assume that the reference rollover week number set in the firmware at compile time is 1524 (which corresponds to a week in calendar year 2009, but would be transmitted by the satellites as 500). In this case, if the receiver sees transmissions containing week numbers in the range 500 ... 1023, these will be interpreted as week numbers 1524 ... 2027 (CY 2009 ... 2019), whereas transmissions with week numbers from 0 to 499 are interpreted as week numbers 2028 ... 2526 (CY 2019 ... 2029).

BeiDou and Galileo have similar representations of time, but transmit sufficient bits for the week number not to be ambiguous for the forseeable future. GLONASS has a different structure, but again transmits sufficient information to avoid any rollover during the expected lifetime of the system.

Bottom Line- The oldest DJI product is is about 6 years old and manufacturers are well aware of this and taken the steps necessary.

No Worries!!!

Cheers.

Very interesting information! Thanks for sharing.
Jim
WA5TEF

 

[Bigbadbob76]

Anyone remember the panic about the "Y2K bug", hard to believe that was 19 years ago.
I had to leave my handheld GPS outside for 24hrs while it updated it's ephemeris data, it was fine after that and still works today.
It might even still work after this rollover too. But it's old and slow compared to modern systems like the Ublox.

 

[Russ43Phantom]

With all car GPS, military GPS, drone GPS, shipboard navigation GPS, ... and the list keeps going on ..., one can't possibly image that the government would, in any way, allow a discontinuity in GPS service.

 

[Bad Andy]

Anyone remember the panic about the "Y2K bug", hard to believe that was 19 years ago.

The company where I worked at the time, put millions into preventing Y2K issues. It went great. Then a mainframe batch job ran a week later and deleted every record in a major database. LULz all around.

With all car GPS, military GPS, drone GPS, shipboard navigation GPS, ... and the list keeps going on ..., one can't possibly image that the government would, in any way, allow a discontinuity in GPS service.

Some fact and some conjecture...
Could the US switch off our access to GPS?

(and an older article)
White House wants plans for GPS shutdown

Now, after reading all that, something from the proverbial horse's mouth:
GPS.gov: Selective Availability

Don't worry. The US government would never, ever lie.

That said, if the poo hits the fan in some way that compels governments to turn off their GPS services, I think that our drones and car nav systems and such are probably gonna be the least of our worries.

 

[solentlife]

Anyone remember the panic about the "Y2K bug", hard to believe that was 19 years ago.
I had to leave my handheld GPS outside for 24hrs while it updated it's ephemeris data, it was fine after that and still works today.
It might even still work after this rollover too. But it's old and slow compared to modern systems like the Ublox.

Sounds like my old Magellan !! The 24hrs outside bit was a way overkill but advised to make sure it did the job.

What the alarmists fail to appreciate is that this is just a repeat of 1999 - when the Date Rollover occurred then.

 

[solentlife]

With all car GPS, military GPS, drone GPS, shipboard navigation GPS, ... and the list keeps going on ..., one can't possibly image that the government would, in any way, allow a discontinuity in GPS service.

It was a while back ... actually just after Presidential Decree to switch of SA ... the question of funding of GPS was in question. It's part of the reason other countries started developing own systems ... Europe, China and India in particular.
The USAF and US interests who had the job of maintaining the system - NEVER and STILL DO NOT receive any fees or commissions from any commercial use of the GPS system. It got so bad in fact - that only NOW are they catching up with the delayed maintenance / replacement / updated sats schedule. It truly is one of the few things in life that's free !

 

[Bigbadbob76]

Does the P4P not use GLONASS as well as GPS?
I know my P3S doesn't but I'm Pretty sure the later models do.
Anyone happen to know when the week No. rollover is for GLONASS?

 

[sar104]

Does the P4P not use GLONASS as well as GPS?
I know my P3S doesn't but I'm Pretty sure the later models do.
Anyone happen to know when the week No. rollover is for GLONASS?

GLONASS uses a different encoding for the date - it doesn't have this issue.

Not that any modern GPS chipset is going to be affected by it anyway.