I see my attached images raised some interest so it seems the subject of DIY rubidium atomic frequency standards isn't totally dead (just rather moribund
).
I did finally get round to sending my reply to our newbie friend, wa4whl but, with only 2 posts to his credit in over nine years, I doubt I'll ever get a reply.
I only jumped on that post out of desperation since I couldn't track down other discussions on the SA22C anywhere on the 'net, just that one reference. I ticked the notification button just in case before closing that tab to post more on my 'new toy' here in this now renamed topic thread.
I've been busy testing it out against my home brewed gpsdo (basically a revamp of the G3RUH design with an M8T replacing the Jupiter T, phase locking the ocxo at 100KHz with a 1200 seconds TC filter) and was finally persuaded to reorganise the bench to accommodate my LPR101 based RFS and give my SDS2502X+ something useful to do for its 46 second boot up time and its 54W consumption (versus the 16 seconds/22W of the SDS1202X-E that usually suffices as a graphic TIC).
The reason for the reorganisation to show both rubidium oscillators against the GPS reference simultaneously being the reappearance of a curious symptom of instability I'd seen with the LPRO a few weeks ago (the impetus for blowing another 290 quid in total on acquiring the SA22C).
Initially I'd assumed the rapid 10 to 20 ns transient backward phase shifts to be a very peculiar intermittent fault being developed by my now 25+ yo lpro but I am now starting to suspect the GPS system may be suffering fall out from the war in Ukraine due to electronic countermeasures by either the Russians or possibly even by the Americans as part of a strategy to wrong foot the Russians who may be using GPS as a sanity check/backup to their GLONAS systems
Yesterday I started seeing similar symptoms with the SA22C which had me dialling in offset corrections via its serial interface to try and keep it syntonised to the GPS reference which raised my suspicions once more about the stability of the GPS system as a high(ish) precision reference source. That was the moment I decided to make room for my LPRO RFS in order to confirm or lay my suspicions to rest. Of course, this 'weirdness' only occurs once every few days or so and the setup now seems to back to its normal state of precision (ionospheric disturbances aside).
Unfortunately, the SA22C is only at the bench testing stage and subject to the variations of ambient temperature (just like the LPRO did when I was first checking it out almost 2 years ago now) which makes the task of pinning down 'the guilty party' just a little more tricky than I like. Still, I only need to witness another such 'event' to determine which, between the LPRO RFS and the GPS reference. is the true cause of these phase jumps.
In the meantime, I'm trying to make sense of the information in the Symmetricom / Microsemi user guides and data sheet specifications. Of more immediate interest to me, is how to interpret the health data which is simply listed in hexadecimal form as per the w command output shown below:-
r>w
AData:
SCont: 6012
SerNum: A12
PwrHrs: 5F18
PwrTicks: 1282841
LHHrs: 5ECF
LHTicks: 10F5542
RHHrs: 5ECF
RHTicks: 1063C65
dMP17: 4159F035.
dMP5: 3D4E9CE6.
dHtrVolt: 4172E210.
PLmp: 3F93465F.
PRes: 3FC3C440.
dLVthermC: B8520000.
dRVthermC: B99CD000.
dLVolt: 3F8F52C5.
dMVoutC: C9D122BB.
dTempLo: 41000000.
dTempHi: 42B10000.
dVoltLo: 4156B1A8.
dVoltHi: 4173473E.
iFpgaCtl: 204C
dCurTemp: 425A0000.
dLVoutC: 3E0508D5.
dRVoutC: 3DF08B1B.
dMV2demAvg: 3F0C7C1A.
Does anyone know how to interpret this data. Unless the PwrHrs: (5F18) counter has wrapped around a 16 bit limit, it looks like it's clocked up just a tad over
1014 24344 hours, a mere 2.7771 years worth of run time, which if true, is just 27% of its design life.
The i command displays this:
r>i
SA22C by Symmetricom, Inc., Copyright 2006
SA22 Version 6.02C of 7/2006; Loader Version 3
Mode CN41 Flag 0004
Unit serial code is 1211EC3234-h, current tuning state is 6
Crystal: 3938700hz, ACMOS: E4E1C0.00000000hz, Sine: 989680.00000000hz
Ctl Reg: 004C, Res temp off: BFC53F7D., Lamp temp off: BFF9418E.
FC: enabled, Srvc: low
The final line just indicates the sense of the service output pin when it asserts a service required warning. The service pin reads 4.9 volts so no warning of imminent failure within the next few months at least. Worthy of note is the firmware version which predates the later version 6.05C which offers customer access to the 1PPS configuration, along with being able to enable sine wave output.
The user guide suggested that the early version would normally default to 10MHz sine wave and enable the PPS feature by default, the implication being that the end user wouldn't be able to tune the PPS control algorithm with the earlier firmware version. To test this, I added an SMA-F socket to my breakout board and connected an M8T to it. Sad to say, there was absolutely no indication that the PPS input option was enabled so it seems I'm out of luck regarding a quick solution to creating a GPSDRO by simply adding nothing more than a suitable GPS receiver module into the mix.
I wasn't too surprised at this after reading this note in the user guide:
================================================================================
Setting the 1PPS Synchronization
The following are the steps for setting 1PPS signal synchronization (SA.22c with 1PPS enabled customer
version of firmware at revision 6.05c or higher installed.)
================================================================================
I did a search to try and track down a firmware update but came up completely dry. I guess such an update has now long since become yet another item of "Unobtainium", so it's looking like I'll just have to create a 10MHz sine wave output GPSDRO the old fashioned way.
I rather think I'm on my own in this endeavour but if anyone knows anything useful about these SA22C units, I'd really appreciate the help.
I've attached four photos of the current bench setup.