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

[Bryan]

Yes, just don't have the view of the sky for a GPSDO (I do have a Rubidium) , just note that the plot I uploaded was from a older Nortel unit. My Symmetricom died on me. I do have a Jupiter-T that gives a much better plot. Out of curiosity does the Elevation strength plot mean that in this case that the strength is much better at 60 degress and perhaps upping the elevation mask may reduce some multi math interference.

[texaspyro]

Out of curiosity does the Elevation strength plot mean that in this case that the strength is much better at 60 degress and perhaps upping the elevation mask may reduce some multi math interference.

I'd try setting the elevation mask low (0-10 degrees) and running it for a few hours so see where the signals start to really fall off.   In that plot it looks like around 40 degrees.

[bingo600]

Sigh, my view of the sky. Facing North from a ground floor condo, with trees around.

That's why I suggested that a GPS-disciplined Rb oscillator might be the best solution for you.  There are a few Rb oscillators that have GPS disciplining built-in.  Datum/Symmetricom X72 and SA22c, Stanford Research PRS10 are three that come to mind.  But be careful.  Some firmware versions don't have that feature.  Be sure to get confirmation from the seller that his units have the feature.  Unfortunately, these units tend to be at the higher end of the price scale.

Afaik the X72 needs fw > 5.x for 1PPS support , and i have 4.x on mine 

/Bingo

[edpalmer42]

Sigh, my view of the sky. Facing North from a ground floor condo, with trees around.

That's why I suggested that a GPS-disciplined Rb oscillator might be the best solution for you.  There are a few Rb oscillators that have GPS disciplining built-in.  Datum/Symmetricom X72 and SA22c, Stanford Research PRS10 are three that come to mind.  But be careful.  Some firmware versions don't have that feature.  Be sure to get confirmation from the seller that his units have the feature.  Unfortunately, these units tend to be at the higher end of the price scale.

Afaik the X72 needs fw > 5.x for 1PPS support , and i have 4.x on mine 

/Bingo

I asked Symmetricom if I could get the file to flash the new firmware.  They said all I had to do was RMA the unit and include a check for $1100.

     Aaarrrgghh!......My heart!!.......   

[bingo600]

I asked Symmetricom if I could get the file to flash the new firmware.  They said all I had to do was RMA the unit and include a check for $1100.

     Aaarrrgghh!......My heart!!.......   

I know ... And got a PRS10 instead , for 25% of that silly price.
I was even lucky enough to inherit PHK's PRS10 adapterboard, from his dead unit. 

BTW: I think i saw someone on *Bay offer to do the upgrade for "small money" , but he wrote it might brick in the process.

Bingo

[texaspyro]

I asked Symmetricom if I could get the file to flash the new firmware.  They said all I had to do was RMA the unit and include a check for $1100.

A few weeks ago there was a guy on Ebay offering to upgrade them for around $40...   I don't see his listing anymore.

[edpalmer42]

I asked Symmetricom if I could get the file to flash the new firmware.  They said all I had to do was RMA the unit and include a check for $1100.

A few weeks ago there was a guy on Ebay offering to upgrade them for around $40...   I don't see his listing anymore.

I think I saw that a few months ago, but there was something about it that I didn't like or it wouldn't work for me.  I can't remember for sure.  Maybe existing firmware had to be at least version X.X.  Maybe just the idea of international shipping (twice!) plus exchange.  Suddenly the price wasn't so attractive for something I didn't really need at the moment.  But it could be very interesting for Bryan if it pops up again on ebay.

[texaspyro]

Maybe existing firmware had to be at least version X.X.

I think that he mentioned that he had upgraded certain firmwares but could probably do others.

[Bryan]

Here is the relative strength vs elevation after 24 hours. Not sure what the yellow marker at ~42 degrees means (It seems to move)?.

[texaspyro]

Here is the relative strength vs elevation after 24 hours. Not sure what the yellow marker at ~42 degrees means (It seems to move)?.

The yellow marker is where the signal strength falls below 87.5% (75% on a Resolution-T) of the average signal strength.  Looks like an elevation mask setting of a little over 30 degrees would be appropriate for your receiver. 

When doing the "autotune" function Heather choses an elevation mask setting half way between the yellow and blue (current elevation mask) values.  It used to set it to where the yellow marker is,  but that seemed to be a little too conservative.

[Bryan]

Excellent, thanks for the information. The plots were for my Nortel, going to try the Jupiter-T receiver and see how it compares. it can see more satellites so hopefully will perform better with the view I have. I did try the autotune with LH4 and it returned a very high elevation mask. Tried the autotune on LH5 and it set the elevation mask at 21 degrees, but I assume it will change depending on the view at the time of the autotune. But yes, think 30+ degrees is the way to go.

[texaspyro]

These "UCCM" receivers only output a time code message every two seconds.  Currently Heather fakes the missing odd numbered seconds internally so that things like the audible clocks and alarms work (semi-)properly, but the clock displays only appeared to update every other second.  I was hacking around in the code and figured out a way to generate the faked seconds "on-time".  So now the clocks tick normally every second.

I also added the ability of Heather to talk to up to 10 external com devices (serial or TCP/IP).  One of the pre-defined com "ports" just echoes whatever comes from the receiver.  Another port can send a NMEA formatted stream of the receiver data.  These "echo" ports let you control, monitor, and configure the receiver and also send the receiver data (in native format or NMEA format) to another device or program like NTP, GPSD, etc. 

If one really wanted to, you could add code to echo the receiver data in any format that you wanted (like convert Trimble receiver TSIP data to Ublox format)... an exercise left to the reader...

[edpalmer42]

I also added the ability of Heather to talk to up to 10 external com devices (serial or TCP/IP).  One of the pre-defined com "ports" just echoes whatever comes from the receiver.  Another port can send a NMEA formatted stream of the receiver data.  These "echo" ports let you control, monitor, and configure the receiver and also send the receiver data (in native format or NMEA format) to another device or program like NTP, GPSD, etc. 

Would this allow you to run LH on the Tbolt's port and then run NTPD with refclock29 (Tbolt) against LH's virtual port?  Does that include the 1 PPS?  Any idea what kind of jitter/delay you'd see?  Delay could probably be adjusted for,  but jitter would be more of a problem.

[texaspyro]

Would this allow you to run LH on the Tbolt's port and then run NTPD with refclock29 (Tbolt) against LH's virtual port?  Does that include the 1 PPS?  Any idea what kind of jitter/delay you'd see?  Delay could probably be adjusted for,  but jitter would be more of a problem.

That's the idea...

Heather knows nothing about hardware 1PPS signals... there is no connection to the 1PPS signal.

Delay would be dependent upon your system and buffering delays.  If you are using a 1PPS signal, it should not matter to NTPD as longs as the message gets out before the next 1PPS pulse... which it should.  If you are not using 1PPS signal, you would need to compensate for the delay.  Jitter should be minimal in either case.

As the receiver data comes in Heather crams it into a buffer.  When the last byte of a message comes in, Heather processes the message and, for the echoed data, sends it out the echo port.

One could cause Heather to echo the unbuffered data as it comes in, but that is rather inefficient... particularly for TCP/IP connections... you would be sending lots of 1 byte packets.  You could reduce any delay by echoing the data at a higher baud rate.

I'm going to do some comparisons with the direct receiver data and echoed data tomorrow.

[edpalmer42]

Would this allow you to run LH on the Tbolt's port and then run NTPD with refclock29 (Tbolt) against LH's virtual port?  Does that include the 1 PPS?  Any idea what kind of jitter/delay you'd see?  Delay could probably be adjusted for,  but jitter would be more of a problem.

That's the idea...

Heather knows nothing about hardware 1PPS signals... there is no connection to the 1PPS signal.

That's what I suspected, but I thought I'd ask.  The best NTPD performance is obtained by having the 1 PPS on one of the RS-232 control leads.  The Tbolt doesn't do this unless you do the hardware mod yourself, but other GPSDOs do.  If LH doesn't pass that on to its virtual port, NTPD will only have the ASCII to work from and won't provide its best performance.

God, don't tell me I'm becoming an NTP-nut too! 

Delay would be dependent upon your system and buffering delays.  If you are using a 1PPS signal, it should not matter to NTPD as longs as the message gets out before the next 1PPS pulse... which it should.  If you are not using 1PPS signal, you would need to compensate for the delay.  Jitter should be minimal in either case.

I'm confused.  If LH is connected to the hardware port, how could you use a 1 PPS signal for NTPD?

As the receiver data comes in Heather crams it into a buffer.  When the last byte of a message comes in, Heather processes the message and, for the echoed data, sends it out the echo port.

One could cause Heather to echo the unbuffered data as it comes in, but that is rather inefficient... particularly for TCP/IP connections... you would be sending lots of 1 byte packets.  You could reduce any delay by echoing the data at a higher baud rate.

You'd only use NTPD on the echo port, i.e. it would run on the same machine as LH.  Network delays, both fixed and variable would severely compromise the performance otherwise.  Other apps might find the timestamp via TCP/IP useful.

I'm going to do some comparisons with the direct receiver data and echoed data tomorrow.

Looking forward to it! 

[texaspyro]

The best NTPD performance is obtained by having the 1 PPS on one of the RS-232 control leads.  The Tbolt doesn't do this unless you do the hardware mod yourself, but other GPSDOs do.  If LH doesn't pass that on to its virtual port, NTPD will only have the ASCII to work from and won't provide its best performance.

You would just wire the 1PPS signal from the receiver to whatever pin your NTP expects.  For 1PPS in via the serial port (the standard pin used by NTP is the carrier detect line) you would wire the 1PPS signal to the the virtual com port connector CD pin.  Heather passes the data stream from the receiver through to the virtual com port which then feeds NTP.

For the serial data the flow is RCVR -> HEATHER RCVR PORT -> HEATHER VIRTUAL PORT -> NTP
For the 1PPS signal it is RCVR -> VIRTUAL PORT CONNECTOR CD pin-> NTP

If you are using a receiver that NTP understands, you could do much the same thing with just a serial "Y" cable and send the receiver serial output signal to both the Heather serial port and the NTP serial port.   But if you are using something like the UCCM receivers that NTP doesn't know about and that only send the time out every other second, Heather can generate a NMEA stream to feed NTP.

My intended configuration is to have a Raspberry PI with the 800x480 touchscreen controlling and monitoring the receiver and spitting out a NMEA stream and 1PPS for feeding NTP.

[edpalmer42]

Okay, thanks.

I think we've hijacked this thread enough.  I'll reserve any more questions until after the software is issued.

"We now return you to your regular programming".

[texaspyro]

Looking forward to it! 

I did some testing.  Receiver was a Thunderbolt at 9600:8:N:1.  I measured the message timing offset (the difference between the time in the time code message and the time the last byte of the message arrived) and the standard deviation of the message arrival times.

Direct rcvr connection to Linux laptop:  msg_ofs:60 msecs     sdev:0.55 msecs
Direct rcvr connection to Windows XP:  msg_ofs:52 msecs     sdev:42.1 msecs

Echo TSIP from XP box to Linux box:  msg_ofs: 99 msecs   sdev:44.6 msecs
Echo NMEA from XP box to Linux box:  msg_ofs: 160 msecs    sdev:25.36 msecs

Echo TSIP from XP box to Linux box running GPSD:  msg_ofs: 373 msecs   sdev:28.5 msecs
Echo NMEA from XP box to Linux box running GPSD:  msg_ofs: 261 msecs    sdev:8.5 msecs

[Bryan]

Here is the relative strength vs elevation after 24 hours. Not sure what the yellow marker at ~42 degrees means (It seems to move)?.

The plot of my Jupiter-T receiver shows quite an improvement, better receiver I suppose, can see 12 birds vs 8.

[edpalmer42]

Do you have equipment that can measure the jitter on the Jupiter-T?  Either the period of the 1 PPS or the time delay between the 1 PPS and your Rb.  Since the Jupiter-T has to pick up signals that come through the building, there's no telling how good the results will be.  The results could actually be worse than before if the Jupiter-T is accepting signals that are basically garbage.

[Bryan]

The Jupiter-T is using the same antenna as the Nortel, just swapped the Nortel out to test (wasn't tested indoors). I have a DSO and suppose can use persistence mode and see how much the 1pps output varies. That good enough?

[edpalmer42]

The Jupiter-T is using the same antenna as the Nortel, just swapped the Nortel out to test (wasn't tested indoors). I have a DSO and suppose can use persistence mode and see how much the 1pps output varies. That good enough?

I realize that both units are using the same antenna.  The problem is that by picking up weaker signals, the Jupiter-T might be picking up signals that are so crappy that they should be rejected.  By comparison, the relatively deaf Nortel unit doesn't see them at all.

Give the DSO a try.  Does the Jupiter-T include an OCXO or is it just a GPS receiver?  My experience is that a GPSDO has jitter of < 5 ns while a plain GPS receiver has jitter of 20 - 100 ns under good conditions.  A data sheet I found for the TU60 Jupiter-T GPS Receiver says that timing accuracy is typically 10 - 20 ns and then states that in position hold mode it's +- 40 ns.  That might be a worst case measurement.  If yours measures significantly worse, it's probably because of your poor sky visibility.  See how the Nortel compares and use whichever one gives the best results, regardless of what the graphs show.

[Bryan]

Yes, good point, that could very well be the case. The Jupiter-T is just a receiver with a 1pps and 10kHz output. Any suggestions as to properly test the jitter on the 1pps. Looking at a few tutorials and it is easy if you have a 100K scope<g> I can use the persistence mode on my DS1052e and monitor the rising edge of the 1pps pulse stretched across the display. 

[edpalmer42]

Yes, good point, that could very well be the case. The Jupiter-T is just a receiver with a 1pps and 10kHz output. Any suggestions as to properly test the jitter on the 1pps. Looking at a few tutorials and it is easy if you have a 100K scope<g> I can use the persistence mode on my DS1052e and monitor the rising edge of the 1pps pulse stretched across the display.

You can't just look at the pulse, you have to look at the period of the 1 PPS.  So you'd have to trigger on the 1 PPS, but tell the DSO to delay the data acquisition for about 1 sec. so that you can see the rising edge of the next pulse.  The jitter on this rising edge will show you the quality of the output.  Maybe your DSO could measure the period of the 1 PPS and report that. 

If your DSO can't do this, you could trigger off of the 1 PPS on one channel and look at your Rb on the other channel.  But you'd have to tweak the Rb to be exactly on frequency, otherwise, the Rb signal will just walk across the screen and smear the results.

The best way to make this measurement is with a time interval counter that measures the time from the rising edge of the 1 PPS from the GPSDO to the rising edge of a signal (ideally 1 PPS) derived from the Rb.  Make many measurements, collect the data electronically, then process it with a program like Timelab.  I don't know if your DSO can be coaxed into doing something like that.  In the end, the results should look something like the attached.  The diagonal part on the left is due to limitations of the measuring equipment.  The flat part shows the performance of the OCXO.  Looks like the Trimble UCCM is okay, but nowhere near as good as the Z3801A.  Both graphs then turn and follow the "GPS line" which is the approximate performance limit of the GPS system.  Finally, at about 10K sec., the Rb starts to peek out from underneath the GPS line.  The black line would have turned and followed a similar path to the blue line if the data run had lasted longer.

[VK2AN]

Hi Everyone,

Not sure if this is the right place to post this question, but I have also recently bought a Symetricom board off Ebay. I seem to have been lucky as no broken caps, no missing sockets and the unit appears to work fine, but it has a couple of peculiarities.

I have mounted it in a case and brought the alarm and lock LEDs out to the front panel. I also have it connected to an ex telco GPS antenna (another Ebay purchase) and it locks fairly quickly and can see around 10 sats most of the time, but the Alarm led refuses to go out.

The ALAR:HARD? and ALAR:OPER? commands both come back "None" but the SYST:STAT? command  tells me it is "Settling"? It is still in this state after being on for more than 24 hours? The 10 Meg output seems quite stable and locked to 10Mhz (as far as I can tell)

Does anyone have any ideas how I can get the alarm led to go off?