The name NMEA does not refer to a single string type. There are quite a number of different string formats, called NMEA sentences. A basic problem with NMEA is that most 3rd party GPS receivers send different NMEA sentences one after the other, and usually there is no fixed timing relationship at which point in time a certain NMEA sentence is sent after the beginning of a new second. So if an application receives a particular string it doesn't know if the string has been send at the beginning of a second, or at the end, or shortly before the second rolls over to the next one.
That's why usually a 1 PPS signal is required with NMEA to get this working properly. The NMEA sentences indicate the absolute time which is sent at a random time during the second, and the 1 PPS signal indicates when a new second starts, so the combination of both is required for good time synchronization.
The NTP software can directly evaluate NMEA sentences, but it can be pretty tricky to set this up properly, depending on the GPS receiver model, the way the NMEA sentences are transmitted by that receiver, which NMEA sentences are actually transmitted, and which are to be evaluated for timing. Finally you have to determine the baud rate. Originally 4800 baud was used for NMEA, but nowadays also faster transmission speeds are used to be able to transfer more information.
So you first have to investigate to find out how your GPS receiver behaves.
If a 1 PPS signal is available from the receiver it would be even trickier to set this up under Windows since unlike Linux and some other operating systems, Windows has no native support for 1 PPS input signals.
Example configuration where the NMEA driver handles both the serial string and the 1 PPS signal :
server 127.127.20.0 mode 17 minpoll 5 maxpoll 5 # RMC message 9600 fudge 127.127.20.0 time2 0.130 flag1 1 flag3 1 # PPS enabled
Example configuration where the NMEA driver handles the serial string, and the ATOM driver handles the 1 PPS signal:
server 127.127.20.0 mode 17 minpoll 5 maxpoll 5 prefer # RMC message 9600, 'prefer' is for the ATOM driver fudge 127.127.20.0 stratum 10 time2 0.130 # NMEA offset server 127.127.22.0 minpoll 5 maxpoll 5 # ATOM driver used to evaluate PPS signals fudge 127.127.22.0 flag3 1 # PPS enabled
By default, the NMEA driver provided by ntpd tries to open a device /dev/gpsn, where n is the unit number
which has to match the unit number in the server example configuration lines above.
On Unix-like systems, a symbolic link can be created which points to a real serial port device, e.g.
/dev/gps0 can point to /dev/ttyS9 on a Linux system.
On Windows, the unit number is directly mapped to a COM port number, e.g.
/dev/gps2 is mapped to COM2.
This implies that /dev/gps0 can not be configured / used on Windows since COM0
is not a valid COM port name on Windows.
Here is some basic description how ntpd can be configured to work with NMEA:
https://www.meinbergglobal.com/download/ntp/docs/html/drivers/driver20.html
And here is some information by David J. Taylor who has done a lot of testing on Windows:
http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html
— Martin Burnicki martin.burnicki@meinberg.de, last updated 2023-01-25