[time-nuts] Re: GPS D (i.e. gpsd) roll over bug..Oct 24th

Magnus Danielson said: > This is correct, but the bug re-introduces the 1024 wrapping issue, which > should have a basic safetynet after it. What do you mean by "safetynet"? The gpsd project has a lot of checking. It would be an interesting example for a software engineering course. It's

[time-nuts] Re: GPS D (i.e. gpsd) roll over bug..Oct 24th

Björn writes: > The L1 C/A was optimised many decades ago. The first GPS receiver to use the L1 C/A code took up four full racks and required to very alert persons to operate. There is a picture of it in one of the many "History of GPS" presentations given by the principals of the

[time-nuts] Re: GPS D (i.e. gpsd) roll over bug..Oct 24th

Chris, On 2021-10-22 22:18, Chris Caudle wrote: On Fri, October 22, 2021 12:22 pm, Magnus Danielson via time-nuts wrote: I find it amusing, as this was discussed on ntp-questions email-list in mid August 2013, and clearly explained with due references. According to the problem report this

[time-nuts] Re: GPS D (i.e. gpsd) roll over bug..Oct 24th

On Fri, October 22, 2021 12:22 pm, Magnus Danielson via time-nuts wrote: > I find it amusing, as this was discussed on ntp-questions email-list in > mid August 2013, and clearly explained with due references. According to the problem report this problem was only introduced in 2019, so seems to be

[time-nuts] Re: GPS D (i.e. gpsd) roll over bug..Oct 24th

Björn, The C/A code format have seen much greater changes before that. It's extention from 24 to 32 birds was not small, neither was the addition of the GPS-UTC corrections. Cheers, Magnus On 2021-10-22 21:29, Björn wrote: ”It's actually a systemflaw that never was fixed in L1 C/A code. It

[time-nuts] Re: GPS D (i.e. gpsd) roll over bug..Oct 24th

Hi As various GPS module designs done over the last decade or so have shown, you *can* fix this at the module level. Yes, each of those fixes has its drawbacks. However, the modern designs are a lot less likely to “die” 10 or 20 years from now. ….. and to address the inevitable follow up

[time-nuts] Re: GPS D (i.e. gpsd) roll over bug..Oct 24th

”It's actually a systemflaw that never was fixed in L1 C/A code. It would have been good if they added additional GPS-weeks bits in that signal, but it never materialiseras. It did for other newer signals.” The L1 C/A was optimised many decades ago. How Do you change the bitstream definition,

[time-nuts] Re: GPS D (i.e. gpsd) roll over bug..Oct 24th

Hi, On 2021-10-22 17:58, Kevin Rowett wrote: For those using GPSD (https://gpsd.gitlab.io/gpsd/index.html ) to read GPS receivers, and get the GPS time, there is a bug that could cause problems on Oct 24th.