[LinuxPPS] Oncore section of the LinuxPPS NTPD support web page. Improve docmumentation.
Hal V. Engel
hvengel at astound.net
Thu Feb 19 02:32:39 CET 2009
Reg sent this to me rather than the list but I thought that it may be of
interest to other Oncore users here. In addition he includes some code that
could be of use to all LinuxPPS users. So I am replying by way of the email
list. See my comments in line below.
On Wednesday 18 February 2009 12:38:42 pm Reg Clemens wrote:
> Hal:-
>
> Some comments on your posting.
> I should have written something like this ages ago, but I never did,
> Thanks for your effort.
>
> I do have some comments and some errata.
>
> (1) Under Installation, you have the lines
>
> Run the configure command with the following parameters:
> ./configure --disable-all-clocks --disable-parse-clocks --enable-ONCORE \
> --enable-LOCAL-CLOCK -enable-SHM
>
> That should be --enable-SHM
Typo on my part. Good catch.
>
> (2) Under Symlinks you say
>
> There has to be a /dev/oncore.pps or /dev/oncore.pps.<X> device file which
> is a symlink to /dev/pps<X>
>
> That really should read
>
> There has to be a /dev/oncore.pps or /dev/oncore.pps.<X> device file which
> is a symlink to /dev/pps<Y>
>
> There is no reason for X and Y to be the same. In fact I link
>
> ln -s /dev/oncore.pps.0 /dev/pps1
You are correct. There is no need to use the same number for both the
symlinks and the pps device. In fact if you only have one Oncore you do not
need to use the number for the symlinks or the SHMEM file.
>
> (3) Ill have to try the udev lines.
> I used to use udev, but at that time they were making rapid changes to it
> and I gave up trying to keep up with the changes...
udev appears to be working nicely now days and it definitely works for this
stuff. My system is using udev version 124 (the most recent release is 137).
>
> In FACT I do this differently, since I am often changing my configuration
> I do it dynamically with the following lines in the init.d/ntpd file
>
> ---
>
> # arg is serial line $a
> start_ppsldisc()
> {
> # First step is to create the ldisc and link /dev/pps? to oncore.pps.0
>
> echo -n "Starting ppsldisc: "
> ( /usr/local/bin/ppsldisc $1 & sleep 120 ; killall ppsldisc ) >& /dev/null
> &
>
> # Now link it to the devices that oncore will be looking for.
>
> rm /dev/oncore.serial.0 >& /dev/null
> ln -s $1 /dev/oncore.serial.0
>
> # findpps2 tries at 5sec intervals for 50sec
>
> c=`/usr/local/bin/findpps2 /dev/ttyS1`
>
> rm /dev/oncore.pps.0 >& /dev/null
> if [ -n "$c" ]; then
> ln -s $c /dev/oncore.pps.0
> success
> else
> echo "Can't find /dev/pps<x>"
> failure
> fi
> echo
> }
>
> ---
>
> The program findpps2 is just the following code (I tried doing it as a
> shell script, and I think I had it working at one time, but its much easier
> in C.
>
> ---
>
> #include <stdio.h>
> #include <sys/types.h>
> #include <dirent.h>
> #include <stdlib.h>
> #include <string.h>
> #include <sys/stat.h>
> #include <fcntl.h>
> #include <unistd.h>
>
>
> /* give the /dev/ttyS<n> as an argument, find the /dev/pps<x> that
> corresponds to it. */
> /* wait up to 50sec for it to appear, checking for it every 5 sec */
>
> int
> main(int argc, char* argv[])
> {
> char dir[] = "/sys/class/pps";
> DIR *ppsdir;
> struct dirent *pps_subdir, pps_subdirx;
> char name[100], path[100];
> int fd, i, j;
>
> for (j=0; i<10; j++) {
> if ((ppsdir = opendir(dir)) >= 0)
> break;
> sleep (5);
> }
> if ( ppsdir < 0 ) {
> fprintf (stderr, "%s: Can't open directory %s\n", argv[0], dir);
> exit (1);
> }
>
> /* here /sys/class/pps has been created j*5sec used so far */
>
> for (; j<10; j++) {
> while ((pps_subdir = readdir(ppsdir))) {
> /* have . .. and /dev/pps1 ... /dev/ppsn here */
> if (! strcmp(pps_subdir->d_name, ".") || ! strcmp(pps_subdir->d_name,
> ".." continue;
>
> /* a real subdirectory */
>
> strcpy (name, dir);
> strcat (name, "/");
> strcat (name, pps_subdir->d_name);
> strcat (name, "/path");
>
> if ((fd = open(name, 0)) < 0) {
> fprintf (stderr, "%s: Can't open path file\n", argv[0]);
> exit (1);
> }
>
> i = read (fd, path, 100);
> path[i-1] = '\0'; /* this one has a \n on it */
>
> if (!strcmp(path, argv[1])) {
> /* here have a path back to the desired /dev/ttyS<n> */
> fprintf(stdout, "/dev/%s", pps_subdir->d_name);
> exit (0);
> }
> }
> sleep (5);
> rewinddir(ppsdir);
> }
> fprintf (stderr, "%s: Cant find PPS file for %s\n", argv[0], argv[1]);
> exit(1);
> }
>
> ---
>
> Im not sure if anyone else would be interested in that or not.
>
> (4) Your comments about --enable-SHM are just WRONG.
> The option --enable-SHM enables the Shared Memory Driver (which I use with
> my WWVB
> receiver). The thing that turns on the Shared Memory file itself is the
> line
>
> SHMEM /var/log/ntpstats/ONCORE.0
I mention this in the section about the oncore configuration file. But it
should also be in this section of the writeup.
>
> and the 'option'
>
> Posn3D
In my comments I did mention that this was to enable shared memory for
external software. "The second function is to allow external software to get
a read only interface to the GPS data stream. Please see the on-line ntp
Oncore docs for a link to an example program which will allow you to monitor
the reception of the GPS while ntp is running." But I put more weight on the
fact that the driver would use this to initialize the GPS during startup.
I also use a modified version of OncorePlot on a regular basis and find it
useful even given the Posn3D/Posn2D issues (see next paragraph). So I
consider both functions of the SHMEM setting important even if GPS
initialization was not intended to be the primary function. That section in
my writeup was about how to speed up GPS initialization so I will rewrite it
to be about SHMEM and have two sections that cover initialization and external
software like OncorePlot.
My experience is with Posn3D is that it is not required for the SHMEM setting
to work and only the SHMEM entry is needed to enable this. In fact in my
testing I have never been able to get Posn3D or Posn2D to work as both of
these stop my UT+ from working reliably. At one point I though that this was
because I was using an indoor patch antenna (IE. that a weak signal was
causing this issue). But I have since installed an outdoor antenna which
improved the received signal to noise ratio by about 10db (satellite s/n is
between 40 and 50 most of the time and at times as high as 55 with the outdoor
antenna, the GPS almost always locks onto either all satellites in the sky if
there are fewer than 9 or 8 satellites if there are more than 8 available) and
I still can not get this to work.
By the way I am using a modified version of the latest OncorePlot code that
displays the signal to noise data when satellite information is enabled. It
is a simple mod that only adds perhaps 8 or 10 lines of code. If you are
interested I can create a patch and get this to you.
>
> in the ntp.oncore.<x> file. This file not only saves stuff for the next
> restart
> but is useful for plotting satellite positions, seeing your Horizon, and
> computing an accurate position for your antenna.
>
> As you noted, by default, ntp will use 10000 samples to get a location for
> your antenna, and this takes 2h45m. It is controled by the define in the
> code
>
> #define POS_HOLD_AVERAGE 10000 /* nb, 10000s ~= 2h45m */
You are correct that with a setting of MODE 2 or 4 that the ntp Oncore driver
will do a site survey at startup. I didn't cover this because I had advised
using MODE 1 in the writeup. As you point out it takes almost 3 hours to do a
site survey. This may not be an issue for users running servers that are
constantly up but for those using an Oncore on a workstation that gets
rebooted (or that need to restart ntp for some reason) it is an issue. That is
why I suggested using WinOncore12 to do a site survey so that users could do
this one time and use MODE 1 to avoid having to wait 2 hours and 45 minutes
for the antenna position to stabilize each time they started ntp.
>
> A much better way to get a long term averge for your position is to use
> my graphics program, OncorePlot, which requires libSX . The version of the
> plot routine out on ntp.org is VERY OLD and I will try to update it this
> week. Also, the most recent version of libSX is also hard to find, and I
> will put it out there with the graphics package.
>
> Note that you can leave this graphics package running for days/weeks, and
> it keeps a running mean position for your location.
>
> BUT the information needed, namely location is NOT saved for the more
> recent M12/M12T Oncores, and they had a software problem that kept me from
> switching in and out of position hold mode. With the older models, if
> you did the switch out, to get a current position (once every 15 sec)
> when you returned you were back where you were with position hold. With
> the newer M12/M12T you were not. Rather you were hunting for the position
> which made it worthless.
This needs to have Posn3D or Posn2D set in the Oncore configuration file and I
have not been able to get this to work. I know you have tested this with VP
and M12 models but I don't know if you have tested this with UT or UT+ models.
I know with my UT+ devices with firmware versions 2.2, 3.1 and 3.2 it does not
work. So I have never been able to get the position averaging stuff to work
with OncorePlot.
>
> Well, thanks again for your notes, with the above errata they really should
> go out somewhere where others can read tnem.
Detailed configuration and setup instructions needs to be somewhere public and
all in one location. I know I struggled a little getting mine working and if
I had found a set of documentation like my writeup it would have been way
easier. I had to go to several different locations to pull together all of
the info needed and even then some of it was sketchy at best. So my intention
was to help others by getting enough info in one place to get an Oncore
working with LinuxPPS. It seems to me that the ntp page of the LinuxPPS wiki
is as good a place as any for this info in particular since my writeup had
some Linux specific information like the udev section.
There is also some very useful information located in the comments of
refclock_oncore.c that should probably be extracted and included in a more
public place. In particular this comment in function oncore_read_config():
/*
* First we try to open the configuration file
* /etc/oncoreN
* where N is the unit number viz 127.127.30.N.
* If we don't find it we try
* /etc/ntp.oncore.N
* and then
* /etc/ntp.oncore
*
* If we don't find any then we don't have the cable delay or PPS offset
* and we choose MODE (4) below.
*
* Five Choices for MODE
* (0) ONCORE is preinitialized, don't do anything to change it.
* nb, DON'T set 0D mode, DON'T set Delay, position...
* (1) NO RESET, Read Position, delays from data file, lock it in, go to 0D
mode.
* (2) NO RESET, Read Delays from data file, do SITE SURVEY to get
position,
* lock this in, go to 0D mode.
* (3) HARD RESET, Read Position, delays from data file, lock it in, go to
0D mode.
* (4) HARD RESET, Read Delays from data file, do SITE SURVEY to get
position,
* lock this in, go to 0D mode.
* NB. If a POSITION is specified in the config file with mode=(2,4) [SITE
SURVEY]
* then this position is set as the INITIAL position of the ONCORE.
* This can reduce the time to first fix.
*
-------------------------------------------------------------------------------
* Note that an Oncore UT without a battery backup retains NO information if
it is
* power cycled, with a Battery Backup it remembers the almanac, etc.
* For an Oncore VP, there is an eeprom that will contain this data, along
with the
* option of Battery Backup.
* So a UT without Battery Backup is equivalent to doing a HARD RESET on each
* power cycle, since there is nowhere to store the data.
*
-------------------------------------------------------------------------------
*
* If we open one or the other of the files, we read it looking for
* MODE, LAT, LON, (HT, HTGPS, HTMSL), DELAY, OFFSET, ASSERT, CLEAR,
HARDPPS,
* STATUS, POSN3D, POSN2D, CHAN, TRAIM
* then initialize using method MODE. For Mode = (1,3) all of (LAT, LON, HT)
must
* be present or mode reverts to (2,4).
*
* Read input file.
*
* # is comment to end of line
* = allowed between 1st and 2nd fields.
*
* Expect to see one line with 'MODE' as first field, followed by an
integer
* in the range 0-4 (default = 4).
*
* Expect to see two lines with 'LONG', 'LAT' followed by 1-3 fields.
* All numbers are floating point.
* DDD.ddd
* DDD MMM.mmm
* DDD MMM SSS.sss
*
* Expect to see one line with 'HT' as first field,
* followed by 1-2 fields. First is a number, the second is 'FT' or
'M'
* for feet or meters. HT is the height above the GPS ellipsoid.
* If the receiver reports height in both GPS and MSL, then we will
report
* the difference GPS-MSL on the clockstats file.
*
* There is an optional line, starting with DELAY, followed
* by 1 or two fields. The first is a number (a time) the second is
* 'MS', 'US' or 'NS' for miliseconds, microseconds or nanoseconds.
* DELAY is cable delay, typically a few tens of ns.
*
* There is an optional line, starting with OFFSET, followed
* by 1 or two fields. The first is a number (a time) the second is
* 'MS', 'US' or 'NS' for miliseconds, microseconds or nanoseconds.
* OFFSET is the offset of the PPS pulse from 0. (only fully
implemented
* with the PPSAPI, we need to be able to tell the Kernel about
this
* offset if the Kernel PLL is in use, but can only do this
presently
* when using the PPSAPI interface. If not using the Kernel PLL,
* then there is no problem.
*
* There is an optional line, with either ASSERT or CLEAR on it, which
* determine which transition of the PPS signal is used for timing by
the
* PPSAPI. If neither is present, then ASSERT is assumed.
* ASSERT/CLEAR can also be set with FLAG2 of the ntp.conf input.
* For Flag2, ASSERT=0, and hence is default.
*
* There is an optional line, with HARDPPS on it. Including this line
causes
* the PPS signal to control the kernel PLL.
* HARDPPS can also be set with FLAG3 of the ntp.conf input.
* For Flag3, 0 is disabled, and the default.
** There are three options that have to do with using the shared memory
option.
* First, to enable the option there must be a SHMEM line with a file
name.
* The file name is the file associated with the shared memory.
*
* In shared memory, there is one 'record' for each returned variable.
* For the @@Ea data there are three 'records' containing position data.
* There will always be data in the record corresponding to the '0D'
@@Ea record,
* and the user has a choice of filling the '3D' record by specifying
POSN3D,
* or the '2D' record by specifying POSN2D. In either case the '2D'
or '3D'
* record is filled once every 15s.
*
* Two additional variables that can be set are CHAN and TRAIM. These
should be
* set correctly by the code examining the @@Cj record, but we bring
them out here
* to allow the user to override either the # of channels, or the
existence of TRAIM.
* CHAN expects to be followed by in integer: 6, 8, or 12. TRAIM
expects to be
* followed by YES or NO.
*
* There is an optional line with MASK on it followed by one integer
field in the
* range 0 to 89. This sets the satellite mask angle and will
determine the minimum
* elevation angle for satellites to be tracked by the receiver. The
default value
* is 10 deg for the VP and 0 deg for all other receivers.
*
* So acceptable input would be
* # these are my coordinates (RWC)
* LON -106 34.610
* LAT 35 08.999
* HT 1589 # could equally well say HT 5215 FT
* DELAY 60 ns
*/
>
> [[ Im sending this to you and not to the list, feel free to post it if
> you want, but I syspect you can just make the corrections and repost
> your previous note ]]
>
> Reg.Clemens
> reg at dwf.com
Udo,
I have attached a diff as per the instructions on the wiki about contributing
documentation. This diff has modifications to reflect Reg's comments but it
does not include anything from the code comment.
Hal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LinuxPPS_NTPS_support.diff
Type: text/x-patch
Size: 14633 bytes
Desc: not available
Url : http://ml.enneenne.com/pipermail/linuxpps/attachments/20090218/267dc608/attachment-0001.bin
More information about the LinuxPPS
mailing list