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

Bryan · « **Reply #625 on:** June 17, 2016, 12:24:26 am »

Quote from: texaspyro on June 16, 2016, 03:44:14 pm

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

texaspyro · « **Reply #626 on:** June 17, 2016, 02:48:56 am »

Thanks for trying those... I've got the list of "official" commands... it's the undocumented ones that are where the action is.

Bryan · « **Reply #627 on:** June 17, 2016, 05:57:26 am »

PTIM:LEAP? returns 0 if that helps.

texaspyro · « **Reply #628 on:** June 17, 2016, 07:11:52 am »

Quote from: Bryan on June 17, 2016, 05:57:26 am

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?"

Bryan · « **Reply #629 on:** June 18, 2016, 06:13:42 am »

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"

texaspyro · « **Reply #630 on:** June 18, 2016, 06:23:11 am »

Ugh... I detect suckage in the force...

Many thanks for trying those.

Bryan · « **Reply #631 on:** June 18, 2016, 07:42:17 am »

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.

texaspyro · « **Reply #632 on:** June 18, 2016, 08:39:43 am »

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...

Bryan · « **Reply #633 on:** June 18, 2016, 08:57:29 am »

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.

texaspyro · « **Reply #634 on:** June 18, 2016, 07:02:54 pm »

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.

uncle_bob · « **Reply #635 on:** June 18, 2016, 07:17:52 pm »

Quote from: texaspyro on June 18, 2016, 07:02:54 pm

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

Bryan · « **Reply #636 on:** June 18, 2016, 08:13:56 pm »

Quote from: texaspyro on June 18, 2016, 07:02:54 pm

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.

texaspyro · « **Reply #637 on:** June 18, 2016, 08:43:29 pm »

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.

PA0PBZ · « **Reply #638 on:** June 21, 2016, 06:50:48 pm »

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.

NivagSwerdna · « **Reply #639 on:** June 21, 2016, 09:32:02 pm »

Quote from: PA0PBZ on June 21, 2016, 06:50:48 pm

... 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!

Bryan · « **Reply #640 on:** June 22, 2016, 01:02:01 am »

Quote from: PA0PBZ on June 21, 2016, 06:50:48 pm

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.

Macbeth · « **Reply #641 on:** June 22, 2016, 03:37:40 pm »

Quote from: texaspyro on June 16, 2016, 01:44:43 pm

Quote from: NivagSwerdna on June 16, 2016, 07:26:37 am
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

texaspyro · « **Reply #642 on:** June 23, 2016, 04:32:34 am »

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.

TiN · « **Reply #643 on:** June 23, 2016, 04:38:24 am »

Just 5c, "Undefined Header" for PTIM:LEAP? on my OEM Trimble too.

Macbeth · « **Reply #644 on:** June 23, 2016, 02:18:09 pm »

Quote from: texaspyro on June 23, 2016, 04:32:34 am

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.

deepskyridge · « **Reply #645 on:** June 23, 2016, 03:40:29 pm »

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

Bryan · « **Reply #646 on:** June 23, 2016, 03:51:56 pm »

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.

texaspyro · « **Reply #647 on:** June 23, 2016, 04:55:29 pm »

Quote from: Macbeth on June 23, 2016, 02:18:09 pm

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...

PA0PBZ · « **Reply #648 on:** June 23, 2016, 06:51:43 pm »

Quote from: deepskyridge on June 23, 2016, 03:40:29 pm

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

texaspyro · « **Reply #649 on:** June 23, 2016, 07:02:35 pm »

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.


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

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

Share me