Hi Well, we’re not talking about $9 parts here. Typical prices in the $500 to $2,000 in quantity would be a better description. That said, the OEM’s normally saw the field upgrade process as a bigger risk than not getting involved in it …..
Bob > On Dec 21, 2020, at 7:51 PM, Magnus Danielson <mag...@rubidium.se> wrote: > > Hi Bob, > > Yes, there is even receivers with no know way of upgrade in the field. > But this framework was not meant to make all receivers meet the > requirements, rather the opposite, the unofficial class of level 0 is > most of those receivers. If level 1 or higher is needed for critical > infrastructure of any kind, vendors aiming to sell to that market needs > to adapt. Getting a 9 USD module from some obscure vendor just won't cut > it. Also, if there is a way to clear the NV memory on the module, the > way the module is wrapped into another device must maintain the ability > to clear the NV. So would be true for the ability to upgrade for those > needing to meet that requirement. > > I take some pride in the upgrade requirement. It ripples over from the > NASPI TSTF report where I contributed such formulations. I also > advocated for it in this work. It comes from bitter experience. Very > bitter. Luckily for me, I did not have to do the major part of > suffering, but I was there to see the troubles on multiple times. > > For the reset thing, that came from another source, where jamming caused > some mobile phones to loose capability, which was a kind of bitter > experience considering they where meant to illustrate the problem, not > to brick peoples devices. So that was also bitter experience. Especially > the air-safety folks was very keen to have a way to make devices go back > to well behaved maner after the event, and by manual methods in the > field. I think it is a wise way of reasoning. > > Also, this is a framework, and these are the common minimum requirement. > This is not ruling out that for some application the requirements may be > more detailed and stricter in some sense. For instance, the actual > performance may differ, or the time to recovery from factory default > restart or time to fix in normal setting. While Time To Fix had lots of > focus initially, we concluded that it was actually not the parameter of > greatest importance here, as that has already improved a lot, but other > properties may dominate. > > Cheers, > Magnus > > On 2020-12-21 20:08, Bob kb8tq wrote: >> 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. > > _______________________________________________ > 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.