Re: [time-nuts] LN RB
(Forwarded message from Said below) -Original Message- From: Said Jackson [mailto:saidj...@jackson-labs.com] Sent: Tuesday, February 05, 2019 4:25 PM To: 'John Miles'; 'Discussion of precise time and frequency measurement' Subject: RE: [time-nuts] LN RB Gents, We have to also put this into perspective. We put a large number of configuration capabilities into the unit to be able to optimize it just for this type of thermally challenging application, and those options have not been explored yet. In particular the loop time constants can be simply set with the SERV:MODE commands (user manual section 3.10.2), and by default the setting is SLOW as we assume stationary laboratory conditions with only typical AC excursions and want to provide the absolute maximum ADEV and PN performance under typical laboratory conditions. As Johns testing shows, the unit is extremely stable even when not shielded from airflow and experiencing windows with -2C outside air temp being opened in the room etc. We do not optimize the unit to be thermally shocked from 25C to 65C+ by default, but alas it is very easy to use the above pre-configured settings, or to even come up with more aggressive loop settings to accommodate such extreme environmental conditions. In this case, none of these options were explored, and the results should be predictable based on knowing that the OCXO has a thermal stability of +/-10ppb from -20C to +70C and the default loop time constants go out to 30+ minutes, and the unit was thermally shocked with much faster time constants. The math becomes very simple with this information about the default settings. We also describe much more aggressive loop settings than the FAST setting in Table 2.6 in the user manual. These could be explored to guarantee that the loop time constants remain significantly faster than the expected thermal gradients, which guarantees that the loop is able to keep the OCXO on-phase with the Rubidium oscillator during thermal excursions. We cannot cheat physics here, but with almost 10x difference in the loop time constant options between the default SLOW and the FAST settings as described in Table 2.6 it is not surprising that the unit does not perform well when not properly configured for a particular environment. Also, as John mentioned - there are potentially other issues in that particular unit, and it's hard to judge without having access to comprehensive log file information. Bye, Said -- -- john, KE5FX Miles Design LLC > -Original Message- > From: time-nuts [mailto:time-nuts-boun...@lists.febo.com] On Behalf Of > AC0XU (Jim) > Sent: Monday, February 04, 2019 7:31 PM > To: time-nuts@lists.febo.com > Subject: [time-nuts] LN RB > > John- > > The LNRB had been powered on continously for several weeks prior to my > tests. Also, the same antenna/LNA is feeding multiple GPSDOs (4 others) > with Lady Heather connected and running continuously, and none of them > exhibited any kind of strange behavior at the times of the anomalies in the > LN RB timing. > > It certainly appears that Jackson Labs did not design the LN RB to be stable in > the presence of external temperature fluctuations. To be useful, this seems > to imply that it needs an external environmental temperature control. > Furthermore, it doesn't seem to be stable near the top end of its supported > temperature range even when the external temperature is constant, so the > external temperature needs to be fairly low (probably under 40C or so). One > application I was interested in is a low SWaP timing reference for smallsats. > Its sensitivity to temperature seems to make that application unlikely, > because adding external temperature control would make the electrical > power prohibitive, even if size and weight can be kept under control. As a > lab reference, I expect I can implement an external temperature control and > it may work well enough. Overall, I am very disappointed with the product. I > have written to Jackson Labs about my concerns but I have not heard back > from them. > > Jim > ___ 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] Att: Hugh Rice
This is a note of Encouragement. Best Regards Ulf KylenfallOnsalaSweden ___ 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] Auto-fail-over switch
Would this work? http://www.wenzel.com/wp-content/parts/501-09371.pdf I have few of these, they have good enough PN to be used as run-around reference source for measurements: http://www.ebay.com/itm/16307191 Leo > From: Jeff Blaine > > Wondered if anyone had seen some sort of gadget that would look to see > if there was a 10 Mhz signal and switch a relay (or provide some other > output) in the absence?? I would like to cook up some sort of fail over > switch without having to do much actual work. :) ___ 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] GPS Weekly Rollover Fail
This will be my Z3801A's second rollover and its third 1024-week epoch. Is there any pre-1980 GPS equipment still out there that will be undergoing a third rollover and fourth 1024-week epoch? Was the 1978-1979 Block 1 GPS usage, using a different base date, or were there more fundamental changes in 1980? The Block 1 birds were still in use in the 1990's. Tim N3QE On Wed, Feb 6, 2019 at 8:18 AM Bob kb8tq wrote: > Hi > > One would *hope* that everybody making multi GNSS modules would be cross > checking > and taking care of GPS rollover that way. It’s always nice to see them > explicitly stating > that they are doing it. > > Bob > > > On Feb 6, 2019, at 12:57 AM, Michael Wouters > wrote: > > > > BeiDou, Galileo and GLONASS all broadcast UTC time of day (or thereabouts > > for GLONASS - it's offset by the timezone for Moscow) so any multi-GNSS > > receiver has a sanity check on UTC calculated from GPS. > > > > Michael > > > > On Wed, 6 Feb 2019 at 11:03 am, Bob kb8tq wrote: > > > >> Hi > >> > >> From what I can see, you can send it a command that puts a new “oldest > >> date” > >> number into flash. Since it also tracks Glonass and Galileo, that will > >> stretch out the > >> time before you *need* to do something (like into the next century). > They > >> also have > >> the “no dates before the firmware was issued” check. There may be other > >> date > >> checks in there. Those are just what I’ve found so far. > >> > >> It also is likely that the “new” GPS sats will be flying within 19 > years. > >> That will add > >> more bits to the GPS time fields. Who knows if the “modern” modules > >> already handle > >> those bits or not …. > >> > >> Bob > >> > >>> On Feb 5, 2019, at 5:23 PM, Hal Murray > wrote: > >>> > >>> > >>> kb...@n1k.org said: > The F9P has multiple cross checks, traps, and even a user configurable > “oldest possible date” entry. > >>> > >>> Neat/thanks. > >>> > >>> Is that stored in flash, or lost on power cycle? > >>> > >>> If it's in flash, I can "fix" things for another 20 years by extracting > >> the > >>> device from its box, taking it to a bench setup, running a flash-update > >>> program, then reassembling things. As ugly as that is, it may be > >> simpler than > >>> updating the firmware in the box. > >>> > >>> > >>> -- > >>> 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. > > > ___ > 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] GPS Weekly Rollover Fail
Hi One would *hope* that everybody making multi GNSS modules would be cross checking and taking care of GPS rollover that way. It’s always nice to see them explicitly stating that they are doing it. Bob > On Feb 6, 2019, at 12:57 AM, Michael Wouters > wrote: > > BeiDou, Galileo and GLONASS all broadcast UTC time of day (or thereabouts > for GLONASS - it's offset by the timezone for Moscow) so any multi-GNSS > receiver has a sanity check on UTC calculated from GPS. > > Michael > > On Wed, 6 Feb 2019 at 11:03 am, Bob kb8tq wrote: > >> Hi >> >> From what I can see, you can send it a command that puts a new “oldest >> date” >> number into flash. Since it also tracks Glonass and Galileo, that will >> stretch out the >> time before you *need* to do something (like into the next century). They >> also have >> the “no dates before the firmware was issued” check. There may be other >> date >> checks in there. Those are just what I’ve found so far. >> >> It also is likely that the “new” GPS sats will be flying within 19 years. >> That will add >> more bits to the GPS time fields. Who knows if the “modern” modules >> already handle >> those bits or not …. >> >> Bob >> >>> On Feb 5, 2019, at 5:23 PM, Hal Murray wrote: >>> >>> >>> kb...@n1k.org said: The F9P has multiple cross checks, traps, and even a user configurable “oldest possible date” entry. >>> >>> Neat/thanks. >>> >>> Is that stored in flash, or lost on power cycle? >>> >>> If it's in flash, I can "fix" things for another 20 years by extracting >> the >>> device from its box, taking it to a bench setup, running a flash-update >>> program, then reassembling things. As ugly as that is, it may be >> simpler than >>> updating the firmware in the box. >>> >>> >>> -- >>> 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. ___ 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] GPS Weekly Rollover Fail
BeiDou, Galileo and GLONASS all broadcast UTC time of day (or thereabouts for GLONASS - it's offset by the timezone for Moscow) so any multi-GNSS receiver has a sanity check on UTC calculated from GPS. Michael On Wed, 6 Feb 2019 at 11:03 am, Bob kb8tq wrote: > Hi > > From what I can see, you can send it a command that puts a new “oldest > date” > number into flash. Since it also tracks Glonass and Galileo, that will > stretch out the > time before you *need* to do something (like into the next century). They > also have > the “no dates before the firmware was issued” check. There may be other > date > checks in there. Those are just what I’ve found so far. > > It also is likely that the “new” GPS sats will be flying within 19 years. > That will add > more bits to the GPS time fields. Who knows if the “modern” modules > already handle > those bits or not …. > > Bob > > > On Feb 5, 2019, at 5:23 PM, Hal Murray wrote: > > > > > > kb...@n1k.org said: > >> The F9P has multiple cross checks, traps, and even a user configurable > >> “oldest possible date” entry. > > > > Neat/thanks. > > > > Is that stored in flash, or lost on power cycle? > > > > If it's in flash, I can "fix" things for another 20 years by extracting > the > > device from its box, taking it to a bench setup, running a flash-update > > program, then reassembling things. As ugly as that is, it may be > simpler than > > updating the firmware in the box. > > > > > > -- > > 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.
