Using the 6[5,7]00 Internal GPS time for Local NTP server - How hard could it be to programme?

k3Tim

Q: How hard could it be to setup a local Network Time Protocol (NTP) server to use the GPS time from the 6500/6700?  

A short outline of what is available and programme flow:

API  to read the UTC time from the 6k:

        private string _gpsUtcTime;        /// <summary>
        /// Gets the GPS UTC time as a string

Seem this would be a fairly straightforward task:

0. start local NTP server                   ;; open source code available
1. discover radio                               ;;  existing
2. open radio                                    ;;  existing
3. read time via GPSUtcTime()        ;;  existing
4. Determine time delay for above   ;; ??
5. Update local NTP server
6. sleep N-seconds, then GoTo 3


So it seems the biggest challenge is porting the NTP server code and interfacing it with the GPS time reads.

Determining the time delay should be straight forward. Read local time, get UTC time and read local time once more computing the delta in time for the network call to get_UTC time. Does this several times to check if the delay is variable. 

That seems about it.  Is anything missing besides the "spare time" to implement ?


Regards,
k3Tim

Kevin

Hi Tim.

I don't have the GPS module but I've been looking at this Arduino project for a local NTP server. I wonder if some answers to your questions can be found here. It's not quite the same thing as reading a clock in the radio but does make use of the 10 MHz reference signal. The Flex GPS module provides this I think?

Kev

docdailey

It would be easier if Flex would just install NTP

Walt - KZ1F

To my recollection from working with ntpclients there is more to it than just updating the system clock. Specifically, they also adjust the internal clock frequency. An option would be looking at the source for a full functionality ntp client and modifying it to look at the f6000. The issue there is it is presented as a string.If the precision is to the hundredth of a second or even millisecond it really would do no useful purpose. There are very good, high precision ntp clients for Windows that wount lose sync on a rainy day or when trees leave. Then there is the whole issue of why you bought the radio. Best case is the radio would be a low quality time server.

Peter K1PGV

The problem is getting step 4 to be accurate. If you want accuracy give or take a second or so, you'll be fine. Otherwise, I think you've got a lot of non-deterministic processing for which to account. The again, if you want accuracy within a few hundred ms you can just use the built-in Windows to,e client. Peter K1PGV

docdailey

You have the gps, you have a linux box in there. You can easily get stratum 1 performance out of it. Likely within 1ms easily.

Patrick

Like a few people in this community, I have been wanting a built in ntp server so as to sync the time of my external computers so as to be in sync with my 6500. I've tried a couple of external solutions. First one being the normal computer based clients, but that requires the internet. Being close to wwvh here on Kauai, I found a decoder app, run on the computer and sourced via wwvh on the available frequencies (2500 kHz, 5000 kHz). This app is from COAA and is called RadioClock. Works ok but has long term reliability issues. It does a good job setting the computer clock and is usable in emergency situations when the internet is unavailable. My final solution was to purchase a TimeMachines ™ TM1000A. GPS referenced time server sharing my roof mounted Active GPS antenna. This does what I wanted and serves all the computers I have and in the Shack and even my Mac's used by the rest of the family. So it would be nice to have had this available in my Flex 6500 but I no longer have to hold my breath. Maybe it will be in SmartSDR v2, who knows. This does not constitute any thing against Flex. Just another way of doing time reference. Thanks......

docdailey

You can do it easily with a raspberry pi and a gps puck also. Google yields a bunch of solutions. I have done it with several different GPS's and revisions of the pi.

Walt - KZ1F

That's best case....and... do you want to pay $8500 for what you can get for free? I want my radio to be a radio, floor wax to be a floor wax, and shampoo to be shampoo. Sorry, that was floor wax and desert topping. You still have reliability issues, like vegetation and bad weather. There are Window based clients that keep the Windows system very accurate...for free.

docdailey

The point is.. it can be done easily. It is a no brainer.

Walt - KZ1F

is that a guess? MHH? It's not a 'no brainer'. What the radio returns is a HH:MM:SSz string not the 64 bit timestamp.

Peter K1PGV

>It is a no brainer Nonsense. In an embedded system, with soft real-time constraints, almost nothing is a "no brainer." I'm not saying it couldn't bedone... I'm just saying that it's not a nonce. Anyhow, the OP didn't ask if a NTP server could be added to the radio. The OP asked if he could build an NTP server by querying the time on the radio across the network. Peter K1PGV

Walt - KZ1F

Further, I recall from folks doing WSJT want that they need uSec accuracy. That can not be achieved from Flexlib.

George KF2T

Less than a second error is fine with WSJT modes, but no need for uS performance. Passing the time data out over the LAN connection sounds "reasonable," but at this point unnecessary. Probably wouldn't use it for a "precision" NTP setup anyway, since there are better, simpler ways with fewer potential error introductions.

Walt - KZ1F

I am glad you weighed in with that George as uSec sensitivity seemed awfully odd to me. Not doing WSJT or JT-65 or JT-69 I wasn't in a position to argue. I believe also there is some misunderstand...could be on my part. I've heard people on here say they find WinTime useless and, in fact, it is less accurate but claims to be accurate essentially to the second. But in setting up Windows OSs to get ntp time from time.gov (there is a time.gov option on the combobox) doesn't sound to me like a Microsoft time service. I believe the issue is whether one is referring to service or client. I am thinking, in this sense, the wiki is referring to starting a Windows 'ntpd' or service in Windows-speak. I've always just pointed the Microsoft applet at what was NIST in CO. Back in the 80's when I was doing PMNOS I did an NTPD for OS/2. I based it on the unix ntp and ntpd. They were both very involved pieces of code.

EA4GLI

The Flex 6700 is already pretty stable. The added stability of the GPSDO is not that important on HF. I think it will it will help on VHF and UHF. I selected my DEMI UHF transverter with the apollo 10 Mhz reference in. I even bought the 10 MHz reference signal hub that DEMI sells so that I can use the 10 MHz reference from the 6700 with other gear.

However, if all I will ever get out of the GPSDO in the Flex is the 10Mhz reference.... then I am afraid I just spent $700 extra for limited benefit. I can get a used HP Z3805A on ebay for $300 and that can already feed the 10 Mhz to 2 devices in my radio shack (including the 6700 that can take a 10 MHz ref in).

I really look forward to an NTP server out of the radio for every single device at home that will take that time reference... regardless if it is a Windows machine or Android.

And I also look forward to geographic diversity and fancy features to come out of the GPSDO. 

Michael Coslo

Everything would be easier if someone else did it. 8^)

k3Tim

Thanks to all for the comments and the links, this is very helpful. From the links I read over quickly it seems JT-65 needs to PC time to be within 1 second accuracy. Not sure what WSPR net needs. If the PC time can be set accurate enough to work with various modes used on the bands that would seem to be "good enough".  Being able to set time independent of the internet is the main goal. An auxiliary device (RP-3) is feasible but if taking to the field that's another device to setup and more power to budget. It's totally awesome to have "Atomic Frequency" standard accuracy by simply connecting a GPS antenna to the 6[57]00 box.

A proposed solution to the step 4 problem of accuracy (as Peter points out and I totally missed!) is to read t he time string, save it and re-read a second copy and  keep comparing the two until they are not equal, ie. the seconds field had tic'ed. This should be close to the beginning of the next second, for example 12:45:10.000  where 10.000 is exactly ten seconds. We don't know precisely the .000 portion but adding a small offset one can hope to get the clock set to withing 0.1 seconds. That's 100 milli-Seconds of tolerance to build into the code for the offset and 'clock jitters' when reading the string. I would think there would be enough consistence in reading the time string to ultimately set the PC clock (via NTP server) to within 0.1 second.

I appreciate the informative and thoughtful replies...
 
Best Regards to all,

k3Tim/6

Walt - KZ1F

Sal! Yet another topic of conversation! The primary justification I had for it was precisely that, geographic diversity. If FRS does not do that then I, too, threw away $700. Should that be the case, we can commiserate together.

Walt - KZ1F

Tim, the time feld is only updated every second and only accurate to the second. Depending on what's to the antenna's south the GPS could easily oscillate between locked and unlocked due to foliage, rain, obstructions.

Peter K1PGV

So, you'll know that it WAS 12:45:10.000  at the radio... at some point in the past.

My primary question is if you can reliably determine the delta time between receiving the notification of the time on your system and the radio's time stamp.

If the radio itself tends to respond to requests to read the time in a reasonably consistent manner, than you should be all set.  If the radio services these queries as a sort of background activity, you'll get a Xms lag one time and 5 times Xms lag another, which would pretty much wreck havoc with your scheme.  You have to drift your time changes... perhaps use a PID loop for the tuning?

And Walt raises an interesting point: If the API reports times at a level of one-second accuracy, there's always the issue of how much internal delay there is between the radio updating the time (as reported by the API) and the time actually changing.

Then again, perhaps I'm over-thinking this.  If you just want the time, and to be reasonably accurate, you're probably good to go.

I'd be VERY surprised if JT65 needed anything even remotely like 1ms accuracy, by the way.  The JT65 docs I've read say " If you can get within +/- 1 second you should be able to operate JT65" ... so that should be achievable.

Peter
K1PGV

docdailey

I know my opinion appears not to be popular. But... the latency and overhead of NTP is minimal and well understood. Why reinvent the wheel. Sudo apt-get install NTP.. do some minor config and you are done.

Peter K1PGV

I think you mean "ntpd", right?  And then you'd need to integrate that NTPD with the radio;s GPSDO.  So, you'd at least need gpsd... if not a modified version of that to talk to the GPSDO in the FlexRadio.

Then there's the issues about the time and CPU budget on the radio (as a real-time embedded device), to support not only the daemons, but also the arbitrary queries you'll receive from clients.

And then there's Walt's point about whether you want your multi-thousand dollar radio spending its cycles doing what a cheaper, dedicated, time server could do.

Or do I misunderstand what you're proposing?

Peter
K1PGV

docdailey

Yes... my bad ntpd. Yes you need a gps that has a pps and serial that is tied to the embedded computer. And it isn't a true real time OS.

k3Tim

Hi Peter I agree with your post, the big question is if the radio (and network) can consistently send out the time stamp. I would suspect the answer is yes. Thanks for checking the Jt65, at +/- 1 second that should be easy to obtain. If the radio sent an even second pulse signal out on a digital pin that would allow for a very accurate signal. I suspect the GPS module has such a pin out but it's internal routing is not connected. Then again, we didn't buy these SDRs to serve up time. When I get some spare time I'll have a go at this from a s/w perspective. To DocD - the motivation is mainly as a technical exercise, even if not implemented it's interesting to think about. Many Thanks! k3Tim

EA4GLI

Lately, I keep getting this feeling (from some of the comments) that my radio is at the end of the rope as far as resources is concern. It seems that an NTP server or a basic webserver will take it to its knees.... Something that can be easily handled with a $50 Raspberry will make my radio unusable. I just cannot believe it!

Unless FRS states publicly that the radio cannot handle anymore I find it a "lame" excuse to NOT enable more features.

Anytime we ask for something out of the radio we get the excuse from some people not to have it. "It uses processor cycles and the radio cannot handle it." Are you telling us this because you know for a fact that the radio cannot handle it?

So I get this uncomfortable feeling that my radio cannot improve due to having a processor that it is not swap-able and at 100% duty cycle with the set of features available now.....

But then, on the other hand, some of those same persons that state these things want to believe the radio can and will handle WAN in v.2.0 of the software! 

So which one is it? I prefer to believe that there is plenty of headroom and any improvements, including having your own NTP server out of the radio is one of the many features that could be available on the radio in the near future.

 EDIT: I am not looking for drama or pointing fingers, it is a genuine concern. I am personally "invested" in a platform.... and this talk of reaching the end of what the platform can do ... not very optimistic. 

docdailey

Thank you.. exactly what I have been saying. I am surprised by the resistance to change here. The defensiveness is astounding.

EA4GLI

Exactly! If I want to play it safe a get an Icom! But I want cutting edge, I want to have things other do not have! 

k3Tim

You guys are joking right?  !! ???  

It's already been stated by FRS the resources in the radio are not even close to their limit. Adding something like a time server that may wake up once a second and consume 0.01% of CPU / resources is nothing. Finding someone to stop code on more pressing requests (noise reduction / WAN etc etc) and working on this rather esoteric use-case isn't in the sked. 
I brought this up to see if it's feasible given the APIs that are already available and not to shame FRS into making the feature. I apologize to FRS the thread went of the rails as this wasn't my intention. They are working **** more pressing issues / features and delivering the goods.

The concept does appear to doable by any interested third party - and yes that would be us.
I can understand some folks not understanding the 'need' (more a want) since there are plenty of NTP servers on the web.

Take Care!
k3Tim

docdailey

Nobody is shaming FRS. I am shaming the defensiveness of the users.

Walt - KZ1F

Two separate concerns, headroom and ntpd. Knowing how to install NTP on Debian is not the same thing as understanding how it works and how real time OSs work. Peter was spot on. GPS time comes through as a status message. In order to have the radio perform the functions as a time service, that would involve writing an ntpd into the ssdr which is the radio, not the flexlib or SSDRfW. If I recall how engineering measurements work, if the level of granularity is hh:mm:as, the max level of granularity is second, not milli, not micro. NTP(D) uses a 64bit number, 32 bits of it being the fractional second. As for the 6000 series being the pinnacle of SDR for all time, time will tell. Personally, I wouldn't expect FRS to tell people the when it would be out of gas any more than I'd expect Dell to announce your current pc is the pinnacle of the engineering science, not just right now but forever