Issue seems currently limited only to GT g3 / Mediatek MT3333 ... with <3.2 GPS firmware. Issue shouldn't affect later Blues with newer module. Now, I'm guessing, since I'm not that experienced with GPS, and way behind on technology, but:
Just thinking with fingers here... 
Personally, I think those lower version GT/MT had a bad 'birth date', or whatever it's called, as this lot seems to be March, 2003... whatever they certainly had the vulnerability not to roll over, running exactly 1024 wks.
Reds Haven't apparently done 1024 wks, from their 'birth' of the older GT module but, if they're going to be affected, I'd suggest anytime between now and before about 2029, assuming they were 'birthed' in 2010 or erlier, and assuming they have original GT firmware... .
Another thought,
Since WE built, and initialized / activatedthe
REDS ourselves, it may be that that would start when we first powered our
reds up... hmmm... maybe could check that. So, if I activated my Red 689 in 2013(?) that might mean I could expect issues about 2032 or something...The
BLUES were 'factory' built, initialized in 'batches', and perhaps somewhere along certain modules were either 'glitched' from the git-go, or initialized with error ... just thinking out loud about why older
reds aren't whackin out while but oldest
blues are.
Keeping in mind that the 1024 weeks for a device, has nothing to do with the GPS epoch time, but the count begins when the 'device' determined it was 'born'... or whatever the technical stuff really is... Some devices have a command that can reset the 'RTC' (real time clock), (which is different from the 'GPS' satellite time signals, I understand) , but these don't seem to have been published anywhere that I could find.
So... the Blitz FW 9.3 just published for both Reds and Blues, effectively tells the controller to 'ignore' the RTC from the GPS module. It actually has little effect on computation anyway, but the controller doesn't like the bad time..... The computation server uses the computing server's RTC, against the 'receiving server's RTC, ... using the station's known, 'DNA' (sieve), firmware, antenna type, location, filter settings, operating mode,etc.
The controller, at least yesterday, was showing the 'bad date/time' on sigs page, and 'bad date/time' on Status Page, since, so far, the new firmware hasn't told the controller to fix it, just igno the GPS error for the 'watchdog'... I think. ??? Doesn't affect sigs sent, just allows them to be sent, instead of suppressed.
This means we should make darn sure our configuration for the controller is absolutely as accurate and stable as possible.. antenna type and manual mode with as few automatics as possible. Everything computed is 'relative' to other receivers, so we want ours stable, and hopefully 'theirs'will be also. Egon has been hinting at operators using only manual mode, as have I and some others, for several years now, and letting the system / network work as it's designed, with 'stable' stations, not with widely varying gains and band widths, etc.... also if we DON'T send noise signals, and go interference as designed, the smarter algorithms now used won't get smarter...
End of brain hurricane.
Mike
