Added NMEA-183 Functionality
Closed this issue · 1 comments
The current library is aimed entirely at background reading of NMEA-183 sentences from a GPS source, coming in over a serial port, then parsing those sentences to extract GPS information and make it available to the calling sketch. It also works well to acquire any other NMEA-183 sentences, but doesn't parse them (yet). I see two related issues:
- It is difficult to test software at your desk to respond to expected GPS movements of a project out in the world.
- There is no support for a larger NMEA-183 operation that could involve listening and responding to multiple talkers using more sentences, e.g. a GPS chartplotter and wind speed / direction instruments.
build(): Adding a build function that's the reverse of parse() would allow the easy simulation of the periodic receipt of NMEA sentences from a moving target. It would create sentences based on the current values of the underlying variables in that instance of the class. It would require managing two instances of the class, one to provide the simulation values and the other to receive the simulated sentences and set its own values accordingly. #105 provides the support for multiple instances.
Extended parse(): NMEA-183 includes a lot more than just GPS sentences, covering the wide range of marine instrumentation variables, many only of interest to sailors. Adding parsing for more sentences is straightforward, but increases the size requirements of the library by adding more code and data space to hold the additional values. This would be especially problematic for AVR applications with tiny memory spaces.
Options
- Build another library that would work alongside the GPS library to build and parse more sentences. (I am most of the way there for a project of my own.)
- Add check() functionality to test a sentence is well formed, e.g. starts with $ and ends with a valid checksum. This would address #96 and let parse concentrate on well formed sentences.
- Add build() functionality to the current library for just the sentences currently supported by parse().
- Add build() and extended parse() functionality for sentences I care about, with a framework for managing additional sentences if others want to add them, and a mechanism to exclude the extensions from compiles on small processors or when the user doesn't want them.
ARDUINO_ARCH_AVR could be used to control conditional compilation of the extensions. Is there a mechanism for a user sketch to insert a #define into the compilation of libraries?
#ifndef ARDUINO_ARCH_AVR
#define NMEA_EXTENSIONS // if defined will include more NMEA sentences
#endif
I would welcome any suggestions before moving on with implementation.