Symmetricom X99 - Rubidium Oscillator

[Name00]

I recently obtained a X99 Symmetricom.  Although I do not have a x72, it seems to be the same in appearance, features, and outputs with a different label. 
Hooking it up to lady heather shows where some of the differences are.  The firmware does not return the “r>” prompt that lady heather 6.14 was designed for, the second is the baud rate defaults to 9600, and the output is data is not in hex. 

By the way Mark Sims, you did an awesome job on putting in all the support for it!

I’ve taken the source code from KG7NUX (4.16.1), and have spent a few hours making “minimally” non-destructive changes to correct the support for the X99 that I have.

After doing an initial disciplining against 3 different sources with saving procedures similar to the SA.22c  I outlined in another thread using lady heather.  The performance, drift, and accuracy is comparable with the SA.22c that I own.

So the questions I have for those reading this:

1)   Does anyone out there have the user's manual for the X99 Symmetricom?

2)   Does anyone with a X72 have the ability to extract the firmware loaded on the X72?  Can you share it?

3)   Is anyone interested in the changes I’ve made to Lady Heather?     I have it working in Linux currently but if someone wants to provide some instructions on building for Windows I can give it a try.   I’ll also need to test it against the SA.22c to make sure all the features I used are still good.
The source changes that support the X99 are now on github: https://github.com/randomthings00/ladyheather

I’ve also included a picture of it during one of my non-calibrations testing for those interested.


[Updated: with github link]

[Name00]

I've decided to put this as a new post..  Above and beyond putting on github the updated code of Lady Heather with the X99 change update above. 

I've also put together a small micro-python Raspberry Pi Pico / ESP32-S3 code that keeps the drift to the lower end and reduces the need for a re calibration while the PPS in is supplied by a GPS.  After a 5 day run it seems to keep it within +/-20ns of a Datum StarLoc2, it does drift, I presume that's based on the GPS stability..   Looking at trying to get a proper ADEV for this long term.

Is there any interest for this?

Waiting for Rubidium Lock..
Setting Control Register to:  0
Setting DSS to:  -79.8
Resetting PSS Delta to: 0
Waiting PPS Delta to reset..
-- GC Memory Alloc: 38608 GC Memory Free: 138672 GC Collected: None
Model: X 9 9    -- S/N: xxxx-H -- Service Pin: HIGH
Rb Lock: Good -- Current Temp: 50.5 -- Lamp Voltage: 16.9192
Current PPS Delta: 0 ( 0 ) -- Counter: 4 -- DSS Adjust: -79.8

[bingo600]

Nice job w. the X99 support in LH.

Please tell more about the Pi-Pico / ESP "thingy" ....
Can it disipline  a  x72/x99 or what does it do ?

I have an x72 (not active atm) , that has an older non pps capable firmware.

Any chance to see the ESP/Pico source on github too ?

/Bingo

[Name00]

Nice job w. the X99 support in LH.

Please tell more about the Pi-Pico / ESP "thingy" ....
Can it disipline  a  x72/x99 or what does it do ?

I have an x72 (not active atm) , that has an older non pps capable firmware.

Any chance to see the ESP/Pico source on github too ?

/Bingo

I decided to remove the last post and put in a new one, I spent a few hours and copied the lady heather disciplining code yesterday and cleaned up a few typos and logic errors this morning and the old post is no longer valid. 

Short answer to your question is, yes it can be used to discipline now.  :-)

The program itself can be viewed as a poor man's GPS DRO or GPS DRO Lite.   It does small adjustments as needed to the DDS  to keep the 1 PPS Delta in sync with what the Symmetricom is reporting, I use two different methods to do this but settled on one but given the addition of the LH discipline code, I'm now checking the long and short term viability of using both mine and the LH's since the LH code doesn't work well with very short time periods.

This project has been a bit of a proof of concept that (as you can tell) has been evolving, once I reach a stable state after sometime, I'll put it up on github.     I've since upgraded to this version on both the X99 and SA.22c, as a teaser on the functionality a small output for the X99 is below..
 

Code: [Select]

MPY: soft reboot
Model: X 9 9    -- S/N: xxxx-H -- Service Pin: HIGH
Rubidium lock is good.
Calculating a new DDS value..
  Setting DDS to:  0.0
  Resetting PPS Delta to: 0
    Waiting for PPS reset.
  Starting calculations ( 1800 )..
    Current Count:  100 -- current Delta:  59999995 ( -5 )
    Current Count:  200 -- current Delta:  59999990 ( -10 ) -- Total Values: -928 -- Average:  -4.64 -- Slope: -8.50834e-10
    Current Count:  300 -- current Delta:  59999986 ( -14 )
    Current Count:  400 -- current Delta:  59999981 ( -19 ) -- Total Values: -3845 -- Average:  -9.6125 -- Slope: -8.34818e-10
    Current Count:  500 -- current Delta:  59999975 ( -25 )
    Current Count:  600 -- current Delta:  59999971 ( -29 ) -- Total Values: -8778 -- Average:  -14.63 -- Slope: -8.37008e-10
    Current Count:  700 -- current Delta:  59999966 ( -34 )
    Current Count:  800 -- current Delta:  59999960 ( -40 ) -- Total Values: -15710 -- Average:  -19.6375 -- Slope: -8.36142e-10
    Current Count:  900 -- current Delta:  59999955 ( -45 )
    Current Count:  1000 -- current Delta:  59999950 ( -50 ) -- Total Values: -24634 -- Average:  -24.634 -- Slope: -8.34646e-10
    Current Count:  1100 -- current Delta:  59999946 ( -54 )
    Current Count:  1200 -- current Delta:  59999941 ( -59 ) -- Total Values: -35571 -- Average:  -29.6425 -- Slope: -8.34826e-10
    Current Count:  1300 -- current Delta:  59999935 ( -65 )
    Current Count:  1400 -- current Delta:  59999931 ( -69 ) -- Total Values: -48514 -- Average:  -34.65286 -- Slope: -8.34939e-10
    Current Count:  1500 -- current Delta:  59999926 ( -74 )
    Current Count:  1600 -- current Delta:  59999920 ( -80 ) -- Total Values: -63426 -- Average:  -39.64125 -- Slope: -8.33796e-10
    Current Count:  1700 -- current Delta:  59999915 ( -85 )
  Total value:  -80364  -- Entries:  1800  --Average:  -44.64667 -- Slope: -8.34019e-10
  Current DDS Value:  0.0   -- DDS Offset:  -83.4  -- New DDS Value:  -83.4
   Setting DDS to:  -83.4
  Resetting PPS Delta to: 0
    Waiting for PPS reset...
-- GC Memory Alloc: 102992 GC Memory Free: 74288 GC Collected: None
Model: X 9 9    -- S/N: xxxx-H -- Service Pin: HIGH
Rb Lock: Good -- Current Temp: 48.5 -- Lamp Voltage: 16.9205
Current PPS Delta: 0 ( 0 ) -- Counter: 4
DDS Adjust: -83.4 Running Slope: 0.0 Calc Slope: 0.0
.....
-- GC Memory Alloc: 35472 GC Memory Free: 141808 GC Collected: None
Model: X 9 9    -- S/N: xxxx-H -- Service Pin: HIGH
Rb Lock: Good -- Current Temp: 51.25 -- Lamp Voltage: 16.9164
Current PPS Delta: 0 ( 0 ) -- Counter: 13364
DDS Adjust: -83.2 Running Slope: 1.956299e-11 Calc Slope: -1.481767e-10 Last Averages: 10: 0.1


[Name00]

I've now published the code publicly, don't mind some oddies with the comments and the print outputs was playing around with different formats in Python, I also added support for the ESP32-C3 since I didn't use any threads.. yet...

It's worked relatively well, I've also included an ADEV from TimeLab comparing it with the BH3SAP, Thunderbolt, and the SA22, with the X99 as the reference source.  Based on the R Slope value in my outputs it seems the X99 is by far more "stable" with the adjustments than the SA.22c.

https://github.com/randomthings00/gpsdro-symmetricom

Feedback welcomed.

[edpalmer42]

I think you can make your graphs look better than they are.  The 53131 is somewhat limited and it's hiding the performance of your DUT.  A general rule of thumb and sanity check is that the 1 sec. ADEV should be similar to the resolution of your counter.  In the case of the 53131 and its' 150 ps resolution, that works out to an ADEV @ 1 sec. of ~1.5e-10 so your measurements look good.

It looks like you're using your X99 as the external reference for your counter and then measuring the frequency of your DUT.  To reduce the compications, I'd recommend using your best free-running Rb standard as the reference for the 53131.  Connect the DUT to CH1 and the reference Rb to Ch2.  Then measure the time interval from the rising edge of CH1 to the rising edge of CH2.  Square waves are preferred if they're available.  Your original configuration was comparing two disciplined sources to each other which disguised the performance of each of them.  Now you can look at them seperately vs. a stable Rb standard.

On your new graphs, instead of the left part dropping one decade for every two decades of time (i.e. 1:2), it will now drop at a 1:1 ratio.  You'll be able to see more of your DUT instead of having the 53131 hide it.

FYI, I've attached some measurements that I've made of GPSDOs vs. free-running Rb standards.  The 'GPS Line' is the approximate performance of raw GPS.  You can see that all the GPSDOs turn and follow the GPS Line (more or less) at higher values of Tau.  A GPSDO *must* turn and follow the GPS Line or it's *not* disciplining the oscillator to GPS.

[Name00]

It looks like you're using your X99 as the external reference for your counter and then measuring the frequency of your DUT.  To reduce the compications, I'd recommend using your best free-running Rb standard as the reference for the 53131.  Connect the DUT to CH1 and the reference Rb to Ch2.  Then measure the time interval from the rising edge of CH1 to the rising edge of CH2.  Square waves are preferred if they're available.  Your original configuration was comparing two disciplined sources to each other which disguised the performance of each of them.  Now you can look at them seperately vs. a stable Rb standard.

Thanks!  That's exactly what I did, I've switched it, the X99 now in free run mode fed in both reference and channel2 and the SA.22c on Channel 1.  I've set the counter to TI 1 vs 2, it feels odd that I'm not running it against the a non continuously disciplined source, but I think from what you've said it wouldn't be considered stable otherwise. -- I'll do another 12 hour run and see how it holds up and placed it up for more feedback.

Thanks again!

[Name00]

Okay a new graph.   The Green line was taken where the X99 was completely free-running.  The Orange and Cyan line were the X99 in GPSDRO mode being disciplined also.

The question is I have is would you consider the sloping on the GPS line to have occurred after the right turn even though it's much longer?  Trying to understand the mechanics of free-run and GPSDRO since it seems they produce "similar" results but takes much longer to achieve it but didn't hit your 1:1 ratio which makes me wonder what it's measuring and if it make sense to just keep it running off the GPS.

Sidenote:  I updated the program, an issues with the ESP32 pins used, and fixed up the holdover exit code (it wasn't properly exiting),

[edpalmer42]

Okay a new graph.   The Green line was taken where the X99 was completely free-running.  The Orange and Cyan line were the X99 in GPSDRO mode being disciplined also.

Are you sure about that?  The green line is showing what looks like disciplining, although that could just be the end of the graph flapping around - it likes to do that.  ADEV doesn't care if the REF or the DUT is being disciplined.  The graph will look the same.  If you draw in my GPS Line, both lines turn and start to drop at the right time.  The cyan trace (i.e. the Tbolt) seems to have a rather high noise floor.  The green trace looks okay.

The question is I have is would you consider the sloping on the GPS line to have occurred after the right turn even though it's much longer?  Trying to understand the mechanics of free-run and GPSDRO since it seems they produce "similar" results but takes much longer to achieve it but didn't hit your 1:1 ratio which makes me wonder what it's measuring and if it make sense to just keep it running off the GPS.

All three of the unsaved graphs are showing a slope of 1:1 from Tau of 1 to 10 sec.  At that point, the Tbolt starts to fade due to its internal noise.  The other two carry on until about 300 sec. where the orange trace flattens out.  This flattening, possibly with a gentle hump, shows the performance of the oscillator in the GPSDO.  The green trace isn't showing much flattening because the noise level appears to be much lower and the flat area is masked by the limitation of the 53131.  The delay in the orange trace turning to follow the GPS LIne might be due to noise - whether internal or external.  It could also be due to 'digital noise' in the disciplining algorithm.  Note that the undisciplined trace (Green) is lower (quieter) than the disciplined trace (Orange) for the same two devices.

The increase in the 1 sec. ADEV values of your unsaved traces is suspicious.  Instead of being down near the counter's resolution of 1.5e-10, they're up around 7 - 8 e-10.  This is often due to noise.  I avoid measuring frequency because, typically, the counter reports a value that represents the frequency averaged over whatever gate time it's set for.  This has the effect of making the results look better than they really are because the noise has been averaged out.

Tracking down noise sources and beating them into submission is an ongoing task when you're working at these levels.  I always use low pass filters on the inputs and before the signals get to the counter, they go through a home-brew sine to square converter that gives them a nice sharp rise time.  This reduces timing jitter that occurs when you're using sine waves in this type of measurement.  I also use double-shielded coax cables to further reduce external noise.  Switching power supplies and other RF sources like cell phones should be kept away from your bench.  Sunbeams are evil because they cause temperature changes.  Moving a cable during a data run is forbidden because it will change the delay through that cable.  No, I'm not kidding!  I set up a data run and then access the PC running Timelab from a second computer that's on the other side of the room.  That way, I'm nowhere near the equipment.  No, I'm still not kidding!

The second ongoing task is getting better and better counters.  I've gone through six or seven counter/analyzers.  My Fluke PM6681 has been my go-to unit for a few years, but I'm starting to replace it with Eric Kaashoek's tinyPFA.  It's hard to beat its price/performance ratio.  I'm still working on how to get the best performance out of it.

Ed

[Name00]

Okay a new graph.   The Green line was taken where the X99 was completely free-running.  The Orange and Cyan line were the X99 in GPSDRO mode being disciplined also.

Are you sure about that?  The green line is showing what looks like disciplining, although that could just be the end of the graph flapping around - it likes to do that.  ADEV doesn't care if the REF or the DUT is being disciplined.  The graph will look the same.  If you draw in my GPS Line, both lines turn and start to drop at the right time.  The cyan trace (i.e. the Tbolt) seems to have a rather high noise floor.  The green trace looks okay.

Very sure.  You said put the best Rubidium source on, this X99 was getting 9.0e-13 sometimes with the slope adjustment forced -- meaning there was no adjustment that needed to be made after I set the DDS at the start and told it to discipline itself for 2200 seconds, ran it through the disciplining process -- it was also a shorter run, only 7 hours.   This flapping around I saw a lot of on the 2 day run, and I also noticed after the ~ 20 hours that line slowly rising upward as if the (upper?) performance/noise averaged itself out at ~3e-12 at 10000s

All three of the unsaved graphs are showing a slope of 1:1 from Tau of 1 to 10 sec.  At that point, the Tbolt starts to fade due to its internal noise.  The other two carry on until about 300 sec. where the orange trace flattens out.  This flattening, possibly with a gentle hump, shows the performance of the oscillator in the GPSDO.  The green trace isn't showing much flattening because the noise level appears to be much lower and the flat area is masked by the limitation of the 53131.  The delay in the orange trace turning to follow the GPS Line might be due to noise - whether internal or external.  It could also be due to 'digital noise' in the disciplining algorithm.  Note that the undisciplined trace (Green) is lower (quieter) than the disciplined trace (Orange) for the same two devices.

The Green line comment makes much more sense then, I was getting extremely good accuracy where the GPS was not seeing tuning at 80k+ seconds and small sprints of adjustments and settled back to the original dds value.  The Orange is seeing the GPS 1 PPS noise and disciplining for  both oscillators made into noise, it was cloudy for 1 day during that run also!   I think I'm seeing the pattern to the analysis from your wise words!  Thank you, thank you!

The increase in the 1 sec. ADEV values of your unsaved traces is suspicious.  Instead of being down near the counter's resolution of 1.5e-10, they're up around 7 - 8 e-10.  This is often due to noise.  I avoid measuring frequency because, typically, the counter reports a value that represents the frequency averaged over whatever gate time it's set for.  This has the effect of making the results look better than they really are because the noise has been averaged out.

Tracking down noise sources and beating them into submission is an ongoing task when you're working at these levels.  I always use low pass filters on the inputs and before the signals get to the counter, they go through a home-brew sine to square converter that gives them a nice sharp rise time.  This reduces timing jitter that occurs when you're using sine waves in this type of measurement.  I also use double-shielded coax cables to further reduce external noise.  Switching power supplies and other RF sources like cell phones should be kept away from your bench.  Sunbeams are evil because they cause temperature changes.  Moving a cable during a data run is forbidden because it will change the delay through that cable.  No, I'm not kidding!  I set up a data run and then access the PC running Timelab from a second computer that's on the other side of the room.  That way, I'm nowhere near the equipment.  No, I'm still not kidding!

Again this makes sense sunshine, lollipops and all!     I have the  GPSDRO across the room due to where the antenna is so the run to the counter is exposed to the sunshine, so that green line was subjected to far less noise also cause it was night time and I was no where near the equipment.   The brain explodes now to realizing, I should have left the green running MUCH MUCH longer..  it also partially confirms the shifting up of the orange line!

Wow the NanoVNA into a TinyPFA!  That is extremely cost effectiveness, it's awesome, I hear my wallet lightening soon..  You may also have a follower trying to learn your wisdom and knowledge, I'm normally not so concerned about this but the process of wanting to improve the GPSDRO in such a cost effective way as tweaking a few variables is insanity at it's best! Given the accuracy is near 1 second in 10 years and I'm not playing in the GHz range for equipment, good times!    I can see how chasing the perfect lab could be an obsession!

Thanks again!

[bingo600]

My Fluke PM6681 has been my go-to unit for a few years, but I'm starting to replace it with Eric Kaashoek's tinyPFA.  It's hard to beat its price/performance ratio.  I'm still working on how to get the best performance out of it.
Ed

Hi Ed
Please share your wisdom/tips regarding the tinyPFA 
I'm playing around with mine too.

/Bingo

[edpalmer42]

If you haven't already done so, I'd recommend searching here on eevblog for Allan Deviation, ADEV, tinyPFA, and Timelab.  There's been lots of discussion over the years and there's lots of good info here.  But be warned!  The further you go, the deeper the rabbit hole gets!

One other note about data runs is that an ADEV graph is only valid if the phase and frequency plots are free of spikes, jumps, or other glitches.  It's rather terrifying to watch the effect a single glitch can have on the ADEV plot.  If you're watching as the data is being processed, you can see an instantaneous order of magnitude jump in the graph!  Some problems are easier to see/fix on one graph or the other, so check both.

I have an operational trick that I use with Timelab that might interest you.  When you're in the middle of a data run there are heavy limits on what you can do with the data.  But one thing you can do is save a copy.  So I save a copy to a directory that's shared on the lan.  Then, from another computer, I open the saved data in another copy of Timelab.  Now, I can inspect, slice, dice, and edit the data.  Is the data good?  Is it what I expect?  Is there an error in my setup?  If there's a problem, is the data recoverable?  If the data is trash, there's no point in waiting a few days to find out.  Cut the data run short, fix the problem, and start again.  Some of this can be done on live data, but some can't.

Bingo, I don't think there will be any words of wisdom from me.  More likely a list of mistakes to avoid.  I previously posted some tinyPFA noise floor graphs measured with various input parameters.  I think I messed them up because I didn't understand how to use the side channel. 

Ed

[Name00]

I'll have to wait awhile before I can see the performance with the tinyPFA, and the layout here for the testing.

For anyone interested, I just pushed the last update for awhile, this version has been modified to support Python3 on Linux.  I've tested this with a Pi Zero, and a LuckFox Pico Mini B.  The latter offers 2/3 UARTs and a GHz CPU in a form factor slightly larger than an a ESP32-C3 OLED.   If you use it on a X72, let me know, from what I can tell I've used the commands that should be compatible with the older 4.x firmware from what was stated in the SA.22c thread.

Suggestions are welcomed, I'm trying to balance memory usage vs features but given how basic it this is we still have over 60KB of memory left on the Raspberry Pi Pico W still even with the Python 3 code in place.

Hope you guys find it useful, if you do use it or test it, send a thank you on this message.  it will help me figure out up take of the program.. :-)

[Name00]

Got the NanoVNA-H4, updated with the tinyPFA firmware and redid the measurements. 

The results looks interesting, they look good to me and confirms the overall performance on the X99/SA22 to be fairly good.  The tail end seems odd to me how the BH3SAP did better, but my understanding is it's well within the noise margin, it's a good snapshoit in time.

[Name00]

I've been testing and putting this code through some long term testing.    I found some logic errors in the holdover code which I believe is now correctly. 

I also tried to put this in a small aluminum box to try to shield it form noise based on Ed's previous feedback..  It worked and gave it a slight edge.  I've included them in a note, they were all tested with a Trimble 66266-45
driving the timing as I found it the most stable in stormy days of summer and the cloudy days of the last couple of weeks here.

Last change, I also tried different "averaging" windows and settled on a combination that produced a bit less jitter and was a good all around on less stable 1 PPS modules and tested on both my SA.22c and the X99.  I'll be updating the code sometime this weekend; for now I've posted an image of the 3 new captures.

Update:  New code up on Github.
Update2: I also corrected the disciplining timing, didn't realize I introduced this which was affected by the speed of the processor.

[KE5FX]

I have an operational trick that I use with Timelab that might interest you.  When you're in the middle of a data run there are heavy limits on what you can do with the data.  But one thing you can do is save a copy.  So I save a copy to a directory that's shared on the lan.  Then, from another computer, I open the saved data in another copy of Timelab.  Now, I can inspect, slice, dice, and edit the data.  Is the data good?  Is it what I expect?  Is there an error in my setup?  If there's a problem, is the data recoverable?  If the data is trash, there's no point in waiting a few days to find out.  Cut the data run short, fix the problem, and start again.  Some of this can be done on live data, but some can't.

No need to open it in a separate copy of TimeLab, just load the file into the copy that's already running.

[cncjerry]

Name00, 
Do you know if the PID code in Lady Heather supports the X72?  I use the auto tune feature in LH to set the X72 tuning word by feeding the X72 from a u-blox LEA-M8T GPS unit and that works fine.  I had been wondering if Mark's disciplining loop would work with it.  I have two X72s, neither have the V5 software otherwise I could just let the X72 do the loop.  Mark and I bought X72s at the same time.  I machined his heatsink and he sent me an x72 adapter board, though I wished I had bought another from him as it was better than the one that came with the X72.

I was given two of the u-blox M8T units for machining 120 sets of front and back plates for the box used to contain them.  There was a deal on the GPS units on the time-nuts reflector a while back.

Thanks

Jerry

[Name00]

It looked like Mark started with a X72 then "grafted" the SA22c and X99 support to it. 

It could be easier to force it to the X72 mode by using "/rxx7" and then setting the required baudrate if it's not 57600.

Things to check for "r>" prompt shows up using a serial program first.  If it does then then the code will work provide the rest of the code behaves like the SA22c.  If not then some testing to see the difference and make changes from the X99 maybe be needed so double check the commands below:

Code: [Select]

i – Oscillator Model Information Banner
w – Oscillator Health Output
j – 1 PPS Delta Information
k – Override or reset 1 PPS Delta
f – Set Frequency Adjustment
q - Set Control Register

Your alternative is to take the python code I've written and check with that, I've avoided the use of the "R>" but that also means I've hard coded the output but it works on both with the SA22c and X99 so there's some changes that can be done easily hopefully to do a hybrid of the behaviour.

Just realized I didn't answer your question:  Marks discipline and the auto tune  are one in the same.  So there's no continuous tuning loop, I presume you're trying to mimic the V5 command?  If so that's what the Python code I did does, but in a much cruder way.

[cncjerry]

I have gpsdo code and hardware with sawtooth and dual dacs that works with the X72 but you are right, I'd like to have the v5 code in my x72 but the guy that used to upgrade them said he could brick it by accident.  So I just auto tune my X72 now and then, but I thought Mark put a PID loop in heather, no?  But I have better Wenzel oscillators I'd rather discipline because Rbs are noisy.  I have 4 Rb units and none of them are anywhere near my Wenzels for phase noise.  But if lady heather could discipline it, it would be a good alternative as I have LH running on a beaglebone black and that sips power.

Thanks, I have to look at the source for LH.  I assume your python code grabs the 1PPS delta reg and calculates the tuning word, but doesn't resetting the tuning word glitch the X72 output?

Thanks again.

Jerry

[Name00]

Thanks, I have to look at the source for LH.  I assume your python code grabs the 1PPS delta reg and calculates the tuning word, but doesn't resetting the tuning word glitch the X72 output?

I think I answered most of the questions in our PM thread, I have no real way to measure the glitching if it occurs seems to mask itself as part of the frequency noise.   

I did a few tests and noticed if I modified the PPS delta itself it was difficult to do a proper delta to track it, so in the code I use an offset instead may also be why I didn't notice the glitch but my equipment may just not have the resolution to do that tracking.

[cncjerry]

i had glitches using a gtc to measure pps and couldn't get rid of them until I turned off the timestamp on the output.  monitor the gtc in timelab and make sure you only get one number, not a timestamp followed by a delta number.

[Name00]

Thanks to some feedback from cncjerry, the code is now far easier way to lock the dds tracking without editing the code.  It will allow you to set the DDS word without editing a couple of spots or commenting thing out.    The code also is now confirmed to work with the X72, so it officially supports the X72, X99, and SA22c.

As a result of the changes, I also updated so it works on Windows, I haven't tested on a raspberry pi (proper) yet, there's no algorithm change but testing with the TinyGTC vs TinyPFA, I'm near tracking the accuracy of the GPS PPS as of my previous update, and unless I get a far more accurate PPS source it is going to be hard to determine what else to tweak.  I'm near averaging 2e-12 +/- 0.75e-12 after 23 hours on the adev.

I still need to update the Readme on github but for those who are using or testing it, please do provide feedback, constructive complaints, or kudos.