Re: [Gpsd-commit-watch] r4727 - trunk

[Jeff Francis]

/bin/bash ./libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H
-I.     -g -O2 -Wall -Wcast-align -Wmissing-declarations
-Wmissing-prototypes -Wstrict-prototypes -Wpointer-arith -Wreturn-type
-D_GNU_SOURCE  -MT rtcm3.lo -MD -MP -MF .deps/rtcm3.Tpo -c -o rtcm3.lo
rtcm3.c
 gcc -DHAVE_CONFIG_H -I. -g -O2 -Wall -Wcast-align
-Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes
-Wpointer-arith -Wreturn-type -D_GNU_SOURCE -MT rtcm3.lo -MD -MP -MF
.deps/rtcm3.Tpo -c rtcm3.c  -fPIC -DPIC -o .libs/rtcm3.o
rtcm3.c:189: error: width of 'ecef_x' exceeds its type
rtcm3.c:194: error: width of 'ecef_y' exceeds its type
rtcm3.c:197: error: width of 'ecef_z' exceeds its type
rtcm3.c:210: error: width of 'ecef_x' exceeds its type
rtcm3.c:215: error: width of 'ecef_y' exceeds its type
rtcm3.c:218: error: width of 'ecef_z' exceeds its type
make[1]: *** [rtcm3.lo] Error 1
make[1]: Leaving directory `/usr/local/src/gpsd'
make: *** [all] Error 2
jfrancis@truck:/usr/local/src/gpsd$ uname -a
Linux truck 2.6.22-15-generic #1 SMP Tue Jun 10 09:21:34 UTC 2008 i686
GNU/Linux
jfrancis@truck:/usr/local/src/gpsd$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=7.10
DISTRIB_CODENAME=gutsy
DISTRIB_DESCRIPTION="Ubuntu 7.10"
jfrancis@truck:/usr/local/src/gpsd$




esr at BerliOS wrote:

> Author: esr
> Date: 2008-07-10 16:28:54 +0200 (Thu, 10 Jul 2008)
> New Revision: 4727
>
> Added:
>    trunk/rtcm3.c
> Modified:
>    trunk/Makefile.am
>    trunk/drivers.c
>    trunk/gps.h
>    trunk/gpsd.h-tail
> Log:
> Rudimentary RTCM104v3 support compiles and splints clean.  
> BNow to actually test it...
>
>
> Modified: trunk/Makefile.am
> ===================================================================
> --- trunk/Makefile.am 2008-07-10 13:13:02 UTC (rev 4726)
> +++ trunk/Makefile.am 2008-07-10 14:28:54 UTC (rev 4727)
> @@ -129,6 +129,7 @@
>   report.c \
>   isgps.c \
>   rtcm2.c \
> + rtcm3.c \
>   srecord.c \
>   bsd-base64.c \
>   strl.c \
>
> Modified: trunk/drivers.c
> ===================================================================
> --- trunk/drivers.c 2008-07-10 13:13:02 UTC (rev 4726)
> +++ trunk/drivers.c 2008-07-10 14:28:54 UTC (rev 4727)
> @@ -786,7 +786,7 @@
>  
>  static gps_mask_t rtcm104v3_analyze(struct gps_device_t *session)
>  {
> -    // FIXME: Add a real unpacking function
> +    rtcm3_unpack(&session->gpsdata.rtcm3, (char *)session->packet.inbuffer);
>      gpsd_report(LOG_RAW, "RTCM 3.x packet type 0x%02x length %d words: %s\n",
>   session->gpsdata.rtcm3.type,
>   session->gpsdata.rtcm3.length,
>
> Modified: trunk/gps.h
> ===================================================================
> --- trunk/gps.h 2008-07-10 13:13:02 UTC (rev 4726)
> +++ trunk/gps.h 2008-07-10 14:28:54 UTC (rev 4727)
> @@ -365,7 +365,8 @@
>      unsigned char iode;
>      /* ephemeris fields, not scaled */
>      unsigned int t_sub_oc;
> -    unsigned char a_sub_f2;
> +    signed int a_sub_f2;
> +    signed int a_sub_f1;
>      signed int a_sub_f0;
>      unsigned int iodc;
>      signed int C_sub_rs;
>
> Modified: trunk/gpsd.h-tail
> ===================================================================
> --- trunk/gpsd.h-tail 2008-07-10 13:13:02 UTC (rev 4726)
> +++ trunk/gpsd.h-tail 2008-07-10 14:28:54 UTC (rev 4727)
> @@ -114,6 +114,8 @@
>  extern bool rtcm2_repack(struct rtcm2_t *, isgps30bits_t *);
>  extern void rtcm2_output_magnavox(isgps30bits_t *, FILE *);
>  
> +extern void rtcm3_unpack(/*@out@*/struct rtcm3_t *, char *);
> +
>  /* Next, declarations for the core library... */
>  
>  /* factors for converting among confidence interval units */
>
> Added: trunk/rtcm3.c
> ===================================================================
> --- trunk/rtcm3.c 2008-07-10 13:13:02 UTC (rev 4726)
> +++ trunk/rtcm3.c 2008-07-10 14:28:54 UTC (rev 4727)
> @@ -0,0 +1,451 @@
> +/*****************************************************************************
> +
> +This is a decoder for RTCM-104 3.x, a serial protocol used for
> +broadcasting pseudorange corrections from differential-GPS reference
> +stations.  The applicable specification is RTCM 10403.1: RTCM Paper
> +177-2006-SC104-STD.  This obsolesces the esrlier RTCM-104 2.x
> +specifications. The specification document is proprietary; ordering
> +instructions are accessible from <http://www.rtcm.org/>
> +under "Publications".  
> +
> +Unike the RTCM 2.x protocol, RTCM3.x does not use the strange
> +sliding-bit-window IS-GPS-200 protocol as a transport layer, but is a
> +self-contained byte-oriented packet protocol.  Packet recognition is
> +handled in the GPSD packet-getter state machine; this code is
> +concerned with unpacking the packets into well-behaved C structures,
> +coping with odd field lengths and fields that may overlap byte
> +boudaries.  These report structures live in gps.h.
> +
> +Note that the unpacking this module does is probably useful only for
> +RTCM reporting and diagnostic tools.  It is not necessary when
> +passing RTCM corrections to a GPS, which normally should just be
> +passed an entire correction packet for processing by their internal
> +firmware.
> +
> +*****************************************************************************/
> +
> +#include <sys/types.h>
> +#include <unistd.h>
> +#include <stdlib.h>
> +#include <string.h>
> +#include <stdbool.h>
> +#include <stdio.h>
> +#include <assert.h>
> +#include <arpa/inet.h> /* for ntohl(3) and friends */
> +
> +#include "gpsd_config.h"
> +#include "gpsd.h"
> +
> +#ifdef RTCM104V3_ENABLE
> +
> +/*
> + * Structures for interpreting words in an RTCM-104 3.x packet Note,
> + * these structures are overlayed on the raw packet data in order to
> + * decode them into bitfields; this will fail horribly if your C
> + * compiler ever introduces padding between or before bit fields, or
> + * between 8-bit-aligned bitfields and character arrays.
> + *
> + * (In practice, the only class of machines on which this is likely
> + * to fail are word-aligned architectures without barrel shifters.
> + * Very few of these are left in 2008.)
> + */
> +#pragma pack(1) /* try to tell the compiler not to pad at all */
> +
> +/*
> + * These structures mostly parallel the rtcm3 report structures in
> + * gps.h.  The differences are that some structures have to be twinned
> + * because the GPS/Galileo versions can't have the extra channel field
> + * in them that the GLONASS version does, or because some packed bit
> + * lengths differ.
> + *
> + * The bitfield widths
> + */
> +
> +struct rtcm3_msg_rtk_hdr_t { /* header data from 1001, 1002, 1003, 1004 */
> +    uint station_id:12; /* Reference Station ID (DF003) */
> +    uint time:30; /* GPS Epoch Time (TOW) (DF004) in ms */
> +    uint sync:1; /* Synchronous GNSS Message Flag (DF005) */
> +    uint satcount:5; /* # Satellite Signals Processed (DF006) */
> +    uint smoothing:1; /* Divergence-free Smoothing Indicator (DF007)*/
> +    uint interval:3; /* Smoothing Interval (DF008) */
> +};
> +
> +struct rtcm3_msg_basic_rtk_t {
> +    uint indicator:1; /* Indicator (DF010) */
> +    uint pseudorange:24; /* Pseudorange (DF011) */
> +    uint rangediff:20; /* PhaseRange – Pseudorange in meters (DF012) */
> +    uint locktime:7; /* Lock time Indicator (DF013) */
> +};
> +
> +struct rtcm3_msg_t_extended_rtk {
> +    uint indicator:1; /* Indicator (DF010) */
> +    uint pseudorange:24; /* Pseudorange (DF011) */
> +    uint rangediff:20; /* PhaseRange – Pseudorange in meters (DF012) */
> +    uint locktime:7; /* Lock time Indicator (DF013) */
> +    uint ambiguity:8; /* Pseudorange Modulus Ambiguity (DF014)*/
> +    uint CNR:8; /* Carrier-to-Noise Ratio (DF015) */
> +};
> +
> +struct rtcm3_msg_glonass_rtk_hdr_t { /* header data from 1009, 1010, 1011, 1012 */
> +    uint station_id:12; /* Reference Station ID (DF003) */
> +    uint time:27; /* GLONASS Epoch Time in ms (DF034) */
> +    uint sync:1; /* Synchronous GNSS Message Flag (DF005) */
> +    uint satcount:5; /* # Satellite Signals Processed (DF006) */
> +    uint smoothing:1; /* Divergence-free Smoothing Indicator (DF007)*/
> +    uint interval:3; /* Smoothing Interval (DF008) */
> +};
> +
> +struct rtcm3_msg_basic_glonass_rtk_t {
> +    uint indicator:1; /* Indicator (DF039) */
> +    uint channel:5; /* Satellite Frequency Channel Number (DF040)*/
> +    uint pseudorange:25; /* Pseudorange (DF041) */
> +    uint rangediff:20; /* PhaseRange – Pseudorange in meters (DF042)*/
> +    uint locktime:7; /* Lock time Indicator (DF043) */
> +};
> +
> +struct rtcm3_msg_extended_glonass_rtk_t {
> +    uint indicator:1; /* Indicator (DF010) */
> +    uint channel:5; /* Satellite Frequency Channel Number (DF040)*/
> +    uint pseudorange:25; /* Pseudorange (DF041) */
> +    uint rangediff:20; /* PhaseRange – Pseudorange in meters (DF042) */
> +    uint locktime:7; /* Lock time Indicator (DF043) */
> +    uint ambiguity:8; /* Pseudorange Modulus Ambiguity (DF044)*/
> +    uint CNR:8; /* Carrier-to-Noise Ratio (DF045) */
> +};
> +
> +struct rtcm3_msg_network_rtk_header_t {
> +    uint msgnum:12; /* Message number (DF002) */
> +    uint network_id:8; /* Network ID (DF059) */
> +    uint subnetwork_id:4; /* Subnetwork ID (DF072) */
> +    uint time:23; /* GPS Epoch Time (TOW) in ms (DF065) */
> +    uint multimesg:1; /* GPS Multiple Message Indicator (DF066) */
> +    uint master_id:12; /* Master Reference Station ID (DF060) */
> +    uint aux_id:12; /* Auxilary Reference Station ID (DF061) */
> +    uint satcount:4; /* # of GPS satellites (DF067) */
> +};
> +
> +struct rtcm3_msg_correction_diff_t {
> +    uint ident:6; /* satellite ID (DF068) */
> +    uint ambiguity:2; /* Ambiguity status flag (DF074) */
> +    uint nonsync:3; /* Non Sync Count (DF075) */
> +    int geometric_diff:17; /* Geometric Carrier Phase
> +   Correction Difference (DF070) */
> +    uint iode:8; /* GPS IODE (DF071) */
> +    uint ionospheric_diff:17; /* Ionospheric Carrier Phase
> +   Correction Difference (DF069) */
> +};
> +
> +struct rtcm3_msg_t {
> +    /* frame header */
> +    uint preamble:8; /* fixed, 0xD3 */
> +    uint version:6; /* reserved version field, fixed to 0 in 3.1 */
> +    uint length:10; /* payload length, inclusive of checksum */
> +
> +    /* type field */
> +    uint type:12; /* RTCM3 message type */
> +
> +    union {
> + /* 1001-1013 were present in the 3.0 version */
> + struct {
> +    struct rtcm3_msg_rtk_hdr_t header;
> +    struct {
> + uint satellite_id:6; /* GPS satellite ID (DF009) */
> + struct rtcm3_msg_basic_rtk_t L1;
> +    } rtk_data[RTCM3_MAX_SATELLITES];
> + } rtcm3_msg_t_1001;
> + struct {
> +    struct rtcm3_msg_rtk_hdr_t header;
> +    struct {
> + uint satellite_id:6; /* GPS satellite ID (DF009) */
> + struct rtcm3_msg_t_extended_rtk L1;
> +    } rtk_data[RTCM3_MAX_SATELLITES];
> + } rtcm3_msg_t_1002;
> + struct {
> +    struct rtcm3_msg_rtk_hdr_t header;
> +    struct {
> + uint satellite_id:6; /* GPS satellite ID (DF009) */
> + struct rtcm3_msg_basic_rtk_t L1;
> + struct rtcm3_msg_basic_rtk_t L2;
> +    } rtk_data[RTCM3_MAX_SATELLITES];
> + } rtcm3_msg_t_1003;
> + struct {
> +    struct rtcm3_msg_rtk_hdr_t header;
> +    struct {
> + uint satellite_id:6; /* GPS satellite ID (DF009) */
> + struct rtcm3_msg_t_extended_rtk L1;
> + struct rtcm3_msg_t_extended_rtk L2;
> +    } rtk_data[RTCM3_MAX_SATELLITES];
> + } rtcm3_msg_t_1004;
> + struct {
> +    uint station_id:12; /* Reference Station ID (DF003) */
> +    uint reserved1:6; /* Reserved for ITRF Realization
> +   Year (DF021) */
> +    uint gps_indicator:1; /* GPS Indicator (DF022) */
> +    uint glonass_indicator:1; /* GLONASS Indicator (DF023) */
> +    uint galileo_indicator:1; /* Reserved for Galileo Indicator
> +   (DF024) */
> +    uint reference_station:1; /* Reference Station Indicator
> +   (DF141) */
> +    long int ecef_x:38; /* Antenna Reference point ECEF-X
> +   (DF025) */
> +    uint single_receiver:1; /* Single Receiver Oscillator Indicator
> +   (DF142) */
> +    uint reserved2:1; /* Reserved (DF001) */
> +    long int ecef_y:38; /* Antenna Reference point ECEF-X
> +   (DF026) */
> +    uint reserved3:1; /* Reserved (DF001) */
> +    long int ecef_z:38; /* Antenna Reference point ECEF-Z
> +   (DF026) */
> + } rtcm3_msg_t_1005;
> + struct {
> +    uint station_id:12; /* Reference Station ID (DF003) */
> +    uint reserved1:6; /* Reserved for ITRF Realization
> +   Year (DF021) */
> +    uint gps_indicator:1; /* GPS Indicator (DF022) */
> +    uint glonass_indicator:1; /* GLONASS Indicator (DF023) */
> +    uint galileo_indicator:1; /* Reserved for Galileo Indicator
> +   (DF024) */
> +    uint reference_station:1; /* Reference Station Indicator
> +   (DF141) */
> +    long int ecef_x:38; /* Antenna Reference point ECEF-X
> +   (DF025) */
> +    uint single_receiver:1; /* Single Receiver Oscillator Indicator
> +   (DF142) */
> +    uint reserved2:1; /* Reserved (DF001) */
> +    long int ecef_y:38; /* Antenna Reference point ECEF-X
> +   (DF026) */
> +    uint reserved3:1; /* Reserved (DF001) */
> +    long int ecef_z:38; /* Antenna Reference point ECEF-Z
> +   (DF026) */
> +    uint height:16; /* Antenna height (DF028) */
> + } rtcm3_msg_t_1006;
> + struct {
> +    uint station_id:12; /* Reference Station ID (DF003) */
> +    uint counter:8; /* Descriptor Counter (DF029) */
> +    /*
> +     * The spec designers screwed up here; they put the Setup
> +     * ID field after the variable-length descriptor string so
> +     * it doesn't have a fixed bit offset from start of
> +     * message.  The unpacking code will have to mine the
> +     * byte out of the part of the data that descriptor[] overlays.
> +     */
> +    char descriptor[RTCM3_MAX_DESCRIPTOR+2]; /* Descriptor (DF030) */
> + } rtcm3_msg_t_1007;
> + struct {
> +    /*
> +     * And a similar design error here. There are actually two
> +     * variable-length descriptors in this message and two fixed-
> +     * length fields between them.
> +     */
> +    uint station_id:12; /* Reference Station ID (DF003) */
> +    uint counter:8; /* Descriptor Counter (DF029) */
> +    char rawdata[64];
> + } rtcm3_msg_t_1008;
> + struct {
> +    struct rtcm3_msg_glonass_rtk_hdr_t header;
> +    struct {
> + uint satellite_id:6; /* GLONASS Satellite ID (DF038) */
> + struct rtcm3_msg_basic_glonass_rtk_t L1;
> +    } rtk_data[RTCM3_MAX_SATELLITES];
> + } rtcm3_msg_t_1009;
> + struct {
> +    struct rtcm3_msg_glonass_rtk_hdr_t header;
> +    struct {
> + uint satellite_id:6; /* GLONASS Satellite ID (DF038) */
> + struct rtcm3_msg_extended_glonass_rtk_t L1;
> +    } rtk_data[RTCM3_MAX_SATELLITES];
> + } rtcm3_msg_t_1010;
> + struct {
> +    struct rtcm3_msg_glonass_rtk_hdr_t header;
> +    struct {
> + uint satellite_id:6; /* GLONASS Satellite ID (DF038) */
> + struct rtcm3_msg_extended_glonass_rtk_t L1;
> + struct rtcm3_msg_extended_glonass_rtk_t L2;
> +    } rtk_data[RTCM3_MAX_SATELLITES];
> + } rtcm3_msg_t_1011;
> + struct {
> +    struct rtcm3_msg_glonass_rtk_hdr_t header;
> +    struct {
> + uint satellite_id:6; /* GLONASS Satellite ID (DF038) */
> + struct rtcm3_msg_extended_glonass_rtk_t L1;
> + struct rtcm3_msg_extended_glonass_rtk_t L2;
> +    } rtk_data[RTCM3_MAX_SATELLITES];
> + } rtcm3_msg_t_1012;
> + struct {
> +    uint msgnum:12; /* Message number (DF002) */
> +    uint station_id:12; /* Reference Station ID (DF003) */
> +    uint mjd:16; /* Modified Julian Day (MJD) Number
> +   (DF051)*/
> +    uint sod:17; /* Seconds of Day (UTC) (DF052) */
> +    uint ncount:5; /* Count of announcements (DF053) */
> +    uint leapsecs:8; /* Leap Seconds, GPS-UTC (DF053) */
> +    struct {
> + uint id:12; /* ID (DF055) */
> + uint sync:1; /* Sync flag (DF056) */
> + uint interval:16; /* transmission interval (DF057) */
> +    } announcements[RTCM3_MAX_ANNOUNCEMENTS];
> + } rtcm3_msg_t_1013;
> + /* 1014-1017 were added in the 3.1 version */
> + struct {
> +    uint msgnum:12; /* Message number (DF002) */
> +    uint network_id:8; /* Network ID (DF059) */
> +    uint subnetwork_id:8; /* Network ID (DF072) */
> +    uint stationcount:5; /* # auxiliary stations transmitted
> +   (DF058)*/
> +    uint master_id:12; /* Master Reference Station ID
> +   (DF060) */
> +    uint aux_id:12; /* Auxilary Reference Station ID
> +  (DF061) */
> +    int d_lat:20; /* Aux-Master Delta Latitude (DF062) */
> +    int d_lon:21; /* Aux-Master Delta Longitude (DF063)*/
> +    int d_alt:23; /* Aux-Master Delta Height (DF064) */
> + } rtcm3_msg_t_1014;
> + struct {
> +    struct rtcm3_msg_network_rtk_header_t header;
> +    struct {
> + uint ident:6; /* satellite ID (DF068) */
> + uint ambiguity:2; /* Ambiguity status flag (DF074) */
> + uint nonsync:3; /* Non Sync Count (DF075) */
> + uint ionospheric_diff:17; /* Ionospheric Carrier Phase
> +   Correction Difference
> +   (DF069) */
> +    } corrections[RTCM3_MAX_SATELLITES];
> + } rtcm3_msg_t_1015;
> + struct {
> +    struct rtcm3_msg_network_rtk_header_t header;
> +    struct {
> + uint ident:6; /* satellite ID (DF068) */
> + uint ambiguity:2; /* Ambiguity status flag (DF074) */
> + uint nonsync:3; /* Non Sync Count (DF075) */
> + int geometric_diff:17; /* Geometric Carrier Phase
> +   Correction Difference (DF070) */
> + uint iode:8; /* GPS IODE (DF071) */
> +    } corrections[RTCM3_MAX_SATELLITES];
> + } rtcm3_msg_t_1016;
> + struct {
> +    struct rtcm3_msg_network_rtk_header_t header;
> +    struct {
> + uint ident:6; /* satellite ID (DF068) */
> + uint ambiguity:2; /* Ambiguity status flag (DF074) */
> + uint nonsync:3; /* Non Sync Count (DF075) */
> + int geometric_diff:17; /* Geometric Carrier Phase
> +   Correction Difference (DF070) */
> + uint iode:8; /* GPS IODE (DF071) */
> + uint ionospheric_diff:17; /* Ionospheric Carrier Phase
> +   Correction Difference
> +   (DF069) */
> +    } corrections[RTCM3_MAX_SATELLITES];
> + } rtcm3_msg_t_1017;
> + struct {
> +    uint msgnum:12; /* Message number (DF002) */
> +    uint ident:6; /* Satellite ID (DF009) */
> +    uint week:10; /* GPS Week Number (DF076) */
> +    uint sv_accuracy; /* GPS SV ACCURACY (DF077) */
> +    uint code:2; /* GPS CODE ON L2 (DF078) */
> +    uint idot:14; /* GPS IDOT (DF079) */
> +    uint iode; /* GPS IODE (DF071) */
> +    /* ephemeris fields, not scaled */
> +    uint t_sub_oc:16;
> +    signed int a_sub_f2:8;
> +    signed int a_sub_f1:16;
> +    signed int a_sub_f0:22;
> +    uint iodc:10;
> +    signed int C_sub_rs:16;
> +    signed int delta_sub_n:16;
> +    signed int M_sub_0:32;
> +    signed int C_sub_uc:16;
> +    uint e:32;
> +    signed int C_sub_us:16;
> +    uint sqrt_sub_A:32;
> +    uint t_sub_oe:16;
> +    signed int C_sub_ic:16;
> +    signed int OMEGA_sub_0:32;
> +    signed int C_sub_is:16;
> +    signed int i_sub_0:32;
> +    signed int C_sub_rc:16;
> +    signed int argument_of_perigee:32;
> +    signed int omegadot:24;
> +    signed int t_sub_GD:8;
> +    uint sv_health:6;
> +    uint P_data:1;
> +    uint fit_interval:1;
> + } rtcm3_msg_t_1019;
> + struct {
> +    uint msgnum:12; /* Message number */
> +    uint ident:6; /* Satellite ID */
> +    uint channel:5; /* Satellite Frequency Channel Number */
> +    /* ephemeris fields, not scaled */
> +    uint C_sub_n1;
> +    uint health_avAilability_indicator:1;
> +    uint P1:2;
> +    unsigned short t_sub_k:12;
> +    uint msb_of_B_sub_n:1;
> +    uint P2:1;
> +    uint t_sub_b:7;
> +    signed int x_sub_n_t_of_t_sub_b_prime:24;
> +    signed int x_sub_n_t_of_t_sub_b:27;
> +    signed int x_sub_n_t_of_t_sub_b_prime_prime:5;
> +    signed int y_sub_n_t_of_t_sub_b_prime:24;
> +    signed int y_sub_n_t_of_t_sub_b:27;
> +    signed int y_sub_n_t_of_t_sub_b_prime_prime:5;
> +    signed int z_sub_n_t_of_t_sub_b_prime:24;
> +    signed int z_sub_n_t_of_t_sub_b:27;
> +    signed int z_sub_n_t_of_t_sub_b_prime_prime:5;
> +    uint P3:1;
> +    signed int gamma_sub_n_of_t_sub_b:11;
> +    uint MP:2;
> +    uint Ml_n:1;
> +    signed int tau_n_of_t_sub_b:22;
> +    signed int M_delta_tau_sub_n:5;
> +    uint E_sub_n:5;
> +    uint MP4:1;
> +    uint MF_sub_T:4;
> +    uint MN_sub_T:11;
> +    uint MM:2;
> +    uint additioinal_data_availability:1;
> +    uint N_sup_A:11;
> +    uint tau_sub_c:32;
> +    uint M_N_sub_4:5;
> +    signed int M_tau_sub_GPS:22;
> +    uint M_l_sub_n:1;
> +    //uint reserved:7;
> + } rtcm3_msg_t_1020;
> + struct {
> +    uint msgnum:12; /* Message number (DF002) */
> +    uint station_id:12; /* Reference Station ID (DF003) */
> +    uint mjd:16; /* Modified Julian Day (MJD) Number
> +   (DF051) */
> +    uint sod:17; /* Seconds of Day (UTC) (DF052) */
> +    uint len:7; /* # Chars to follow (DF138) */
> +    uint unicode_units:8; /* # Unicode units (DF139) */
> +    unsigned char text[128];
> + } rtcm3_msg_t_1029;
> +    };
> +};
> +
> +/* scaling constants for RTCM3 real number types */
> +#define PSEUDORANGE_RESOLUTION 0.2 /* DF011 */
> +#define PSEUDORANGE_DIFF_RESOLUTION 0.0005 /* DF012 */
> +#define CARRIER_NOISE_RATIO_UNITS 0.25 /* DF015 */
> +#define ANTENNA_HEIGHT_RESOLUTION 0.0001 /* DF025-027 */
> +#define ANTENNA_DEGREE_RESOLUTION 25e-6 /* DF062 */
> +#define GPS_EPOCH_TIME_RESOLUTION 0.1 /* DF065 */
> +#define PHASE_CORRECTION_RESOLUTION 0.5 /* DF069-070 */
> +
> +/* Other magic values */
> +#define INVALID_PSEUDORANGE 0x80000 /* DF012 */
> +
> +void rtcm3_unpack(/*@out@*/struct rtcm3_t *tp, char *buf)
> +/* break out the raw bits into the scaled report-structure fields */
> +{
> +    struct rtcm3_msg_t *msg = (struct rtcm3_msg_t *)buf;
> +
> +    assert(msg->preamble == 0xD3);
> +    assert(msg->version == 0x00);
> +    tp->type = msg->type;
> +    tp->length = msg->length;
> +
> +    // FIXME: Decoding of packet content goes here
> +}
> +
> +#endif /* RTCM104V3_ENABLE */
>
> _______________________________________________
> Gpsd-commit-watch mailing list
> Gpsd-commit-watch@...
> https://lists.berlios.de/mailman/listinfo/gpsd-commit-watch
>  

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Eric S. Raymond-2]

Jeff Francis <jeff@...>:
> rtcm3.c:189: error: width of 'ecef_x' exceeds its type
> rtcm3.c:194: error: width of 'ecef_y' exceeds its type
> rtcm3.c:197: error: width of 'ecef_z' exceeds its type
> rtcm3.c:210: error: width of 'ecef_x' exceeds its type
> rtcm3.c:215: error: width of 'ecef_y' exceeds its type
> rtcm3.c:218: error: width of 'ecef_z' exceeds its type

Hm.  Are you on a 32-bit machine?
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Jeff Francis]

  Yep.

Eric S. Raymond wrote:
> Jeff Francis <jeff@...>:
>> rtcm3.c:189: error: width of 'ecef_x' exceeds its type
>> rtcm3.c:194: error: width of 'ecef_y' exceeds its type
>> rtcm3.c:197: error: width of 'ecef_z' exceeds its type
>> rtcm3.c:210: error: width of 'ecef_x' exceeds its type
>> rtcm3.c:215: error: width of 'ecef_y' exceeds its type
>> rtcm3.c:218: error: width of 'ecef_z' exceeds its type
>
> Hm.  Are you on a 32-bit machine?

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Chris Kuethe]

reproducible. i'll make 'em long-long and add a configure test to
require 64-bit long-longs (which we already assume in bits.h)

On Thu, Jul 10, 2008 at 12:31 PM, Jeff Francis <jeff@...> wrote:

>  Yep.
>
> Eric S. Raymond wrote:
>> Jeff Francis <jeff@...>:
>>> rtcm3.c:189: error: width of 'ecef_x' exceeds its type
>>> rtcm3.c:194: error: width of 'ecef_y' exceeds its type
>>> rtcm3.c:197: error: width of 'ecef_z' exceeds its type
>>> rtcm3.c:210: error: width of 'ecef_x' exceeds its type
>>> rtcm3.c:215: error: width of 'ecef_y' exceeds its type
>>> rtcm3.c:218: error: width of 'ecef_z' exceeds its type
>>
>> Hm.  Are you on a 32-bit machine?
>
> _______________________________________________
> Gpsd-dev mailing list
> Gpsd-dev@...
> https://lists.berlios.de/mailman/listinfo/gpsd-dev
>

--
GDB has a 'break' feature; why doesn't it have 'fix' too?
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Eric S. Raymond-2]

Chris Kuethe <chris.kuethe@...>:
> reproducible. i'll make 'em long-long and add a configure test to
> require 64-bit long-longs (which we already assume in bits.h)

OK, that's good.  I'll add an appropriate portability warning to the
header comment
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Matthias Urlichs]

Hi,

one of the missing rtcm3 bits seems to be "teach ntrip.c about it". ;-)

The other bit is documentation. Does gpsd forward the RTCM stream
to my GPS receiver? (What if the thing uses a different serial port for
that?) And/or does it apply RTCM corrections itself? if both, how does
it decide?

Anyway, one option I'd also like to have is to forward the raw RTCM
stream somewhere. (Some receivers use a separate serial port for that.)

--
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@...
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
Her lips are roses overwashed with dew.
                                        -- Greene
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Eric S. Raymond-2]

Matthias Urlichs <smurf@...>:
> one of the missing rtcm3 bits seems to be "teach ntrip.c about it". ;-)

OK, what should ntrip.c do?
 
> The other bit is documentation. Does gpsd forward the RTCM stream
> to my GPS receiver? (What if the thing uses a different serial port for
> that?) And/or does it apply RTCM corrections itself? if both, how does
> it decide?

At the moment, yes.  Any RTCM2 stream received is forwarded to all attached
devices with types that have a 'pass_rtcm' rtcm_writer.  This will be true of
RTCM3 too, shortly; I'm still debugging recognition of RTCM3 packets.

> Anyway, one option I'd also like to have is to forward the raw RTCM
> stream somewhere. (Some receivers use a separate serial port for that.)

There's no support for that right now.  Probably the right thing would be
a command to declare an RTCM device port.
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Matthias Urlichs]

Hi,

Eric S. Raymond:
> Matthias Urlichs <smurf@...>:
> > one of the missing rtcm3 bits seems to be "teach ntrip.c about it". ;-)
>
> OK, what should ntrip.c do?
>  
The hack below may actually be sufficient, haven't tested any of it
yet, obviously.

diff --git a/ntrip.c b/ntrip.c
index daf59f4..639be8d 100644
--- a/ntrip.c
+++ b/ntrip.c
@@ -19,7 +19,7 @@
 
 struct ntrip_stream_t {
     char mountpoint[101];
-    enum { fmt_rtcm2, fmt_rtcm2_0, fmt_rtcm2_1, fmt_rtcm2_2, fmt_rtcm2_3, fmt_unknown } format;
+    enum { fmt_rtcm2, fmt_rtcm2_0, fmt_rtcm2_1, fmt_rtcm2_2, fmt_rtcm2_3, fmt_rtcm3, fmt_unknown } format;
     int carrier;
     double latitude;
     double longitude;
@@ -96,6 +96,8 @@ static void ntrip_str_parse(char *str, size_t len,
     hold->format = fmt_rtcm2_2;
  else if (strcasecmp("RTCM 2.3", s)==0)
     hold->format = fmt_rtcm2_3;
+ else if (strcasecmp("RTCM 3.0", s)==0)
+    hold->format = fmt_rtcm3;
  else
     hold->format = fmt_unknown;
     }

> > The other bit is documentation. Does gpsd forward the RTCM stream
> > to my GPS receiver? (What if the thing uses a different serial port for
> > that?) And/or does it apply RTCM corrections itself? if both, how does
> > it decide?
>
> At the moment, yes.  Any RTCM2 stream received is forwarded to all attached
> devices with types that have a 'pass_rtcm' rtcm_writer.  This will be true of
> RTCM3 too, shortly; I'm still debugging recognition of RTCM3 packets.
>
OK.

One thing I'd like to use RTCM3 for is offline correction of my NMEA /
gpsd stream; when I go openstreetmapping or geocaching somewhere in the
wilderness I'm unlikely to have Internet, so I'd have to postprocess
the data.

If not, I guess I'll have to buy two identical receivers, feed the RTCM
stream to only one of them, and remember the offsets for later. Not
perfect, but it should work reasonably well.

> > Anyway, one option I'd also like to have is to forward the raw RTCM
> > stream somewhere. (Some receivers use a separate serial port for that.)
>
> There's no support for that right now.  Probably the right thing would be
> a command to declare an RTCM device port.

That sounds about right. "Start/stop feeding RTCM to device X" would be
a good command to have in any case.

--
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@...
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
Better to throw it out -- than throw it in.
                                        -- Skinny Mitchell
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Eric S. Raymond-2]

Matthias Urlichs <smurf@...>:
> The hack below may actually be sufficient, haven't tested any of it
> yet, obviously.

Applied.  Please test, as I don't have the equipment or knowledge to do it
myself.
 
> One thing I'd like to use RTCM3 for is offline correction of my NMEA /
> gpsd stream; when I go openstreetmapping or geocaching somewhere in the
> wilderness I'm unlikely to have Internet, so I'd have to postprocess
> the data.

What facility, if any, do you want in gpsd to support this?

> > There's no support for that right now.  Probably the right thing would be
> > a command to declare an RTCM device port.
>
> That sounds about right. "Start/stop feeding RTCM to device X" would be
> a good command to have in any case.

Added to the to-do list.
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Steve Franks]

>> One thing I'd like to use RTCM3 for is offline correction of my NMEA /
>> gpsd stream; when I go openstreetmapping or geocaching somewhere in the
>> wilderness I'm unlikely to have Internet, so I'd have to postprocess
>> the data.
>
> What facility, if any, do you want in gpsd to support this?

In my mind, it makes sense to have a "fake" gps source (which I think
we have already), as well as a demo program that just streams all the
gps data to disk (I think we just have "gps/xgps" to monitor things,
maybe they stream to disk already).  Seems to me, a demo app that just
logs the rtcm as well would make sense (given the implementation of a
port for receiveing rtcm like the existing one for gps).  I suppose
one could argue the point of making a seperate rtcmd (dgpsd?) vs.
adding the functionality to gpsd itself (which is already done, of
course).  I'm all for keeping everything gps-related in one daemon,
don't get me wrong.  It just popped into my head.

On a completely different note, the last few emails led me to believe
that gpsd is not applying corrections on it's own, but just streaming
them back to any enabled gps.  I thought gpsd was supposed to do
corrections on it's own to it's output stream, for non-dgps-ready
devices, to add dgps to them.  Is that not the case?

Steve
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Eric S. Raymond-2]

Steve Franks <stevefranks@...>:
> On a completely different note, the last few emails led me to believe
> that gpsd is not applying corrections on it's own, but just streaming
> them back to any enabled gps.

That is correct.

>                         I thought gpsd was supposed to do
> corrections on it's own to it's output stream, for non-dgps-ready
> devices, to add dgps to them.  Is that not the case?

Correct, it is not the case.  I wouldn't have the faintest idea how to do that,
and it would probably be computationally expensive and error-prone if I did.

I';ll add a note to the docs about this.
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Steve Franks]

On Mon, Jul 14, 2008 at 1:18 PM, Eric S. Raymond <esr@...> wrote:

> Steve Franks <stevefranks@...>:
>> On a completely different note, the last few emails led me to believe
>> that gpsd is not applying corrections on it's own, but just streaming
>> them back to any enabled gps.
>
> That is correct.
>
>>                         I thought gpsd was supposed to do
>> corrections on it's own to it's output stream, for non-dgps-ready
>> devices, to add dgps to them.  Is that not the case?
>
> Correct, it is not the case.  I wouldn't have the faintest idea how to do that,
> and it would probably be computationally expensive and error-prone if I did.
>
> I';ll add a note to the docs about this.

So this begs the question, why/how are you parsing the data?  Don't
most DGPS's use the raw RTCM 2.1/3.0 as an input as-is? (of course,
parsing CMR input into an RTCM output would still be handy - most
surveyors are going around outputting CMR, and the ability to use it
on an RTCM-capable DGPS would add possibly tens of new sources of
corrections for urban users, especially as a 35W transmitter is fairly
standard, you can pick them up a long way off at 450MHz [might make a
new market for 450MHz GMSK radios])

Best,
Steve
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Eric S. Raymond-2]

Steve Franks <stevefranks@...>:
> So this begs the question, why/how are you parsing the data?

Basically so people can see it if they want - atmospheric physicists,
for example.  And to enable downstream tools that haven't been written
yet.  And because I view it as gpsd's job to make visible as many of the
data flows sloshing around the GPS system as possible.

> Don't most DGPS's use the raw RTCM 2.1/3.0 as an input as-is?

Yes.

I think it is already the case that svn gpsd passes RTCM3.0 through
to GPSes correctly.  But I am not equipped to test this, and would
welcome confirmation or bug reports.

At the present state of play, rtcmdecode doesn't work on RTCM 3.0
yet.  I don't think I'm more than a few working days from fixing that.

>                                                       (of course,
> parsing CMR input into an RTCM output would still be handy - most
> surveyors are going around outputting CMR, and the ability to use it
> on an RTCM-capable DGPS would add possibly tens of new sources of
> corrections for urban users, especially as a 35W transmitter is fairly
> standard, you can pick them up a long way off at 450MHz [might make a
> new market for 450MHz GMSK radios])

I have not even looked at CMR yet.
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Matthias Urlichs]

Hi,

Eric S. Raymond:
> Matthias Urlichs <smurf@...>:
> > The hack below may actually be sufficient, haven't tested any of it
> > yet, obviously.
>
> Applied.  Please test, as I don't have the equipment or knowledge to do it
> myself.
>  
Will do soon.

> > One thing I'd like to use RTCM3 for is offline correction of my NMEA /
> > gpsd stream; when I go openstreetmapping or geocaching somewhere in the
> > wilderness I'm unlikely to have Internet, so I'd have to postprocess
> > the data.
>
> What facility, if any, do you want in gpsd to support this?
>
Dunno yet.

Postprocessing requires a steam of timestamp+offset-for-lat/long/height
messages that I can apply to the track and waypoint data(*). That may be
extractable from the RTCM stream; I haven't checked yet. If not, I'd
connect two identical GPS receivers, send RTCM to only one of them, and
store the differences between their reported positions.

Also, since a RTCM streamer can deliver a data stream tailored to my
location (by interpolating between multiple "real" receivers), I'd like
an option to request correction data for some place other than what the
receivers say (assuming that the machine which receives RTCM from the
net even has any receiver).


(*) High-end commercial surveying systems which do this kind of
post-processing store the raw satellite reception parameters
(i.e. signal offset and phase) instead of the waypoint coordinate, and
apply the RTCM corrections before they calculate their position, thereby
delivering another order of magnitude of accuracy. Unfortunately that's
all proprietary AFAIK; even if it wasn't, somebody would have to write
code for GPS analysis. Which is NOT easy.

I'm somewhat annoyed about the fact that all this effort would be mostly
unnecessary if the 2-GHz signal wasn't encrypted,