Hi I would guess that out of say 100 OEM’s using a GPSDO, at least 99 of them had *major* concerns about field upgrades. Their take was that supporting them had always turned into a disaster. No matter how clear the instructions, a significant number of systems went down / stayed down while sub assemblies were being upgraded …..
Pretty much the universal approach: Return the device to the factory and do any needed upgrades there. Test it / verify it works and send it back. Having sat through several of those exercises, I do not remember a single device that “bricked” when done that way. Bob > On Dec 21, 2020, at 9:56 AM, Magnus Danielson <mag...@rubidium.se> wrote: > > Hi, > > On 2020-12-21 09:02, Poul-Henning Kamp wrote: >> -------- >> Bob kb8tq writes: >> >>> I have seen cases of “goes away until power cycled”. I have not seen any >>> cases of >>> “goes away forever” other than the obvious ( = feed it an insane almanac >>> that prevents >>> if from ever locking up ). Even with that said, I have not seen an example >>> ot that sort of >>> thing living through a hard reset … ( which isn’t quite the same thing as a >>> power cycle ). >> I have: An corrupt alamanac in NV storage contained something which >> made a particular GPS receiver divide by zero, shit its pants and >> wedge during startup. >> >> The post mortem report said that the alamanac passed the "technical >> consistency checks", by which I suppose they mean the Hamming code, >> but it still caused a divide by zero. >> >> This incident is the reasons why GPS receivers in some critical >> applications are not allowed to have NV storage for "operational >> purposes" and get the almanac downloaded from the attached systems >> at startup. >> > With this new language, they would be required to be Level 1 compliant, > at which it would always be a way for the user to reset corrupt data in > the field. We never even discussed the possibility of prohibiting the > NV, rather we focused on the ability to recover in the field. NV has > it's upsides to boot quickly etc. but as any cache, it needs to be > clearable. > > In a similar sense, we also had a good discussion about being able to > upgrade the receiver. Several of us was driving hard to ensure that > receivers can be upgradeable in the field, so that bugs can be removed > continuously throughout the operational lifetime. In fact, I pointed out > that the operational lifetime should be limited by how long you can > maintain the receiver updated. The whole life cycle aspect is important > in that as you loose support on receivers, they should go out of service > for critical things. You should also make sure there is contracts on how > long they will be maintained. > > Cheers, > Magnus > > > _______________________________________________ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. _______________________________________________ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.