Re: [time-nuts] 100 MHz decade divider advice needed
Am 30.11.19 um 02:10 schrieb Gerhard Hoffmann: Auto-follow-up: Why do you want crystal ovens in each stage when you lock it to something else anyway? Then something cheaper like these should do: < https://www.digikey.de/product-detail/de/crystek-corporation/CVHD-950-100.000/744-1213-ND/1644128 > My score on Morions from China was not so pleasant. .. and while I'm at it: < https://www.digikey.de/product-detail/de/nexperia-usa-inc/74LVC163PW118/1727-3097-1-ND/946754 > 150 MHz min @3V3, 200 MHz typ. Sorry, no DIL. 74ACT, 74F, 74AS are also dying. 74HCT is still there. regards, 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] Garmin 18x GPS WNRO, revisited
The Garmin 18x I have still works, and I verified it works after a power
cycle. I'm running firmware version 4.40.
Apparently all the 4.XX firmware versions are related to GPS week rollover
fixes. Earlier versions also have fixes for "improved" time keeping. Here
is the download link for 18X:
https://www8.garmin.com/support/download_details.jsp?id=4055
These are all the downloads for the 18x, including the Garmin tool
SNSRXCFG:
https://www8.garmin.com/support/collection.jsp?product=010-00321-31
This link from David might also be of interest:
https://www.satsignal.eu/ntp/Garmin-GSP18x-LVC-firmware-issue.htm
I've found the upgrade process to be a bit complicated, the upgrade
instructions didn't work for me. So this is what I did:
* set receiver at 9600 baud, power cycle
* with garmin utility, set receiver in garmin mode, power cycle
* run upgrade utility, power cycle,
After the upgrade I couldn't get the receiver back to NMEA mode, so I just
did it programmatically:
/* fd is the file descriptor pointing to the open file to the tty device
in RAW mode @ 9600 baud */
/* send_byte is a wrapper code to write() which handles timeouts and write
errors */
void garmin_set_nmea(int fd)
{
printf("==> garmin_set_nmea\n");
/*
* garmin binary command to switch to NMEA output
*/
int i;
unsigned char buffer[] = { 0x10, 0x0A, 0x02, 0x26, 0x00, 0xCE,
0x10, 0x03 };
for (i = 0; i < sizeof (buffer); i++)
send_byte(fd, buffer[i]);
}
-- Fio Cattaneo
Universal AC, can Entropy be reversed? -- "THERE IS AS YET INSUFFICIENT
DATA FOR A MEANINGFUL ANSWER."
-Original Message-
From: time-nuts On Behalf Of David J
Taylor via time-nuts
Sent: Friday, 29 November, 2019 10:28
To: Discussion of precise time and frequency measurement
Cc: David J Taylor
Subject: Re: [time-nuts] Garmin 18x GPS WNRO, revisited
From: Rich Wales
I may have found the answer to my own question.
I added "time1 619315200" to the "refclock" line in my ntp.conf file, and
restarted ntpsec, and it appears to be sane once again.
(And, of course, 619315200 = 7,168 days = 1,024 weeks.)
Rich Wales
ri...@richw.org
Thanks for reporting that, Rich. I haven't seen that issue with either
the
GPS18 LVC, or the GPS18x LVC, but neither have been powered down. Were
yours running continually? Anyway, I love the fix!
I'm running reference NTP here, and noted that with a type 22 PPS driver,
the "prefer" must include the type 20 NMEA driver. With the problem
pending, I had hoped that using an e.g. Internet source for coarse time
might have been enough, and had commented out the NMEA source, but it
appears not to be the case. The PPS was never used (but it appeared in
the billboard).
Cheers,
David
--
SatSignal Software - Quality software for you
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk
Twitter: @gm8arv
___
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] 100 MHz decade divider advice needed
Am 30.11.19 um 00:50 schrieb Perry Sandeen via time-nuts: Yo Bubba Dudes!, I'm considering attempting making a 10 MHz frequency difference meter sort of based on the Ticor 527. The design calls for using 100 MHz OCXO's and using the PLL difference to steer the EFC and then mix it with a PLL 90 MHz locked to the reference 10 MHz. Then that 10MHz difference is fed into the next stage PLL and the process repeated in the following stages. Hy problem is this. The only generally available 100MHz decade divider I've found is the 74LS196N. The problem arises that on the TI website it's advertised as going to 100 MHz BUT when one reads the data sheet it says that it only works to 85 MHz or so. I found on ebay the MC12080 100 MHz to 1.1GHz chip that can be configured to divide by 10. Now the ON units carried by the big name distributers are about $6. The Chicom no-brand-name units on ebay are less that $2 each. I'd really like to use the LS296 chip as it is a dip type and *genuine* ones sell for less than $2 on ebay. Since I need one OCXO for each decade stage plus one for the 90 MHz reference, at $50 each used on ebay this starts to get very expensive quickly. I did find some obscure 100 MHz decade counters on some design circuit on the net but I'd never heard of them and expect they will be unobtainum. The same seems to be true for the 74S and 74AC series. 74ls, 74s and mostly 74AC are all obscure now. 5V is mega-out, 3.3V is still standard but the trend goes to even less. 74LVC is mainstream. Not all chips of the old 74 series have been ported to 74lvc because nobody designs system around MSI function blocks any more. There are just the essentials: octal bus drivers, gates, flipflops (mostly only 1 gate/ff per pop in a tiny SO-8 or sot-23-5). There is still the 74LVC163 counter. I think there is no LVC191 whose precursor I have used a lot. These SSI/MSI chips only save as glue logic to make LSI ICs to fit together or to connect them to IO. Heavy functions that do not justify a full custom chip go to FPGAs or at least to CPLDs. I personally like the Xilinx Coolrunner-2 CPLDs as garbage collectors, but they are getting old also. The 74LVC163 + inverter should work for you, up to 200 MHz at least. But remember: with the speed come problems, too. Your output may be only 10 MHz, but rise and fall times are easily as fast as 500 ps. Good rf engineering is absolutely required. The lower-left quarter of the picture should work for you. There are more fast families, like Fairchild NC7SZ04P5X (04 = one inverter in sc70-5) or TI SN74LVC1G04DCKR (mostly the same) or ON Semiconductor NL17SZ74USG (D-type FF), Fairchild NV7SV74K8x or NXP 74LVC163PW ( counter ) as search strings for your google-foo, as typed from the anti-static bags in my drawer. If you find one of the family, the brothers are easy. local bed time now, 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] 100 MHz decade divider advice needed
Hi 74AS161 / 163 are rated to 125 MHz. Bob > On Nov 29, 2019, at 6:50 PM, Perry Sandeen via time-nuts > wrote: > > Yo Bubba Dudes!, > I'm considering attempting making a 10 MHz frequency difference meter sort > of based on the Ticor 527. > The design calls for using 100 MHz OCXO's and using the PLL difference to > steer the EFC and then mix it with a PLL 90 MHz locked to the reference 10 > MHz. Then that 10MHz difference is fed into the next stage PLL and the > process repeated in the following stages. > Hy problem is this. The only generally available 100MHz decade divider I've > found is the 74LS196N. > The problem arises that on the TI website it's advertised as going to 100 MHz > BUT when one reads the data sheet it says that it only works to 85 MHz or so. > I found on ebay the MC12080 100 MHz to 1.1GHz chip that can be configured to > divide by 10. > Now the ON units carried by the big name distributers are about $6. The > Chicom no-brand-name units on ebay are less that $2 each. > I'd really like to use the LS296 chip as it is a dip type and *genuine* ones > sell for less than $2 on ebay. > Since I need one OCXO for each decade stage plus one for the 90 MHz > reference, at $50 each used on ebay this starts to get very expensive quickly. > I did find some obscure 100 MHz decade counters on some design circuit on the > net but I'd never heard of them and expect they will be unobtainum. The same > seems to be true for the 74S and 74AC series. > > So will the LS196 chip work reliably at 100 MHz or am I stuck with the MC > 12080 or is there a better chip that I could use? > Regards, > Perrier > > ___ > 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] 100 MHz decade divider advice needed
Yo Bubba Dudes!, I'm considering attempting making a 10 MHz frequency difference meter sort of based on the Ticor 527. The design calls for using 100 MHz OCXO's and using the PLL difference to steer the EFC and then mix it with a PLL 90 MHz locked to the reference 10 MHz. Then that 10MHz difference is fed into the next stage PLL and the process repeated in the following stages. Hy problem is this. The only generally available 100MHz decade divider I've found is the 74LS196N. The problem arises that on the TI website it's advertised as going to 100 MHz BUT when one reads the data sheet it says that it only works to 85 MHz or so. I found on ebay the MC12080 100 MHz to 1.1GHz chip that can be configured to divide by 10. Now the ON units carried by the big name distributers are about $6. The Chicom no-brand-name units on ebay are less that $2 each. I'd really like to use the LS296 chip as it is a dip type and *genuine* ones sell for less than $2 on ebay. Since I need one OCXO for each decade stage plus one for the 90 MHz reference, at $50 each used on ebay this starts to get very expensive quickly. I did find some obscure 100 MHz decade counters on some design circuit on the net but I'd never heard of them and expect they will be unobtainum. The same seems to be true for the 74S and 74AC series. So will the LS196 chip work reliably at 100 MHz or am I stuck with the MC 12080 or is there a better chip that I could use? Regards, Perrier ___ 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 vulnerability and e-Loran
On 11/29/19 2:46 PM, Tom Van Baak wrote: > back when Woodford and Nakamura wrote their system engineering report. For those of you wondering about Jim's comment, start with this article: https://www.xyht.com/gnsslocation-tech/aerospace-corps-role-development-gps/ and then grab a copy of the then-confidential report from 1966: http://www.xyht.com/wp-content/uploads/2016/07/3-5-redacted-TOR-10012525-17-1-Briefing-navigation-satellite-study_Redacted.pdf Fun reading if you're into the history of clocks & navigation. Warning: the rabbit hole is very deep. /tvb GPSWorld has a nice two part history of GPS, by Brad Parkinson, et al. https://www.gpsworld.com/origins-gps-part-1/ https://www.gpsworld.com/origins-gps-part-2-fighting-survive/ The rabbit hole is the proverbial hole to the antipodes. The politics of how systems like GPS come to be is as interesting (to some) as the technical details. ___ 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 vulnerability and e-Loran
> back when Woodford and Nakamura wrote their system engineering report.
For those of you wondering about Jim's comment, start with this article:
https://www.xyht.com/gnsslocation-tech/aerospace-corps-role-development-gps/
and then grab a copy of the then-confidential report from 1966:
http://www.xyht.com/wp-content/uploads/2016/07/3-5-redacted-TOR-10012525-17-1-Briefing-navigation-satellite-study_Redacted.pdf
Fun reading if you're into the history of clocks & navigation. Warning:
the rabbit hole is very deep.
/tvb
On 11/29/2019 2:05 PM, jimlux wrote:
On 11/29/19 11:54 AM, Martin VE3OAT wrote:
A nice "general reader" article about GPS vulnerabilities to jamming
and spoofing and the expected consequences, with a too-brief mention
of e-Loran, appears in the current issue of Scientific American ("GPS
Down", December 2019, pp 38-45). Says e-Loran is unfunded and no one
is doing anything about it. (What else is new?)
Any "over the air" nav system has an inherent vulnerability to jamming
and/or spoofing, especially a one-way system like GPS or Loran or Omega.
With improved constellation on board processing bandwidth, the need
for a one way system is less important than it was back when Woodford
and Nakamura wrote their system engineering report. Two way nav is
tougher to spoof (assuming you have a good clock), and, depending on
the system, tougher to jam.
A good clock, accelerometers, gyros, and celestial nav is tough to jam.
___
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 vulnerability and e-Loran
On 11/29/19 11:54 AM, Martin VE3OAT wrote:
A nice "general reader" article about GPS vulnerabilities to jamming and
spoofing and the expected consequences, with a too-brief mention of
e-Loran, appears in the current issue of Scientific American ("GPS
Down", December 2019, pp 38-45). Says e-Loran is unfunded and no one is
doing anything about it. (What else is new?)
Any "over the air" nav system has an inherent vulnerability to jamming
and/or spoofing, especially a one-way system like GPS or Loran or Omega.
With improved constellation on board processing bandwidth, the need for
a one way system is less important than it was back when Woodford and
Nakamura wrote their system engineering report. Two way nav is tougher
to spoof (assuming you have a good clock), and, depending on the system,
tougher to jam.
A good clock, accelerometers, gyros, and celestial nav is tough to jam.
___
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] A simple sampling DMTD
Am 29.11.19 um 11:45 schrieb Jan-Derk Bakker: In general: as much as I like having it in my toolbox, I don't see how using an FFT would be the best tool for the job in a zero-crossing detector for a DMTD, let alone this particular sampling DMTD. For one, this 8-bit processor doesn't have the spare cycles to run FFTs on the 32-bit data I get from my CIC^2 decimator; besides that, I would only be interested in a single bin (the beat frequency), where it would be more efficient to simply I/Q-demodulate the samples in software (O(N) vs O(N log N)). While I admit that in the latter case windowing would help, at this point I/Q demodulating (effectively calculating only a single bin of the DFT) does not appear to have advantages over least squares fitting the arcsine of the incoming samples. Am I missing something here? I admit that I did not follow this thread closely, but the Goerzel filter is the single output line DFT , with O(n). < https://www.mathworks.com/help/signal/ref/goertzel.html;jsessionid=8816f77eb76ad7dd1913c7021698 > < https://en.wikipedia.org/wiki/Goertzel_algorithm > If you need to simulate floats, fractional integers are easiest. I/Q demodulation probably requires to recreate a clean carrier if you want absolute phase and not only relative jumps. That sounds more like FPGA than 8051, or whatever the 8 bit processor of the day may be. regards, Gerhard OK, in a previous life I did build a system for geophysics, where they fed dangerous amounts of AC into the soil and measured the potential at some 50 nodes. Rubber boots required. Each node had a 8951 to control some switches and communicate setups. They were most exited when I gave them the sources so they could implement FFT pre-processing locally on each node themselves. That required willingness to suffer. ___ 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] GPS vulnerability and e-Loran
A nice "general reader" article about GPS vulnerabilities to jamming
and spoofing and the expected consequences, with a too-brief mention
of e-Loran, appears in the current issue of Scientific American ("GPS
Down", December 2019, pp 38-45). Says e-Loran is unfunded and no one
is doing anything about it. (What else is new?)
... Martin VE3OAT
___
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] Garmin 18x GPS WNRO, revisited
From: Rich Wales I may have found the answer to my own question. I added "time1 619315200" to the "refclock" line in my ntp.conf file, and restarted ntpsec, and it appears to be sane once again. (And, of course, 619315200 = 7,168 days = 1,024 weeks.) Rich Wales ri...@richw.org Thanks for reporting that, Rich. I haven't seen that issue with either the GPS18 LVC, or the GPS18x LVC, but neither have been powered down. Were yours running continually? Anyway, I love the fix! I'm running reference NTP here, and noted that with a type 22 PPS driver, the "prefer" must include the type 20 NMEA driver. With the problem pending, I had hoped that using an e.g. Internet source for coarse time might have been enough, and had commented out the NMEA source, but it appears not to be the case. The PPS was never used (but it appeared in the billboard). Cheers, David -- SatSignal Software - Quality software for you Web: http://www.satsignal.eu Email: david-tay...@blueyonder.co.uk Twitter: @gm8arv ___ 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] A simple sampling DMTD
Dear Magnus, Removing the slope between the two sample end points (or: trimming/adding the fractional sample part of the period) is the point of the estimator I posted earlier ( http://lists.febo.com/pipermail/time-nuts_lists.febo.com/2019-November/098450.html ). In general: as much as I like having it in my toolbox, I don't see how using an FFT would be the best tool for the job in a zero-crossing detector for a DMTD, let alone this particular sampling DMTD. For one, this 8-bit processor doesn't have the spare cycles to run FFTs on the 32-bit data I get from my CIC^2 decimator; besides that, I would only be interested in a single bin (the beat frequency), where it would be more efficient to simply I/Q-demodulate the samples in software (O(N) vs O(N log N)). While I admit that in the latter case windowing would help, at this point I/Q demodulating (effectively calculating only a single bin of the DFT) does not appear to have advantages over least squares fitting the arcsine of the incoming samples. Am I missing something here? Sincerely, JDB. On Fri, Nov 29, 2019 at 2:32 AM Magnus Danielson wrote: > Hi, > > On 2019-11-28 21:18, Joseph Gwinn wrote: > > JD, > > > > I'll have to think about it, but I will mention that with batch > > processing using window functions, it's common to precede the FFT using > > a simple FIR filter to eliminate the low-frequency energy (due to > > clutter, DC leakage/offset et al), the problem being that the FFT alone > > may not have sufficient rejection to prevent low-frequency energy > > breakthrough. > > > > An alternate approach is to compute the mean of the windowed data and > > subtract that mean from all samples in the window before computing the > > FFT. In analog terms, this is like a big coupling capacitor blocking > > DC. > > You also wants to remove the slope between the two sample end-points, or > else that slope represents an in-phase sawtooth function. A > window-function tends to do that. > > 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.
Re: [time-nuts] Estimating expected time error using info from manufacturers' data sheets
Hi One issue you will quickly run into is the nature of the data sheet parameters. If you are buying a device you can afford, they rarely have a lot of detail. This is hardly unique to frequency references. The real device may exceed the spec’s by a very wide margin. It also may just barely (if at all) meet them. There also will be “assumptions” built into various specs. Is the number taken after running for a month (as with some op-amp parameters) or maybe after a day / week? At what rate of change is the temperature stability measured? How much does this matter in your application? Some devices (TCXO’s) will have a very complex F vs T characteristic. Other devices may be much less dramatic in their behavior. Getting this back to some sort of “change per degree” number …. yikes. With one device rated over 0 to 50 and another over -40 to 85, simply comparing their max excursion numbers really does not tell the story. Lots of nasty problems …. Bob > On Nov 28, 2019, at 8:23 PM, BJ wrote: > > Dear fellow timenuts, > > > > I am looking for some advice and insight from others wiser and more > experienced (than me) in the following: > > > > I want to be able to estimate the ability of a variety of (free running) > time & frequency references (ranging from crystal oscillators to Rb and Cs > frequency references) to remain synchronised to some hypothetical 'perfect' > reference over time. I.e. for each device I want to calculate expected time > error at some time t, given that the device was synchronised to the > 'perfect' reference at t=0. And I need to do this based on what is provided > in the datasheets. I thought this should be a straightforward exercise, but > (probably due to my ignorance) I'm finding this trickier than anticipated. I > have come up with a possible approach, but wanted to get some feedback from > anyone else out there that might have already gone down this path. > > > > The parameters (that appear relevant) in the data sheets are: > > Frequency accuracy > > Frequency stability over temperature > > Aging (per day/week/month/year.) > > Frequency stability (ADEV) > > > > The question then becomes, how do I combine these figures sensibly to come > up with the information I seek? For starters, there is some inconsistency in > how the parameters are recorded in the data sheets. Then there is the fact > that ADEV is often only given for one or a couple of values of tau. Anyway, > I have scoured the literature and came up with a couple of equations that > seemed promising, with the Time Interval Error (TIE) appearing to be the > most applicable. In particular, I have been using RMS TIE_est(t) as > specified in IEEE Std1139-2008. > > > > Without getting too heavily into the maths, the variables in this equation > are: > > 1. Uncertainty in initial synchronisation (sigma_x0), which I am setting > equal to zero, as I am assuming perfect sync at t=0 > > 2. Uncertainty in frequency (sigma_y0), which I am using to represent the > frequency stability over temperature component (although, perhaps I should > be considering the frequency accuracy here as well?) > > 3. Random frequency instability at time t (sigma_y(t)) after linear > frequency drift has been removed, which I am equating to ADEV for tau=t > > 4. Normalised linear frequency drift per unit of time (a), which I am using > to represent the aging component if applicable > > > > I have attached a worked example and would like to know if this makes sense, > or if I am on the wrong track. Note that I have included further questions > (and concerns) in red text in the worked example. I am quite uncomfortable > about all the assumptions I am forced to make and all the interpolating and > extrapolating I am forced to do, due to lack of information in the data > sheets. But at the end of the day I am just looking at a ballpark figure and > this is a bit of a learning exercise of sorts for me, to try to understand > how to interpret the manufacturers' specs and what they really mean in terms > of how long it might be before a free-running clock becomes too inaccurate > for certain purposes. > > > > So, in summary: > > 1.Does the TIE estimate I am using seem like a sensible choice for > what I am trying to do? If not, what would be a better approach? > 2.Am I implementing the data sheet parameters sensibly in this > equation? (as per the worked example in the attachment) > > > > Thanks folks! > > > > Belinda > > > > ___ > 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] Garmin 18x GPS WNRO, revisited
I may have found the answer to my own question. I added "time1 619315200" to the "refclock" line in my ntp.conf file, and restarted ntpsec, and it appears to be sane once again. (And, of course, 619315200 = 7,168 days = 1,024 weeks.) Rich Wales ri...@richw.org ___ 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] Garmin 18x GPS WNRO, revisited
I have a Garmin 18x LVC, connected to a Linux system via a serial port on the motherboard. Ubuntu 18.04.3 LTS, gpsd 3.17, ntpsec-1.1.0+419. I bought this GPS in 2009, and it's worked just fine until earlier this afternoon. At around 2019-11-26T00:00Z, the GPS jumped back 19 years, to 2000-04-11. The time offset reported by cgps is 619,315,200 seconds, or 7,168 days. Is there any feature in gpsd or ntpsec which would allow me to fudge the time value returned by the GPS to make it usable again? Yes, I realize it's not feasible in general to make gpsd deal automatically with every GPS unit's unique week number rollover situation, but I'm thinking more in terms of a command-line configuration option that can be set for the specific piece of hardware in use on a given system. Failing that, is it possible to flash this with new firmware? Or has my GPS become a paperweight? Rich Wales ri...@richw.org ___ 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.
