GPS/TAC Project
Welcome,
This page is focused on building
hardware and software in order to access GPS data for high accuracy timing applications.
We concentrate on the TAPR-Totally Accurate Clock (TAC2) and how it can be used
to build a NTP server and a high accuracy GPS disciplined oscillator. We include detailed notes
on how this can be accomplished.
The creation of this document required many hours of hard work.
The contributions of many personal and online friends was invaluable.
We would like to thank all of them for their assistance.
Please select from the items below and if you enjoyed the
information, drop us a note. This page was last updated on: December 31, 2005
Project build
Now, use our software to display your GPS data and share it with the world!
And finally: How to build a GPS disciplined time standard
Acknowledgements
How it all got started
For a long time I wanted to find a way to calibrate my instruments without going
broke. On Ebay there are sometimes
some very nice Rubidium and Cesium frequency standards but they are usually very expensive or
they are overdue for calibration. In addition, the Cesium standards
need tube replacement before long and I don't know what that involves.
By accident I came across a reference to GPS based frequency standards while
surfing the net. Eventually, I found a link to the article on
QST
by Brooks Shera. Mr. Shera has a very nice
web page that has a lot of info about GPS
and specifically about building a GPS disciplined frequency standard.
Being a ham myself, (N2FGX), I was really pleased to find this information on QST.
Well, that's how it started. After reading about this project I knew that I wanted to build one for myself. It turns out that TAPR
sells a very nice kit, they call the: TAC2 (Totally Accurate Clock version 2).
This allows for the interfacing of a GPS receiver
so one can obtain multiple 1PPS outputs and other timing info.
After discussing this over with a few friends, GK and
VK,
we decided to build the TAC2. Initially, we figured that it would take a few weeks to build.
and another week before we could start calibrating the instruments.
It turns out that we really miscalculated the time frame. If we finish in a year we'll be lucky!
The concept of precision timing is a very complicated science.
It is also very interesting and a lot of fun. We hope you enjoy
reading about what we have done.
Project plan outline
After some discussion, we agreed on the following:
- Build the TAC2 kit from TAPR.
- Setup Linux to read the TAC clock and act like a NTP server.
- Create software that would allow others to share the GPS data.
- Export the GPS satellite data to the web.
- Generate this web page.
- Build the Brooks Shera project.
- Build a frequency standard that can be disciplined with the TAC2.
- Repeat the process for every member in the group.
The discussion that follows, lists the details of each step.
What you need to know before you buy
First thing I did was to send e-mail to TAPR.
The next day I received a very nice response from Laura Trujillo Koster with ordering info.
She had copied John Ackermann - N8UR,
and he also sent me an email. He asked if my needs for the TAC2
were for navigating or timing. He explained in great detail the different options
and was very helpful.
After sending a few more email to John and looking over the TAPR web site, I decided on the following:
- Between Motorola and Garmin, Motorola had the best receiver.
- The Motorola UT+ was the best choice for timing.
- The Motorola antenna was the best fit.
- I needed the pig tail!
- I would get the: Motorola WinOncore12 software.
Motorola says that you have to purchace this product but I was able to just download it and it ran with no problems.
It does not display a registration screen.
- I would also buy the CNS Systems TAC32 Software
- I would become a TAPR member.
I chose Motorola because John said that it was the best unit for the job. After reviewing the specs
I had to agree with him.
On the WEB I also found much more info on the Motorola unit than the Garmin. Since I use the WEB
quite a lot, that helped make up my mind.
The Motorola UT+ was an easy choice over the GT+. If you want timing you must use the UT+.
the GT+ is made for positioning and tracking.
Since I was going with the Motorola unit, I chose the Motorola antenna as well.
In case you are interested, the UT+ part number is: R5222U114, S/N: R0A2SU, Date of Manufacture:
01/30/01.
The model number indicates that the UT+ has a right angle OSX connector and on-board Lithium battery.
The antenna part number is: GNCNAC1121A. That indicates that it has a magnetic mount, a cable length of 60000mm. and
a BNC plug.
I needed the MCX Pig Tail to connect the antenna to the UT+. The Pig Tail is a 5 foot cable with the MSX connector
on one end and nothing on the other end. This allows for custom connection options.
I must mention here that the unit comes with no enclosure and no power supply. I had no problem with
this but it might be a problem for some.
After I made my decision, it was time to buy. The order was placed on Thursday November 8, by sending email to
Laura. She promptly replied with a confirmation. The total was: $459.50.
I requested next day shipping so I expected the
unit to arrive on Friday or Saturday. Guess what? It got here on Sunday November 11, 2001, at 09:00 via USPS!!!
Excellent!!!
TAC2 - Build
First, some tips on building the kit.
-
Take inventory of the kit. We did and everything was there.
-
Read the assembly manual carefully prior to the build.
-
Make sure you have a stable +5V power supply. You could damage the unit
if the +5V supply is too high. I used a Lambda LCS-4-5 5V 4.5A that I had.
Lambda makes great power supplies and this was no exception. It is a cool looking square brick
5" on each side and very solid.
In preparation for the build, I cleaned the supply and let it run for a week. During this time
I checked it periodically with my DMM and it passed with flying colors. It was +5.0085V no load.
Under load, it would regulate at ±0.0005V.
-
Consider the enclosure carefully. Kon had an IBM disk case (Type 3510) that was built like
a tank. Inside it is all metal which will minimize outside interference.
However, we decided not to use the switching power supply built inside the case.
We felt that it would add unnecessary noise and heat to the TAC2.
-
Check all passive components, prior to the build, using an LCR meter. It could save you much time
later if there is a problem.
-
You should have an oscilloscope to verify things.
-
Make sure you use a low wattage soldering iron.
Having done all that, we started the build on Saturday afternoon.
We followed the steps on the assembly manual and we started moving right along.
We had a few minor problems and I would like to cover them in detail.
- On Page 8, is the Power Supply options section.
Naturally, we chose the "Direct 5 Volt" power supply option since we would use the Lambda.
Below the main section, the manual has sub-sections on the
7805 Voltage Regulator and PT5101 Switcher Voltage Regulator.
These two sub-sections are in bold letters and underlined.
The section on "Direct 5V" is on Page 9 (in small letters) and we missed it.
Later, when we did a voltage check things were all wrong and we had to go back and re-read page 9.
Once we installed the jumper, as instructed on Page 9, all was well.
- On page 11 on the top left corner, under header "With a voltmeter, verify the P3 Pins 7 and 9 are: "
there are 4 items. The fourth item that says: "Remove the test LED on P6" should read:
"Remove the test LED on P6 and test jumper".
It is not logical to leave the test jumper, but the manual does not specify to do so. We took out the jumper and everything
worked fine.
- On Page 13 under section: Motorola Oncore VP/UT the third item instructs you to install the threaded
stand-offs. This was a problem because in order to properly install the UT+, you need spacers of length: 0.480in. (12.18mm.).
What was provided was 0.372in. (9.44mm.). This was not a major problem since I have tons of hardware and was able to install
the spacers with a few small washers added.
To sum up, I would give the assembly manual an A+. The problems listed above were really minor.
By the time the TAC2 was assembled it was around 01:00 Sunday. We mounted it temporarily on a metal plate
and made all the proper power and serial port connections.
Next, we installed the TAC32 software on an NT box. The install finished without a problem and was done in just a minute.
We connected the TAC2 serial port to the COM1 port (on the NT box) and stared the TAC32 software.
Next, we put the antenna outside on a heavy metal plate. The antenna wire was more than enough
to bring it inside and make a connection to the TAC2.
Finally, the moment of truth. With fingers crossed, we hit the power switch on the TAC2. After a few seconds, the TAC32 software
found the TAC2 and started displaying the UT+ status messages and giving satellite info! We were ecstatic!!!
We spent the next six hours working with the software and trying out different configurations.
By the time we were finished it was well into Sunday morning.
After getting some well deserved rest, we continued on Sunday afternoon. About 5 hours later, the case was complete.
We installed the TAC2 inside the case and once again tested the unit. Everything worked perfectly.
TAC2 - GPS antenna mounting
At the same time that the TAC2 unit was being ordered from TAPR, I was doing some research on the antenna.
Motorola states that, for the UT Oncore model, the gain must be: [10 minimum] <= [22 Optimum] <= [33 Maximum] dB.
In addition, "The gain in decibels is cumulative through all stages" [Page 4.3 Motorola Oncore User's Guide].
This means that the sum of negative gain (of the cables and connectors) and the positive gain (of the antenna and receiver)
must fall between the limits above. In addition, "System noise (F) is not to exceed 4dB.".
With these figures in mind I called Davis RF.
The salesman, Jeff, was very helpful and we decided that the cable I needed was the
Times Microwave LMR-600 (3.1dB/ft.).
He suggested the LMR-600 because it costs $.98/ft. and it gives me the
dB/ft figure that I wanted for 100ft.
The cable run to my roof was about 80ft. so I decided to get 100ft. to be on the safe side.
This cable is really something. It is very rigid with a 15.1mm (0.59in.) diameter!!
The sum of all the gain figures is as follows:
- Pig Tail MSX connector to Receiver connection Gain = -0.5dB.
- Pig Tail Gain = 5ft*(12in/ft)*(2.54cm/in) = 152.4cm = 1.52m. (1.52m)*(-1dB/m) = -1.52dB.
- Pig Tail cable to (HF female) chassis connection = -0.5dB. 5 feet, [RG 174, 1.5ns/ft, 4.8ns/m]
- Microwave cable (HF male connector) to (HF chassis female connector) = -0.5dB.
- Microwave cable Gain (100ft at -3.1dB/ft.) = -3.1dB.[LMR 600, 1.1ns/ft, 3.8ns/m]
- Microwave cable HF male to BNC female converter = -0.5dB.
- BNC female converter to antenna cable BNC male connection = -0.5dB.
- Antenna Wire gain = -6.0dB. 6 meters, [RG 174, 1.5ns/ft, 4.8ns/m]
- Antenna gain = 28dB.
Total System gain at the receiver input: 15.4. This is above the minimum recommended figure (10dB) and exactly optimal.
Note that I over-estimated the gain from the connectors.
Also note that the biggest loss comes from the antenna wire.
If the gain had fallen below the (Motorola recommended) 10.0dB. level, I was prepared to cut the wire down to
nothing if necessary.
Now, that the gain figures had been worked out, it was time to build the antenna housing.
In the TAC2 Operation manual it is stated that the antenna should be mounted
"on a metal ground-plane which should be at least one wavelength(20cm) in size (and preferably larger)".
What we used was a square metal plate of 8.5" on each side. This is the kind used by electricians
to cover electrical boxes. The plate also had a (1/2)in. lip around the sides.
This is good since the lip will allow water to drop down instead seeping in.
The metal plate math: 1in. = 2.540cm. so, 8.5in = 21.59cm. ... Perfect!
To cover the antenna, I bought, from eBay, four GPS antenna covers at $4.99 each.
The person selling them said that they were Government Surplus - Conical Radome with 0.0dB loss to 2.5Ghz.
They are 8.125" in diameter, black and made of very tough plastic. The little antenna
should be very comfortable and safe under one of these.
Click here to see what they look like.
On my roof, I have a 2 meter VHF antenna attached to the top of a Radio Shack 10' pole.
We decided to attach the GPS antenna+housing somewhere in the middle of the same pole.
To mount the GPS antenna housing to the pole, we attached a 1" pipe to the bottom of the metal plate.
The hardware to connect the GPS antenna pole to the 10" pole was bought from:
WB0W. The items used were four(4)
MMK1 3-Groove backing plate
from Maxrad. The cost was $9.99 each and well worth it. This mounting hardware was heavy duty!
Initially we were worried that the antenna housing might twist around the pole if the wind got too high. Well, after using all four of
the mounting connectors, I can assure you that there absolutely no chance of that ever happening!
Since the pole was already there, the whole operation was done on a Saturday afternoon.
The only trouble we had was with the LMR-600 cable. It is very rigid and we didn't want to damage it by mis-handling.
As a result, none of the turns is greater that 90°. In addition, whenever the cable came in contact with cement
or brick, we covered it with a plastic sleeve.
For the completed project, see pictures link on the left frame or click here.
TAC2 - Finishing up
Once the project was up and running, there was plenty of time to experiment with the parameters and try some things.
Here is a list of things to check for:
- You will need to leave the TAC32 software running for a few days in order to get an accurate position fix.
Make sure your Windows machine is ready for this. Watch out for overheating!
- Once the software is running, it will take about 15-20 minutes for the UT+ to get the almanac from GPS.
This is normal.
- In the TAC32 screen, you will see your coordinates change. After 24-48hours your average position
will begin to stabilize. Save this information so you can configure NTP later.
- Keep an eye on you power supply heat dissipation. This unit will be online 24 hours a day from now on
so it has to keep cool.
- From my position, I usually have 8-10 satellites visible and 6-8 tracked all the time. If you have
less that three tracked satellites you do not have a good view of the horizon. You should re-position your antenna.
- Make sure you use high quality serial cables when connecting the TAC2 to your computer. I used the
Madison Cable "Turbo Quad" cable. I built the DB9 connectors myself
since the application is very custom. This cable, although a bit expensive, is great for this job since it is rated
to over 1Ghz (at 50 Ohms).
Now that the TAC2 was running for a few days, I experimented with a few options.
Basically I tried disconnecting the antenna, suddenly powering off the unit and other "catastrophic" events.
Everyone should do this so when something fails you know where to start.
I also experimented with the Motorola WinOncore12 software. It gives much of the same information as the TAC32 but is does not seem
as polished. However, it does provide some functionality that TAC32 is missing. Personally, I liked the WinOncore12
command line mode better than the TAC32.
Finally, it was time to configure NTP.
NTP - What it means to the TAC2 builder
Now that the TAC2 is built and working, it is time for it to do some serious work. After all,
just looking at the GPS data can get a bit boring.
The next logical step is to configure NTP. I am not going to discuss NTP here since that info is well
documented elsewhere. However, I will discuss certain aspects as the need arises. The NTP documentation is
huge so I will try to show you how to quickly get NTP up and running.
Please note that the following sections deal with NTP under LINUX. If you need info on some other operating system
start with the NTP main page and go from there.
Basically, our objective is to configure Linux so that is becomes a primary NTP server and allow other machines (using NTP)
to get the time from us.
In technical terms: We want to create a Stratum 1 server. Once a Stratum 1 server is established, other machines
that connect to us become Stratum 2 servers.
While NTP is trying to sync with a server (even the local GPS clock) it shows up as a Stratum 16 server.
Remember that NTP synchronization takes a few minutes (as much as 10 minutes). This is normal. I will show you how to check this.
Here is what you need to do in order to setup Linux as a Stratum 1 NTP server:
- Get the Linux Nanokernel.
- Compile and configure the Linux Nanokernel.
- Get the latest NTP source code
- Compile and install NTP
- Configure NTP
Let's begin.
NTP - The Linux Nanokernel and TAC2
The Linux Nanokernel patch refers to a modification that allows the kernel to quickly detect 1PPS signals coming
in from the RS232 interface serial port 1 (COM1). Since the kernel is aware that the serial port is used as a 1PPS
detector, it can quickly process this while still in kernel space. This allows for minimum delay
in the 1PPS processing cycle. For the best precision, kernel clock discipline is the way to go.
The TAC2 provides 2 1PPS outputs via BNC connectors and 2 1PPS outputs via the DCD pin in the serial ports.
This makes life easy because we can use the RS232 port to provide the 1PPS signal to our Linux box.
The ntp.conf file can specify how the kernel performs the clock discipline via the
pps configuration option. Our configuration is examined later in this document.
NTP - Compiling the Linux Nanokernel
Update: 2/09/2002 - I upgraded the kernel to 2.4.16 and applied the PPS patches. Everything works great!
In the discussion below, substitute: 2.4.3 by 2.4.16.
The latest Linux Nanokernel can be downloaded from here: Linux 1PPS kernel driver
In our case, the target Linux machine was an AMD K6 350Mhz, running Slackware 8 and kernel 2.4.5. When I downloaded the Nanokernel
patch I found it for 2.4.3 only, so I had to construct an older kernel. Initially I tried the patches against the 2.4.5 but it failed miserably.
Once I had the right kernel in place the patch went ok.
What you need to do is:
- Download the patch in some permanent directory. NOT in the /usr/src directory.
- Untar the patch and copy the actual patch file to:
"/usr/src/linux"
In my case the actual patch file name was: patch-2.4.3
- Make a copy of your
"/usr/src/linux" tree.
root # cd /usr/src; cp -pr linux linux.save;cd linux
- Patch the kernel
root # patch -p1 < patch_file_name
If your patch program does produce a lot of output, maybe check for rejects using:
root # find . -name '*.rej' -print
You must fix this problem before continuing.
- You must make a copy of the include files:
"timepps.h" and "timex.h".
When I skipped this item, I could not compile NTP. The NTP build configure script should find it but
in my case it didn't. So, do:
root # ln -s /usr/src/linux/include/linux/timepps.h /usr/include/sys/timepps.h
root # cp -p /usr/include/sys/timex.h /usr/include/sys/timex.h.SAVE
root # ln -s /usr/src/linux/include/linux/timex.h /usr/include/sys/timex.h
root # make menuconfig and enable "experimental drivers" to see the PPS option.
- Select
"NTP kernel support", "NTP PPS support", "Debug NTP PPS support" and
"NTP PPS support on serial port" after selecting the serial driver.
The driver can be inserted as a module at runtime if you like.
root # make dep
root # make modules
root # make modules_install
root # make bzImage
- Add the new kernel to LILO, do:
root # lilo
and reboot using the new kernel.
The new linux was:
root # uname -a
Linux myrto 2.4.3-NANO #1 Thu Jan 3 05:30:57 EST 2002 i586 unknown
Note the "NANO" suffix. It means that you have been successful.
NTP - Compiling and installing NTP and the Motorola Oncore driver
The following discussion on NTP refers to NTP version 4.1.72. When I decided to build NTP
this was the Beta code and from the online discussions it seemed like the way to go.
Also I am assuming that you installed the PPSkit and copied the two include files timepps.h and timex.h
to the appropriate system directories as mentioned above.
I tried to compile everything on a machine that did not have the PPSkit kernel. I just copied
the two include files and started configure and the make. Everything compiled ok but when I started
ntpd on the target machine (with PPS kit) something did not look right. I got some weird
kernel messages "kernel: adjtimex: ntpd could be using obsolete ADJ_TICKADJ"
So, I reconfigured and ran make again on the target machine. The error message went away.
I cound be completely wrong here but that's what what happened.
To compile NTP follow these steps:
- copy the tgz file to the place where you will compile everything.
root # tar -xzvf ntp-4.1.72.tar.gz
root # ln -s ntp-4.1.72 ntp; cd ntp # I do this for convenience
root # configure --enable-ONCORE
- Edit the
config.h file that was generated by the configure command.
inside you should see the following statements NOT as comments:
#define CLOCK_ONCORE 1
#define HAVE_PPSAPI 1
#define ONCORE_SHMEM_STATUS 1
#define HAVE_SYS_TIMEX_H 1
#define HAVE_SYS_TIMEPPS_H 1
If these statements are commented out then you did something wrong. You must fix this before going on.
-
root # make
root # make install
So far so good. Now, let's examine the configuration files.
NTP - Simple Configuration
This small section applies to those who just want to start NTP without any local clock reference. That means NO TAC2.
- Create a simple
/etc/ntp.conf with just two lines:
driftfile /var/log/ntp/ntp.drift
server 129.6.15.29 # time-b.nist.gov
- Make sure that the directory:
/var/log/ntp exists.
- Make sure that
ntpd is NOT running.
- Check if you have connectivity to a good NTP server. Do:
root # ntpdate -bdqv 129.6.15.29
You should get an answer with the last line something like:
22 Feb 00:19:45 ntpdate[13615]: step time server 129.6.15.29 offset 0.002790 sec
If you get:
No server suitable for synchronization:
Then, make sure that you have connectivity to that server. Otherwise, try another.
- Set the local time to a "good" time. Do:
root # ntpdate -v 129.6.15.29
- Now, start
ntpd
root # ntpd
- Now, issue:
root # ntpdate -bdqv localhost
You should get a last line that says:
No server suitable for synchronization:
Good! This is normal for about 10-20 minutes.
After that, you will get:
22 Feb 00:35:04 ntpdate[13642]: step time server 127.0.0.1 offset 0.000015 sec
Somewhere in the ntpdate output you should also see:
stratum 2, precision -17, leap 00, trust 000
That is all there is.
Note: For the sake of being a good net citizen, keep in mind two things:
- It is your responsibility to find a NTP server that is closest to you and is not very busy. This will
help congested NTP servers breathe a little.
- If you are syncronizing multiple machines in your internal network, then only one machine
should sync with the internet. Let's call that machine the "External Synchronization Host".
All the other machines should have a server line that
is pointing to the "External Synchronization Host" and NOT machines outside of your network.
There are many reasons for doing this besides keeping the Internet less congested.
Now, let's examine NTP for the TAC2.
NTP - TAC2 Configuration
At this point, I was confident that the TAC2 was working properly since I used TAC32 to make sure.
Before going further, I recommend that you verify this as well. ntpd does not have a nice
interface and possible problems will not be immediately obvious. If you don't have a windows machine
to run TAC32, I suggest you boot from a DOS disk and run the TAC2 DOS interface program.
From Linux, you can quickly check some things by doing:
root # ntpdate -bdqv darksmile.net
You should get about half a page of info from the target NTP server (darksmile.net).
The last line should say something like:
7 Feb 18:38:02 ntpdate[2420]: step time server 216.66.1.158 offset -0.000199 sec
This means that you are connecting to the internet and at least some of the NTP compile went ok.
At this time, you should set your local clock so it has "good" time. If you don't, ntpd will
have a problem starting. So, do:
root # ntpdate -v darksmile.net (Or any other valid NTP server)
Your local clock is set. Now, let's check ntpd.
The Oncore driver requires that two configuration files are present. On my Slackware 8 machine
these files are:
/etc/ntp.conf and /etc/ntp.oncore0.
These are my production configuration files.
To download the config files do: "Save Target As" and copy them
to the /etc directory. Sorry, but I don't allow ftp to my site due to security
concerns.
Create the NTP stats directory: /var/log/ntp
Make sure that the ntpd you've just created is first in your path and do:
root # ntpd -n -vvv
This will create a lot of output like this:
ONCORE: @@Ea
ONCORE: @@At
This means that ntpd is talking to the Oncore. The @@xx type of messages are
coming direct from TAC2.
From seperate xterms do:
root # tail -f /var/log/ntp/xntpd
root # tail -f /var/adm/messages
Note: You should monitor these files and look for errors as you perform the initial configuration.
In /var/adm/messages you should see messages like:
ntpd[20225]: ntpd 4.1.72@1.762-r Mon Feb 4 18:54:07 EST 2002 (1)
ntpd[22302]: precision = 2.000 usec
ntpd[22302]: kernel time discipline status 0040
ntpd[22302]: frequency initialized -28.223 from /var/log/ntp/ntp.drift
and possibly:
kernel: hardpps: PPSERROR limit=2000000, fcount=-2659462, len=93
kernel: hardpps: PPSJITTER: jitter=7308, limit=4316
and then:
kernel: hardpps: new frequency -116508 >> 2 == -29127
If you see something like: "ntpd{22302]: Invalid driver" it means that the Oncore Driver was not compiled in.
You must find out why and re-compile.
If you got to this point, ntpd must be talking to TAC2/Oncore and it is also trying to discipline the local PC clock.
You should Ctrl-C and start ntpd again without debug mode by doing:
root # ntpd
Reminder: You should have a second xterm open and you should be monitoring the messages file.
Now do:
root # ntpdate -bdqv localhost
You should see something like:
.
stratum 16, precision -18, leap 11, trust 000
.
7 Feb 18:29:49 ntpdate[2395]: no server suitable for synchronization found
Don't panic! This is normal for the first ten minutes or so.
"stratum 16" above means the the local clock is not syncronized yet.
The messages file should be displaying lines from ntpd with syncronization
information.
So, after about 10-15 minutes execute the "ntpdate" command above and this time you should see
.
transmit(127.0.0.1)
server 127.0.0.1, port 123
stratum 1, precision -19, leap 00, trust 000
refid [GPS], delay 0.02844, dispersion 0.00000
.
7 Feb 19:04:32 ntpdate[4956]: step time server 127.0.0.1 offset -0.000008 sec
Notice the "Stratum 1" string. You are online!
Things that can go wrong: (I am assuming that you are using my config files here).
- ntpd quits after 1-20 minutes. Fix: You have not set the local clock initially with ntpdate.
See above.
- The stratum changes to 2 not 1. Check your logs. Leave only one server line in /etc/ntp.conf
This happened to me when I put too many "server" lines in ntp.conf.
- Too many "JITTER ...." strings in /var/adm/messages. It is possible that the serial cable length is too long.
You must use a very good quality serial cable and it must be as short as possible.
Note: You will always get some "JITTER" messages.
That can't be avoided. Just make sure that they are not consecutive.
- Too many "INVALID PULSE" strings. Again, check the cable. If you changed the
ntp.oncore file
and modified the ASSERT or CLEAR keywords, then make sure of your settings. More on this below.
If you are still having problems continue to the "Advanced NTP Configuration" section below.
Also, try reading the online ntp documentation. There is a huge
amount of information there.
NTP - TAC2 Advanced Configuration
Now that we have ntpd working, let's go over the details of the entire setup. In order to get
my configuration files in their final form, I spent a lot of time trying different options.
Although there is a ton of ntp related information on the web, I couldn't find a HOWTO that matched my hardware.
While going through this testing phase, I vowed to create a document that would make it easy for others trying to do the same.
A great deal of configuration confusion was cleared by Mr. John Hay and
Mr. Ulrich Windl.
Anyone reading through the NTP docs online (including the NTP source code) will instantly recognize their names.
They responded to numerous email with invaluable information.
A great big "Thank You" to these gentlemen.
As I mentioned above, ntpd is made up of two configuration files. Let's examine the main one: /etc/ntp.conf first,
starting from the top:
driftfile /var/log/ntp/ntp.drift
logfile /var/log/ntp/xntpd
statsdir /var/log/ntp/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
First, make sure that the "/var/log/ntp" directory exists.
These lines basically tell ntpd to start gathering statistics and the directory where to store them.
Note: If you are just configuring a machine as a NTP client, then all you need is the driftfile option.
enable pps
I am not sure if this is needed. I leave it there just to be safe.
pps /dev/oncore.pps.0 hardpps
Warning: This line MUST precede any "server" statements!
Before the hardpps keyword, some sites have "ASSERT" or "CLEAR" specified.
In the case of the Motorola Oncore NTP driver, the ntp.oncore0
configuration file, has an "ASSERT" option that overides the ntp.conf file, so I skipped it here.
Important note: I bet that I will get alot of email because I chose the hardpps
option. Let me explain why I did this.
The hardpps option tells ntpd that it should perform some sanity checks (on the PC clock and PPS hardware) and then work with
the Linux kernel to discipline the PC clock. The kernel traps the 1PPS signal, coming in from the serial port DCD line, and
disciplines the PC clock if it drifts too much. This is typically done once in 16 seconds although this can be changed with the
server option.
Initially, I did not specify the hardpps option. I was viewing the loopstats file using the ntploopwatch
script (provided in the NTP distribution) and I noticed that the clock drift was ±400 microseconds.
When I put the hardpps option in, I noticed that the clock varied by ±50 microseconds (sometimes), and most of the time
by only ±20 microseconds. This was a tenfold improvement!! I don't know if this is unusual
but this is solid proof that hardpps should be specified.
I am willing to listen to other views on this, but until I see better drift stats I will stick to my guns on this.
server 127.127.30.0 prefer
This line does all the work.
The "127.127" is required.
"30" specifies that we will be using the Motorola Oncore driver.
The "prefer" keyword specifies that all things being equal, this is the server that will be used as the primary NTP standard.
fudge 127.127.30.0 refid GPS
The only reason I have this here is so I can customize the "refid". This is the string that you see
when you run the: "ntpdate" command. You can change this to any four letter string. Have fun!
server 208.184.49.9 # nist1-ny.glassey.com NYC local server
Specifying a second "server" line, as I have done, basically accomplishes two things.
- The second server is used as a sanity check in case something really weird starts happening with the Oncore driver.
- The second server is used as a backup in case the TAC2 stops responding.
Whenever I check some NTP server on the net with:
ntpq -c peer "internet_NTP_server"
I always look for machines that have at least two peers. Some have four or more but,
Warning:
When I used more that one additional "server"
lines, I got a lot on "Syncronization Lost" messages in the syslog. This may be due to my machine's
speed but be careful here.
Now that we have finished the main configuration file, let's go over the "ntp.oncore0" file.
MODE 1
This mode means that I will specify my longitude, lattitude and height manualy. From the Oncore driver
source code you might get the impression that "MODE 0" is what you need. "MODE 0"
means, that the Oncore clock is pre-initialized by some other means. If you used the TAC32 software, you might think that
you have already pre-initialized your Oncore clock. Well, this is not exactly true. I found that the Oncore was NOT
pre-initialized, even after I just set everything up with TAC32.
The issue here is that in order to get the best possible timing configuration, you need to have the Oncore in
"Position Hold". This means that you already know your 3D Fix on the planet and you just want the Oncore to
calculate the timing solution and provide the 1PPS output.
What I am trying to say here is: Don't trust the condition of your Oncore prior to starting NTP. "MODE 1"
performs some checks and starts the Oncore properly.
How do you know what your 3D position is? What I did was, I started TAC32 and let it run for about 48 Hours. Then I took
the averages for latitude, longitude and height and used those numbers. I read somewhere that this is the recommended way.
Note:
If you are using The Oncore UT+ without battery backup, you must use
"MODE 3" or "MODE 4". These modes do a "COLD START" on the GPS clock. If you start from a "COLD START"
then it will take as much as 20 minutes before the Oncore is ready. NTP will take even longer. If you have the battery
backup, avoid these modes.
LONG -73 54 41.6193
LAT 40 46 18.9539
HT 5.18 m
As I said above, in "MODE 1" you need to specify these.
DELAY 168.9 ns
This option allows the Oncore UT+ to compensate for the different cables delays between your Oncore and the 1PPS signal
coming in to your computer. I got this number from using the TAC32 "Cable Delay Calculator".
ASSERT
This option specifies that the leading edge of the 1PPS is used to calculate the pulse width. The idea here is
that the leading edge has less jitter that the falling edge. If you determine that it is the trailing edge
that has less jitter, you can specify: "CLEAR" here. According to my scope, the leading edge was the right choice
for me.
STATUS /var/log/ntp/ONCORE
This option allows the Oncore NTP driver to create a shared memory interface so other programs
can view the sattelite data in real time. This option was used to create software that allows
others to view your GPS data over the net. This is explained in detail in the sections below.
Just make sure that the PATH to the file exists.
Warning: I do NOT recommend that you specify: "Posn3D".
As you can see in my configuration file, I have this option commented out.
"Posn3D" means that every 15 seconds, change the status of the Oncore from 0D(Position Hold) to 3D(Navigating mode)
so you can get the extra info provided in the Navigating Mode. Well, according to my event counter, instead of the
expected 3600 pulse count (every hour) I was getting something in the range of 1100!. That means I was losing one out of every three pulses.
The transition from "Position Hold" to "Navigating Mode" was causing major problems with the Oncore.
I modified the source code so you can specify the interval in seconds before the transition was made. This allows you to do:
Posn3D delay_in_seconds
Where "delay_in_seconds" is the mumber of seconds to wait before switching to 3D mode and back. Even though this modification works well, I still
do not recommend using the "Posn3D" option. You can download these changes from the Download section on the left frame.
That is basically all of it. Hopefully, you have a working NTP stratum 1 server and you had fun building it. I strongly recommend that you spend
some time trying out different options and configurations. If you spent all that money on this project (like I did) I am sure you want to know every
detail.
darksmile.net as a NTP server
After many hours of hard work I think that I have a good NTP configuration. However, darksmile.net
should be considered as a test NTP server. It might be erratic due to constant work that I am doing on the page and the hardware.
Feel free to use this site as a NTP server but don't get too angry if NTP is not working. Over the coming months I hope
to stabilize the system so it is more usefull to the net community.
We've developed custom GPS software that allows for the display of the entire TAC2 and GPS receiver
dynamicaly. Click here for the complete project details.
All this effort is towards building a GPS disciplined frequency standard.
Click here for the complete project details.
Acknowledgements
Many Many thanks to the following people:
Mr. Brooks Shera. Mr. Shera gave me the original idea in his great article in QST.
Mr. George Kontakis. My best friend of countless years. Without his help none of this would be possible.
Mr. Vasili Kambouroglou. A great friend and brilliant programmer.
Mr. John Ackermann. His email was of great help in ordering the TAC2.
Mr. John Hay. His email was invaluable in the NTP configuration phase.
Mr. Ulrich Windl. Great information for the Oncore configuration.
All members of the TAPR TAC2 mailing list. The list members answered many of my questions.
|
