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.
?
*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
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?"
Also on "PTIM:LEAP?" does it matter if you do ":PTIM:LEAP?"
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.
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.
... 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.
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.
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 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.
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.
I have requested replacement or refund, have any of you dealt with this seller before ?
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...
Thanks for your understanding,
We will make improvement on our service asap,
Many thanks