From: Harlan Stenn Date: Thu, 17 Feb 2000 07:00:12 +0000 (-0000) Subject: ChangeLog, Oncore-SHMEM.htm, driver30.htm, refclock_oncore.c: X-Git-Tag: NTP_4_0_99_F~2 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=5271d3efe85a5fd8a167cf8f1603cab070d16bc1;p=thirdparty%2Fntp.git ChangeLog, Oncore-SHMEM.htm, driver30.htm, refclock_oncore.c: * ntpd/refclock_oncore.c: Cleanup/fixes * html/driver30.htm: Cleanup * html/Oncore-SHMEM.htm: Cleanup From: Reg Clemens bk: 38ab9c7cLXYdtnGQHBBYz4oJTEqTqw --- diff --git a/ChangeLog b/ChangeLog index bd230b922..b08d68d99 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,4 +1,9 @@ +2000-02-17 Harlan Stenn + * ntpd/refclock_oncore.c: Cleanup/fixes + * html/driver30.htm: Cleanup + * html/Oncore-SHMEM.htm: Cleanup + From: Reg Clemens 2000-02-16 Sven Dietrich diff --git a/html/Oncore-SHMEM.htm b/html/Oncore-SHMEM.htm index d4a65c466..3148f6a9a 100644 --- a/html/Oncore-SHMEM.htm +++ b/html/Oncore-SHMEM.htm @@ -16,8 +16,6 @@ Introduction In NMEA mode, the Oncore GPS receiver provides the user with the same information as other GPS receivers. In BINARY mode, it can provide a lot of additional information. -When using the Oncore GPS receiver with NTP, this additional information is usually -not available since the receiver is only talking to the oncore driver in NTPD.

In particular, you can ask for satellite positions, satellite health, signal levels, the ephemeris and the almanac, and you can set many operational parameters. @@ -25,19 +23,45 @@ In the case of the VP, you can get the pseudorange corrections necessary to act as a DGPS base station, and you can see the raw satellite data messages themselves.

-To make use of this information you will need an Oncore Reference Manual for the -Oncore GPS receiver that you have. The Manual for the VP only exists as a paper -document, the UT manuals are available as a pdf document online. -

+When using the Oncore GPS receiver with NTP, this additional information is usually +not available since the receiver is only talking to the oncore driver in NTPD. To make this information available for use in other programs, (say graphic displays of satellites positions, plots of SA, etc.), a shared memory interface (SHMEM) has been added to the refclock_oncore driver on those operating systems that support shared memory.

+To make use of this information you will need an Oncore Reference Manual for the +Oncore GPS receiver that you have. The Manual for the VP only exists as a paper +document, the UT manuals are available as a pdf document online. +

This interface was written by Poul-Henning Kamp (phk@FreeBSD.org), and modified by Reg Clemens (reg@dwf.com). The interface is known to work in FreeBSD, Linux, and Solaris.

+Activating the Interface +

+Although the Shared Memory Interface will be compiled into the Oncore driver +on those systems where Shared Memory is supported, to activate this interface you must +include a STATUS line in the /etc/ntp.oncore data file that looks like +
+        STATUS < file_name >
+
+Thus a line like +
+        STATUS /var/adm/ntpstats/ONCORE
+
+would be acceptable. +This file name will be used to access the Shared Memory. +

+In addition, one the two keywords Posn2D and Posn3D can be added to +see @@Ea records containing the 2D or 3D position of the station (see below). +Thus to activate the interface, and see 3D positions, something like +

+        STATUS /var/adm/ntpstats/ONCORE
+        Posn3D
+
+would be required. +

Storage of Messages in Shared Memory

With the shared memory interface, the oncore driver (refclock_oncore) allocates space @@ -68,7 +92,7 @@ if something like that were legal. That is, there are two bytes (caution, these may NOT be aligned with word boundaries, so the field needs to be treated as a pair of u_char), that contains the length of the next message. -This is followed by a u_char, a sequence number, that is incremented whenever a new message of +This is followed by a u_char sequence number, that is incremented whenever a new message of this type is received. This is followed by 'length' characters of the actual message.

@@ -82,35 +106,37 @@ The messages are recognized by reading the headers in the data itself, viz @@Ea

There are two special cases.

-(1) The almanac takes a total of 34 subrecords all starting with @@Cb.
-35 records are allocated. +(1) The almanac takes a total of 34 submessages all starting with @@Cb.
+35 slots are allocated in shared memory. Each @@Cb message is initially placed in the first of these locations, -and then later it is moved to the appropriate location for that sub-message. +and then later it is moved to the appropriate location for that submessage. The submessages can be distinguished by the first two characters following the @@Cb header, and new data is received only when the almanac changes.

-(2) The @@Ea record contains the satellite position, and are received 1/second. +(2) The @@Ea message contains the calculated location of the antenna, and is received +once per second. However, when in timekeeping mode, the receiver is normally put in 0D mode, with the -position fixed to get better accuracy, so the current position is not available. +position fixed, to get better accuracy. +In 0D mode no position is calculated.

-When the SHMEM option is active, one @@Ea record is hijacked each 15s, and the receiver -is put back in 3D mode so the the current location can be determined (for position determination, or for +When the SHMEM option is active, +and if one of Posn2D or Posn3D is specified, +one @@Ea record is hijacked each 15s, and the receiver +is put back in 2D/3D mode so the the current location can be determined (for position determination, or for tracking SA). -The timekeeping code is careful NOT to use the time associated with this (less accurate) 3D tick +The timekeeping code is careful NOT to use the time associated with this (less accurate) 2D/3D tick in its timekeeping functions.

-Following the initial @@Ea record are 3 subrecords for a total of four. +Following the initial @@Ea message are 3 additional slots for a total of four. As with the almanac, the first gets filled each time a new record becomes available, -Later in the code, it is distributed to the appropriate subrecord. -These records can be distinguished by different bit patterns in the last byte of the record. -Currently there -are subrecords for 0D, 2D, 3D, but the code only fills in the 0D and 3D positions at -present. +later in the code, the message is distributed to the appropriate slot. +The additional slots are for messages containing 0D, 2D and 3D positions. +These messages can be distinguished by different bit patterns in the last data byte of the record.

Opening the Shared Memory File

-The shared memory segment is accessed through a file name given on a ACCESS card in the -/etc/ntp.oncore input file. +The shared memory segment is accessed through a file name given on a ACCESS card in the +/etc/ntp.oncore input file. The following code could be used to open the Shared Memory Segment: 
@@ -205,24 +231,27 @@ The following code shows how to get to the individual records.
         }
-

The structure Hdr contains the Identifying string for each of the messages that we want to examine, and the name of a program to call when a new message of that type is arrives. -

The loop can be run every few seconds to check for new data. -

-There are two more complete examples -(one that that show satellite positions and the station position as affected by SA, and -another that computes the effective horizon by watching satellite tracks) that -will be found in the GNU-zipped tar file +

+Examples +

+There are two complete examples available. +The first plots satellite positions and the station position as affected by SA, and +keeps track of the mean station position, so you can run it for periods of days +to get a better station position. +The second shows the effective horizon by watching satellite tracks. +The examples will be found in the GNU-zipped tar file ftp://ftp.udel.edu/pub/ntp/software/OncorePlot.tar.gz.

-Try it, have fun. +Try the new interface, enjoy.

- reg@dwf.com -
+Reg.Clemens (reg@dwf.com), +Poul-Henning Kamp (phk@FreeBSD.org) +
diff --git a/html/driver30.htm b/html/driver30.htm index c32cc52af..cfe685510 100644 --- a/html/driver30.htm +++ b/html/driver30.htm @@ -145,7 +145,8 @@ Not used by this driver. Not used by this driver. Additional Information -

The driver was initially developed on FreeBSD, and has since been tested on Linux SunOS and Solaris. +

The driver was initially developed on FreeBSD, and has since been tested +on Linux, SunOS and Solaris.

There is a driver specific configuration file /etc/ntp.oncore that contains information on the startup mode, the location of the GPS diff --git a/ntpd/refclock_oncore.c b/ntpd/refclock_oncore.c index 7b05507cb..8c6e4183d 100644 --- a/ntpd/refclock_oncore.c +++ b/ntpd/refclock_oncore.c @@ -14,7 +14,7 @@ * * (UT) (VP) * COPYRIGHT 1991-1997 MOTOROLA INC. COPYRIGHT 1991-1996 MOTOROLA INC. - * SFTW P/N # 98-P36848P SFTW P/N # 98-P36830P + * SFTW P/N # 98-P36848P SFTW P/N # 98-P36830P * SOFTWARE VER # 2 SOFTWARE VER # 8 * SOFTWARE REV # 2 SOFTWARE REV # 8 * SOFTWARE DATE APR 24 1998 SOFTWARE DATE 06 Aug 1996 @@ -61,7 +61,7 @@ * copy of all types of messages we recognize. This file can be mmap(2)'ed * by monitoring and statistics programs. * - * See separate documentation for this option. + * See separate HTML documentation for this option. */ #ifdef HAVE_CONFIG_H @@ -181,6 +181,8 @@ struct instance { u_char En[70]; u_char Cj[300]; u_char shmem_first; + u_char shmem_reset; + u_char shmem_Posn; u_char As; u_char Ay; u_char Az; @@ -246,6 +248,8 @@ static struct msg_desc { { "Af", 15, 0, "" }, { "As", 20, oncore_msg_As, "" }, { "At", 8, oncore_msg_At, "" }, + { "Au", 12, 0, "" }, + { "Av", 8, 0, "" }, { "Aw", 8, 0, "" }, { "Ay", 11, oncore_msg_Ay, "" }, { "Az", 11, oncore_msg_Az, "" }, @@ -277,12 +281,15 @@ u_char oncore_cmd_Af[] = { 'A', 'f', 0,0,0,0, 0 }; static u_char oncore_cmd_At[] = { 'A', 't', 2 }; /* - * Position-Hold Position + * 0D/2D Position and Set. */ u_char oncore_cmd_As[] = { 'A', 's', 0,0,0,0, 0,0,0,0, 0,0,0,0, 0 }; u_char oncore_cmd_Asx[]= { 'A', 's', 0x7f, 0xff, 0xff, 0xff, 0x7f, 0xff, 0xff, 0xff, 0x7f, 0xff, 0xff, 0xff, 0xff }; +u_char oncore_cmd_Au[] = { 'A', 'u', 0,0,0,0,0 }; +u_char oncore_cmd_Av[] = { 'A', 'v', 0 }; + /* * Set to UTC time (not GPS). @@ -897,6 +904,10 @@ oncore_read_config( instance->assert = 1; } else if (!strncmp(cc, "CLEAR", 5)) { instance->assert = 0; + } else if (!strncmp(cc, "POSN2D", 6)) { + instance->shmem_Posn = 2; + } else if (!strncmp(cc, "POSN3D", 6)) { + instance->shmem_Posn = 3; } } fclose(fd); @@ -913,6 +924,11 @@ oncore_read_config( if (mode == 1 || mode == 3) instance->init_type++; } + + /* simplify SHMEM tests later */ + + if (!instance->shmem) + instance->shmem_Posn = 0; } @@ -1296,6 +1312,10 @@ oncore_msg_Cj( oncore_cmd_As[14] = instance->ss_ht_type; oncore_sendmsg(instance->ttyfd, oncore_cmd_As, sizeof oncore_cmd_As); + w32_buf(&oncore_cmd_Au[2], (int) instance->ss_ht); + oncore_cmd_Au[6] = instance->ss_ht_type; + oncore_sendmsg(instance->ttyfd, oncore_cmd_Au, sizeof oncore_cmd_Au); + instance->site_survey = ONCORE_SS_DONE; oncore_cmd_At[2] = 1; oncore_sendmsg(instance->ttyfd, oncore_cmd_At, sizeof oncore_cmd_At); @@ -1359,11 +1379,11 @@ oncore_msg_Ea( int i; i = 0; - if (instance->Ea[72]&010) /* 0D, Position Hold */ + if (instance->Ea[72]&0x8) /* 0D, Position Hold */ i = 1; - else if (instance->Ea[72]&020) /* 2D, Altitude Hold */ + else if (instance->Ea[72]&0x10) /* 2D, Altitude Hold */ i = 2; - else if (instance->Ea[72]&040) /* 3D fix */ + else if (instance->Ea[72]&0x20) /* 3D fix */ i = 3; if (i) { i *= 79; @@ -1375,7 +1395,7 @@ oncore_msg_Ea( /* When we have an almanac, start the En messages */ if (instance->o_state == ONCORE_ALMANAC) { - if ((instance->Ea[72] & 1)) { + if ((instance->Ea[72] & 0x1)) { if (debug) printf("ONCORE: waiting for almanac\n"); return; @@ -1430,26 +1450,28 @@ oncore_msg_Ea( instance->pp->minute = buf[9]; instance->pp->second = buf[10]; -#if 1 - /* every 15s, steal one 'tick' to get 3D posn */ - - if (instance->site_survey != ONCORE_SS_SW) { /* dont screw up the HWSS by changing mode */ - static int reset; + /* every 15s, steal one 'tick' to get 2D or 3D posn if asked for */ + if (instance->shmem_Posn && instance->site_survey != ONCORE_SS_SW) { /* dont screw up the HWSS by changing mode */ if (instance->pp->second%15 == 3) { /* start the sequence */ - reset = 1; - oncore_cmd_At[2] = 0; - oncore_sendmsg(instance->ttyfd, oncore_cmd_At, sizeof oncore_cmd_At); - } else if (reset) { - reset = 0; - oncore_cmd_At[2] = 1; + instance->shmem_reset = 1; + oncore_cmd_At[2] = 0; /* out of 0D mode, to 3D mode */ + oncore_sendmsg(instance->ttyfd, oncore_cmd_At, sizeof oncore_cmd_At); + if (instance->shmem_Posn == 2) { + oncore_cmd_Av[2] = 1; /* into 2D mode */ + oncore_sendmsg(instance->ttyfd, oncore_cmd_Av, sizeof oncore_cmd_Av); + } + } else if (instance->shmem_reset || !(instance->Ea[72] & 0x8)) { + instance->shmem_reset = 0; + if (instance->Ea[72] & 0x10) { + oncore_cmd_Av[2] = 0; /* out of 2D mode */ + oncore_sendmsg(instance->ttyfd, oncore_cmd_Av, sizeof oncore_cmd_Av); + } + oncore_cmd_At[2] = 1; /* into 0D mode */ oncore_sendmsg(instance->ttyfd, oncore_cmd_At, sizeof oncore_cmd_At); } - - if ((instance->site_survey == ONCORE_SS_DONE) && !(instance->Ea[72]&010)) - return; } -#endif + if (instance->site_survey != ONCORE_SS_SW) return; @@ -1457,11 +1479,6 @@ oncore_msg_Ea( * We have to average our own position for the Position Hold Mode */ - /* We only take PDOP/3D fixes */ - - if (instance->Ea[37] & 1) - return; - /* Not if poor geometry or less than 3 sats */ if (instance->Ea[72] & 0x52) @@ -1494,6 +1511,10 @@ oncore_msg_Ea( oncore_cmd_As[14] = 0; oncore_sendmsg(instance->ttyfd, oncore_cmd_As, sizeof oncore_cmd_As); + w32_buf(&oncore_cmd_Au[2], (int) instance->ss_ht); + oncore_cmd_Au[6] = 0; + oncore_sendmsg(instance->ttyfd, oncore_cmd_Au, sizeof oncore_cmd_Au); + oncore_cmd_At[2] = 1; oncore_sendmsg(instance->ttyfd, oncore_cmd_At, sizeof oncore_cmd_At); record_clock_stats(&(instance->peer->srcadr), "Now in 0D mode"); @@ -1534,7 +1555,7 @@ oncore_msg_En( #endif #endif /* ! HAVE_PPS_API */ - if ((instance->site_survey == ONCORE_SS_DONE) && !(instance->Ea[72]&010)) + if ((instance->site_survey == ONCORE_SS_DONE) && !(instance->Ea[72]&0x8)) return; if (instance->o_state != ONCORE_RUN) return; @@ -1543,7 +1564,7 @@ oncore_msg_En( /* Don't do anything without an almanac to define the GPS->UTC delta */ - if (instance->Ea[72] & 1) + if (instance->Ea[72] & 0x1) return; /* If Time RAIM doesn't like it, don't trust it */ @@ -1565,7 +1586,7 @@ oncore_msg_En( tsp = &pps_i.assert_timestamp; if (debug > 2) - printf("ONCORE: serial/j (%d, %d) %ld.%09ld\n", + printf("ONCORE: serial/j (%lu, %d) %ld.%09ld\n", pps_i.assert_sequence, j, tsp->tv_sec, tsp->tv_nsec); if (pps_i.assert_sequence == j) { @@ -1577,7 +1598,7 @@ oncore_msg_En( tsp = &pps_i.clear_timestamp; if (debug > 2) - printf("ONCORE: serial/j (%d, %d) %ld.%09ld\n", + printf("ONCORE: serial/j (%lu, %d) %ld.%09ld\n", pps_i.clear_sequence, j, tsp->tv_sec, tsp->tv_nsec); if (pps_i.clear_sequence == j) {