Re: [time-nuts] SMPS or conventional?
On 12/21/20 5:59 PM, Gerhard Hoffmann wrote: Both agree that ripple > 1 KHz is harmless. But then the current delivered to the TEC is quite large usually - and It's a different question if you want such large and dirty currents on your table or in your device. Yes.. we were testing a sensitive receiver for 5-30 MHz, and were thinking the TEC would be the best way to step it through the temperature sequence for calibration. Even with the receiver in a box, and coax for the test signal, the noise from the PWM completely obliterated the signals of interest. On the other hand, we used that same TEC unit to run simulated lunar regolith up and down in temperature, hooked up to a gas analyzer. That was fine. https://tetech.com/product-category/temperature-controllers/ ___ 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.
Re: [time-nuts] SMPS or conventional?
A properly-tuned PID system does not cycle! Dana On Mon, Dec 21, 2020 at 6:49 PM Bob kb8tq wrote: > Hi > > Finding a data sheet on a TEC that goes past *very* basic stuff is > essentially > impossible. The bottom line is that the people who make them very much > want to sell them to you. Finding information in those data sheets that > suggest > problems … not so much. > > The problem is (mainly) physical. The expansion / contraction of the > device is > a big deal. KHz level PWM is (likely) not a problem. Aggressive cycling > from > something like a PID is indeed an issue. > > Bob > > > On Dec 21, 2020, at 6:43 PM, Hal Murray wrote: > > > > [Old mail, context is TECs] > > > > bruce.griffi...@xtra.co.nz said: > >> If the drive current ripple is too high fatigue failure from cyclic > >> thermomechanical stress can be significant. > > > > Do good data sheets say anything about that? > > > > Is there a frequency term in there? Can I use PWM, which is as much > ripple as > > you can get, as long as the frequency is high enough? If yes, ballpark > of how > > high? > > > > Physically, where is the heat/cold generated? Is it mostly at the > junction? > > > > -- > > These are my opinions. I hate spam. > > > > > > > > > > ___ > > 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.
Re: [time-nuts] DHS Resilient PNT Conformance Framework
Hi Bob, Sure, but I think some of these requirements will be met for fairly cheap devices soon enough. Another aspect we also discussed is that while a module on its own may not do all the things needed to meet a level, if it has sufficient of capabilities to support additional checks and then those is performed outside, the system they form may achieve the higher level requiring the function. So, with sufficiently open interface to key state to monitor things, as we know several receiver has, then they can achieve that. Now, nothing have been detailed as to what to monitor and when to judge go/no-go, for any system, the framework is there to say that such mechanisms should be described, eventually. That may end up being a fun discussion. In the end, if this takes off, what it does is that it creates a market for devices to meet these requirements. In doing so, the intention is to make sure that there is a high level of commonality between the requirements for the different sectors of the same level. So, not that everyone invent their wheel, but rather they indicate their subset needing extra attention and jot down critical performance numbers for it to fit their environment. Having common threats/scenarios to test for among sectors have been discussed. Having common model for state-analysis of receivers have also been mentioned. Nothing decided. All there is, is to convey the general concepts and see if there is any takers to follow up. I think most importantly that a lot is achieved by trying to build a common ground like this. The framework as it stands is still vague, as little specifics is there. I expect more to come in the future. Cheers, Magnus On 2020-12-22 02:29, Bob kb8tq wrote: > 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 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 wrote: Hi,
Re: [time-nuts] SMPS or conventional?
Am 22.12.20 um 00:43 schrieb Hal Murray: [Old mail, context is TECs] bruce.griffi...@xtra.co.nz said: If the drive current ripple is too high fatigue failure from cyclic thermomechanical stress can be significant. Do good data sheets say anything about that? Is there a frequency term in there? Can I use PWM, which is as much ripple as you can get, as long as the frequency is high enough? If yes, ballpark of how high? Physically, where is the heat/cold generated? Is it mostly at the junction? The g**gl search for "TE coolers ripple current" delivers the first 2 hits of 3.65e6: < https://www.google.de/url?sa=t=j==s=web==2ahUKEwiQ4YK0tuDtAhWKCewKHckIALoQFjAAegQIBRAC=https%3A%2F%2Fwww.ii-vi.com%2Fwp-content%2Fuploads%2F2020%2F07%2FMRLW_Working_with_Thermoelectric_Materials.pdf=AOvVaw3pbUbFp4SsfdKsBzRNf-Wi > (that looks dangerous :-) and < https://www.ferrotec-nord.com/technology-of-thermoelectric-module/ > Both agree that ripple > 1 KHz is harmless. But then the current delivered to the TEC is quite large usually - and It's a different question if you want such large and dirty currents on your table or in your device. The thermal resistance between the hot and cold side is not very large and that explains part of the suboptimum efficiency. You do not want such a thing to regulate the temperature of a crystal etc because if you externally heat or cool one side, that will soon propagate to the other side; delta T stays constant until your regulator takes note and corrects it. Oh, and the google search shows that everybody and their dogs make TE controller chips. Gerhard ___ 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.
Re: [time-nuts] DHS Resilient PNT Conformance Framework
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 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 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 >>>
Re: [time-nuts] DHS Resilient PNT Conformance Framework
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 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 >>
Re: [time-nuts] SMPS or conventional?
Original source about TEC lifetime reduction when the TEC ripple cureent is high: https://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1991-02.pdf Page 74 I suspect that someone there may have been bitten by the short TEC life experienced without the LC filter. Although they used relatively small TECs the size of the individual Peltier element is the determining factor for the ripple current frequency dependence of TEC life. HP used a 40kHz PWM frequency. There should be a relatively uniform temperature gradient along the length of each Peltier element. TEC module datasheets are generally silent on the effect of ripple current on TEC lifetime. CUI merely indicate that keeping the TEC ripple current below 5% ensures that TEC performance is maximised. Peltier element solder junctions to the ceramic endplates usually fail after 3000 cycles or therabouts. CUI use a compliant thermally conductive adhesive to achieve a longer cycle life. Bruce > On 22 December 2020 at 12:43 Hal Murray wrote: > > > [Old mail, context is TECs] > > bruce.griffi...@xtra.co.nz said: > > If the drive current ripple is too high fatigue failure from cyclic > > thermomechanical stress can be significant. > > Do good data sheets say anything about that? > > Is there a frequency term in there? Can I use PWM, which is as much ripple > as > you can get, as long as the frequency is high enough? If yes, ballpark of > how > high? > > Physically, where is the heat/cold generated? Is it mostly at the junction? > > -- > These are my opinions. I hate spam. > > > > > ___ > 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.
Re: [time-nuts] SMPS or conventional?
Hi Finding a data sheet on a TEC that goes past *very* basic stuff is essentially impossible. The bottom line is that the people who make them very much want to sell them to you. Finding information in those data sheets that suggest problems … not so much. The problem is (mainly) physical. The expansion / contraction of the device is a big deal. KHz level PWM is (likely) not a problem. Aggressive cycling from something like a PID is indeed an issue. Bob > On Dec 21, 2020, at 6:43 PM, Hal Murray wrote: > > [Old mail, context is TECs] > > bruce.griffi...@xtra.co.nz said: >> If the drive current ripple is too high fatigue failure from cyclic >> thermomechanical stress can be significant. > > Do good data sheets say anything about that? > > Is there a frequency term in there? Can I use PWM, which is as much ripple > as > you can get, as long as the frequency is high enough? If yes, ballpark of > how > high? > > Physically, where is the heat/cold generated? Is it mostly at the junction? > > -- > These are my opinions. I hate spam. > > > > > ___ > 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.
Re: [time-nuts] SMPS or conventional?
[Old mail, context is TECs] bruce.griffi...@xtra.co.nz said: > If the drive current ripple is too high fatigue failure from cyclic > thermomechanical stress can be significant. Do good data sheets say anything about that? Is there a frequency term in there? Can I use PWM, which is as much ripple as you can get, as long as the frequency is high enough? If yes, ballpark of how high? Physically, where is the heat/cold generated? Is it mostly at the junction? -- These are my opinions. I hate spam. ___ 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.
Re: [time-nuts] DHS Resilient PNT Conformance Framework
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 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] FEI FE-5440A TO 49B3-36-2 missing page fill in......
Hello; I have a TD-1251/U USAF version of the FE-5440A Master clock. I have a photocopy of the manual however there are four errors: - Page 8-7 Fig 8-2 Sheet 2 of 2 - Page 8-31 Fig 8-10 3 of 3 - Page 8-69 Fig 8-22 - Page 8-75 Fig 8-24 Sheet 2 of 3 At a bare minimum I'd like even photos of page 8-7 Sheet 2 of 2. Can anyone please help fill those in with a paper copy or scan? Also there is an OP manual T.O. 49B3-36-1 which I do not have. Thanks! ___ 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.
Re: [time-nuts] DHS Resilient PNT Conformance Framework
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.
Re: [time-nuts] DHS Resilient PNT Conformance Framework
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. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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.
