Marine navigation company Savvy Navvy introduces a new NMEA Connect feature that seamlessly integrates NMEA-enabled boat instruments with the app, providing real-time data and enhanced AIS visibility.
Working with award-winning Actisense, recognized globally for their NMEA interconnectivity specialty, Savvy Navvy’s new NMEA Connect feature enables boaters to view real-time data including wind, depth, engine RPMs, speed through water, heading and more in the app.
By combining onboard and over-the-horizon AIS, NMEA Connect delivers a complete view of nearby vessels for safer, smarter navigation. Through NMEA Connect, boaters can now access their boat’s instruments and Savvy Navvy’s smart routing technology from their pocket, eliminating the need to switch between multiple screens or devices.
“Boaters increasingly seek apps that simplify navigation and enhance onboard intelligence. NMEA Connect combines the proven reliability of NMEA technology with Savvy Navvy’s smart routing capabilities, giving boaters everything they need in one place. For boats without NMEA-compatible chart plotters, Savvy Navvy now becomes your all-in-one display,” says Misha Vysokovskiy, chief product officer at Savvy Navvy.
Actisense, global specialists in marine electronics, help leisure and commercial operators build safer, smarter and more dependable onboard networks.
“Savvy Navvy already delivers a huge amount of value to boaters, pulling together geographic location and environmental data streams. The addition of NMEA data connection means that other integral navigation and systems data will give boaters better visibility of things like depth, speed over ground, wind speed, heading and engine RPM — all within the easy-to-use Savvy Navvy app. Actisense are proud to have partnered with Savvy Navvy, lending our NMEA specialism. We share company missions of making journeys safer and more efficient through better data,” says Justin Cohen, commercial director at Actisense.
Savvy Navvy has had more than 3 million downloads globally. Unlike any other boating navigation solution, Savvy Navvy provides smart routing — giving users optimal routes and dynamic ETAs based on real-time data: departure time, chart information, weather conditions, tide, boat specifications and local regulations.
The NMEA Connect feature comes just weeks after Savvy Navvy launched an industry-first new chart annotation tool and Three Point Fix, following requests from boating instructors to turn digital charts into interactive learning tools for the next generation of boaters.
One of a small army of PhytoPatholoBots (PPB) developed by Cornell University and deployed to four grape breeding programs across the United States. These autonomous robots will roll through vineyards, using computer vision to gather data on the physiological state of each grapevine. They use a NovAtel SMART antenna. (Image: Allison Usavage / Cornell University)
One GNSS receiver widely used in autonomous ground vehicles is Hexagon | NovAtel’s SMART7 antenna. Matteo Luccio, GPS World’s editor-in-chief, discussed the product and its applications with Haley Lawrance, Senior Positioning Product Manager, Agriculture for Hexagon | NovAtel.
Luccio: “How do you differentiate your SMART antennas from your other GNSS receivers?”
Lawrance: “The reason why the SMART antenna portfolio has been so attractive within the agriculture market and to our autonomy customers specifically, has been the ease of integration and the high performance it provides. GNSS positioning is just one part of an autonomous system, and the autonomous integrators don’t necessarily have the volume of machines out of the gate that would justify the development time for them to integrate the OEM components.
With NovAtel’s SMART antennas, they only need to consider the single cable harness that will run power and communications to and from the receiver – and a single mount point on the vehicle. The SMART antennas offer a waterproof and rugged enclosure, designed to withstand the demanding environments typical for agriculture – and help accelerate our customers’ time to market.”
Luccio: “Is there some standard, as there is for cars, that enables developers of autonomous systems to easily plug your system into theirs?”
Lawrance: “We support a variety of communication protocols – serial, CAN, Ethernet, and Wi-Fi. For autonomy, Ethernet tends to be the most common option for communication with the GNSS receiver – especially when using features that require more bandwidth, such as our SPAN GNSS+INS sensor fusion solution that leverages an inertial measurement unit.
NovAtel’s_OEM7_driver, built for the Robot Operating System (ROS), is a great option because it makes it even quicker for them to integrate and allows the receiver to essentially plug-and-play into the ROS environment with minimal development. For CAN, we support both J1939 Transport and Extended Transport Protocol and NMEA 2000 if they would like to communicate onto an existing bus they are using on the vehicle.”
Luccio: “What about the ease of integration on the software side?”
Lawrance: “We have a very large library of proprietary NovAtel-formatted logs that are available in binary and ASCII, which provide flexibility and allow customers to customize a unique set of logs that provide the data they are interested in. This could be anything from information on which satellites are being used in the solution, to the roll and pitch of the vehicle, or status information from the receiver. NovAtel receivers also output in standard formats, such as NMEA 2000 and NMEA 0183, that consolidate the data that they are most likely to need, such as position, velocity, and quality indicators.”
Luccio: “What markets do your SMART antennas target?”
Lawrance: “Broadly speaking, the SMART antenna product line was designed specifically for agriculture use cases and environments. Customers include agriculture OEMs, aftermarket integrators that develop retrofit precision ag solutions, and autonomous solution providers.
Within that product line, we have SMART7 and SMART2, with different performance options that allows us to scale the best product solution for each application. For high-performance semi-autonomous or autonomous applications that need centimetre-level accuracy – even in highly variable terrain and challenging GNSS-obstructed environments, SMART7 is the best fit – together with SPAN GNSS+INS and TerraStar-C PRO Correction Services or RTK.
For additional positioning redundancy on an autonomous vehicle, SMART2 can be used together with SMART7 – meaning there are two different, independent GNSS hardware, software, and positioning solutions running in parallel. This allows autonomous machinery manufacturers to utilize both positioning solutions in parallel for an additional layer of protection.”
In this issue’s cover, a man with a backpack lidar unit, a GNSS receiver and a tablet computer is surveying in a complex and challenging urban setting. That same lidar unit also can be mounted on a UAV. One of the contributors to this month’s cover story describes the role of aerial photogrammetry in the architecture, engineering and construction (AEC) industry. Satellite navigation, remote sensing, mapping software, a great variety of platforms, and ever more powerful handheld computers — those are the key ingredients in today’s ecosystem of geospatial technologies. The current generation of surveying equipment has more than halved fieldwork in the past two decades while greatly improving the quality of the data collected.
The AEC industry relies on surveyors to be “a bridge between the existing landscape and the design landscape,” said another contributor to our cover story. Unlike traditional boundary surveying, he explained, surveying for AEC requires consideration of a detailed 3D world. It also involves many more stakeholders and much greater liability.
The tight integration of GNSS, inertial systems, lidar sensors and 360° spherical imagery into mobile mapping systems makes 3D modeling possible and traditional GNSS or optical measurement instruments obsolete. However, while inertial systems are invaluable to bridge brief gaps in the availability and reliability of GNSS signals, they are far from the panacea they are sometimes claimed to be, as Brad Parkinson reminds us in an interview with Dana Goward, also in this issue.
Surveying for AEC requires at least centimeter accuracy. The challenges of surveying in urban settings include urban canyons that occult signals and create multipath, traffic and multiple layers of underground, ground-level and above-ground infrastructure.
Beyond the construction phase, 3D survey data is increasingly used to create digital twins of buildings, which facilitate their operation and maintenance throughout their life cycle and help lower their carbon footprint. Once they have completed an initial survey, surveyors often set control to be used for machine control — the theme of our cover story in next month’s issue.
In this issue we also:
• Inaugurate a “letters to the editor” section to make more room for debate in the GNSS/PNT community on the critical issues it faces.
• Report on a Jet Propulsion Laboratory study of the impact on the ionosphere of the enormous volcanic eruption in Tonga and the beginnings of a GNSS-based early warning system for natural hazards.
• Continue our series of articles on GNSS constellations, with an update from Japan’s QZSS constellation.
• Feature three studies: one on real-time simulator testing using an NMEA data stream, one on the first transmission of L1C/B signals by QZSS, and one on self-driving cars in major metropolitan areas.
All these advances, however, are threatened when GPS is threatened. Earlier in the month, three members of our editorial advisory board comment on the recent threat to GPS satellites by the Russian government.
The use of GPS signals is certainly commonplace in today’s technological age. Various locating systems, tracking systems and precision timing applications all use the common decoded NMEA and 1 PPS signals from a GPS satellite in a multitude of different ways.
When a direct line-of-sight path to GPS satellites is unavailable, the GPS signal must first be received where there is a direct line-sight path, decoded, and then the resulting signals routed to where they are needed. The Luxlink GPSX-1001 has been designed to do exactly that.
LuxLink GPSX-1001 fiber-optic transceiver.
The GPSX-1001 is the result of a specific request by a research group of a midwestern U.S. university for seismic studies in an underground mine. More than 20 units were installed in several branches of the mine and have been in continuous operation successfully for two years.
The GPSX-1001 transceiver is a multifunctional device that can be used as a transmitter or a receiver/repeater. In operation, the NMEA signal and the 1 PPS signal are both multiplexed by the GPSX-1001 (set as a transmitter) and launched into a single optical fiber. The multiplexed signal is then received from the fiber at a second GPSX-1001 set as a receiver/repeater. Here, the NMEA and 1PPS signal are de-multiplexed and available as individual outputs (see Figure 1).
FIGURE 1. GPSX-1001 block diagram.
The original multiplexed signal is also then reapplied to another integral optical transmitter for use at a third receiver/repeater. Additional receiver/repeaters can be connected in the same fashion to allow the signals to be transmitted to numerous locations.
Fiber-optic cable is virtually immune to electrical interference and can be routed wherever convenient without regard to the proximity of electrical noise producers, water or high voltages. Because fiber optic cable is non-conducting, ground loops that can result in loss or corruption of the GPS signals are virtually eliminated. The bandwidth of the fiber and circuitry in the GPSX-1001 is such that the fast rise and fall times of the 1-PPS signal are maintained and the NMEA signal is as noise free as the original input.
Transmission distances using the GPSX-1001 can extend to a mile or more. For longer distances, additional GPSX-1001 units can be added.
The GPSX-1001 is user configured by means of front-panel DIP switches. Integral LED indicators are provided to continuously monitor the NMEA, 1 PPS, power and optical link signals. Power is obtained from simple wall type plug-in adapters or low voltages and need not be regulated because the GPSX-1001 units contain internal regulators.
Figure 2 shows three GPSX-1001 units in a typical GPS signal distribution system. The NMEA interface can be RS-422 or RS-232, depending on the requirements of the signal source. The 1 PPS signal is 50-ohm TTL compatible. Each transceiver pair will produce signals over distances in excess of several miles and will operate from –35° to +75° C (–31° to 167° F), allowing them to be used both indoors and outdoors. Units are available for use with multimode or single-mode fiber and with standard fiber-optic connectors.
FIGURE 2. GPS NMEA/1 PPS transmission system.
Irwin Math is president of Liteway Inc. and has more than 30 years of experience in the design and development of fiber-optic transmission systems. He was also the founder of Math Associates Inc., one of the pioneering firms in fiber-optic transmission system technology in the early 1980s.
Jackson Labs Technologies Inc. (JLT) has entered the GNSS simulation and synthesis market with the small size, weight and power (SWAP) CLAW GPS/GNSS simulator. The CLAW is only slightly larger than a standard deck of cards.
CLAW targets applications that require small, low-power and low-cost GNSS synthesis with repeatable and highly accurate GNSS RF signals such as production testing of GNSS receivers, simulating GNSS anomalies such as leap-second events, 1023 GPS Week roll-overs, simulated operation in inaccessible locations around the world, real-time transcoding of different GNSS systems, and testing using dynamically user-configured RF signal levels.
With nanosecond-accurate encoding, CLAW is particularly suited to allow easy stress-testing of GPSDO Frequency and Timing Reference products such as JLT’s GNSDOs under various different mission scenarios, the company said.
The CLAW GNSS simulator is a no-frills solution that contains real-time processing hardware to simulate GPS constellations without the need to connect any external equipment other than a USB power source or power supply.
Providing a real-time computed RF output signal rather than an offline file-playback differentiates CLAW from competitive solutions that are only capable of recording and playback operation in non-real-time, or require offline computation of data files using external computers that are played back on the simulation device.
CLAW is a completely self-contained, ruggedized, miniature, real-time hardware GPS simulator.
Navigation coordinates and 1PPS timing pulses can be provided in real-time through the NMEA and SCPI compatible USB interface or via the built-in RS-232 interface, and are encoded in the CLAW into RF GPS signals in real-time with nanosecond-level accuracy and minimal delay.
Position, velocity and timing (PVT) information may be provided as a simple NMEA stream from an external source such as an inertial navigation system (INS), Galileo/GLONASS/BeiDou/SAASM GNSS receiver, and CLAW will encode this PVT data into standard L1 C/A GPS RF signals in real-time with minimal phase/position shifts. This allows real-time GNSS transcoding of any other GNSS standard simply by connecting an external GNSS receiver, INS system or PVT source to the RS-232 inputs of the CLAW, allowing retrofit of existing legacy equipment with the latest GNSS systems.
CLAW includes glueless drivers for Rockwell Collins Remote Secure Receiver (RSR Puck) among others, allowing transcoding of assured, secure L2 P(Y) code into legacy L1 C/A code in real time to retrofit commercial receivers with military P(Y) capability. CLAW also allows user-entry of ephemeris and almanac information, providing a means to simulate any past or future GPS constellation and time/date event.
CLAW was designed with a particular emphasis to encoding the optional externally-provided 1PPS GPS system time with nanosecond-level accuracy targets, allowing accuracy testing of GPS timing and frequency devices on top of simply providing a positioning/velocity reference. CLAW initially will support GPS L1 C/A code encoding with up to 12 satellites, and later versions will support additional GNSS systems such as L2 GPS, GLONASS, BeiDou and Galileo.
A comprehensive cost-free optional user application for Windows will be offered that allows control and monitoring of the unit, creation of simulation scenarios using Google Earth and manual waypoint entry, among other options. The unit also can be controlled via simple serial terminal commands, or various other available public-domain freeware programs.
Once position information is stored in the units’ NVRAM, the unit will generate GPS RF constellations within seconds upon power-up and thus does not require any user interaction other than plugging in the power supply.
CLAW contains a highly accurate and stable internal 10-MHz reference oscillator that may optionally be synchronized by an external 1PPS reference, 10-MHz reference, or both. CLAW supports a user-selectable RF signal attenuation range of 63 dB in 0.5-dB steps, allowing a wide range of RF signal levels to be generated with high accuracy and power-level resolution. Antenna DC power consumption also can be controlled via software command.
CLAW can be powered by its USB interface, or by a 6.5V to 28V DC power feed, and consumes less than 1.7W allowing extended operation of 24 hours or more from low-cost ubiquitous USB consumer battery packs.
CLAW pre-production GPS simulator evaluation units are shipping to select customers, and are priced at $2,995 each.
Aman Enterprises introduces NMEA-BT — a Bluetooth iOS adapter that enables any high-precision GNSS receiver with a serial port to connect to an iPad or iPhone.
The NMEA-BT adapter is a small, weatherproof device that solves the problem of connecting non-iOS GNSS receivers and other field sensors to iOS devices. It connects to the iOS devices wirelessly using the native Bluetooth built into the iOS devices.
By replacing the iOS device’s internal GPS location information with the location information from the intrinsically more accurate external GNSS devices used by mapping and survey professionals, NMEA-BT allows users to pair external GNSS devices to their location-enabled iPhone or iPad app. The patent-pending product helps preserve the user’s investment in sub-meter and centimeter GNSS receivers and other sensors while users migrate their workforce to iOS devices.
A free app from the Apple iTunes App Store (NMEA Talker) enables the user to specify any required GPS connection parameters; connect to a local cellular RTK network (NTRIP) or a Direct IP (DIP) based correction service; and feed the corrections to the GNSS receiver, allowing for centimeter accuracy in real time in the field. The app can also be used to display error notifications like high PDOP, loss of an RTK correction, loss of satellite lock.
In addition to connecting to GNSS devices, users can connect to other sensors like laser rangefinders, resistographs, underground cable locators, and commercial weigh scales that output NMEA-formatted data.
For developers, they have full access to the entire raw NMEA stream of data from multiple devices without sacrificing app security or design architecture. No proprietary libraries are required to access the NMEA data stream.
GPS/GNSS Receiver Compatibility
The NMEA-BT has been tested with the following receivers:
John Deere StarFire
Trimble Pro 6, Geo Explorer, 372
Casel H372
Topcon HiPer series
Septentrio APS and NR series
Geneq SXBlue series
Ag Leader 6000 and 6500 series
Raven Industries – Envizio Pro series
Novatel
The only requirement to interface the NMEA-BT adapter is that the GNSS receiver must output at least the $GPGGA and $GPRMC messages via serial port.
At the European Navigation Conference held in Bordeaux, France, April 7–10, a keynote session and ensuing panel discussion addressed the issue of “GNSS Resilience for Terrestrial and Naval Applications.” During the discussion, two questions from the floor drew these responses from panelist Jan Wendel of Airbus Defence & Space GmbH, a leading European aerospace company.
Do you believe that receiver manufacturers will be able to deliver resilient receivers in the future?
JW: In order to achieve resilience, regulatory measures can only provide a mid- to long-term solution. Therefore, resilience needs to be addressed at the receiver level as well.
Considering spoofing, I am not aware of any confirmed spoofing incident. Iran has been claiming to have spoofed a CIA drone, which became for me at least theoretically feasible when I heard the rumor that this drone was equipped with a GPS C/A code receiver. Also, there has been a wrongly configured repeater at the Hannover airport. Nevertheless, spoofing to me does not seem to be a current threat.
However, jamming is clearly a reality nowadays. In my opinion, we should first decide which level of resilience we actually want to achieve for which type of user receiver. If the simple receivers like in smartphones become more and more robust against jamming, the simple jammers available on the Internet will react with an increasing jamming power. This will leave less margin for the receivers used in more critical applications, which we really would like to see functioning permanently.
Therefore, resilience for low-end receivers might not be a good idea; maybe it would be better to see them fail in some scenarios.
Another aspect in the discussion we have had so far is the spreading-code encryption for authentication purposes. Actually, I see spreading-code encryption more as a means to restrict the access of a GNSS signal to authorized users and as an anti-spoofing measure, but not primarily as a means for authentication. Here, we must be aware that the access is not necessarily as restricted as we would like to think.
With directive antennas, blind demodulation techniques and a communication link, it is possible with a slight delay to achieve a position, velocity and time solution at a rover, without being an authorized user of the respective service.
We must understand resilience also in a more global sense, that such a possibility must not be detrimental to the applications assuming a restricted access to specific GNSS services.
Do standards help?
JW: In general, standards are a good thing, as they help in the construction of complex systems by assuring interface compatibility and also minimum performances. However, care needs to be taken when the standards are defined. For example, in the NMEA 0183 protocol, essential information is missing that is required for integration of a GNSS receiver with an inertial navigation system, for example, vertical velocity, full variance-covariance matrices of the receiver’s position and velocity, or raw data like pseudorange, delta ranges and ephemeris to name a few. Clearly, the NMEA protocol was not designed for GNSS/INS integration, and for its intended use the NMEA protocol fits perfectly.
However, for many applications, it is not usable. Being a de-facto standard offered by most receivers, I think it would be beneficial if this protocol would follow more a general-purpose spirit, like most of the proprietary protocols of the different receiver manufacturers do. So with the NMEA protocol lacking relevant information, we are in a situation where for many applications either the receiver manufacturers’ proprietary protocols have to be used — given these protocols offer the required information — or the receiver cannot be used at all. For me, this is an example where a standard is not of great help, also because the process of developing such a standard towards an extended scope takes considerable time, if possible at all.
Jan Wendel is a system engineer at Airbus DS GmbH in Munich, Germany, where he is involved in activities related to satellite navigation, including tracking, integrity and sensor integration algorithms. He received the Dr.-Ing. degree from the University of Karlsruhe, where he is also a private lecturer.
The The Kannad Integra Smart Pack by McMurdo Group could make it twice as easy to find missing aircraft. Photo: McMurdo Group
McMurdo Group, maker of end-to-end search and rescue solutions, has launched the Kannad Integra Smart Pack, an aviation emergency locator transmitter (ELT) bundle with both GPS and antenna redundancy. The product can result in Integra Smart Pack-equipped aircraft being twice as likely to be found in the event of an emergency compared to standard ELTs.
The Kannad Integra Smart Pack includes:
The Kannad Integra ELT – a small, light ELT with a built-in antenna and embedded GPS receiver.
The new Kannad Integra e-NAV NMEA – an NMEA-standard interface cable that connects the Integra ELT to the aircraft GPS. The latest known aircraft GPS position is continually updated and stored on the interface cable itself to provide an additional level of redundancy over the embedded Integra ELT GPS data.
Traditional ELTs rely on an aircraft’s external antenna and GPS equipment, which is subject to failure in the event of an emergency. The Integra ELT, however, can operate independently of the aircraft to provide key positioning data through its internal antenna and GPS receiver.
With the Integra Smart Pack bundle, in the event that the Integra ELT’s internal GPS antenna is unsuccessful for any reason, the positioning coordinates from the Integra e-NAV NMEA will be used. This additional GPS redundancy will result in better location positioning and higher chance of rescue.
“McMurdo is delighted to continue its long history of aviation search and rescue innovation with the introduction of the Kannad Integra Smart Pack,” said Christian Belleux, head of McMurdo’s Kannad Aviation Business Unit. “The Integra Smart Pack is a must-have SAR [search-and-rescue] solution to help ensure accelerated rescue response in the event of an emergency and to ultimately save more lives.”
The Integra ELT Smart Pack is suitable for all types of aircraft with specific versions to support helicopters, general aviation planes and large commercial jets. Once activated, the Integra ELT transmits a distress signal to alert international rescue services to the emergency location via the global Cospas-Sarsat Search and Rescue satellite system, which has helped to save more than 37,000 lives since 1982.
The McMurdo Group is exhibiting this week at Heli Expo 2015, Booth 5465, in Orlando, Fla.
You may have heard about “NMEA data” with respect to GPS.
NMEA is an acronym for the National Marine Electronics Association. NMEA existed well before GPS was invented. According to the NMEA website, the association was formed in 1957 by a group of electronic dealers to create better communications with manufacturers. Today in the world of GPS, NMEA is a standard data format supported by all GPS manufacturers, much like ASCII is the standard for digital computer characters in the computer world.
The purpose of NMEA is to give equipment users the ability to mix and match hardware and software. NMEA-formatted GPS data also makes life easier for software developers to write software for a wide variety of GPS receivers instead of having to write a custom interface for each GPS receiver. For example, VisualGPS software (free), accepts NMEA-formatted data from any GPS receiver and graphically displays it. Without a standard such as NMEA, it would be time-consuming and expensive to write and maintain such software.
What makes NMEA a bit confusing is that there are quite a few “NMEA” messages, not just one. So, just like there are all kinds of GPS receivers with different capabilities, there are many different types of NMEA messages with different capabilities. Furthermore, NMEA data can be transmitted via different types of communications interfaces such as RS-232, USB, Bluetooth, Wi-Fi, UHF and many others.
NMEA Message Structure
To understand the NMEA message structure, let’s examine the popular $GPGGA message. This particular message was output from an RTK GPS receiver:
13 denotes number of satellites used in the coordinate
1.0 denotes the HDOP (horizontal dilution of precision)
495.144 denotes altitude of the antenna
M denotes units of altitude (eg. meters or feet)
29.200 denotes the geoidal separation (subtract this from the altitude of the antenna to arrive at the Height Above Ellipsoid (HAE).
M denotes the units used by the geoidal separation
1.0 denotes the age of the correction (if any)
0000 denotes the correction station ID (if any)
*40 denotes the checksum
The $GPGGA is a basic GPS NMEA message. There are alternative and companion NMEA messages that provide similar or additional information.
Here are a couple of popular NMEA messages similar to the $GPGGA message with GPS coordinates in them (these can possibly be used as an alternative to the $GPGGA message):
In addition to NMEA messages that contain a GPS coordinate, several companion NMEA messages offer additional information besides the GPS coordinate. Following are some of the common ones:
$GPGSA – Detailed GPS DOP and detailed satellite tracking information (eg. individual satellite numbers). $GNGSA for GNSS receivers.
$GPGSV – Detailed GPS satellite information such as azimuth and elevation of each satellite being tracked. $GNGSV for GNSS receivers.
$GPGST – Estimated horizontal and vertical precision. $GNGST for GNSS receivers.
Rarely does the $GPGGA message have enough information by itself. For example, the following screen requires: $GPGGA, $GPGSA, $GPGSV.
VisualGPSView screenshot. (Photo: VisualGPC LLC)
The following screen, focused on the time capabilities of GPS, requires a slightly different set of NMEA messages: $GPGGA or $GPRMC or $GPZDA, $GPGSA, $GPGSV.
NMEATime. (Photo: VisualGPC LLC)
The above screenshot examples are useful for the general GPS user. The $GPGST message is particularly useful for high-precision GPS mapping and surveying. In fact, I would say it’s a requirement for high-precision users. The reason is that GPS metadata is very important for the high-precision user as a method of assisting in determining the quality of a particular GPS coordinate. Typical GPS real-time metadata used in understanding the quality of the GPS coordinate include: PDOP, number of satellites tracked, correction method and horizontal/vertical standard deviation values. If a GPS receiver user has the ability to see this information in the field during data collection, they have a level of confidence in the precision of the GPS data they are collecting. If you’ve used RTK before, you probably recall the familiar horizontal RMS (HRMS) and vertical RMS (VRMS) values displayed on your data collection device. The $GPGST message generates those values.
DD.MMMMMMM, DDMM.MMMMM, or DDMMSS.SSSSS
One of the challenges in dealing with raw NMEA data (data not using a software like VisualGPS to decode it for you) is the format of the GPS coordinate. It’s not user-friendly. It’s expressed in DDMM.MMMMM; degrees, minutes and decimal minutes. To display the coordinate in a different format, there’s a useful Excel spreadsheet published by the UK Ordnance Survey.
UK Ordnance Survey Coordinate Calculator
To use the spreadsheet, simply enter the GPS coordinate in the format you have, and the spreadsheet will calculate and display the GPS coordinate in the other two formats.
Click here to download the UK Ordnance Survey Excel spreadsheet coordinate calculator.
A kickstarter campaign has launched for an NMEA dongle that connects any existing GPS receiver to iOS devices. The device connects and communicates with high-accuracy GPS/GNSS devices and other field sensors that emit NMEA data to iOS devices over Bluetooth, allowing users to collect data on an iPad or iPhone using one or more sensors in the field.
Primary functions include:
overriding the internal GPS on iOS device with the location data coming from the external GPS so all existing apps using internal location services can benefit from the increased accuracy without any changes to the app.
providing the ability to connect with other field sensors that emit NMEA-format data (such as underground cable locators, lasers, resistographs, and audiographs) simultaneously with a GPS so data from multiple sensors can be incorporated into the data-collection application.
Garg explained the need for the dongle on his Kickstarter page: “The accuracy and precision of the internal GPS on iPads and iPhones is highly unreliable — it works fine for navigational purposes but fails miserably for mapping and asset management applications. The accuracy varies in range from a few meters to a few hundred meters depending on operating conditions, and there is no easy way to reliably ascertain that. Tests have proven that the accuracy rating on the location data returned by Apple is more of a general estimate than a reliable metric.”
The NMEA dongle is business-card-sized, and has an internal battery and a long-range Bluetooth. The dongle plusg into an existing GPS receiver’s serial port or connects via bluetooth to transmit the GPS data to the iPad. This allows users to feed RTK/NTRIP data to their iOS device.
“We have tested our solution with most of the leading brands of GPS receivers available in U.S., including Trimble, Topcon, John Deere, Altus, Geneq, EOS, CHC,” developer Sharad Garg told GPS World, “on most of the popular networks that we could get access to, including the Leica, Trimble, MyWayRTK, a few state-run networks and of course Unavco. Our solution is compatible with all of them, so its a very generic product at this point compatible with just about all the different solutions out there.”
Garg said his team also designed the dongle so that it allows users to connect to sensors such as laser range finders, valve exercising machine, Resistographs or agricultural sensors that emit data in NMEA format. The National Marine Electronics Association (NMEA) specification defines the interface between various pieces of marine electronic equipment, a standard that permits marine electronics to send information to computers and to other marine equipment.
“We have actually improved the design very significantly to be very modular and be compatible with all sorts of GPS connections that might be offered by the different vendors out there,” Garg said.
This YouTube video shows the dongle’s RTK functionality.
GPS World published general articles on NMEA and RTK in Innovation:
By Sarang Thombre, Jussi Raasakka, Tommi Paakki, Francescantonio Della Rosa, Mikko Valkama, Laura Ruotsalainen, Heidi Kuusniemi, and Jari Nurmi
INNOVATION INSIGHTS by Richard Langley
WE HAVE A CAT. My wife and I do, that is. One with a voracious appetite. She likes to be fed on demand, even at the most inopportune times. Like three o’clock in the morning. No, it doesn’t help to close the bedroom door. Her squeaking (yes, some cats squeak) still wakes us up. I was designated as the one to get up in the night to feed her. Sometimes twice. Each night, every night. That got tiresome (literally) very quickly. Automation came to the rescue. We now have a microprocessor-controlled cat feeder, which rotates food compartments into the feeding position at pre-programmed times. Just fill up one or two of the compartments with “crunchies” before retiring, set the activation time to 3:00 a.m., say, and no more middle-of-the-night squeaking interrupting blissful sleep.
This is just one example of how automation — machines replacing (or supplementing) human activity to perform repetitive, difficult, undesirable, or even humanly-impossible tasks — can affect (and benefit) our everyday lives.
As noted on Wikipedia, two common types of automation are ones that involve feedback control, which is usually continuous and involves making measurements using one or more sensors and computing adjustments to keep the measured variables within a set range, and those that involve sequence control, in which a programmed sequence of discrete operations is performed, often based on system logic. An aircraft autopilot is an example of the former while our cat-feeding machine is an example of the latter. Some systems, such as Earth-orbiting satellites, can involve both types.
Automation applications range from the (now) mundane (such as point-and-shoot cameras, smart phones, home control, and factory assembly lines) to the (now) exotic (such as robots to assist the elderly and the infirm and robots to explore space). Laboratories have also benefited from increasing automation, making rapid clinical and analytical testing, for example, possible.
The testing of GNSS receivers can also benefit from automation. This work typically requires the active participation of humans to initiate, control, monitor, and terminate test cases. These manual operations are often inefficient and inaccurate, rendering the test results unreliable. Furthermore, accessing the internal signals of a receiver at different stages of processing is necessary to pinpoint the exact location of any anomalies. Using traditional black-box testing techniques, it is only possible to test the final outputs of a receiver. In this month’s column, we take a look at an automated test bench for analyzing the overall performance of multi-frequency, multi-constellation GNSS receivers. The system includes a data-capture tool to extract internal process information and controlling software, called the Automated Performance Evaluation Tool or AutoPET, which is able to communicate between all modules of the system for hands-free, one-button-click testing of GNSS receivers. Would my cat appreciate the benefit? Likely not, but GNSS engineers and scientists certainly will.
“Innovation” is a regular feature that discusses advances in GPS technology and its applications as well as the fundamentals of GPS positioning. The column is coordinated by Richard Langley of the Department of Geodesy and Geomatics Engineering, University of New Brunswick. He welcomes comments and topic ideas.
The prototype GNSS receiver developed at the Department of Electronics and Communications Engineering of Tampere University of Technology (TUT), called TUTGNSS, is now in the performance-testing phase. TUTGNSS is a GPS L1/L5 + Galileo E1/E5a dual-frequency dual-constellation receiver jointly developed by TUT and its international partners under two European Union Framework Programme research grants.
During the manual testing of the receiver, it was noticed that the results were often contaminated with errors due to imprecise time-keeping and inconsistent test environments.
It was also strenuous and time consuming to perform repetitive tests over multiple iterations, with decreasing personnel efficiency as the number of iterations increased. The aforementioned problems led to the results being deemed unreliable and unrepeatable. There was thus a need to innovate and automate the testing process and environment. In addition, there was also the need to study the signals as they flowed through the internal signal processing chain, so that the exact location of anomalies could be detected.
Currently, few solutions are available in the commercial and academic domains, which can perform end-to-end fully automated, yet customizable testing of GNSS receivers. A couple of commercial testing tools were recently unveiled, which claim to perform similar automated testing of GNSS receivers. However, these are not fully customizable by the end-user, having the limitation that they can be used only with their parent company’s proprietary signal simulators. Other commercial automated testing tools are available nowadays. However, they are targeted towards electronic systems other than GNSS receivers. It was due to these reasons that we decided to implement an in-house solution. Consequently, we devised the Automated Performance Evaluation Tool (AutoPET), along with a data capture tool.
AutoPET is implemented completely in software (Qt, with C++) and communicates with the receiver under test (RUT) via RS-232 and a National Marine Electronics Association (NMEA) protocol and with a commercial GNSS signal simulator via an RS-232 link. It handles the GNSS test cases with user-defined iterations and other system settings. AutoPET has already been used for making test runs on the TUTGNSS receiver with positive results. It is possible to initiate the overall testing of the receiver with a single button-click and the results are stored in the computer without any human intervention. Test scenarios currently included in the tool’s library are: time-to-first-fix (TTFF), position accuracy, acquisition sensitivity, tracking sensitivity, and reacquisition time. By changing the scenarios in this library, the tool can be used with different simulator models. Another innovative aspect of AutoPET is that it uses multi-threading to perform the receiver testing. Multiple software processing threads are necessary to keep track of the receiver operations and simulator feeds simultaneously, so that an appropriate interrupt can be generated when the receiver has performed the desired operation. This feature is explained in further detail later on.
Data Capture Tool (dCAP) is a hybrid (software-controlled hardware) entity capable of extracting the user-defined internal process data from the different modules (acquisition, tracking, bit decoding, and so on) of the GNSS RUT and stores it in a computer via a 100-Mbps Ethernet link. The dCAP hardware is independent of the receiver module (although implemented on the same softcore) and operates through minimal interference with the receiver operation. This data can then be post-processed to monitor and record the behavior of the receiver and to investigate any anomalies in its intermediate stages. An experimental version of dCAP has already been used to monitor the carrier-to-noise-density ratio (C/N0), carrier Doppler, and code delay from the internal tracking channels, and the raw GNSS signals in I/Q format entering the baseband processing unit (BPU) of the TUTGNSS receiver from its radio front end.
The benefits of AutoPET over state-of-art approaches are that it is portable (software platform independent), easy to use, suitable for testing most receivers using a variety of simulators (provided each of them can communicate with the outside world using some form of communication protocol), and its operational parameters are easy to modify through an external configuration file. dCAP is designed specifically for the TUTGNSS receiver; however, it can be easily replicated for most experimental embedded system receivers. Once implemented, dCAP offers a clear view of the internal operation of the receiver by accessing intermediate signals between the input and output terminals. The speed and size of data capture are limited only by the type of Ethernet connection and the size of the internal and external memories. Additional details of AutoPET and dCAP are provided in the next two sections of this article, while the third section describes the application of these tools in testing the GPS L1 operation of the TUTGNSS receiver.
Automated Performance Evaluation Tool
AutoPET is a software program developed using the Qt platform and the C++ language, which communicates between the GNSS receiver, signal simulator, and its associated computer through a remote PC that houses AutoPET. The set-up is shown in FIGURE 1. This figure also denotes the different communication protocols used between the different modules.
FIGURE 1. Block schematic of the AutoPET assembly.
At the center is the GNSS receiver, which accepts RF signals from the GNSS signal simulator. These signals represent signals from the sky in accordance with the scenario loaded in the simulator, and therefore represent unidirectional communication. On the other hand, the receiver communicates with the remote PC housing AutoPET using the NMEA-0183 protocol. This is bidirectional communication, as the receiver continuously updates its status via NMEA messages to AutoPET and, in turn, AutoPET sends a response/control command to the receiver. The receiver sends the $GPGGA NMEA message every second, and through reading this message, AutoPET can determine the current status (acquisition, tracking, position fix, and so on) of the receiver.
The TUTGNSS receiver has the capability to perform a cold start to initiate the next test iteration when commanded by AutoPET. For this purpose, we have designed a simple custom message string, which can be identified by the TUTGNSS receiver as a cold-start command. In response, the receiver sends a custom NMEA message, $GPTXT, which identifies that it has successfully performed a cold start. Performing a cold start involves erasing all a priori navigation-related information from the receiver memory. This includes erasing the ephemeris, almanac, and timing information, and ensuring that all satellite tracking is lost.
AutoPET communicates with the GNSS signal simulator through its controlling computer, called the Sim-PC (which runs the control software for the simulator). This communication is bidirectional using a 100-Mbps Ethernet link. The AutoPET library holds the scenario files, through which it remotely controls the simulator. In turn, the Sim-PC returns responses or error messages in the form of Extensible Markup Language (XML) strings to the AutoPET. The communication between the Sim-PC and the simulator is through its proprietary protocols.
AutoPET makes extensive use of multi-threading. The receiver, AutoPET, and the simulator function autonomously of each other and hence are independently controlled using their own processing threads running in parallel. Examples of some processing threads are:
Thread 1 – monitors the receiver operation through the received NMEA messages. This thread is responsible for identifying, for example, if the receiver achieves a position fix or if it performs a successful cold start.
Thread 2 – monitors the simulator through the received XML error messages and response messages from the Sim-PC. It is responsible for identifying, for example, if the simulator scenario is successfully set up or if the satellite signals are turned on and off when demanded by the test case.
Thread 3 – monitors the internal operation of AutoPET itself to check, for example, if a timer has expired or if the user performs any operation on the GUI during the progress of a test.
Each thread generates an internal software interrupt within AutoPET based on which future course of action has to be dynamically determined.
Later in the article, the application of AutoPET for single-frequency, single-constellation operation and testing of the TUTGNSS receiver is described. However, it can just as easily be applied for more complex, multi-frequency, multi-constellation testing. The scenarios are stored in the library of AutoPET, and they can be easily updated without requiring any changes in the tool itself. On the other hand, the receiver operation needs to be updated to perform position fixes with multiple signals and constellations. If the receiver allows updating of its operation mode using software commands, as is the case in TUTGNSS, these commands can also be included within AutoPET.
In the case of TUTGNSS, two configuration settings control the mode of operation and the manner in which it has to be turned on (cold, warm, or hot start) via a 32-bit control word. Table 1 describes the various options and the digital control word bits corresponding to each option. There are eight possible modes of operation that would require three bits to be uniquely represented. However, we have assigned five bits, to accommodate any planned future increase in operating modes. Similarly, there are three ways to turn on the TUTGNSS receiver, and they can be uniquely represented by two bits. Therefore, out of the 32 available bits, only seven bits are currently utilized. The rest of the bits are in reserve for future use. The mode selection bits are in least significant bit positions of the control word. For example, if the receiver should perform a position fix after a warm start using GPS L1 and Galileo E1 signals, the 32 bit control word would be 00000000_0000000_00000000_00100010. Using this control word at the beginning of every test, AutoPET can be used for a simple single constellation or more advanced multi-constellation testing of the receiver.
TABLE 1. Control words for multi-frequency, multi-constellation testing of TUTGNSS.
Data Capture Tool
The overall set up of dCAP is shown in FIGURE 2. The TUTGNSS receiver consists of the radio front end and the BPU implemented on an Altera Stratix-II development board. This board consists of the NIOS-II softcore embedded processor controlled by the MicroC operating system within a field-programmable gate array (FPGA) board. The hardware is programmed using VHSIC Hardware Description Language (VHDL) and consists of the system entity and a few peripheral entities, such as a phase-locked loop (PLL), which are not shown in the figure for sake of simplicity. The system entity consists of (among others) two software-controlled hardware entities, one for the TUTGNSS receiver BPU and the other for the dCAP server, called CPU-0 and CPU-1 respectively. The Control-PC is responsible for the overall programming of the FPGA board through a USB link. It also holds a Qt-based user interface acting as the dCAP client implementation.
FIGURE 2. Overall block schematic of the dCAP assembly.
The dCAP client (in the Control-PC) establishes an Ethernet connection with the dCAP server (on the FPGA) and requests a user-specified internal data sample. As an example, let us assume the user requests raw I/Q samples input to the TUTGNSS BPU from the radio front end. The dCAP server software communicates with the TUTGNSS software, which in turn allows the dCAP server hardware access to the requested data from the appropriate region of the TUTGNSS hardware, similar to how a signal across a resistor on a dense printed circuit board is viewed by placing oscilloscope probes across it. The only limitation with dCAP is that the user has to predict, in advance, which internal data parameters are of interest and create access points within the correct hardware entities. The dCAP server hardware will connect to the respective access point when demanded by the client.
This data snapshot is first buffered in the local shared memory entity on the FPGA board due to the requirements of speed, size, and time synchronization. The dCAP server software is responsible for transferring this data from the internal memory to the Control-PC through the Ethernet link. The data is stored on the Control-PC hard drive in the form of a *.bin file. Therefore, the size of each data-packet that can be accessed at a time is limited by the size of the FPGA memory entity, while the total data size is limited only by the size of the hard drive of the Control-PC. The speed of data capture is restricted by the maximum speed of the Ethernet link between the dCAP client and server.
In FIGURE 3, the internal operation of the dCAP server is illustrated, assuming that we would like to access the raw samples from the radio front end. The first block that the samples enter inside the TUTGNSS BPU is the baseband converter unit (BCU). This is where the dCAP hardware probes listen in on the signal samples. Through these probes, the signals are diverted to the first-in-first-out (FIFO) data collector on the dCAP server (CPU-1) in addition to their usual route through the further baseband processing blocks of the receiver. After the FIFO collector, the data undergoes clock arbitration, time synchronization, and master-slave synchronization, before being buffered into the on-chip Synchronous Dynamic Random Access Memory (SDRAM), where it waits until the dCAP server transfers it through the Ethernet-based local network to the requesting dCAP client within the Control-PC. In the case where different internal data has to be monitored, the probes simply reorient to the correct access point within the correct hardware entity (for example, to monitor the signal C/N0, the probes access the tracking loops).
FIGURE 3. Block schematic of an example of the dCAP internal operation.
TUTGNSS Receiver Performance Testing
During the GPS L1 performance testing of the TUTGNSS receiver, the reference receiver position in the simulator was set randomly. Ionosphere and troposphere errors were turned off in the simulator. On average, 100 iterations were performed for each test, and the total duration to complete all tests was two weeks. dCAP was used in monitoring the tracking channels and extracting information such as the C/N0, carrier Doppler, and code-delay estimates for the satellites being tracked. Access to these parameters enabled testing the acquisition and tracking sensitivity of the TUTGNSS receiver, thus confirming the results of the tests performed using AutoPET.
Acquisition Sensitivity. Acquisition sensitivity for the TUTGNSS receiver was measured to be -141.5 dBm via AutoPET and -141 dBm via dCAP. Each coherent integration interval was 4 milliseconds, and 256 such intervals were integrated non-coherently. Using AutoPET, 100 acquisition iterations were performed at every power level, and the average number of satellites acquired was recorded. It was observed that no satellites were acquired at -142 dBm. The acquisition sensitivity test using dCAP involved extracting the carrier Doppler and code-delay estimates. A successful acquisition was assumed only if the code-delay estimate error was less than ±1 chip (300 meters) and the carrier Doppler estimate error was less than ±150 Hz. Based on these criteria, 96.72% of acquisitions were found to be successful when the satellite power was maintained at -141 dBm in the simulator as shown in the histograms in FIGURES 4 and 5.
FIGURE 4. Code-delay estimate within ±1 chip (300 meters).
FIGURE 5. Carrier Doppler estimate within ±150 Hz.
Tracking Sensitivity. Tracking sensitivity for the TUTGNSS receiver was measured to be -151 dBm via both tools, assuming a coherent integration interval of 20 milliseconds. Using AutoPET, 100 tracking iterations were performed at every power level and the average number of satellites tracked was recorded. Using dCAP, this test was performed by selecting one satellite and observing how the receiver C/N0 tracked this satellite during high and low signal power conditions. Twenty tracking iterations of 90 seconds each were performed for a particular satellite. In each iteration, the satellite power in the simulator was maintained at the nominal condition of -130 dBm (equivalent to 38 dB C/N0 in the receiver) for the first 30 seconds. Subsequently, the power of the satellite was dropped to -151 dBm (equivalent to 17 dB C/N0 in the receiver).
As visible in Figure 6, the receiver was able to continue tracking the satellite at -51 dBm in 19 out of the 20 iterations. In the case where tracking was lost, the C/N0 can be seen to diverge rapidly to 0. To make sure that in the rest of the 19 cases the receiver was really tracking the satellite at low power, the power of the satellite was increased again after an additional 30 seconds. In each of the 19 cases, the receiver successfully continued to track the satellite.
FIGURE 6. Tracking C/N0 in one tracking channel using dCAP.
3D Position Accuracy and TTFF. Computation of the position fix was performed using a least-squares algorithm without any filtering. Using only AutoPET, 100 position fix iterations were performed and the average 3D error in meters was computed. Within the same test case, the time for achieving a position fix was also recorded. The initial (0–30 seconds) position fix estimates are not very accurate. This is because only the first four acquired satellites are used for the position computation. As more satellites are acquired and tracked, their inclusion into the computation gradually improves the position accuracy to within 1 meter. The average TTFF was computed to 60.59 seconds.
Validity of C/N0 Estimator. FIGURE 7 presents a comparison of C/N0 measurements between the TUTGNSS receiver (extracted using dCAP) and a commercial receiver. The input power from the simulator was varied between -130 dBm and -151 dBm with steps of around 2 dB for 10 seconds each. The C/N0 readings from the two receivers were measured at each power level and plotted on the same scale. The reference power level represents the C/N0 readings of a hypothetical (ideal) receiver with zero radio front-end losses. As the figure shows, on average there is close conformance between the estimated values of C/N0 in the two receivers. The difference between the two receivers and the reference is approximately 5 dB, which includes radio front-end noise and other losses. The TUTGNSS receiver displays lower C/N0 estimation peak-to-peak inconsistency than the commercial receiver.
FIGURE 7. C/N0 measurement using dCAP: Comparison between TUTGNSS, a commercial, and a hypothetical receiver.
Other Uses of dCAP. During initial prototype validation, we noticed that satellite tracking was inconsistent even under high C/N0 conditions. dCAP was used to extract detailed baseband tracking information that helped to identify the source of the problem: signal anomalies due to insufficient clock buffering on an experimental RF front end, as shown in FIGURE 8. Such anomalies would have been impossible to detect with traditional black-box testing practices. Once the problem was rectified, dCAP was used once again to monitor the RF front-end signals and performance of the baseband tracking loops, where FIGURES 9 and 10 show a marked improvement in the receiver signal processing and satellite tracking performance.
FIGURE 8. Signal anomaly in the Q-branch signal due to insufficient clock buffering in the experimental RF front end: detected using dCAP.
FIGURE 9. Code Doppler extracted from one tracking loop.
FIGURE 10. Carrier Doppler extracted from one tracking loop using dCAP.
Conclusion
In this article, we have demonstrated the results of the TUTGNSS prototype receiver testing using AutoPET and dCAP. Results were presented, analyzed, and conclusions drawn for the GPS L1 performance of the receiver. Furthermore, the procedures can be easily replicated through software modifications for testing more advanced multi-frequency, multi-constellation modes of the receiver.
Added to the benefits of automation in terms of improved accuracy and personnel efficiency, the proposed AutoPET is a cost-effective solution to anyone working on GNSS receiver technology to understand its most important performance parameters. This tool is portable (software platform-independent), easy to install, and easy to execute on any computer with the basic scientific software. From an academic point of view, dCAP is useful for teaching the spectral characteristics of GNSS signals at every stage from deep inside the receiver to researchers or university students in laboratory exercises. Together, these tools have assisted in the complete characterization of the TUTGNSS receiver at TUT, and can be easily adapted, enhanced, and applied to other research-based receivers as well. In other words, the proposed research has an academic as well as practical appeal.
Acknowledgments
This research work received support from the Tampere Doctoral Programme in Information Science and Engineering (TISE), Nokia Foundation, and the Ulla Tuominen Foundation. It has also been partially supported by the Academy of Finland (under the projects: 251138 “Digitally-Enhanced RF for Cognitive Radio Devices”, and 256175 “Cognitive Approaches for Location in Mobile Environments”). We wish to gratefully acknowledge each of these institutions. This article is based on the paper “Automated Test-bench Infrastructure for GNSS Receivers – Case Study of the TUTGNSS Receiver” presented at the 26th International Technical Meeting of the Satellite Division of The Institute of Navigation held in Nashville, Tennessee, September 16–20, 2013.
Manufacturers
The tests described in this article used a Spirent Federal Systems STR4500 multi-channel GPS/SBAS simulator and a u-blox AG EVK-5P GNSS receiver evaluation kit with a LEA-5P receiver module.
SARANG THOMBRE is a GNSS research scientist in the Department of Navigation and Positioning at the Finnish Geodetic Institute (FGI), Helsinki.
JUSSI RAASAKKA is a GNSS R&D scientist at Honeywell International s.r.o. in the Czech Republic.
TOMMI PAAKKI is a teaching assistant and a doctoral student at the Department of Electronics and Communications Engineering, Tampere University of Technology (TUT).
FRANCESCANTONIO DELLA ROSA is the project manager of the Multitechnology Positioning Professionals (MULTI-POS) Marie Curie Initial Training Network and a research scientist at TUT.
MIKKO VALKAMA is a full professor and the head of the Department of Communications Engineering at TUT.
LAURA RUOTSALAINEN is the deputy head of the Department of Navigation and Positioning and aspecialist research scientist at FGI.
HEIDI KUUSNIEMI is a professor and the acting head of the Department of Navigation and Positioning at FGI.
JARI NURMI is a professor in the Department of Electronics and Communications Engineering at TUT.
FURTHER READING
• Authors’ Conference Paper
“Automated Test-bench Infrastructure for GNSS Receivers – Case Study of the TUTGNSS Receiver” by S. Thombre, J. Raasakka, T. Paakki, F. Della Rosa, M. Valkama, and J. Nurmi in Proceedings of ION GNSS+ 2013, the 26th International Technical Meeting of the Satellite Division of The Institute of Navigation, Nashville, Tennessee, September 16–20, 2013, pp. 1919–1930.
• TUTGNSS
“TUTGNSS – University Based Hardware/Software GNSS Receiver for Research Purposes” by T. Paakki, J. Raasakka, F. Della Rosa, H. Hurskainen, and J. Nurmi, in Proceedings of Ubiquitous Positioning Indoor Navigation and Location Based Service (UPINLBS), 2010, Helsinki, Finland, October 14–15, 2010, doi: 10.1109/UPINLBS.2010.5654337.
“Software-based GNSS Signal Simulators: Past, Present and Possible Future” by S. Thombre, E.S. Lohan, J. Raquet, H. Hurskainen, and J. Nurmi, in Proceedings of ENC GNSS 2010, the European Navigation Conference 2010, Braunschweig, Germany, October 19–21, 2010.
NMEA 0183, The Standard for Interfacing Marine Electronic Devices, Ver. 4.10, published by the National Marine Electronics Association, Severna Park, Maryland, June 2012.
Advanced Navigation has released Spatial Dual, its new dual-antenna GNSS/INS. Spatial Dual is a ruggedized miniature GPS-aided inertial navigation system and AHRS that provides accurate position, velocity, acceleration and orientation under demanding conditions. It combines temperature calibrated accelerometers, gyroscopes, magnetometers and a pressure sensor with a dual-antenna RTK GNSS receiver. These are coupled in a sophisticated fusion algorithm to deliver accurate and reliable navigation and orientation, the company said.
Spatial Dual contains the Trimble BD982 GNSS receiver, which is a triple frequency dual-antenna RTK GNSS receiver. Using dual-frequency moving baseline RTK, Spatial Dual is able to provide heading accuracy of less than 0.1 degrees using its dual antennas. The dual-antenna heading works while both stationary and moving and allows for very accurate heading in both slow moving and 3D vehicles, where equivalent single antenna systems must rely on magnetic heading. An additional benefit of the dual antennas is the ability to measure slip angle to within 0.2 degrees.
Spatial Dual supports all of the current and future satellite systems, including GPS, GLONASS, Galileo and BeiDou. In addition, Spatial Dual supports RTK for centimeter positional accuracy and the recent Omnistar G2 network for 10 centimeter accuracy.
Spatial Dual provides position, velocity and orientation at rates up to 1000 Hz for highly dynamic applications. When Spatial Dual loses a GNSS fix it continues to navigate using dead reckoning inertial navigation to provide seamless navigation data through tunnels and other outage situations.
Spatial Dual is housed in a precision marine-grade aluminum enclosure that is waterproof and dirtproof to the IP67 standard and shockproof to 2000g, allowing it to be used in tough conditions.
Spatial Dual supports a wide range of peripherals including odometers and wheel speed sensors for ground vehicle navigation, DVLs and USBLs for underwater navigation and many other external sensors. It supports both industry standard NMEA output and an efficient binary protocol.
