A look at my Symmetricom GPSDO / 10MHz reference (OCXO + Furuno receiver)

[edpalmer42]

Don't bother with the lottery.  You've used up all your good luck! 

What kind of AlDev numbers are you getting?

[texaspyro]

I haven't done any analysis on the adevs, etc.

[texaspyro]

I did some more poking and prodding of the Trimble receiver.  If you do a SYST:PRES command it resets to the factory defaults and starts a 30 minute self survey.  There is a command to enter your own coordinates which will stop the self survey.   Once the survey completes or it has user coordinates, it stores the location into EEPROM.  A power-cycle will re-load the saved coordinates from EEPROM and does not cause another survey.

I assume, but have not tested, that if you move the unit significantly it will detect that and automatically start a new survey...  That is pretty much standard for timing receivers.

[ekyle]

I assume, but have not tested, that if you move the unit significantly it will detect that and automatically start a new survey...  That is pretty much standard for timing receivers.

I moved the antenna for my Symmetricom version about 40 feet and tried the original coordinates. It got very confused and would drop and add satellites every other second. Everything worked again when I did a new survey. I think if it's moved at all, a new survey should be done.

[davebb]

 Hi The Symmetricom Does a new survey any time the power is interrupted
Dave

[uncle_bob]

I assume, but have not tested, that if you move the unit significantly it will detect that and automatically start a new survey...  That is pretty much standard for timing receivers.

I moved the antenna for my Symmetricom version about 40 feet and tried the original coordinates. It got very confused and would drop and add satellites every other second. Everything worked again when I did a new survey. I think if it's moved at all, a new survey should be done.

Hi

Forty feet may not be far enough for it to really *know* it has moved.

Bob

[Bryan]

Hi The Symmetricom Does a new survey any time the power is interrupted
Dave

I second that, Texaspyro are you sure the Trimble saves the survey, doesn't seem to happen with the Symmetricom

[davebb]

Yes the Trimble does save it
Dave

[TheSteve]

Yes the Trimble does save it
Dave

+1
The Trimble does save the survey.

[texaspyro]

Just for grins I tried powering my Trimble unit with a 2A Samsung USB charger wall wart.  It works!  The USB type AS to barrel plug cable wires are rather thin and around 3 feet long.  When cold the voltage at the Trimble was 4.2V,  warmed up it was 4.6V  Unloaded, the charger output was 5.23V

[texaspyro]

I have Lady Heather working pretty well with my Trimble unit. 

I added some code to poll and read the DIAG:LOOP? message.  The main value that seems interesting is the FREQ DIFF value.  I log and plot that as the "OSC" parameter.   It is 0.0 if the unit is not discipling the oscillator (power-up, user turned off disciplining by setting a fixed DAC value, etc).   

Occasionally the FREQ DIFF has a bogus value -2.79E-07.  I treat this as noise and ignore that reading.   One very interesting thing that I noticed is than once an hour (at xx:26:26) the loop goes a bit whacky.  It looks like the firmware does something that upsets / resets / whatever-sets the PLL.   Attached is a plot of the resulting havoc...  It takes around 3 minutes for the loop to start settling down,  but takes around 18 minutes to stabilize and 36 minutes to really dampen out... only to have it's bell rung 24 minutes after that.

[Bryan]

Do you have/offering a link to the beta software. Would like to give it a go with the Symmetricom.

[uncle_bob]

Do you have/offering a link to the beta software. Would like to give it a go with the Symmetricom.

Hi

Does the beta code handle the Bolivian calendar properly?

http://www.bbc.com/news/world-latin-america-36595192

One *must* keep up to date.

Bob

[texaspyro]

Do you have/offering a link to the beta software. Would like to give it a go with the Symmetricom.

Hi

Does the beta code handle the Bolivian calendar properly?

http://www.bbc.com/news/world-latin-america-36595192

One *must* keep up to date.

Bob

Why, yes it does!  Lady Heather know all,  speaks all,  clocks all.  Has support for various Mayan, Inca, and Aztec calendars (and being pan-denominational Druid, Jewish, Islamic, Persian, Afghan, Kurdish, Indian, and a whole lot of others).   

The 13 month years are key to the Tzolkin calendars (both Mayan and Aztec have their own versions).  That heretical year 1492 offset can be accommodated by specifying an offset to the real calendar using the "set Mayan correlation offset" command...  the archaeological dweebs can't agree about when the reference date of the calendars should be, so there is a "correlation factor" adjustment capability.

[texaspyro]

Do you have/offering a link to the beta software. Would like to give it a go with the Symmetricom.

Not yet,  still waiting on my Symmeticom to come in.  I know that it has some incompatibilities with the Trimble that must be fixed.

[texaspyro]

I've made a very nice discovery this evening. I know there have been several questions posted about a battery backup for the GPS data. Well, I was looking at the silk screen printing for J3. It reads 1:Rx, 2:Tx,3:BT,4:GD. 1,2 are of course the serial port. 4 is ground. BT.... Could it be short for battery? While the unit was on I measured about 3.2v on pin 3. I hooked up a power supply to pin3 and removed power on the unit. I waited a while and plugged it back in. It booted and I could see immediately that it had the GPS location and was in hold mode. Now for the bad news. With the unit powered off, it draws about 88ma from this pin and 0ma when its on. It could be that it keeps the GPS receiver alive with it. Definitely not just a CMOS memory backup. I'm not sure if its current limited so a super cap could be used on it.

I suspect that BT may be a built-it-test-system status output... almost all the telco reference units and rubidium oscillators have some sort of BITS signal.  Connecting a voltage source to it is probably powering the electronics through the protection diodes in whatever chip it goes to (and stressing the hell out it).  There is no way a memory backup line would draw 88 mA.

[ekyle]

I suspect that BT may be a built-it-test-system status output... almost all the telco reference units and rubidium oscillators have some sort of BITS signal.  Connecting a voltage source to it is probably powering the electronics through the protection diodes in whatever chip it goes to (and stressing the hell out it).  There is no way a memory backup line would draw 88 mA.
[/quote]

Good point there! That may very well be the case that it is a logic gate output.

[gm8bjf]

Phase noise checks on UCCM-P units.

I now have several Symetricom units and one Trimble UCCM-P unit. I have been making some comparative measurements of their phase noise (PN) performance as I want to use them as references for microwave PLLs. I did these checks using the PLL technique and compared them to a couple of HP10811 OCXOs that I have which are probably as good a PN standard as I can easily (and reasonable cheaply) lay my hands on. I also have some bare OCXOs off the Symetricom and Trimble units. (The ones I could not raise from the dead!)

I found that the PN seems to be determined by the OCXOs in use which is not surprising and suggests the locking/disciplining process is not degrading the PN which is reassuring. The Symetricon units are better than the Trimble units by 10- 12 dB and the Symetricom was only 2-3 dB worse that the than the HP10811.  The Trimble units did seem relatively noisy and it comes from the OCXO.

To detect the PN I was using a HP 11848 PN test set and measuring the demodulated output noise with a HP 3400 rms voltmeter. I have not managed to stumble across the proper FFT analyser for the HP3048 test set yet. A computer sound card and and audio spectrum analyser programme also works if you can do enough averaging on the signal.

I need to compare them to my Z3801 now!

Hope that is of passing interest,

73s
Brian GM8BJF

[texaspyro]

I got in my Symmetricom unit (and another Trimble).  Both (from the same seller) arrived in excellent condition (except the parcel smashers had their way with the well packed box).

I have Lady Heather working fairly well with it.   Along the way I noticed a couple of things...  The time stamp message does not seem to be sent in the middle of things like the SYST:STAT? command results like some people have reported.  It can come out while one is in the middle of sending a command to the unit... when that happens that command is corrupted and you get an "undefined header" response.

Also, it occasionally skips sending the time stamp message.

You can stop the power-on self survey by sending your position to the unit.  No setting that you made to the unit survive a power-cycle.

I think that the altitude that it reports is in MSL, not WGS84 geoid height.  It is about 20 meters too high for WGS84.

Attached is a screen dump from an 8-hour run.  The TEMP plot is a plot of the "temp corr" value multipled by 1E12... it is mislabeled as being in degrees (should probably be labeled as in being in PPT (parts per trillon).  The OSC plot is the "freq corr" value. The PPS plot is from the SYNC:TINT? message.

 

[Macbeth]

The time stamp message does not seem to be sent in the middle of things like the SYST:STAT? command results like some people have reported.  It can come out while one is in the middle of sending a command to the unit... when that happens that command is corrupted and you get an "undefined header" response.

Also, it occasionally skips sending the time stamp message.

Odd. I have the exact opposite behaviour. I did think maybe you have a different firmware but your screen shot shows the same as mine, 1.0.0.2-01

Just to test my sanity I fired it up from cold and logged the results using PuTTY

Code: [Select]

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2016.07.03 12:52:16 =~=~=~=~=~=~=~=~=~=~=~=
 

Symmetricom Boot Code ver. 1.01.01


Press Enter to go to boot
Image1: [1.0.0.2] [454535 bytes] [valid checksum:0x20AFA24] [timestamp:3]
Image2: [1.0.0.1] [454535 bytes] [valid checksum:0x2142B89] [timestamp:2]

Loading Image1
 UCCM-P > *IDN?
Symmetricom,090-03861-03,W5609120082,1.0.0.2-01
Command Complete
UCCM-P > TOD EN
Command Complete
UCCM-P > c5 00 80 00 00 00 00 28 1c 52 00 00 20 60 c1 91 00 00 00 00 00 00 00 00 00 00 00 00 00 00 22 00 00 41 00 8f 50 00 00 00 00 97 72 ca
SYSc5 00 80 00 00 00 00 28 1c 52 00 00 20 60 c1 91 00 00 00 00 00 00 00 00 00 00 00 00 00 00 24 00 00 41 00 8f 50 00 00 00 00 9c 15 ca
T:STATc5 00 80 00 00 00 00 28 1c 52 00 00 20 60 c1 91 00 00 00 00 00 00 00 00 00 00 00 00 00 00 26 00 00 41 00 8f 50 00 00 00 00 6a d7 ca
?c5 00 80 00 00 00 00 28 1c 52 00 00 20 60 c1 91 00 00 00 00 00 00 00 00 00 00 00 00 00 00 28 00 00 41 00 8f 50 00 00 00 00 8a db ca

-------------------------------------------------------------------------------
090-03861-03   serial number W5609120082   firmware ver 1.0.0.2-01     LINK mode
-------------------------------------------------------------------------------
Reference Status __________________________   Reference Outputs _______________
   Ref 8KHz 0: [LOS]                         
                                              TFOM     9             FFOM     3
                                              UCCM-P Status[OCXO WARMUP]
                                             
>> GPS: [no ref]                             
ACQUISITION .............................................. [ GPS 1PPS Invalid ]
Tracking: 0 ____   Not Tracking: 0 ________   Time ____________________________
                                              GPS      00:00:43 [?] 06 JAN 1980
c5 00 80 00 00 00 00 28 1c 52 00 00 20 60 c1 91 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2a 00 00 41 00 8f 50 00 00 00 00 7c 19 ca
                                              GPS      Invalid: not tracking
                                              ANT DLY  +0.000E+00
                                              Position ________________________
                                              MODE     Survey:      0% complete
                                                       Suspended: track <4 sats
                                              INIT LAT N  34:44:00.000
                                              INIT LON E 135:21:00.000
                                              INIT HGT           +0.00 m  (MSL)
                                             
                                             
                                             
                                             
ELEV MASK  5 deg                             
-------------------------------------------------------------------------------

Command Complete
UCCM-P > c5 00 80 00 00 00 00 28 1c 52 00 00 20 60 c1 91 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2c 00 00 41 00 8f 50 00 00 00 00 77 7e ca
TODc5 00 80 00 00 00 00 28 1c 52 00 00 20 60 c1 91 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2e 00 00 41 00 8f 50 00 00 00 00 81 bc ca
 DI
Command Complete
UCCM-P >

After issuing TOD EN you can see I am typing in SYST:STAT? and it getting garbled amongst the timestamps, however this is just fine - no undefined header errors.

I also timed it so when I pressed enter I would get the TOD message in the normal output of SYST:STAT? which can clearly be seen. I then turned off timestamps with the TOD DI command and it was interrupted but the command completed with no undefined header errors.

I can't say I've noticed skipped time stamps but I haven't been looking for them anyway.

Well done on your progress with Lady Heather though. I hear she can be a cruel mistress (groan) 

[texaspyro]

Lady Heather uses the time stamp message to pace / trigger sending requests for info from the receiver.  Whenever a time stamp message arrives, I send a few queries to the receiver from a queue of pending info request messages.  I suspect that the reason I am not seeing time stamps arrive in the middle of query results is because my requests are always done right after a time stamp message arrives.  As long as all the results come back within 2 seconds, I will never see a time stamp arrive in the middle of a response from the receiver.

The "Undefined header" response that I see whenever a time stamp arrives in the middle of sending a query to the receiver is probably an artifact of the way that Heather queues up and sends requests to the unit.   They don't occur very often and the info will be re-requested on the next message polling cycle.

[texaspyro]

I've done several self-surveys with the Symmetricom unit and it consistently reports an altitude that is around 30 meters above the WGS84 altitude (I know my antenna location to within a centimeter).   The geoid-ellipsoid separation at my location is 27.3 meters.  It sure looks like it is reporting the altitude in MSL (mean sea level), not WGS84 coordinates.  So, if you manually set the survey location send it MSL altitude and not the WGS84 altitude that most GPS receivers report.

I need to run the Trimble unit some and see if it does the same thing.

[uncle_bob]

I've done several self-surveys with the Symmetricom unit and it consistently reports an altitude that is around 30 meters above the WGS84 altitude (I know my antenna location to within a centimeter).   The geoid-ellipsoid separation at my location is 27.3 meters.  It sure looks like it is reporting the altitude in MSL (mean sea level), not WGS84 coordinates.  So, if you manually set the survey location send it MSL altitude and not the WGS84 altitude that most GPS receivers report.

I need to run the Trimble unit some and see if it does the same thing.

Hi

But do you *really* know any altitude to within a centimeter from day to day? 

http://www.navipedia.net/index.php/Solid_Tides

Now if only there was a program out there that displayed that .... Yes, you *must* include the gravitational impact of Pluto to get "all the details" ....

Bob

[texaspyro]

I think I figured out why I get an "Undefined header" response if a time code message comes out in the middle of sending a command to the unit...  the unit stops accepting and echoing input characters while the time code is coming out (which takes around 25 milliseconds).  I suspect that it also blocks input while it is sending responses to any query, but the way that Lady Heather works prevents that from happening... only those unsolicited time code messages cause the queries being sent to the unit to get garbled. 

I've only seen queries sent right after the rather long DIAG:LOOP? response comes in getting munged.  I suspect that a query sent after a SYST:STAT? message arrives could also be munged, but Heather only sends that query once a minute (at xx:xx:33 seconds).

[uncle_bob]

I think I figured out why I get an "Undefined header" response if a time code message comes out in the middle of sending a command to the unit...  the unit stops accepting and echoing input characters while the time code is coming out (which takes around 25 milliseconds).  I suspect that it also blocks input while it is sending responses to any query, but the way that Lady Heather works prevents that from happening... only those unsolicited time code messages cause the queries being sent to the unit to get garbled. 

I've only seen queries sent right after the rather long DIAG:LOOP? response comes in getting munged.  I suspect that a query sent after a SYST:STAT? message arrives could also be munged, but Heather only sends that query once a minute (at xx:xx:33 seconds).

Hi

It could be a bug or there may be a magic "required hold off" period to either side of the time code message.

Bob