I'm in the market for an inexpensive 10MHz Frequency Standard. Yes, I know, you get what you pay for however a 1000USD+ Rubidium Standard is out of the question due to price. But I'm looking at GPSDOs and asking if anyone has any experience with them. In particular these low-cost ones coming out of china. Apparently built using salvaged GPSs and Oven Controlled Oscillators. I've looked at the Leo Bodnar units from the UK which are in the 300USD range for dual outputs but the sub 100USD units from china look interesting. Does anyone have any particular experience with any of the various brands of them? And I am also wondering about the possible Teeing off of a single output port to multiple devices. Is it feasible? Can an open Teed off port be terminated with a 50Ω terminator to be removed and the teed off port used when needed. I understand that it depends on the ampacity of the source but is there any degradation of the signal from the Teeing?

 

Back in the EEVBLOG webpage and their TEST EQUIPMENT subforum, there’s are literally hundreds of threads discussing GOSDOs, including the Leo Bodnar you mentioned.
I have always wanted one, but never had a real reason to purchase one.

 

Hello,

The leo bodnar units are available on box73.de:
https://www.box73.de/index.php?cPath=350

Bertus

 

https://forum.allaboutcircuits.com/...justing-frequency-counter.204571/post-1956405

 

I have always wanted one, but never had a real reason to purchase one.

It is needed by a couple of amateur radios I use to lock their frequencies accurately for data transmission. They are very stable but there is apparently a voltage dip that occurs during transmissions that can unsettle their internal oscillators. I also have a few other bench instruments that could benefit from one although I'm not sure that there is anything I actually do on the bench that could actually need one. Possibly some radio alignments might be improved. The newer radios already have pretty darn good oscillators but apparently not quite good enough frequency locking for digital communications.

 

https://forum.allaboutcircuits.com/...justing-frequency-counter.204571/post-1956405

IMSAI Guy on YouTube shows using an older model from a few years ago Leo Bodnar unit and getting down to hundredths of a Hz stability after a few hours of warmup with a Hewlett Packard Frequency Meter. And there are many other old reviews and bench tests there as well of various GPSDOs from other makers. But there are newer more recent and now available options. There is also the unanswered question about using surplus OCXOs and whether they have drifted out of spec after years of previous use? Yeah, I know, get off my wallet and quit screwing around with chinesium junk... That aside, how about teeing off of their signal? Have you done it and with what success? Can it be done and maintain accuracy? I have found an add-on amplifier with 8 BNC output ports but that adds complexity (KISS) and cost.

 

Back in the EEVBLOG webpage and their TEST EQUIPMENT subforum

Yes, I'll check out Kangaroo Dave's site. Thanks for the heads up!

 

Would you make one yourself?

I made a poor-person's GPS-disciplined OXCO back in the day, for calibrating sensors that have frequency output to 10 ppm. It was one of those Chinese voltage-controlled OXCOs paired with a hobbyist GPS ("GPS arduino" on ebay) and a Teensy board (pjrc.com). We pulled the VCOCXO frequency with a potentiometer, and disciplined it by putting it near a window over a weekend. The annual recertfications showed a drift rate of 50ppb/year, which was easily dealt with by the turning the potentiometer. It was on a factory floor, so the quartz experienced a very stable environment (24/7 operation at controlled temperature).

Today, the GPSs are a few dollars less, and you can buy the OXCOs on a pcb with a potentiometer for thirty bucks. If you do make you own, get the GPS with the 5-pin header. The fifth pin is the 1PPS output. I saved a dollar by getting the no-1PPS 4-pin header, and then soldering a wire to the 1PPS pin. ... yeah, but I saved a dollar ... Learn from my mistake.

I should mention: The GPS constellation has a 12-hour period. This causes the time of a hobbyist GPS to wander back and forth by a dozen nanoseconds. We started and stopped the measurement at exact times, and recorded those times in a logbook with witnessed signatures. I do not know how real GPSDOs deal with this.

Anyway, just a random guy on the internet saying how he would do something ...

 

I made a poor-person's GPS-disciplined OXCO back in the day,

Thanks for the reply. What I'm seeing being reviewed after being opened and tested are surplus scrap GPS and OCXO units with a Nano Arduino program in control! Well, OK, that's great IF they work and are even close (within 0.1 Hz of drift) to spec. For less that 100USD I'll take a stab IF I can find one that has a current review that looks promising. What I'm finding, so far, are old reviews of past models and I'd like to see something more current if anyone knows anything of or has hands on experience with the new batch of GPSDOs coming from china. I've got other more important priorities right now than taking on a project to put one together myself. There's still a lot that I want to get done before my Alzheimer's makes it impossible. I am salvaging an external GPS antenna from my old boat GPS to use for the GPSDOs antenna. Anyways, I'm doing my due diligence now and trying rein myself in before buying some cheap crappy one that isn't worth having. I'm putting my target at the Leo Bodmar or better mark if it's possible.

 

IMSAI Guy on YouTube shows using an older model from a few years ago Leo Bodnar unit and getting down to hundredths of a Hz stability after a few hours of warmup with a Hewlett Packard Frequency Meter. And there are many other old reviews and bench tests there as well of various GPSDOs from other makers. But there are newer more recent and now available options. There is also the unanswered question about using surplus OCXOs and whether they have drifted out of spec after years of previous use? Yeah, I know, get off my wallet and quit screwing around with chinesium junk... That aside, how about teeing off of their signal? Have you done it and with what success? Can it be done and maintain accuracy? I have found an add-on amplifier with 8 BNC output ports but that adds complexity (KISS) and cost.

https://blog.febo.com/?p=636

Mine works just fine at the analog level (needed to reduce the signal in the video input a bit) with a $20 TV video amp used as a signal distribution box. I also needed the RS232 data port for my local computer time NTP standard. A 3.3 logic level converter for the HackRF uses one of the video amp ports. We ran scores of receivers/transmitters at the Navy radio sites off of one Master freq standard and a rack of disto amps for the signal, loss of accuracy from signal splitting is not a problem.
https://www.amazon.com/AuviPal-Splitter-Distributor-Amplifier-Monitoring/dp/B01MSQYHVI

Detail are all in the link I posted at post #4

 

also needed the RS232 data port for my local computer time NTP standard

Thanks, very interesting that the NTP signal was sufficient in lieu of GPS. Or am I missing something? I'll go back and look again at what you posted in the other thread. I've seen some with data ports but assumed they were for accessing the systems programming as most seem to be Nano or FPGA based these days. But most of those Nano ones I've seen are programmed using a USB interface board that connects to the programming pins on the Nano. Not sure how the FPGAs are interfaced and that is one very deep rabbit hole I'm not ready to tackle. As a side note, the clocks on the radios can be set by interfacing them to my NTP server on my computer but I've not gotten, as yet, any further than plugging in the USB cables. These new radios are a real step change from being just simply solid state and incorporate FPGAs extensively and are software upgradeable. One even has a built-in oscilloscope for audio and Rf with FFT for making adjustments to the filtering. And they eliminated the motors driving the variable capacitors for the internal tuners replacing them with whole slew of small mechanical relays that are computer driven and settings once made are kept in memory for automatic recall. Kinda noisy when tuning but very accurate results. I only wonder just what kind of longevity the relays have. Probably longer than me though...

Instruction Manual / Guides | Support | Icom Inc.

 

Thanks, very interesting that the NTP signal was sufficient in lieu of GPS. Or am I missing something? I'll go back and look again at what you posted in the other thread. I've seen some with data ports but assumed they were for accessing the systems programming as most seem to be Nano or FPGA based these days. But most of those Nano ones I've seen are programmed using a USB interface board that connects to the programming pins on the Nano. Not sure how the FPGAs are interfaced and that is one very deep rabbit hole I'm not ready to tackle. As a side note, the clocks on the radios can be set by interfacing them to my NTP server on my computer but I've not gotten, as yet, any further than plugging in the USB cables. These new radios are a real step change from being just simply solid state and incorporate FPGAs extensively and are software upgradeable. One even has a built-in oscilloscope for audio and Rf with FFT for making adjustments to the filtering. And they eliminated the motors driving the variable capacitors for the internal tuners replacing them with whole slew of small mechanical relays that are computer driven and settings once made are kept in memory for automatic recall. Kinda noisy when tuning but very accurate results. I only wonder just what kind of longevity the relays have. Probably longer than me though...

Instruction Manual / Guides | Support | Icom Inc.

There are many NTP servers on the network that I used before adding the GPS signal to the mix to have local stratum 1 time standard.
The workstation hpdesk is connected to the GPS RS232 data.

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

driftfile /var/lib/ntp/ntp.drift

# Leap seconds definition provided by tzdata
leapfile /usr/share/zoneinfo/leap-seconds.list

# Enable this if you want statistics to be logged.
#statsdir /var/log/ntpstats/

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable


# You do need to talk to an NTP server or two (or three).
server 10.1.1.172

# pool.ntp.org maps to about 1000 low-stratum NTP servers.  Your server will
# pick a different set every time it starts up.  Please consider joining the
# pool: <http://www.pool.ntp.org/join.html>
#pool 0.debian.pool.ntp.org iburst
#pool 1.debian.pool.ntp.org iburst
#pool 2.debian.pool.ntp.org iburst
#pool 3.debian.pool.ntp.org iburst

# GPS Serial data reference (NTP1)
server 127.127.28.0
fudge 127.127.28.0 time1 0.0001 refid GPS

# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details.  The web page <http://support.ntp.org/bin/view/Support/AccessRestrict
ions>
# might also be helpful.
#
# Note that "restrict" applies to both servers and clients, so a configuration
# that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.

# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery limited
restrict -6 default kod notrap nomodify nopeer noquery limited

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict 10.1.1.0
restrict ::1

# Needed for adding pool entries
restrict source notrap nomodify noquery

# Clients from this (example!) subnet have unlimited access, but only if
# cryptographically authenticated.
#restrict 192.168.123.0 mask 255.255.255.0 notrust


# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)
#broadcast 192.168.123.255

# If you want to listen to time broadcasts on your local subnet, de-comment the
# next lines.  Please do this only if you trust everybody on the network!
#disable auth
#broadcastclient

server 10.1.1.172 is the master NTP server for the network.

remote refid st t when poll reach delay offset jitter
+hpdesk .PPS. 1 u 1034 1024 377 0.1777 1.2351 0.1145
-time-c-wwv.nist .NIST. 1 u 1045 1024 377 38.4608 -1.0994 0.2216
-time-c-b.nist.g .NIST. 1 u 54 1024 377 38.3102 -1.4659 0.1580
*gpstime.la-arch .PPS1. 1 u 579 1024 377 28.1037 2.7115 0.3492
-time-b-b.nist.g .NIST. 1 u 62 1024 377 38.4065 -1.5658 0.2326
-144.202.66.214. 162.159.200.123 4 u 93 1024 377 58.3798 0.0810 0.3010
-216-144-228-179 129.6.15.30 2 u 107 1024 377 69.8759 2.9390 0.2826
-23.186.168.129 132.163.97.4 2 u 989 1024 377 8.0672 -1.6267 0.3802
+ntp1.glypnod.co 38.6.228.170 2 u 205 1024 377 19.8803 2.7614 0.4754
ntpd ntpsec-1.2.3 Updated: 2025-11-27T08:42:47 (512)
lstint avgint rstr r m v count score drop rport remote address
0 0.062 0 . 6 2 13 0.638 0 51916 localhost
11 66 0 . 3 4 6529 0.052 0 123 10.1.1.201
27 3600 0 . 3 3 1043 0.050 0 46398 10.1.1.84
55 1037 c0 . 4 3 3621 0.050 0 123 time-c-b.nist.gov
62 1037 c0 . 4 3 3619 0.050 0 123 time-b-b.nist.gov
93 1035 c0 . 4 4 3627 0.050 0 123 144.202.66.214 (144.202.66.214.vultruser
107 1036 c0 . 4 4 3625 0.050 0 123 216.144.228.179 (216-144-228-179-host.co
205 1035 c0 . 4 4 3627 0.050 0 123 ntp1.glypnod.com
539 923 0 . 3 4 4064 0.050 0 123 sma2.rain.com
580 1042 c0 . 4 4 3604 0.050 0 123 gpstime.la-archdiocese.net
900 3596 0 . 3 4 1044 0.050 0 55843 10.1.1.181
921 1000 0 . 3 4 3753 0.050 0 123 hp.sma2.rain.com
989 1151 c0 . 4 4 3260 0.050 0 123 23.186.168.129
1035 548 0 . 4 4 6853 0.050 0 123 hpdesk
1046 1036 c0 . 4 3 3623 0.050 0 123 time-c-wwv.nist.gov
3467 3600 0 . 3 3 1042 0.050 0 46463 newage.sma2.rain.com
19030 43199 0 . 3 3 87 0.050 0 55915 10.1.1.183
1994013 85 0 . 3 4 30 0.052 0 123 10.1.1.73
1996787 329 0 . 3 4 310 0.050 0 123 nmusic
3408664 831 0 . 3 4 208 0.050 0 123 10.1.1.206

That data: # GPS Serial data reference (NTP1)
is processed using this background daemon.
https://gpsd.gitlab.io/gpsd/index.html

About gpsd
gpsd is a service daemon that monitors one or more GPSes or AIS receivers attached to a host computer through serial or USB ports, making all data on the location/course/velocity of the sensors available to be queried on TCP port 2947 of the host computer.

With gpsd, multiple location-aware client applications can share access to supported sensors without contention or loss of data. Also, gpsd responds to queries with a format that is substantially easier to parse than the NMEA 0183 emitted by most GPSes. The gpsd distribution includes a linkable C service library, a C++ wrapper class, and a Python module that developers of gpsd-aware applications can use to encapsulate all communication with gpsd. Third-party client bindings for Java and Perl also exist.

https://gpsd.gitlab.io/gpsd/gpsd-time-service-howto.html#_1pps_quality_issues

GPSD is useful for precision time service because it can use the 1PPS pulse delivered by some GPS receivers to discipline (correct) a local NTP instance.
It’s tempting to think one could use a GPS receiver for time service just by timestamping the arrival of the first character in the report on each fix and correcting for a relatively small fixed latency composed of fix-processing and RS232 transmission time.
At one character per ten bits (counting framing and stopbits) a 9600-bps serial link introduces about a mSec of latency per character; furthermore, your kernel will normally delay delivery of characters to your application until the next timer tick, about every 4 mSec in modern kernels. Both USB and RS232 will incur that approximately 5mSec-per-char latency overhead. You’ll have to deal with this latency even on chips like the Venus 6 that claim the beginning of their reporting burst is synced to PPS. (Such claims are not always reliable, in any case.)
Unfortunately, fix reports are also delayed in the receiver and on the link by as much as several hundred mSec, and this delay is not constant. This latency varies (wobbles) throughout the day. It may be stable to 10 mSec for hours and then jump by 200mSec. Under these circumstances you can’t expect accuracy to UTC much better than 1 second from this method.
For example: SiRF receivers, the make currently most popular in consumer-grade GPS receivers, exhibit a wobble of about 170mSec in the offset between actual top-of-second and the transmission of the first sentence in each reporting cycle.
To get accurate time, then, the in-band fix report from the GPS receiver needs to be supplemented with an out-of-band signal that has a low and constant or near-constant latency with respect to the time of the fix. GPS satellites deliver a top-of-GPS-second notification that is nominally accurate to 50nSec; in capable GPS receivers that becomes the 1PPS signal.
1PPS-capable GPS receivers use an RS-232 control line to ship the 1PPS edge of second to the host system (usually Carrier Detect or Ring Indicator; GPSD will quietly accept either). Satellite top-of-second loses some accuracy on the way down due mainly to variable delays in the ionosphere; processing overhead in the GPS receiver itself adds a bit more latency, and your local host detecting that pulse adds still more latency and jitter. But it’s still often accurate to on the order of 1 uSec.

 

I've been working mostly with the HF rig but was just going through the manuals on the 2M/70cm/1.2GHz rig and discovered that its native oscillator is far worse. +/- 75Hz on 2M/143MHz and progressively worse at the higher frequencies so it is pretty much inoperable for data transmissions without external 10MHz frequency-locking the oscillator. So... Need to do this before I can even start working on the data transmissions aspect.

 

While doing my due diligence research on GPSDOs I came across this from the Netherlands. Pretty long but very informative coverage of the Leo Bodamar ones and comparing them to some of the cheap ones in the marketplace and a bit of history about timing oscillators. Also, fairly recent from 2024.
REL #53 The new (2024) Leo Bodnar 2-port GPSDO Model LBE-1421

 

The very best deal I got on such a GPS stablized source was when the local cellular carrier updated quite a few years back Some guy grabbed all their discards including three GPS regulated 10 MHZ receivers. Changing the 48 volts power requirement to a mains powered module was not a big deal, but while learning to talk with it via the RS 232 9 pin connection will take some effort.

 

Apparently the oven controlled crystal oscillators used by the majority of the chinese makers had previous lives working in cell tower usage. To start, I ordered the frequency distribution amplifier module with a built in 10MHz OXCO. I am going to need the distribution amplifier anyway as I have several devices that can benefit from external oscillation control. Adding the internal OXCO is a minor upgrade. It tends to drift a bit but much less than the stand-alone radios and instruments. Once I get it installed and cabled to all the external device ports I will check the drift and determine stability. The next step is to feed the distribution amp from a Leo Bodnar OXCO device which is extremely stable to lock down the drift. Bodnar's have an excellent reputation as being extremely stable and do not use unknown quality surplus OXCOs.

 

I have not investigated the scheme used to adjust or control a 10 MHZ oscillator from the precise one pulse per second obtained from the GPS signal, so I am not able to provide any advice in that direction. It might be similar to a speed control design I created 45 years ago, but I really hope not. Possibly another participant knows a simple scheme
I have an idea but it can waitto see whaat some others may arrive at.

 

https://tf.nist.gov/general/pdf/2294.pdf

https://www.nist.gov/pml/time-and-frequency-division/services/gps-data-archive

 

I do know one way to do it but it uses a counter that counts up to ten million plus a bit more.a