Based on Mark Sims updates to Heather v5.0 I've updated Ralph Smith's NTP daemon to handle the rollover. I haven't updated the gpsd. https://wa5znu.org/2011/08/tbolt/ It's not as ambitious as Mark's update; this one doesn't read system time so it will have to be recompiled again in about 20 years. I took Mark's Julian and Gregorian date calculations as is ;-) This is running now as well as it ever did. Thanks for the great community. Leigh/WA5ZNU

Thanks for doing this, I was just about to dive into this. I've been neck deep in some other things recently and just became aware of this issue. Could you check the source tarball? I just downloaded it and it appears to be the unmodified version of my code from 2010. Ralph AB4RS Sent from my iPhone > On Aug 1, 2017, at 2:42 AM, Leigh L. Klotz, Jr WA5ZNU <Leigh@WA5ZNU.org> wrote: > > Based on Mark Sims updates to Heather v5.0 I've updated Ralph Smith's NTP daemon to handle the rollover. I haven't updated the gpsd. > > https://wa5znu.org/2011/08/tbolt/ > > It's not as ambitious as Mark's update; this one doesn't read system time so it will have to be recompiled again in about 20 years. > I took Mark's Julian and Gregorian date calculations as is ;-) > > This is running now as well as it ever did. Thanks for the great community. > > Leigh/WA5ZNU > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there.

Hmm.. Just a while ago, I watched the heather display on ours go to 12:59:59 and stop....................... Still giving me 10 MHz though which is all I really need.

Thank you, Ralph! Indeed, I had tarred up the branch on github with your original code, not the branch with my changes...how embarrassing! I've updated the tarball and re-arranged the page to make it easier to find the latest. Also, if you make an official version I'll remove my download and just put back the startup scripts that I have added. Note that I didn't touch gpsclientd... Leigh/WA5ZNU On 08/01/2017 09:37 AM, Ralph Smith wrote: > Thanks for doing this, I was just about to dive into this. I've been neck deep in some other things recently and just became aware of this issue. > > Could you check the source tarball? I just downloaded it and it appears to be the unmodified version of my code from 2010. > > Ralph > AB4RS > > Sent from my iPhone > >> On Aug 1, 2017, at 2:42 AM, Leigh L. Klotz, Jr WA5ZNU <Leigh@WA5ZNU.org> wrote: >> >> Based on Mark Sims updates to Heather v5.0 I've updated Ralph Smith's NTP daemon to handle the rollover. I haven't updated the gpsd. >> >> https://wa5znu.org/2011/08/tbolt/ >> >> It's not as ambitious as Mark's update; this one doesn't read system time so it will have to be recompiled again in about 20 years. >> I took Mark's Julian and Gregorian date calculations as is ;-) >> >> This is running now as well as it ever did. Thanks for the great community. >> >> Leigh/WA5ZNU >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts@febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there.

I have updated my version of tboltd to do the following: 1) I incorporated your fix for the GPS epoch rollover, with the following change: Since I was already converting the time internally to the Unix epoch I did not use the Julian conversion, rather I simply modified the returned Unix epoch time prior to writing to the NTP shared memory segment. 2) Sprinkled in some #ifdef statements so the unmodified source will compile on FreeBSD and on Debian Linux. 3) This does not include the gpsdclientd. I may or may not care enough to fix that in the future. Source is available at http://ralphsmith.org/~ralph/tboltd-2017-08-02.tar.gz There are also some changes in there from the 2010 base originally used, mostly parsing of some additional packets. Don't do anything with them though. I also added the ability to write a PID file when running as a daemon on BSD systems. I should probably pull all of this into a github project, and use autoconf or something similar to address cross-platform builds. I'm too lazy to mess with that at the moment. Let me know if this works for you. Ralph AB4RS > Thank you, Ralph! > > Indeed, I had tarred up the branch on github with your original code, > not the branch with my changes...how embarrassing! > > I've updated the tarball and re-arranged the page to make it easier to > find the latest. > > Also, if you make an official version I'll remove my download and just > put back the startup scripts that I have added. Note that I didn't > touch gpsclientd... > > Leigh/WA5ZNU > > On 08/01/2017 09:37 AM, Ralph Smith wrote: >> Thanks for doing this, I was just about to dive into this. I've been >> neck deep in some other things recently and just became aware of this >> issue. >> >> Could you check the source tarball? I just downloaded it and it appears >> to be the unmodified version of my code from 2010. >> >> Ralph >> AB4RS >> >> Sent from my iPhone >> >>> On Aug 1, 2017, at 2:42 AM, Leigh L. Klotz, Jr WA5ZNU >>> <Leigh@WA5ZNU.org> wrote: >>> >>> Based on Mark Sims updates to Heather v5.0 I've updated Ralph Smith's >>> NTP daemon to handle the rollover. I haven't updated the gpsd. >>> >>> https://wa5znu.org/2011/08/tbolt/ >>> >>> It's not as ambitious as Mark's update; this one doesn't read system >>> time so it will have to be recompiled again in about 20 years. >>> I took Mark's Julian and Gregorian date calculations as is ;-) >>> >>> This is running now as well as it ever did. Thanks for the great >>> community. >>> >>> Leigh/WA5ZNU >>> >>> _______________________________________________ >>> time-nuts mailing list -- time-nuts@febo.com >>> To unsubscribe, go to >>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >>> and follow the instructions there. >> _______________________________________________ >> time-nuts mailing list -- time-nuts@febo.com >> To unsubscribe, go to >> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. > > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. >

Attila, On 07/28/2017 02:01 AM, Attila Kinali wrote: > On Thu, 27 Jul 2017 17:49:14 -0500 > Didier Juges <shalimr9@gmail.com> wrote: > >> I cannot imagine a work around since the problem stems from the GPS service >> only identifying the current date within a particular 1024 weeks epoch >> unless the government changes the amount of data that is sent over the GPS >> system. Somebody has to use other method to determine the epoch and add the >> corresponding offset. > > There is: There is a 13bit week number in message type 10. This gives > a 157 year span instead of the ~19 years of the 10bit week number. > This has been part of the GPS standard since IS-GPS-200D which was > released in 2004. As such I am a little bit surprised that the u-blox > receivers still don't support this message (the LEA-5 family was released > in 2007 IIRC). But you can use the UBX RXM-SFRBX messages to get the > raw GPS messages and decode them yourself. Yes, but it is only relevant if you to L2C, on which CNAV is encoded. As far as I have seen, there is no support in the L1 C/A NAV, also known as LNAV, message for anything but 10 bit GPS-week numbers, which brings back the topic. Now, there is a reason I advocate for L2C and L5 capable receivers, this is one of them. Don't blame receiver vendors for not using L2C CNAV messages when they only do L1 C/A receivers. Cheers, Magnus

                             Attila Kinali

It should only be the failure of producing the wrong "display-date". The internal time system use different gears for everything, so the display-date is a side-product. Adjust with +1024 weeks and you should be all set. Leap-second info work on internal gears. Cheers, Magnus On 07/28/2017 02:36 AM, paul swed wrote: > Well quite an unpleasant surprise. So after the 30th do the TBolts stop > working or is it a case of just the wrong date? I know my Hp3801s been > working just fine and its old. Is the TBolt the same issue. Wrong date but > still locks thats all I care about actually. > With to respect of some sort of a hack I can see that being fairly > difficult. > Regards > Paul > WB8TSL > > On Thu, Jul 27, 2017 at 8:01 PM, Attila Kinali <attila@kinali.ch> wrote: > >> On Thu, 27 Jul 2017 17:49:14 -0500 >> Didier Juges <shalimr9@gmail.com> wrote: >> >>> I cannot imagine a work around since the problem stems from the GPS >> service >>> only identifying the current date within a particular 1024 weeks epoch >>> unless the government changes the amount of data that is sent over the >> GPS >>> system. Somebody has to use other method to determine the epoch and add >> the >>> corresponding offset. >> >> There is: There is a 13bit week number in message type 10. This gives >> a 157 year span instead of the ~19 years of the 10bit week number. >> This has been part of the GPS standard since IS-GPS-200D which was >> released in 2004. As such I am a little bit surprised that the u-blox >> receivers still don't support this message (the LEA-5 family was released >> in 2007 IIRC). But you can use the UBX RXM-SFRBX messages to get the >> raw GPS messages and decode them yourself. >> >> >> Attila Kinali >> >> -- >> You know, the very powerful and the very stupid have one thing in common. >> They don't alters their views to fit the facts, they alter the facts to >> fit the views, which can be uncomfortable if you happen to be one of the >> facts that needs altering. -- The Doctor >> _______________________________________________ >> time-nuts mailing list -- time-nuts@febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/ >> mailman/listinfo/time-nuts >> and follow the instructions there. >> > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. >

The Trimble Thunderbolts are used in many Radio Paging Systems to synchronize their transmitters in simulcast mode. Systems that are using the models affected by the 1024 week epoch are currently off the air or functioning poorly. This is a very serious issue because many doctors and nurses as well as first responders rely on their pagers for emergency notification. Trimble’s only distributor, Novotech, did not know about it and had no inventory of the new replacement E series Thunderbolt GPS Receivers. Trimble says they are shipping new units from their overseas factory in about 2 weeks — thats the best they can offer! I read here on the Time Nuts messages that some are considering: "some in-line device that re-writes the serial data as it comes out of the Thunderbolt” Does anyone plan to do this? Or does anyone have any ideas for a short-term solution. Any suggestions would be sincerely appreciated. Best Regards, Brad Dye Editor, The Wireless Messaging News P.O. Box 266 Fairfield, IL 62837 USA Telephone: 618-599-7869 Skype: braddye http://www.braddye.com

While it wouldn't be difficult to build such a device, manufacturing a decent quantity in less than 2 weeks to beat Trimble would be a tall order. There are, however, programmable converters : all the hardware you need and just needs some suitable software. For example : http://www.kksystems.com/programmable-protocol-converters/ppc-4-h2-c.html It does rather more than you need, there may be cheaper alternatives. On Thu, Aug 10, 2017 at 6:24 PM, Brad Dye <brad@braddye.com> wrote: > The Trimble Thunderbolts are used in many Radio Paging Systems to > synchronize their transmitters in simulcast mode. Systems that are using > the models affected by the 1024 week epoch are currently off the air or > functioning poorly. This is a very serious issue because many doctors and > nurses as well as first responders rely on their pagers for emergency > notification. > > Trimble’s only distributor, Novotech, did not know about it and had no > inventory of the new replacement E series Thunderbolt GPS Receivers. > Trimble says they are shipping new units from their overseas factory in > about 2 weeks — thats the best they can offer! > > I read here on the Time Nuts messages that some are considering: "some > in-line device that re-writes the serial data as it comes out of the > Thunderbolt” > > Does anyone plan to do this? Or does anyone have any ideas for a > short-term solution. > > Any suggestions would be sincerely appreciated. > > Best Regards, > > Brad Dye > Editor, The Wireless Messaging News > P.O. Box 266 > Fairfield, IL 62837 USA > Telephone: 618-599-7869 > Skype: braddye > http://www.braddye.com > > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/ > mailman/listinfo/time-nuts > and follow the instructions there. >

Just remember you are taking on E911 responsibility. Not that brave. But come on all those tbolts going in the trash. Sounds like goodies. Regards Regards Paul WB8TSL On Thu, Aug 10, 2017 at 7:55 PM, Adrian Godwin <artgodwin@gmail.com> wrote: > While it wouldn't be difficult to build such a device, manufacturing a > decent quantity in less than 2 weeks to beat Trimble would be a tall order. > > There are, however, programmable converters : all the hardware you need and > just needs some suitable software. For example : > > http://www.kksystems.com/programmable-protocol-converters/ppc-4-h2-c.html > > It does rather more than you need, there may be cheaper alternatives. > > > > On Thu, Aug 10, 2017 at 6:24 PM, Brad Dye <brad@braddye.com> wrote: > > > The Trimble Thunderbolts are used in many Radio Paging Systems to > > synchronize their transmitters in simulcast mode. Systems that are using > > the models affected by the 1024 week epoch are currently off the air or > > functioning poorly. This is a very serious issue because many doctors and > > nurses as well as first responders rely on their pagers for emergency > > notification. > > > > Trimble’s only distributor, Novotech, did not know about it and had no > > inventory of the new replacement E series Thunderbolt GPS Receivers. > > Trimble says they are shipping new units from their overseas factory in > > about 2 weeks — thats the best they can offer! > > > > I read here on the Time Nuts messages that some are considering: "some > > in-line device that re-writes the serial data as it comes out of the > > Thunderbolt” > > > > Does anyone plan to do this? Or does anyone have any ideas for a > > short-term solution. > > > > Any suggestions would be sincerely appreciated. > > > > Best Regards, > > > > Brad Dye > > Editor, The Wireless Messaging News > > P.O. Box 266 > > Fairfield, IL 62837 USA > > Telephone: 618-599-7869 > > Skype: braddye > > http://www.braddye.com > > > > > > _______________________________________________ > > time-nuts mailing list -- time-nuts@febo.com > > To unsubscribe, go to https://www.febo.com/cgi-bin/ > > mailman/listinfo/time-nuts > > and follow the instructions there. > > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/ > mailman/listinfo/time-nuts > and follow the instructions there. >