Symmetricom X99 - Rubidium Oscillator - Page 1
Forum section: electronics / general

author: Name00
author_rank: Contributor
timestamp: April 03, 2025, 09:30:45 pm
content: 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/ladyheatherI’ve also included a picture of it during one of my non-calibrations testing for those interested.[Updated: with github link]

author: Name00
author_rank: Contributor
timestamp: April 17, 2025, 12:51:07 am
content: 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?Quote

author: bingo600
author_rank: Super Contributor
timestamp: April 17, 2025, 05:58:44 pm
content: 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

author: Name00
author_rank: Contributor
timestamp: April 19, 2025, 04:32:42 pm
content: Quote from: bingo600 on April 17, 2025, 05:58:44 pmI 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:MPY: soft rebootModel: X 9 9 -- S/N: xxxx-H -- Service Pin: HIGHRubidium lock is good.Calculating a new DDS value..Setting DDS to: 0.0Resetting PPS Delta to: 0Waiting 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-10Current Count: 300 -- current Delta: 59999986 ( -14 )Current Count: 400 -- current Delta: 59999981 ( -19 ) -- Total Values: -3845 -- Average: -9.6125 -- Slope: -8.34818e-10Current Count: 500 -- current Delta: 59999975 ( -25 )Current Count: 600 -- current Delta: 59999971 ( -29 ) -- Total Values: -8778 -- Average: -14.63 -- Slope: -8.37008e-10Current Count: 700 -- current Delta: 59999966 ( -34 )Current Count: 800 -- current Delta: 59999960 ( -40 ) -- Total Values: -15710 -- Average: -19.6375 -- Slope: -8.36142e-10Current Count: 900 -- current Delta: 59999955 ( -45 )Current Count: 1000 -- current Delta: 59999950 ( -50 ) -- Total Values: -24634 -- Average: -24.634 -- Slope: -8.34646e-10Current Count: 1100 -- current Delta: 59999946 ( -54 )Current Count: 1200 -- current Delta: 59999941 ( -59 ) -- Total Values: -35571 -- Average: -29.6425 -- Slope: -8.34826e-10Current Count: 1300 -- current Delta: 59999935 ( -65 )Current Count: 1400 -- current Delta: 59999931 ( -69 ) -- Total Values: -48514 -- Average: -34.65286 -- Slope: -8.34939e-10Current Count: 1500 -- current Delta: 59999926 ( -74 )Current Count: 1600 -- current Delta: 59999920 ( -80 ) -- Total Values: -63426 -- Average: -39.64125 -- Slope: -8.33796e-10Current Count: 1700 -- current Delta: 59999915 ( -85 )Total value: -80364 -- Entries: 1800 --Average: -44.64667 -- Slope: -8.34019e-10Current DDS Value: 0.0 -- DDS Offset: -83.4 -- New DDS Value: -83.4Setting DDS to: -83.4Resetting PPS Delta to: 0Waiting for PPS reset...-- GC Memory Alloc: 102992 GC Memory Free: 74288 GC Collected: NoneModel: X 9 9 -- S/N: xxxx-H -- Service Pin: HIGHRb Lock: Good -- Current Temp: 48.5 -- Lamp Voltage: 16.9205Current PPS Delta: 0 ( 0 ) -- Counter: 4DDS Adjust: -83.4 Running Slope: 0.0 Calc Slope: 0.0.....-- GC Memory Alloc: 35472 GC Memory Free: 141808 GC Collected: NoneModel: X 9 9 -- S/N: xxxx-H -- Service Pin: HIGHRb Lock: Good -- Current Temp: 51.25 -- Lamp Voltage: 16.9164Current PPS Delta: 0 ( 0 ) -- Counter: 13364DDS Adjust: -83.2 Running Slope: 1.956299e-11 Calc Slope: -1.481767e-10 Last Averages: 10: 0.1

author: Name00
author_rank: Contributor
timestamp: May 03, 2025, 12:54:39 pm
content: 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-symmetricomFeedback welcomed.

author: edpalmer42
author_rank: Super Contributor
timestamp: May 03, 2025, 06:52:24 pm
content: 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.

author: Name00
author_rank: Contributor
timestamp: May 03, 2025, 08:57:56 pm
content: Quote from: edpalmer42 on May 03, 2025, 06:52:24 pmThanks! 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!

author: Name00
author_rank: Contributor
timestamp: May 10, 2025, 03:25:57 am
content: 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),

author: edpalmer42
author_rank: Super Contributor
timestamp: May 10, 2025, 09:17:04 am
content: Quote from: Name00 on May 10, 2025, 03:25:57 amAre 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.QuoteAll 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

author: Name00
author_rank: Contributor
timestamp: May 10, 2025, 12:08:04 pm
content: Quote from: edpalmer42 on May 10, 2025, 09:17:04 amVery 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 10000sQuote from: edpalmer42 on May 10, 2025, 09:17:04 amThe 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!Quote from: edpalmer42 on May 10, 2025, 09:17:04 amAgain 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!

author: bingo600
author_rank: Super Contributor
timestamp: May 10, 2025, 02:17:30 pm
content: Quote from: edpalmer42 on May 10, 2025, 09:17:04 amHi EdPlease share your wisdom/tips regarding the tinyPFAI'm playing around with mine too./Bingo

author: edpalmer42
author_rank: Super Contributor
timestamp: May 11, 2025, 01:28:00 am
content: 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

author: Name00
author_rank: Contributor
timestamp: May 12, 2025, 01:54:44 am
content: 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.. :-)

author: Name00
author_rank: Contributor
timestamp: May 27, 2025, 12:27:21 am
content: 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.