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

[gm8bjf]

I just bought one of the Trimbles advertised as Symmetricom units from waikeionline_uk and on testing it will not lock up. The only visible damage was a missing 0 Ohm link which I replaced and that did not cure the problem. The SYST:STAT? page shows the OCXO as warming up after many hours of operation and the LEDs never settle into the fast green flashing mode. Bit stumped with this one. I have asked for a refund or a replacement.

Brian.

[Bryan]

So he is now shipping the Trimble unites?. I THINK that the Trimble 57963 has slightly better specs than the Symmetricom, at least that is my recollection.

[rastro]

hi rastro,
1 . for L20 I used an smd choke 4x4.5 mm 2.2 uH 2.5 A
2 & 3 both yes, I looked at my ripped off L20 and did find only one coil.  L20 is mounted in parallel next to the unpopulated R105
4 yes, my board does run fine (with two green blinking LEDs) and all status messages ok as you can see from my other postings in this thread.
hope this helps Kutte

Kutte, thanks for confirmation that the L20 replacement works. 
Since I've done pretty much the same fix on my unit, the problem I am facing is probably due to different issue.

I went back to monitored  the EFC pin on the OSC as ekyle suggested.  This turned out to be a good idea.
1. The unit initially draws 500mA from the 12VDC supply but drops to around 200-250mA in a few minutes.  Temperature of the OSC is hot to the touch.
-- This would be consistent with proper temperature regulation.
2. The 5VDC draws around 200mA .
3. The OCS EFC-Pin reads +13mVDC during OSC warm up and drops to +5mVDC as soon as current drops on the 12VDC (reaching regulated temperature) then stays at that level.
4. Right after 9% of the survey it gets an EFC error on the system status.

Code: [Select]

UCCM-P > status

                 - UCCM Slot STATE -



1-1. #Now ACTIVE STATUS ---------------- [Alarm]
1-2. #Before ACTIVE STATUS ------------- [Wait for GPS]
2-1. #Reference Clock Operation -------- [Not Used]
2-2. #Current Reference Type ----------- [GPS]
2-3. #Current Select Reference --------- [GPS 1PPS]
2-4. #Current Reference Status --------- [Ref Analyzing]
     #GPS STATUS ----------------------- [Available]
     #Priority Level ------------------- [GPS > LINK]
     #ALARM STATUS
     #H/W FAIL ---------- [ EFC ]
     #Bad Quality ------- [ LINK ]
3-1. PLL STATUS ------------------------ [Enable]
3-2. Current: PLL MODE ----------------- [OFFSET OBSERVATION MODE]
At this point it seems that the 10MHz OSC can't adjust frequency to sync up with the GPS values.  I'm guessing that EFC means Electronic Frequency Compensation. 
So now I need to figure out if it is the control circuit or the OSC unit that is the problem. 
Unless I can figure something else out I'll probably desolder the OSC and try and test it with a variable voltage applied to the EFC-pin and see if it loads down or shifts the 10MHz output.

Any other suggestions?

-rastor

[ekyle]

hi rastro,
1 . for L20 I used an smd choke 4x4.5 mm 2.2 uH 2.5 A
2 & 3 both yes, I looked at my ripped off L20 and did find only one coil.  L20 is mounted in parallel next to the unpopulated R105
4 yes, my board does run fine (with two green blinking LEDs) and all status messages ok as you can see from my other postings in this thread.
hope this helps Kutte

Kutte, thanks for confirmation that the L20 replacement works. 
Since I've done pretty much the same fix on my unit, the problem I am facing is probably due to different issue.

I went back to monitored  the EFC pin on the OSC as ekyle suggested.  This turned out to be a good idea.
1. The unit initially draws 500mA from the 12VDC supply but drops to around 200-250mA in a few minutes.  Temperature of the OSC is hot to the touch.
-- This would be consistent with proper temperature regulation.
2. The 5VDC draws around 200mA .
3. The OCS EFC-Pin reads +13mVDC during OSC warm up and drops to +5mVDC as soon as current drops on the 12VDC (reaching regulated temperature) then stays at that level.
4. Right after 9% of the survey it gets an EFC error on the system status.

Code: [Select]

UCCM-P > status

                 - UCCM Slot STATE -



1-1. #Now ACTIVE STATUS ---------------- [Alarm]
1-2. #Before ACTIVE STATUS ------------- [Wait for GPS]
2-1. #Reference Clock Operation -------- [Not Used]
2-2. #Current Reference Type ----------- [GPS]
2-3. #Current Select Reference --------- [GPS 1PPS]
2-4. #Current Reference Status --------- [Ref Analyzing]
     #GPS STATUS ----------------------- [Available]
     #Priority Level ------------------- [GPS > LINK]
     #ALARM STATUS
     #H/W FAIL ---------- [ EFC ]
     #Bad Quality ------- [ LINK ]
3-1. PLL STATUS ------------------------ [Enable]
3-2. Current: PLL MODE ----------------- [OFFSET OBSERVATION MODE]
At this point it seems that the 10MHz OSC can't adjust frequency to sync up with the GPS values.  I'm guessing that EFC means Electronic Frequency Compensation. 
So now I need to figure out if it is the control circuit or the OSC unit that is the problem. 
Unless I can figure something else out I'll probably desolder the OSC and try and test it with a variable voltage applied to the EFC-pin and see if it loads down or shifts the 10MHz output.

Any other suggestions?

-rastor

The efc-pin should vary the frequency by about 7-8Hz. I pulled mine out and bench tested it. Mine was running cool and I couldn't pull the frequency up. It sounds like yours is running hot and can't pull the frequency down.

[deepskyridge]

I just bought one of the Trimbles advertised as Symmetricom units from waikeionline_uk and on testing it will not lock up. The only visible damage was a missing 0 Ohm link which I replaced and that did not cure the problem. The SYST:STAT? page shows the OCXO as warming up after many hours of operation and the LEDs never settle into the fast green flashing mode. Bit stumped with this one. I have asked for a refund or a replacement.

Brian.

I got one of these as well, I found some info over at xdevs:

https://xdevs.com/fix/rb_lpfrs/

The Trimble info is halfway down the page.+

Here's another discussion on time-nuts:

http://time-nuts.febo.narkive.com/O8izIFSh/trimble-gps-board

Gary

[Vgkid]

Hook a frequency counter or scope to the rf output of the ocxo. If it is not around 10 Mhz there is a issue. If it is a lot out post the frequency, im curious .

[deepskyridge]

Does anyone have a pinout for the 50 pin FPC connector on these units ?

Thanks

Gary

[dpersuhn]

Just picked up a preassembled GPSDO based on the symmetricom board and I thought all was going reasonably well.  I fired it up, it surveyed for a few hours, locked, and life was good.  Then I came home from work today and saw a new bit of LED blink action going on.  Lock is solid, but "on" is blinking.  Here's what I now have:

UCCM-P > system:status?
-------------------------------------------------------------------------------
090-03861-03   serial number W561002396   firmware ver 1.0.0.2-01     LINK mode
-------------------------------------------------------------------------------
Reference Status __________________________   Reference Outputs _______________
   Ref 8KHz 0: [LOS]
                                              TFOM     4             FFOM     2
                                              UCCM-P Status[HOLDOVER]

   GPS: [no ref]
ACQUISITION .............................................. [ GPS 1PPS Invalid ]
Tracking: 0 ____   Not Tracking: 0 ________   Time ____________________________
                                              GPS      15:27:57     14 JUN 2016
                                              GPS      Invalid: GPS rcvr failed
                                              ANT DLY  +0.000E+00
                                              Position ________________________
                                              MODE     Hold

                                              LAT      N  XX:37:29.862
                                              LON      W  XX:57:09.846
                                              HGT              +351.30 m  (MSL)




ELEV MASK  5 deg
-------------------------------------------------------------------------------

Command Complete



UCCM-P > posstatus
-----------------------------------------------------------------------------
6/14/2016 15:28:19
-----------------------------------------------------------------------------
 Position : LAT(N XX:37:29.862) LON(W XX:57:9.846) H(351.30 m MSL)
-----------------------------------------------------------------------------
 Geometry : PDOP(0.0) HDOP(0.0) VDOP(0.0)
-----------------------------------------------------------------------------
 Channel Status
   num of visible sats > 10
   num of sats tracked > 6
   ------ Receiver Channel State ------
     CH 0 >  SateID(10) TrackMode(code search) SigValue(39)
     CH 1 >  SateID(14) TrackMode(code search) SigValue(34)
     CH 2 >  SateID(22) TrackMode(code search) SigValue(35)
     CH 3 >  SateID(26) TrackMode(code search) SigValue(35)
     CH 4 >  SateID(31) TrackMode(code search) SigValue(42)
     CH 5 >  SateID(32) TrackMode(code search) SigValue(31)
     CH 6 >  SateID(0) TrackMode(code search) SigValue(0)
     CH 7 >  SateID(0) TrackMode(code search) SigValue(0)
     CH 8 >  SateID(0) TrackMode(code search) SigValue(0)
     CH 9 >  SateID(0) TrackMode(code search) SigValue(0)
     CH 10 >  SateID(0) TrackMode(code search) SigValue(0)
     CH 11 >  SateID(0) TrackMode(code search) SigValue(0)
-----------------------------------------------------------------------------
  Rcvr Status(2) :
-----------------------------------------------------------------------------
  Antenna Voltage: 5735 mV,  Antenna Current: 23 mA
-----------------------------------------------------------------------------
Command Complete



UCCM-P > gps:sat:trac?
"Data corrupt or stale"
UCCM-P >


WTF?  Worked for about 16 hours then went in the tank.  Has anyone else seen this before?  Its bee in holdover mode for the last 9 hours, but says it is tracking 6 satellites, yet all 6 show code search instead of pos available.  Reboot and all is back to swell and it happily starts surveying again.

[uncle_bob]

Hi

Watch the survey location. Get a location from another GPS (even a USB stick) and see how it's doing. If (for some reason) the survey heads for the next county, you will pretty much never get back to your location.

No idea *why* this would happen, it's just one on the list of "how come?" issues that you can check out.

Bob

[texaspyro]

I have Lady Heather working with the Z3801A (and probably all the Z38xx and HP5xxxx device, but I don't have any to test).  SCPI devices were NOT designed with computer control in mind and it was a real mother to get it working properly.   It doesn't take much deviation in the expected responses for it to all fall apart.   I have a couple of these devices (Symmetricom and Trimble) on order and hope to get the good Lady Heather working with them.

Lady Heather now also speaks NMEA,  Ublox,  Zodiac (Jupiter-T), Motorola 6/8/12 channel), SCPI, TSIP, and GPSD (with Venus and Sirf on the calendar)... and can do it under Windoze or Linux.  Remote accesses to a receiver can be via either IPv4 or IPv6.  Receiver type auto-detection is possible if it is running at 9600:8N1 (or is a Z3801A at 19200:7O1)

[dpersuhn]

Its weird.  The original survey pretty much put it on my lap according to a google earth mapping of the LAT/LON coordinates.  This time it is taking forever to settle on satellites that it likes.  10 visible, its been screwing around for an hour and hasn't managed to go above 4 that happen to have too poor of a geometry for it to continue surveying at the moment.  Sucks to only have clear sky to the west, but that still doesn't answer why it would just decide to go retarded after 16 hours.  I'd consider a better antenna if I had a measure of confidence that signal strength had anything to do with it.

[uncle_bob]

Its weird.  The original survey pretty much put it on my lap according to a google earth mapping of the LAT/LON coordinates.  This time it is taking forever to settle on satellites that it likes.  10 visible, its been screwing around for an hour and hasn't managed to go above 4 that happen to have too poor of a geometry for it to continue surveying at the moment.  Sucks to only have clear sky to the west, but that still doesn't answer why it would just decide to go retarded after 16 hours.  I'd consider a better antenna if I had a measure of confidence that signal strength had anything to do with it.

Hi

Ahhh, that question I can answer.

If you have a poor antenna location and a view mainly in one direction, you can get in trouble. The constellation of sats moves around. You can watch the "best guess" location move as they do this. If you have a multi path issue on top of a one direction view, the location can take a *major* jump. If the unit is still set for "timing compatible" limits on elevation mask, it may never really get a good set of sats for location. Timing wants a bunch of sats straight overhead. Location wants them as spread out as they possibly can get.

Bob

[dpersuhn]

I take it that is the EMANgle setting, which mine reports back as +5.  Forgive my ignorance about the difference between timing and location optimization for GPS.  I can see why having a bunch of overhead satellites would be preferred for timing, as they would incul much less signal delay and atmospheric interference.  I also acknowledge why that would be less than ideal for location.  The two questions it leaves me with are 1.Should I modify the emangle satting?  What affect would that have on timing accuracy (what I really care about)?

Correction on the horizon facing direction, its more southwest than west.

After two hours, I now have 8 satellites locked and surveying is happy again.

[texaspyro]

T1#H4430443220000B0
T1#H4430443420000B2
T1#H4430443620000B4

I cannot get the checksum calculation to work with these.  I thought it was meant to be the last 2 characters were the HEX of a sum of the ASCII values of the preceeding characters... weird I get 7A, 7C, 7E not B0, B2 and B4.

That number is the hex representation of the number of seconds since 6 Jan 1980.   Since yours is incrementing by 2, you are probably running in pulse-per-2-seconds mode.

[NivagSwerdna]

That number is the hex representation of the number of seconds since 6 Jan 1980.   Since yours is incrementing by 2, you are probably running in pulse-per-2-seconds mode.

T1#H4430443220000B0

At this time there are roughly 448B5D00 seconds since 6 Jan 1980 so that explains the first 8 characters after the literal T1#H

But what about the 20000B0?

I don't use this input anyway now, it is in GPS time, I use the GPS Receiver UTC time output.

[texaspyro]

But what about the 20000B0?

Last 7 chars are t f l r v cc:
   t=TFOM time figure of merit
   f=FFOM frequency figure of merit
   l=LEAPSECOND pending ('0'=none, '+'=forward, '-'=backwards)
   r=REQUEST for service summary bit of the status byte register
   v=VALIDITY of time related info (0=valid, 1=invalid)
   cc=checksum of all preceding ASCII chars

This comes from the Z3801A manual...

There is also a T2 format where the date/time is in ASCII.

[NivagSwerdna]

   cc=checksum of all preceding ASCII chars

The reason for my original post is I couldn't get the checksum to work.  Have you tried?
(I can't really remember now but I think the samples I gave were just random examples, they weren't meant to be particularly sequential or complete)

[texaspyro]

The reason for my original post is I couldn't get the checksum to work.  Have you tried?
(I can't really remember now but I think the samples I gave were just random examples, they weren't meant to be particularly sequential or complete)

No, my code just ignores the checksum...  I run the Z38xx's in time format T2 mode, but can handle T1 messages.  I do seem to vaguely remember something like a leading ' ' being included or excluded.

[NivagSwerdna]

I run the Z38xx's in time format T2 mode

I tried but failed to change the time format on the UCCM-P.  I think it only supports T1 (and since that is in GPS time not UTC isn't very useful to me).

[texaspyro]

I tried but failed to change the time format on the UCCM-P.  I think it only supports T1 (and since that is in GPS time not UTC isn't very useful to me).

If you can get the leapsecond offset count, you can add it to GPS time to get UTC.  I do that to convert UTC time to GPS time on receivers that do not support GPS time.   It is particularly easy to do if you can convert Julian date/time to Gregorian.  Get the seconds from the T1 message, add the leapsecond offset,  add Julian seconds of 6 Jan 1980,  convert to Gregorian.

[texaspyro]

Try sending:

:PTIM:LEAP:ACC?   (maybe without the leading ':') and see if you get the leapsecond offset back...

[NivagSwerdna]

UTC time is available from the GPS module, that's where I get it from with one wire.  No need to mess with GPS leap seconds.

[texaspyro]

If you (or somebofy else) can,  please try the :PTIM:LEAP:ACC? command with and without the leading ':' and let me know the responses.  It will answer most of the questions that I have about what I need to mod in Lady Heather to be able to control these units.  Heather is currently working with SCPI receivers like the Z3801A.  If I can use (most of) my existing SCPI code instead of having to do special UCCM commands it will make life a lot easier... the SCPI commands are a lot more capable than the UCCM commands.  It will be a few weeks before my UCCM devices come it.

Another command to try is (with / without leading ':'
   :DIAG:GPS:UTC 0
   :DIAG:GPS:UTC 1

This might switch the receiver between GPS and UTC mode.

[NivagSwerdna]

the SCPI commands are a lot more capable than the UCCM commands.

UCCM-P commands are SCPI commands.  You will find, when you receive your device, that UCCM-P are a poor subset of what you are used to.

[texaspyro]

UCCM commands are in the SCPI format, but they are not the same as the standard SCPI GPSDO commands.  It appears that these UCCM devices do respond to many of the standard SCPI GPSDO commands... I'm trying to find out just how well they do that (without waiting weeks for mine to come in), hence my request.