wiki:gps

Version 23 (modified by Ryan Erbstoesser, 3 months ago) ( diff )

clean up old gps notes

  1. Global Navigation Satellite Systems (GNSS)
    1. United States NAVSTAR Global Positioning System (GPS)
    2. Russian Federation Global Orbiting Navigation Satellite System (GLONASS)
    3. BeiDou Navigation Satellite System (China)
    4. Galileo Navigation Satellite System (EU)
    5. Satellite-Based Augmentation System (SBAS)
  2. Software Links
  3. Gateworks on-board GPS GNSS Hardware
    1. Example On-Board GPS Connector
    2. Hardware UART and Device Mappings
    3. Hardware Devices Used
      1. u-blox ZED-F9P
      2. u-blox ZOE-M8 (Venice Family of SBC's)
        1. u-blox Receiver Protocol (UBX)
        2. NMEA considerations for EVA-M8M
        3. One Socket Protocol (OSP), aka SiRF Binary Protocol
    4. Antennas
      1. u-blox EVA-M8M (Ventana product family)
      2. Active Antenna Short Circuit Detect / Recover
  4. Add-in cards supporting GPS
  5. NMEA 0183
  6. Time synchronization via PPS (Pulse-Per-Second)
  7. gpsd
  8. Differential GPS (DGPS)
    1. Radio Technical Commission for Maritime Services (RTCM)
    2. Traditional land-based beacon DGPS
    3. Wide Area Augmentation System (WAAS)
  9. Indoor GPS Testing

Global Navigation Satellite Systems (GNSS)

GNSS (Global Navigation Satellite System) is a satellite system that is used to pinpoint the geographic location of a receiver anywhere in the world.

Each of the following GNSS systems employ a constellation of orbiting satellites working in conjunction with a network of ground stations:

  • GNSS systems are currently in operation:
    • the United States' NAVSTAR Global Positioning System (GPS)
    • the Russian Federation's Global Orbiting Navigation Satellite System (GLONASS)
  • GNSS systems not currently at full capacity:
    • Europe's Galileo is slated to reach full operational capacity by 2020

The following are similar navigation systems that do not have world-wide coverage:

  • China's BeiDou Navigation Satellite System
  • India's GPS Aided GEO Augmented Navigation (GAGAN) and Indian Regional Navigation Satellite System (IRNSS)

References:

United States NAVSTAR Global Positioning System (GPS)

The United States NAVSTAR Global Positioning System (GPS) operates at a frequency of 1575.42MHz referred to as L1C/A. It has world-wide coverage originally using 24 satellites which began deployment in 1973 and became fully operational in 1995.

Reference:

Russian Federation Global Orbiting Navigation Satellite System (GLONASS)

The Russian Federation Global Orbiting Navigation Satellite System (GLONASS) operates at a frequency of 1602MHz + k*562.5 (where k = -7,...,5,6) referred to as L1OF. It is a space-based system providing an alternative to US GPS. Deployment began in 1982 and was originally completed in 1995 but followed with a decline in capacity until fully restored to 24 satellites in 2011.

Reference:

BeiDou Navigation Satellite System (China)

The BeiDou Navigation Satellite System covers China and is planned to begin serving global customers upon its completion in 2020.

Galileo Navigation Satellite System (EU)

Galileo is the GNSS that is currently being created by the European Union (EU) and the European GNSS Agency (GSA). The system became operational in October 2011 and as of Dec 2016 the system has 18 of 30 satellites in orbit and is expected to reach full operational capability in 2019 with the complete 30-satellite system (24 operational and 6 active spares) expected by 2020.

Reference:

Satellite-Based Augmentation System (SBAS)

A Satellite-Based Augmentation System (SBAS) is a system that supports wideo-area or regional augmentation of positioning systems.

There are several common SBAS implementations:

Software Links

For using the GPS in software, please see the Operating Systems pages:

Gateworks on-board GPS GNSS Hardware

Gateworks has several products that have on-board GNSS modules.

The advantage of using a Gateworks product with an on-board modules are:

  • Active Antenna support (with auto-short-circuit detect/protect/recovery for some models)
  • PPS signal for time synchronization
  • Tighter integration

Refer to the details below as well as the individual product manuals for details of connection such as:

  • Data serial port
  • PPS GPIO
  • Active antenna detect/protect/recovery support

Note the only external GPS that Gateworks offers is the GW16143 high precision GNSS Mini-PCIe card, read more on the GW16143 Wiki Page

Example On-Board GPS Connector

The average Gateworks SBC with GPS installed will have a gold MMCX connector like pictured below:

Hardware UART and Device Mappings

The GPS devices used on Gateworks products communicate with the host processor over a serial UART:

  • Venice:
    • GW7401/GW7301/GW7201: /dev/ttymxc0 u-blox ZOE-M8Q 9600bd NMEA 0183 output 1Hz
  • Newport:
    • GW6104/GW6204/GW6304/GW6404: /dev/ttyAMA1 u-blox ZOE-M8Q 9600bd NMEA 0183 output 1Hz
    • Note must disable echo on serial port, Read more in troubleshooting section here
  • Ventana:
    • GW5100: /dev/ttymxc0 Wi2Wi W2SG0008i 4800bd NMEA 0183 output 1Hz
    • GW52xx (rev A-D) / GW53xx (rev A-F) / GW54xx (rev C-F) : /dev/ttymxc4 Wi2Wi W2SG0008i 4800bd NMEA 0183 output 1Hz
    • GW52xx (rev E+) / GW53xx (rev G+) / GW54xx (rev G+) : /dev/ttymxc4 u-blox ZOE-M8Q 9600bd NMEA 0183 output 1Hz
    • GW553x: /dev/ttymxc3 u-blox EVA-M8M 9600bd NMEA 0183 output of GGA/GLL/GSA/GSV/RMC/VTG/TXT GPS, GLONASS, and SBAS enabled

Hardware Devices Used

u-blox ZED-F9P

This module is a high precision GNSS/GPS module for providing up to 2CM accuracy with RTK. It is used on the GW16143 Mini-PCIe Card. Read more on the GW16143 Wiki Page.

u-blox ZOE-M8 (Venice Family of SBC's)

References:

  • ZOE-M8 Datasheet (UBX-16008094)
  • u-blox M8 Receiver Protocol Specification (UBX-13003221)

Features:

  • 72-channel u-blox M8 concurrent position receiver engine supporting multiple concurrent Global Navigation Satellite System's (GNSS):
  • Differential GPS (DGPS): RTCM 10402.3:
  • Navigation Update Rate: 10Hz (GPS&GLONASS) or 18Hz (GPS)
  • Accuracy:
    • Velocity: 0.05m/s
    • Heading: 0.3degrees
    • Horiz position: Autonomous 2.5m / SBAS 2.0m
    • PPS: 30ns RMS, 99% 60ns
  • Sensitivity:
    • Tracking & Navigation: -167dBm (GPS&GLONASS) -166dBm (GPS) -166dBm (GLONASS) -160dBm (BeiDou) -159dBm (Galileo)
    • Re-acquisition: -159dBm
    • Cold start: -147dBm
  • Acquisition:
    • Cold start Time-to-First-Fix (TTFF): 27s (GPS&GLONASS) or 30s (GPS only)
    • Hot start Time-to-First-Fix (TTFF): 1s
  • PPS:
    • 30ns accuracy, configurable via UBX-CFG-TP5 with rate 0.25Hz to 10Mhz, high or low polarity, 0 to 232 ms pulse width (see u-blox M8 Receiver Description UBX-13003221 Chapter 18)
    • Default is 1Hz rising edge 100ms length
    • Note that for best PPS accuracy it is recommended to disable the SBAS subsystem
  • Communication:
    • 9600 baud, 8bit no parity, 1 stop bit, no flow control supporting multiple protocols:
      • NMEA: Input / Output ASCII 0183 version 4.0 (configurable for 2.3 or 4.1)
      • UBX: Input / Output binary u-blox proprietary (see ubx below)
      • RTCM: Input, messages 1,2,3,9
  • Active Antenna: 15dB to 50dB recommended
  • Power Consumption (not including active antenna power consumption):
    • ~40mA@1.8V 72mW (Continuous)
    • ~12.5mA@1.8V 22.5mW (PSM, 1Hz)

Power-on Defaults:

  • 9600 baud, 8 data bits, no parity, 1 stop bit:
  • GPS & GLONASS enabled
  • SBAS enabled
  • output: NMEA: GGA, GLL, GSA, GSV, RMC, VTG, TXT messages
  • input: UBX, NMEA, RTCM
  • PPS: 100ms active high pulse at 1Hz

Note that the GPS is not connected to an RTC, battery backup, or external flash on Gateworks designs (which disallows for permanent configuration storage and firmware upgrade)

The ZOE-M8 GPS has the following improvements over the EVA-M8:

  • Has built in SAW and LNA for passive antenna support whereas the EVA-M8 can't support passive antenna
  • Uses an internal TCXO (temperature compensated) oscillator to provide improved accuracy over the EVA-M8 which uses a crystal
  • Smaller footprint (4.5mm x 4.5mm x 1.0mm) device vs (7mm x 7mm x 1.1mm)
  • Supports Galileo and BeiDou. EVA-8M only supports GPS GLONASS
  • Improved sensitivity (-167dBm vs -164dBm)
  • Faster acquisition time (26s vs 33s)

Troubleshooting

  • The following message may be seen on the GPS line: 
    $GNTXT,01,01,01,NMEA unknown msg*46
    • This happens when echo is enabled on the serial line. To disable it, use the following command, adjusting the device in the example below where appropriate: 
      stty -F /dev/ttyAMA1 -echo

u-blox Receiver Protocol (UBX)

UBX (u-blox Receiver Protocol) is a u-blox proprietary binary communication protocol used in their GNSS engines described in detail in M8 Receiver protocol: UBX-13003221

NMEA considerations for EVA-M8M

The following need to be taken into consideration when operating in multi-GNSS mode (Note that the power-on default is GPS & GLONASS):

  • multiple sets of GSV messages will be output back to back, 1 for each system
  • multiple sets of GSA and GRS messages are output for each fix, one for each GNSS

The main Talker ID (the two-letter identifier) will vary based on GNSS configuration:

  • GPS/SBAS/QZSS - GP
  • GLONASS - GL
  • GNSS - GN (message pertaining to any type of GNSS)

One Socket Protocol (OSP), aka SiRF Binary Protocol

One Socket Protocol (OSP), also known as the SiRF BINARY™ protocol, is a binary communication protocol available with the SiRFstar family of GPS receiver products from SiRF (which was purchased by CSR). In general, there are more message types and data available when using this protocol over NMEA 0183.

References:

  • One Socket Protocol Interface Control Document (OSP_ICD) (CS-129291-DC-15)

Examples:

  • To switch from NMEA 4800bd 8N1 to OSP at 9600 baud, you can use the following bash script: 
    #!/bin/sh

# Make sure we talk to the device at its current configured data format
# (assuming power-on default of 4800 8N1)
stty -F /dev/gpsdevice 4800 cs8

# change to mode=0 (OSP/SiRF binary) 9600bd 8N1
echo "\$PSRF100,0,9600,8,1,0*0C" > /dev/gpsdevice

# set new tty baudrate for future communication
stty -F /dev/gpsdevice 9600
  • To switch from OSP at 9600bd back to NMEA 4800bd, you can use the following bash script: 
    #!/bin/sh
send_hex() {
  while [ "$1" ]; do
    printf "\x$1"
    shift
  done
}

# Make sure we talk to the device at its current configured data format
# (assuming it has been changed to 9600bd)
stty -F /dev/gpsdevice 9600 cs8

# send MID 129: Switch to NMEA protocol
send_hex A0 A2 00 18 > /dev/gpsdevice # start sequence and payload length (24 bytes)
send_hex 81 02 01 01 01 01 01 01 01 01 01 01 01 01 00 01 00 01 00 01 00 00 12 C0 > /dev/gpsdevice # payload specifying baudrate and msg rates
send_hex 01 64 B0 B3 > /dev/gpsdevice # checksum and end sequence

# set new tty baudrate for future communication
stty -F /dev/gpsdevice 4800
    • Note that MID 129 also specifies the period of the various NMEA messages. If changing the above data you need to also re-calculate the checksum. See ​here section 5.4 for more info on the MID 129 message
    • ensure that /dev/gpsdevice cooresponds to the correct tty above in the hardware mappings section
  • To enable SBAS based DGPS assuming you are already in 9600bd OSP mode: 
    #!/bin/sh

send_hex() {
  while [ "$1" ]; do
    printf "\x$1"
    shift
  done
}

# Make sure we talk to the device at its current configured data format
# (assuming it has been changed to 9600bd)
stty -F /dev/gpsdevice 9600 cs8

# send MID 133: DGPS Source
send_hex A0 A2 00 07 > /dev/gpsdevice # start sequence and payload length (7 bytes)
send_hex 85 02 00 00 00 00 00 > /dev/gpsdevice # payload specifying DPGS Source (Table 5.43)
send_hex 00 87 B0 B3 > /dev/gpsdevice # checksum and end sequence
    • when DPGS is enabled GGA NMEA messages will show a position fix indicator of 2 to indicate a DGPS fix vs 1 to indicate a GPS fix.
    • use MID 170 to set SBAS parameters if you need to change the SBAS mode or region between WAAS/EGNOS/MSAS/GAGAN

Antennas

GPS receivers can use active or passive GPS antennas. An active antenna is powered and uses an LNA (Low Noise Amplifier) at the antenna instead of at the GPS receiver making it more sensitive than a typical passive antenna.

Some of the GPS modules can be used with passive antenna. See the modules datasheet for more information. Gateworks provides 3.3V for the active antenna DC voltage on all boards.

Gateworks typically uses a 50 ohm MMCX connector on it's board however as a special configuration a U.FL connector can be loaded in the same location.

Here is an SMA antenna we sell in our shop that is 50 Ohm and 27-28 dBi (+- 3-4dBi) - GW10044:

Antenna Adapter Cables:

u-blox EVA-M8M (Ventana product family)

Maximum Antenna Gain:

  • 15dB to 50dB recommended

Please also consult the manual / datasheet above.

Active Antenna Short Circuit Detect / Recover

All Gateworks boards with on-board GPS support active (powered) GPS antenna connections. On many boards that have a Gateworks System Controller the antenna power is periodically monitored (1Hz) for short circuit and automatically disabled/re-enabled to allow resolving the GPS antenna without power cycling the unit.

See the product manual for your board to determine if it has this capability.

Add-in cards supporting GPS

There are many GPS receivers that communicate over UART or USB-UART. Some of these are in the miniPCIe form-factor which provides USB to the connector (Note that USB is not routed to all Gateworks miniPCIe connectors - consult the product user manual for details on your board).

References:

NMEA 0183

NMEA 0183 is a combined electrical and data specification for communication between marine electronics such as echo sounder, sonars, anemometer, gyrocompass, autopilot, GPS receivers and many other types of instruments. It has been defined by, and is controlled by, the National Marine Electronics Association. It replaces the earlier NMEA 0180 and NMEA 0182 standards.[1] In marine applications, it is slowly being phased out in favor of the newer NMEA 2000 standard.

Most GPS receivers use this standard for communication, however typically they may only use a subset of the standard, add their own proprietary commands, and use different baudrates. Refer to the specific GPS receiver documentation being used for details.

Most GPS devices allow customizing the NMEA output such as the UART baudrate, the types of messages, and the rate at which they are sent. Please see sections above for the particular GPS device you are interested in configuring

NMEA messages end with a checksum and most devices will ignore messages with an invalid checksum. You can use the ​online NMEA sentence checksum calculator to aid you.

References:

Time synchronization via PPS (Pulse-Per-Second)

One handy feature of an on-board GPS is that it can deliver Pulse-Per-Second (PPS) signal. This signal can be used to get a high-precision time reference that an application can use to adjust system clock time.

PPS is supported by the Linux kernel by the pps-gpio driver (CONFIG_PPS_CLIENT_GPIO). This adds a pps device to /sys/class/pps which you can interact with: 

# cat /sys/class/pps/pps0/assert
170026870.983207967#8
  • The above shows the most recent timestamp and sequence number that has been asserted via PPS

Common use is to configure the Network Time Protocol Daemon (NTPD) with a PPS source to obtain a wallclock-time with sub-millisecond synchronization to UTC.

The various Gateworks Board Support Packages includes PPS support (if a GPS is present). However, in order to hook NTPD with a PPS source, you have to have the fully featured ntpd package (i.e. not busybox).

Note that the gpsd app will keep your NTP service syncrhonized to the time from a GPS:

The PPS signal is also routed to a spare pin on the miniPCIe slots of many models:

Model Revision Introduced Pin PCIe Slot Resistor Loading
GW51xx Rev C 49 J6 R118
GW52xx Rev C 49 J7,J8 R190/J8 R191/J7
GW53xx Rev C 49 J7,J8 R212/J7 R213/J8
GW553x Rev A 49 J5 R31
GW54xx Rev E 49

Reference:

gpsd

gpsd is a service daemon that monitors one or more GPS devices via serial or USB making all the data on location/course/velocity available to be queried on a TCP port. There are multiple client applications that can connect to a gpsd server.

Example:

  • Ubuntu Focal:
    1. Install apps 
      root@focal-venice:~# apt update
root@focal-venice:~# apt-get install gpsd gpsd-dbg gpsd-clients
    2. Configure gpsd via /etc/defaults/gpsd 
      root@focal-venice:~# cat /etc/default/gpsd
# Default settings for the gpsd init script and the hotplug wrapper.

# Start the gpsd daemon automatically at boot time
START_DAEMON="true"

# Use USB hotplugging to add new USB devices automatically to the daemon
USBAUTO="true"

# Devices gpsd should collect to at boot time.
# They need to be read/writeable, either by user gpsd or the group dialout.
DEVICES=""

# Other options you want to pass to gpsd
GPSD_OPTIONS=""
root@focal-venice:~# cat /etc/default/gpsd
root@focal-venice:~# sed -i 's;DEVICES="";DEVICES="/dev/ttymxc0";' /etc/default/gpsd
      • replace the above with the proper GPS device for your system - see #uart
    3. Restart the gpsd service 
      root@focal-venice:~# systemctl restart gpsd.socket
    4. Verify gpsd is listening: 
      root@focal-venice:~# netstat -a | grep gpsd
tcp        0      0 localhost:gpsd          0.0.0.0:*               LISTEN     
tcp6       0      0 localhost:gpsd          [::]:*                  LISTEN     
unix  2      [ ACC ]     STREAM     LISTENING     23508    /run/gpsd.sock
    5. Verify gpsd is working using one of its client apps, for example cgps which is a simple terminal client: 
      root@focal-venice:~# cgps

Troubleshooting:

  • you can run gpsd manually in foreground with the '-N' parameter and enable debugging with the '-D' parameter to see any errors. Make sure nothing is running that is listening to the gpsd port first 
    root@focal-venice:~# systemctl stop gpsd.socket
root@focal-venice:~# netstat -a | grep gps
root@focal-venice:~# gpsd -N -D3 /dev/ttymxc0
gpsd:INFO: launching (Version 3.21)
gpsd:INFO: listening on port gpsd
gpsd:INFO: stashing device /dev/ttymxc0 at slot 0
gpsd:INFO: running with effective group ID 20
gpsd:INFO: running with effective user ID 108
gpsd:INFO: startup at 2021-10-08T21:30:00.000Z (1633728600)

Differential GPS (DGPS)

​Differential Global Positioning System (DGPS) is an enhancement to GPS that provides improved location accuracy from the 15-meter nominal GPS accuracy to about 10cm in the case of the best implementations.

Radio Technical Commission for Maritime Services (RTCM)

The standards applying to Differential Global Navigation Satellite Systems (DGNS) are defined by the Special Committee 104 of the ​Radio Technical Commission for Maritime Services (RTCM). Except for RTCM, there exist other proprietary DGPS standards, such as Trimble Compact Measurement Record (CMR).

References:

Traditional land-based beacon DGPS

Traditional DGPS uses a network of fixed ground-based reference stations that broadcast the difference between their known location and the location determined via GPS. These stations would broadcast using VHF/UHF which traditionally were available on maritime vessels where GPS was originally intended to be used.

To use this you must have a receiver that can receive both GPS broadcasts as well as the VHF/UHF broadcasts from the land-based beacons. In addition you need to be in an area that has such land based beacons. The U.S. Coast Guard and Canadian Coast Guard operate these near large waterways.

Wide Area Augmentation System (WAAS)

An alternative system was developed called Wide Area Augmentation System (WAAS) which uses satellites in geostationary orbit that receive broadcasts from fixed ground-based stations. In this system the additional satellites periodically broadcast (about every 5 seconds) a Deviation Correction (DC) created from the data continually received from the ground based reference systems. This signal can be received with the same receiver used to receive signals from traditional GPS satellites.

To use this you need only a receiver that can receive GPS broadcasts, however you still need to be in an area that both has ground based reference stations and need to have at least 1 SBAS capable satellite in view. This system was created for North America however there are SBAS based systems being developed in Europe and Asia as well:

  • SBAS - North America / Hawaii Satellite-Based Augmentation System
  • EGNOS - European Geostationary Navigation Overlay Service
  • MSAS - Jpanase Multi-functional Satellite Augmentation System
  • GAGAN - Indian GPS Aided Geo Augmented Navigation

Indoor GPS Testing

Gateworks uses a GPS repeater when doing in-building GPS testing. These can be found from a variety of vendors:

The unit we use is the ​Sumalink SL1500 available for $200 and features:

  • L1 GPS: 1575±5MHz
  • 5V DC input
  • Interference suppression: >=20dB;
  • Reflection loss: -14dB
  • Range: 15 meters (re-transmission range)
  • Cable: 30 meters (cable from rooftop receiver to transmitter)

We use various test software including:

  • ​test_gps - shell script that parses GSV, GGA, GSA messages and provides fix, average satellites in view, and signal strength details
  • gpsd and related clients (gpxlogger can capture a path to an XML file, GPS Babel can convert GPX log to KML, Google Earth can view KML files)
  • sirf_osp - C application used for sending commands and receiving messages from ventana gps devices

An example of a test procedure carried out on our gps devices was the verification of optimal LNA mode for Ventana boards when using our standard active antenna. The procedure for this test is defined as follows:

  1. Power on the device with antenna connected
  2. Download the gateworks-gps-utils.tar.gz (see bottom attachments) and extract
  3. Use the Makefile provided to build the sirf_osp application (refer to your BSP's 'Building' wiki for help)
  4. Make the application executable chmod +x sirf_osp
  5. Put the device into osp mode ./sirf_osp <device> <baud> osp 115200
  6. Set the LNA mode of the device ./sirf_osp <device> 115200 lna <low/high>
  7. Verify the LNA mode via the "LNA:X" field of ./sirf_osp <device> 115200 config
  8. Begin storing gps fix data to file ./sirf_osp <device> 115200 csv <filename>
  9. Use gps visualization tool of your choice to analyze gathered data (e.g. Google My Maps)

*Note: If any sirf_osp command results in a stream of gps data, retrying the command with the correct arguments will typically solve the problem.

Attachments (4)

Download all attachments as: .zip

Note: See TracWiki for help on using the wiki.