FE-5680A and GPS Breakout 1PPS signal experiments with NTP

Another cheap rubidium frequency standard  under $ 100: The FE-5680A. This  type of  commercial rubidium  (as opposed to the M-100 that is intended for military use) was first used in large GSM repeaters and installed in racks presumably because it achieves quite high temperatures in a short time on its little alluminium chassis . The lock  time recorded is very low : we are under 3 minutes as opposed to 5′ previously recorded by the Efratom M-100. (they use different technologies too.) Anyway, the interesting thing is that this kind of FE-5680A has an output that was described by the seller as 1PPS.

So first i’ve powered the FE-5680 with 15v on pin 1 and check out the 10 Mhz signal (with Claudio Re we’ve done a preliminary observation test on  the phase noise compared with  the Efratom M-100  at this link http://air-radiorama.blogspot.it/2014/11/test-preliminare-efratom-m-100-e-fe.html) and , from pin 6  and to be sure, i’ve used  the FAT-PPS from TAPR ( https://www.tapr.org/kits_fatpps.html )The FatPPS triggers on pulses as short as 20 nanoseconds and stretches it out to at least 30 milliseconds, which is enough to reliably work with nearly any serial port.I’ve powered it with 5v of an Arduino Uno and  i’ve checked the FE-5680A 1PPS output with an oscilloscope (Channel 1, yellow) , compared with the GPS Ultimate Breakout 1PPS (channel 2 , blue) . That was the result :

20141121_21544820141121_222559You can quickly see the main difference of the output quality : the one from the rubidium is not at 1 hz or 1 second but instead  is at 8.388 ms wich which is divided by a fixed 2^23 from the internal DDS-generated frequency (8.3xxxMHz) and is not costant in time. (this will generate some problems when trying to take this “1PPS” to the GPIO pin of the Raspberry NTP server.  )I think  that the signal it is just an engineering test/diagnostic signal but not a precise 1PPS. More than this ,on time-nuts forums, i’ve read about CPLD chip wich can be programmed in different way on what the custumer needed…)

The other problem was the peak voltage. 4.1 was just too much for the Raspberry wich has to be filled with 3 – 3.3 v. So i’ve used a  adjustable trimmer to lower the voltage level of the output to the requested voltage :

20141121_231956I’ve regulated it on 3 v instead of 3.20 (which is on channel 2, the GPS Breakout) — but i’ve tested it at the same voltage without any changes.– The signal is also very short compared with the GPS one.If you look at this video , check the CH1 time reference that is the rubidium one (yellow) with the precise 1PPS from GPS:

Finally i’ve connected the output to the GPIO pin of the Raspberry and check out with #ppstest if the board was accepting the 1PPS rubidium signal inside it  and it was there, faster as we expected, compared to the GPS one.

20141121_215523

compared with the one from the GPS breakout wich is locked on satellites:

The first results with NTP algorithm  using 1PPS with a modified Linux Debian Kernel to accept it, confirmed  data seen on the oscilloscope in the time domain :  the internal chip creates a similar 1PPS at 838.8 ms which varies and it’s not stable. I don’t know why this instability, probably as I said before, has been designed for other purposes than to generate a precise 1PPS. Anyway just for fun i’ve tried to manage this input with the stratum 1 NTP server and that  was the output in few seconds before , as predicted , NTP rejected it because of its too much variable offset.

Screenshot - 11212014 - 11%3A08%3A57 PM

Advertisements

3 thoughts on “FE-5680A and GPS Breakout 1PPS signal experiments with NTP

  1. So, in short, are you trying to say that the ‘1 pulse per second’ (1 pps) signal from the FE-5680A does not actually produce a 1 pulse per second signal? Is that what you mean?
    Your ‘wrote’ that the 1 pps pin of the FE-5680A actually produces pulses with pulse period of 8.388 ms, but your oscilloscope measurements are indicating 833.8 millisecond pulse period (ie 0.8388 second pulse period). Things don’t appear to be consistent in what you’re saying here.

    Like

    1. Hi Kenny. No the problem was with NTP algorithm that was refusing the 1PPS from the Rubidium, probably due to the wrong assert/clear status.
      Those Rb units come with different configurations all depending from the final destination customer request.
      Anyway it is possible to make it working with RFC 2783.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s