Add NMEA-over-UDP support

[kpfleming]

ubxtool can now forward NMEA sentences as UDP datagrams; this can be used to feed them to gpsd, avoiding the need for gpsd to have its own connection to the GPS receiver.

The --udp-nmea command line argument accepts an IPv4/6 address-and-port as the destination to receive the datagrams.

The behavior of the --keep-nmea command line argument has also been changed; it now ensures that NMEA is enabled in the receiver, instead of assuming it is enabled by default.

Usage is straighforward; if ubxtool and gpsd are running on the same system, then choose a port number for the UDP connection (there is no default or standard port number). This example uses port 4242, and assumes that the u-Blox receiver is connected to a Raspberry Pi's serial port and PPS GPIO pin.

To launch ubxtool:

ubxtool --gps --port /dev/ttyAMA0 --station 1 --udp-nmea 127.0.0.1:4242

To launch gpsd:

gpsd -n udp://127.0.0.1:4242 /dev/pps0

To verify that gpsd is receiving the NMEA data, use cgps -s or one of the other gpsd client tools.

[mahtin]

This (in my mind) is very welcome code; however, I would highly recommend the code be reengineered into a separate source code file. I would recommend a NMEA processing file and a UDP processing file (even if only includes just a few lines). A quick read thru the committed edits seems like this is a very useful addition to the codebase.

I would also recommend you add your comments above into a README edit such that the change/commit becomes core documentation.

I also think this code needs to be tested on both a USB and a piggybacked RPi install such that the serial port communications can be confirmed for all setups. I will try to do that over the coming weekend.

[kpfleming]

Thanks! I am definitely aware that the code needs some improvement... the way that I've abused UBXMessage is just... abusive :-) I decided to at least get this first working version posted for comment and to see how much interest there was before diving in to refactoring and cleanup. Most likely, there needs to be a ProtoMessage base class and UBXMessage/NMEAMessage subclasses, which would align well with moving some of the code out into separate translation units.

For reference, my initial testing of this code was with an RPI 4B using a USB connection to a NEO-M9N module; now that the code is in use I've disconnected the USB connection and the RPi and module are communicating over ttyAMA0/UART1, so at least in my system it's been used with both USB and UART connections.

[mahtin]

I choose not to mention your abuse of UBXMessage(). 😀

[kpfleming]

Question: is it reasonable to require a new enough compiler/library to be allowed to use std::variant? If so, I'd do that for the protocol message classes instead of using inheritance when there really isn't any shared behavior.

[kpfleming]

Also, tomorrow I'm going to experiment with a simpler (and less invasive) approach, which is to just feed the UBX protocol binary messages over UDP. gpsd understands those too, so as long as ubxtool hasn't done some sort of weird configuration which causes those messages to be missing something that gpsd requires, it should be able to harvest what it needs without any access to the NMEA messages at all.

[kpfleming]

Closing in favor of #143.