Author Topic: A look at my Symmetricom GPSDO / 10MHz reference (OCXO + Furuno receiver)  (Read 450037 times)

0 Members and 1 Guest are viewing this topic.

Offline Bryan

  • Frequent Contributor
  • **
  • Posts: 618
  • Country: ca
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.

"Undefined Header" is the response for :PTIM:LEAP:ACC? with and without the header, same with the DIAG commands, I tried DIAGNOSTIC, no luck. Here is the list of "supported commands", although I have found with others that there is some undocumented commands that will work. Perhaps it's getting the syntax right.

Code: [Select]
?
*IDN?
ALARm:HARDware?
ALARm:OPERation?
DIAGnostic:OUTPut ON|OFF
OUTPut:ACTive:ENABle
OUTPut:ACTive:DISable
OUTPut:ACTive:HOLDover:DURation:THReshold <seconds>
OUTPut:ACTive:HOLDover:DURation:THReshold?
OUTPut:INACTive
OUTPut:INACTive?
OUTPut:STATe?
SYNChronization:HOLDover:DURation:STATus:THReshold <seconds>
SYSTem:PRESet
SYNChronization:TFOMerit?
LED:GPSLock?
SYNChronization:FFOMerit?
GPS:POSition N or S,<deg>,<min>,<sec>,E or W,<deg>,<min>,<sec>,<height>
GPS:POSition?
GPS:POSition:HOLD:LAST?
GPS:REFerence:ADELay <numeric value>
GPS:REFerence:ADELay?
GPS:SATellite:TRACking:COUNt?
GPS:SATellite:TRACking?
DIAGnostic:ROSCillator:EFControl:RELative?
SYNChronization:TINTerval?
DIAGnostic:LOG:READ:ALL?
DIAGnostic:LOG:CLEar
SYSTem:PON
OUTPut:MODE?
SYSTem:STATus?
SYSTem:COMMunication:SERial1:BAUD 9600|19200|38400|57600
SYSTem:COMMunication:SERial1:BAUD?
SYSTem:COMMunication:SERial1:PRESet
SYSTem:COMMunication:SERial2:BAUD 9600|19200|38400|57600
SYSTem:COMMunication:SERial2:BAUD?
SYSTem:COMMunication:SERial2:PRESet
OUTPut:STANby:THReshold <seconds>
changeSN
SYNChronization:REFerence:ENABLE LINK|GPS
SYNChronization:REFerence:DISABLE LINK|GPS
SYNChronization:REFerence:ENABLE?
STATus
POSSTATus
TOD EN|DI
TIME:STRing?
REFerence:TYPE GPS|LINK
REFerence:TYPE?
PULLINRANGE 0|1|2|...|254|255
PULLINRNAGE?
DIAGnostic:LOOP?
DIAGnostic:ROSCillator:EFControl:DATA GPS|<value>
DIAGnostic:ROSCillator:EFControl:DATA?
OUTPut:TP:SELection PP1S|PP2S
OUTPut:TP:SELection?
GPSystem:SATellite:TRACking:EMANgle <degrees>
GPSystem:SATellite:TRACking:EMANgle?
DIAGnostic:TCODe:STATus:AMASk
DIAGnostic:TCODe:STATus:OMASk
DIAGnostic:TCODe:ERRor:AMASk
DIAGnostic:TCODe:ERRor:OMASk
DIAGnostic:HOLDover:DELay
DIAGnostic:HOLDover:DELay?
GPS:SATellite:TRACking:IGNore <PRN>, ...,<PRN>
GPS:SATellite:TRACking:IGNore?
GPS:SATellite:TRACking:INCLude <PRN>, ...,<PRN>
GPS:SATellite:TRACking:INCLude?
GPS:SATellite:TRACking:<select>:ALL
-=Bryan=-
 

Offline texaspyro

  • Super Contributor
  • ***
  • Posts: 1407
Thanks for trying those...  I've got the list of "official" commands... it's the undocumented ones that are where the action is.
 

Offline Bryan

  • Frequent Contributor
  • **
  • Posts: 618
  • Country: ca
PTIM:LEAP? returns 0 if that helps.
-=Bryan=-
 

Offline texaspyro

  • Super Contributor
  • ***
  • Posts: 1407
PTIM:LEAP? returns 0 if that helps.

Hmmm... that's a new one.  I suspect 0 means no leapsecond pending.  (-1) says backwards leap pending (will probably never happen unless the world gets hit by an asteroid), 1 says forward leap pending.

How about (from the HP53xxx manual):
  PTIM:LEAP:DATE?
  PTIM:LEAP:DUR?
  PTIM:LEAP:STAT?

Also on "PTIM:LEAP?" does it matter if you do ":PTIM:LEAP?"
 

Offline Bryan

  • Frequent Contributor
  • **
  • Posts: 618
  • Country: ca
Quote

Hmmm... that's a new one.  I suspect 0 means no leapsecond pending.  (-1) says backwards leap pending (will probably never happen unless the world gets hit by an asteroid), 1 says forward leap pending.

How about (from the HP53xxx manual):
  PTIM:LEAP:DATE?
  PTIM:LEAP:DUR?
  PTIM:LEAP:STAT?

Also on "PTIM:LEAP?" does it matter if you do ":PTIM:LEAP?"



 PTIM:LEAP:DATE?
"Undefined Header"
PTIM:LEAP:DUR?
"Undefined Header"
 PTIM:LEAP:STAT?
"Undefined Header"

Nope, none worked, even tried removing the leading colon:, as well as various combinations of removing LEAP and PTIM

Quote
Also on "PTIM:LEAP?" does it matter if you do ":PTIM:LEAP?"

Works with a leading colon : , returns "0"
-=Bryan=-
 

Offline texaspyro

  • Super Contributor
  • ***
  • Posts: 1407
Ugh... I detect suckage in the force...

Many thanks for trying those.
 

Offline Bryan

  • Frequent Contributor
  • **
  • Posts: 618
  • Country: ca
Yes, too bad. Hope you still are able to get these receivers to communicate with Lady Heather, would be most appreciated. I just downloaded the latest version (Beta) and could not get it to communicate with the Com port. Changed the baud rate to 57600 in Windows, but still no luck.

Anything else you need tested let me know, don't mind testing commands.
-=Bryan=-
 

Offline texaspyro

  • Super Contributor
  • ***
  • Posts: 1407
The Lady Heather beta on the ke5fx.com site is ver 4.00,  my development version is up to 4.08 ... it changes hourly.   I don't think 4.00 had support for anything but TSIP receivers,  but it could compile for Linux.    Once the development version stabilizes, I'll shoot John a new copy.

Something tells me the UCCM devices are going to be a pain in the latus rectum to do... 
 

Offline Bryan

  • Frequent Contributor
  • **
  • Posts: 618
  • Country: ca
Aah, knew it was redone for Linux, but thought there was some other improvements as well. Yes, think it will be a uphill battle with the UCCM unless somewhere out there a complete list of undocumented commands for the device is found. Think you will may need the NMEA data from the GPS receiver to get what you need.
-=Bryan=-
 

Offline texaspyro

  • Super Contributor
  • ***
  • Posts: 1407
Well,  I'll just try all the SCPI commands that Lady Heather sends and see which ones work,  which ones need changing,  and which ones have no work-around.

UCCM has some annoying protocol differences (like that "Command complete" thing,  differences in the SYST:STATUS response,  differences in the error responses, etc.

Lady Heather does support NMEA,  but I don't do any of the manufacturer proprietary commands.  There is a way to send those manually... but I don't parse any of the proprietary responses.  Besides, tying into the receiver TX data is not something most people will do.

 

Offline uncle_bob

  • Supporter
  • ****
  • Posts: 2441
  • Country: us
Well,  I'll just try all the SCPI commands that Lady Heather sends and see which ones work,  which ones need changing,  and which ones have no work-around.

UCCM has some annoying protocol differences (like that "Command complete" thing,  differences in the SYST:STATUS response,  differences in the error responses, etc.

Lady Heather does support NMEA,  but I don't do any of the manufacturer proprietary commands.  There is a way to send those manually... but I don't parse any of the proprietary responses.  Besides, tying into the receiver TX data is not something most people will do.

Hi

With some luck you might find one that puts the module directly into Mayan Calendar mode ....

Bob
 

Offline Bryan

  • Frequent Contributor
  • **
  • Posts: 618
  • Country: ca
There is a way to send those manually... but I don't parse any of the proprietary responses.  Besides, tying into the receiver TX data is not something most people will do.

Probably not, as if it is integrated into a serial device their would be the necessity of a RS232/TTL converter. To add to the complexity the NMEA commands are not returned with a checksum either.
-=Bryan=-
 

Offline texaspyro

  • Super Contributor
  • ***
  • Posts: 1407
Lady Heather don't need no stinkin' checksums.  Checksums are optional in NMEAville and a NMEA parser that can't work without them is defective... as is a NMEA receiver that requires them.
 

Online PA0PBZ

  • Super Contributor
  • ***
  • Posts: 5195
  • Country: nl
I just felt lucky yesterday and managed to fix 3 out of the 6 in the sh*t pile, and found the probable cause of the alarm 0200 (0.5 Hz) error.
When L20 gets ripped off including the upper 2 pads (a common failure I think, I have 3 boards like that) it breaks the traces to the unpopulated R105 position. But... there is also a trace going from the upper left pad to R97 and that gets also destroyed in the action. So when you just put a new coil on the R105 pads you will miss the connection to R97, which I'm my case caused the alarm 0200.

Like they say, a picture is worth a thousand words: (this is one of the 2 boards nominated as parts donor)



I think I'm done fixing now, I'm out of several components (Like Y1) and I have 4 working ones so I'm good for a while. If anyone is looking for the odd component and I still have spares I can send it to you, just let me know where you are looking for.
Keyboard error: Press F1 to continue.
 
The following users thanked this post: Bryan, NivagSwerdna

Offline NivagSwerdna

  • Super Contributor
  • ***
  • Posts: 2507
  • Country: gb
... found the probable cause of the alarm 0200 (0.5 Hz) error.
Oh wow!  I had "Alarms:  [0200] 0.5Hz Internal Reference" on the board I sent back (and never got refunded for from that crook flyxy2015).

PA0PBZ That's a brilliant bit of work. Respect!
 

Offline Bryan

  • Frequent Contributor
  • **
  • Posts: 618
  • Country: ca
When L20 gets ripped off including the upper 2 pads (a common failure I think, I have 3 boards like that) it breaks the traces to the unpopulated R105 position. But... there is also a trace going from the upper left pad to R97 and that gets also destroyed in the action. So when you just put a new coil on the R105 pads you will miss the connection to R97, which I'm my case caused the alarm 0200.

Great catch, sure to help out others.
-=Bryan=-
 

Offline Macbeth

  • Super Contributor
  • ***
  • Posts: 2571
  • Country: gb
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.

The only way I have figured to get UTC time is with the TOD EN command and decoding the ascii-hex output that repeats until a TOD DI command is sent. I have my serial interrupt handle these packets and filter them out, easy enough because each packet starts with 'c5' byte and ends with 'ca' followed by space, cr, lf. Regular expression "c5.{127}ca\s\r\n" gets it for me.

I've no idea what most of those bytes are, but seconds since 6 Jan 1980 are bytes 28-31. I believe the offset is byte 33 but I can't be sure until they change the leap second again ;)

Observing the logs I do see byte 33 switch from 00 to 11 (17 seconds) exactly when the SYST:STAT? reports 'Synchronized to UTC' instead of 'Synchronized to GPS'

Code: [Select]
ACQUISITION ................................................ [ GPS 1PPS Valid ]
Tracking: 3 ____   Not Tracking: 4 ________   Time ____________________________
PRN  El  Az  C/N   PRN  El  Az                GPS      13:20:41     22 JUN 2016
 21  33 164   34     5   9  69                GPS      Synchronized to GPS
 25  32 108   37     9   5 345                ANT DLY  +0.000E+00
 29  59  66   41    16  16 287                Position ________________________
                    31  59 221                MODE     Hold

...                                                                              ** ** ** **    **
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 44 95 53 2a 00 00 60 04 85 40 00 00 00 00 ce 94 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 44 95 53 2c 00 00 60 04 85 40 00 00 00 00 f5 f3 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 44 95 53 2e 00 00 60 04 85 40 00 00 00 00 33 31 ca
...

ACQUISITION ................................................ [ GPS 1PPS Valid ]
Tracking: 3 ____   Not Tracking: 4 ________   Time ____________________________
PRN  El  Az  C/N   PRN  El  Az                GPS      13:22:09     22 JUN 2016
 21  33 163   30     5  10  68                GPS      Synchronized to UTC
 25  31 109   38     9   5 345                ANT DLY  +0.000E+00
 29  58  65   43    16  16 287                Position ________________________
                    31  58 220                MODE     Hold

...                                                                              ** ** ** **    **
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 44 95 53 82 00 11 60 04 85 40 00 00 00 00 db 6b 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 44 95 53 84 00 11 60 04 85 40 00 00 00 00 d0 0c 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 44 95 53 86 00 11 60 04 85 40 00 00 00 00 26 ce ca

The TOD message can interrupt regular terminal output like in the middle of a SYST:STAT? response for example, but nothing appears to mangle the TOD stream. The TOD output occurs every 2 seconds whether in 1PPS or PP2S modes. I have also checked the timing between the actual 1PPS output and the data burst on my scope. I've found the end of the TOD packet (at 57600 baud) occurs between 90ms - 100ms of the actual pulse.

Another byte I have observed is 37. It indicates 40 if GPS PPS valid, 50 if invalid, and 60 when the GPS antenna is unplugged.

Of course the TOD output keeps time and continues in these conditions, unlike NMEA.

So I think I will build a Raspberry Pi NTP server using the TOD output  :-+
« Last Edit: June 22, 2016, 04:05:51 pm by Macbeth »
 

Offline texaspyro

  • Super Contributor
  • ***
  • Posts: 1407
One of my units (a Trimble) came in today.  It was in excellent condition,  no broken stuff, no goo.   I have Lady Heather sort of talking to it.

I thought that the fact that the units echo the incoming commands was going to cause lots of problems,  but it actually solves a MAJOR issue with SCPI receivers... telling what message that a response is associated with.   It makes the code quite a bit simpler and more robust.

The Trimble receivers do NOT send the TOD string in the middle of another messages' response.  That is a very good thing.  The Symmetricom units are going to need some major kludgeoscity to handle that little issue.
 

Offline TiN

  • Super Contributor
  • ***
  • Posts: 4543
  • Country: ua
    • xDevs.com
Just 5c, "Undefined Header" for PTIM:LEAP? on my OEM Trimble too.
YouTube | Metrology IRC Chat room | Let's share T&M documentation? Upload! No upload limits for firmwares, photos, files.
 

Offline Macbeth

  • Super Contributor
  • ***
  • Posts: 2571
  • Country: gb
The Trimble receivers do NOT send the TOD string in the middle of another messages' response.  That is a very good thing.  The Symmetricom units are going to need some major kludgeoscity to handle that little issue.
I guess you could implement polling. When you need it send a TOD EN, wait for the packet with just over a 2 second timeout, then immediately send a TOD DI. Process ordinary SCPI commands as usual

I implemented a low level kludge using the serial data arrival interrupt because I've been coding an interactive terminal in C# .NET and so stripping these packets out and processing them "behind the scenes". If the GPS module is entirely under program control then polling would be simpler.

Another minor thing, I believe the Trimble sends its ascii-hex in uppercase and the Symmetricom lower. Symmetricom has an ending space character at the end of the line before the CR LF, not sure if that's the case with Trimble or the order of LF CR.
 

Offline deepskyridge

  • Regular Contributor
  • *
  • Posts: 87
  • Country: us
Yesterday I received the GPSDO I bought from waikeionline_uk. Attached is a picture of the board.

The 2 sma connectors are missing and the mounting pads for them are also missing, the coax from the GPS can has been cut.

Also his ad shows a Trimble board.

I have requested replacement or refund, have any of you dealt with this seller before ?

Gary

« Last Edit: June 23, 2016, 03:42:54 pm by deepskyridge »
 

Offline Bryan

  • Frequent Contributor
  • **
  • Posts: 618
  • Country: ca
Looks like he has closed the listing and probably only had a few junk units to get rid off, wouldn't count on getting a replacement.
-=Bryan=-
 

Offline texaspyro

  • Super Contributor
  • ***
  • Posts: 1407
Another minor thing, I believe the Trimble sends its ascii-hex in uppercase and the Symmetricom lower. Symmetricom has an ending space character at the end of the line before the CR LF, not sure if that's the case with Trimble or the order of LF CR.

The Trimble sends a NULL character with every line of the SYST:STATUS? display.

I am using the TOD string to drive the display and polling for additional messages... without it, Lady Heather won't work...

Attached is an overnight run of the first hack of the code... It's plotting the DAC voltage, TINT value, and sat count.  Lady Heather normally expects consecutive time stamps and flags missing and duplicated ones with those red ticks at the top of the plot area.  The satellites in the analog watch display should have trails behind them,  but I need to add the code that does that (and a whole lot more).

Now I need to get it all tweaked up for what the units can do...
« Last Edit: June 23, 2016, 05:00:38 pm by texaspyro »
 

Online PA0PBZ

  • Super Contributor
  • ***
  • Posts: 5195
  • Country: nl
I have requested replacement or refund, have any of you dealt with this seller before ?

Read the thread :)
After dealing with him for some time (either _us or _uk) I'm convinced that he just buys and have them shipped by another party. He has no idea what was shipped to you so his first question will be to send him pictures of what you received. Then he promises to send a replacement but only after you send back what you got. Again he has no idea how the replacement will look and mine even came from a different address again. I told him it looks like he gets scr*wed by his business partner:

Quote
I'm not sure who told you that the damage is occurring during transport but this is definitely not true! All boards I received where shipped damaged and there is a very easy way to tell: none of the missing components where in the sealed envelopes, so they where never on the shipped boards.
The damage must have been done while these boards were taken out of the original equipment with tools not good for the job and by people not caring and without knowledge. I have seen examples where the connectors where ripped off the boards because people did not understand how to disconnect them.

I still think that you worked with business partners to ship these boards and they are just not honest to you. Be careful with these people...

His response:

Quote
Thanks for your understanding,
We will make improvement on our service asap,

Many thanks

Looks like he didn't work that out yet  ;)
Keyboard error: Press F1 to continue.
 

Offline texaspyro

  • Super Contributor
  • ***
  • Posts: 1407
I got mine from him (_uk).  It arrived in about a week (shipped from China) and was in perfect condition.  No broken parts or slime.  Paid about $45.  Well worth it... maybe I just got lucky and should play the lottery this week.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf