Talk:NMEA 0183

div

Currently, the article doesn't explain how raw GPS satellite data is converted into a stream of NMEA 0183 data and how this stream contains information about where on the world this GPS receiver currently is. I think this would be a great addition to this article, as GPS localization is the most important use of NMEA 0183. --Abdull 09:39, 29 March 2007 (UTC)

The proper place for that discussion is in the GPS article; once the GPS receiver has done it's magic, formatting the results is trivial. NMEA is used for things other than GPS, too, so an "in depth" (pardon the pun) description belongs elsewhere. --Wtshymanski 17:53, 29 March 2007 (UTC)

I agree --Steinmb 04:03, 9 August 2007 (UTC)

Protocoll

I found this article extremely confusing - and left more unanswered than said.
(a) It specifies a sentence structure, then gives what appears to be an example - but that example has very little semblance to the specified protocol

(b) I know that there are multiple sentences possible - but there is no mention in the article about which sentences equipment emit, and how they emit them. Is there some 2-way communication where a listener can ask for specific sentences? Or does a talker simply emit as many sentences as it knows how, in regular sequence, and it is up to the listener to find and parse whatever sentences it wants? Gary Turner 22:51, 17 April 2007 (UTC)

All devices have diffrent set of sentences it transmitt and are able to receive, impossible to litst them all here :) No it is noe possible to poll the eq. asking for data. Normally you can finetune what sentences that are to be sent and what taker to use (ID) like GPS uses GP, Gyro uses HE, the list is long. --Steinmb 04:03, 9 August 2007 (UTC)

Update speed

(c) Do things that talk NMEA talk all the time? Is that the default behaviour, or do they need to be addressed somehow to talk? Gary Turner 22:51, 17 April 2007 (UTC)

Normally talk "all the time" but there is exeptions. Echo sounders normally transmitt as soon new data is available, in transmitting with higher update speed on shallow water then on hundreds of meter deep. --Steinmb 04:03, 9 August 2007 (UTC)

(d) Under vendor extensions - where you say "special messages to the standard NMEA" - do you mean "special messages in addition to the standard NMEA" Gary Turner 22:51, 17 April 2007 (UTC)

(e) It would probably help to provide a link to the specific piece of equipment you mention. Gary Turner 22:51, 17 April 2007 (UTC)

The 'Serial configuration' section has nothing to do with the NMEA 0183 protocol. The values stated are merely default settings. --193.163.1.101 10:56, 30 May 2007 (UTC)

Serial Configuration

The listed serial communications specification is extremely important - it's the actual, OFFICIAL configuration specified in the NMEA 0183 standard v. 2.01). Any other use of the sentence structure at different baud rates, etc. may be "NMEA-like", but it would not be NMEA 0183 strictly speaking. 155.212.113.117 13:34, 16 July 2007 (UTC)

I think we need to add the diff between ver. 1.5 2.0 2.01 AND that different equipment is transmitting with different HZ (update speed) and bitspeed (2400-57600bps). I also think it is a problem that the NMEA is rederected to NMEA183. What about NMEA 0180, 0181, 0182? I think we should link to IEEE RS-422 standard --Steinmb 04:03, 9 August 2007 (UTC)

Important Error in Protocol Spec

The article specifies that a NMEA-0183 sentence is terminated with a <CR><LF>.

THIS IS NOT CORRECT!

There is NO <CR> specified in the official document. A NMEA-0183 sentence is terminated by a <LF> ONLY. (In Unix-speak, this would be a Newline, the canonical Unix line terminator.) Software that expects to find a <CR> will be rudely surprised when it attempts to process real NMEA-0183 data. —Preceding unsigned comment added by 67.98.153.113 (talk) 16:23, 25 January 2008 (UTC)

Actually, the <CR><LF> terminator is correct. I have a copy of the 1994 NMEA 0183 Standard in front on me, and I can clearly see several places where this is specified. For instance, see page 9 of this version, section 5.3, last paragraph. It's been like this since I care to remember. Also, I'd like to point out to everyone that the checksum is OPTIONAL for most data sentences unless specifically required by the individual data sentence (like RMA, RMB, RMC). —Preceding unsigned comment added by 75.127.151.42 (talk) 20:14, 4 February 2008 (UTC)

More sentence info...

I found this page not too long ago and I thought it might be a useful external link;
I'll leave it up to you folks.
http://aprs.gids.nl/nmea/
--Samahnub (talk) 04:35, 25 June 2008 (UTC)

checksum

The article leaves unclear whether there should be a comma between the last field and the asterisk that precedes the checksum. It offers two conflicting examples:

Example 1: $GPAAM,A,A,0.10,N,WPTNME*32

Example 2: GLL,4916.45,N,12311.12,W,225444,A,*1D<CR><LF>

—Ksn (talk) 17:13, 19 June 2009 (UTC)

A comma between the last value and the checksum is an indication that a null data field is present. That is a field with no value supplied. So the answer to your query is that no comma precedes the checksum if the last fields value is supplied. Both the examples are correct, although confusing.--195.33.114.129 (talk) 12:02, 30 October 2009 (UTC)

Suspicious example

Obsolete request
This is a request from May 2010. It's not been resolved for over 10 years, so I close it. --CiaPan (talk) 15:05, 29 August 2021 (UTC)
Anonymous user 84.19.238.82 added a compound, multi–line 'message' in this edit. Can anyone prove or disprove it is correct, please?! Compared to the rest of the article, as well as the sources in References and External links, it seems absurd. As the article (or Google*) says: But in the 'example'... each message starts with a dollar sign and ends with CR/LF there's only one line starting with $, but it contains no data before CR/LF no other line starts with $ and the last line contains an ampersand sign alone, not mentioned anywhere as an NMEA protocol symbol the first data field in each message is the 5-character code built with 2-char system type (GP or GL) and 3-char message type all lines have 3-char prefix with no GP or GL indicator *GPGSV is the NMEA–0183 message type for GPS satellite (SV) data there are several lines of 'type' NSV, not GSV, described as SV data (however words pair GPNSV+NMEA seems absent in the Net, and NSV+NMEA all seem a quotations from Wikipedia...) *GPGSV contains: № of GPGSV lines, sequent number of the current GPGSV line, № of SV in view, SV ID, its elevation and azimuth and signal strength ratio, for up to 4 satellites NSV lines contain only zeros, except each says there is different № of NSV lines (including zero, denying itself!) and an undocumented D or N at the end CiaPan (talk) 21:47, 7 May 2010 (UTC) 10 days passed and nobody confirmed the commented part is valid. On the other hand I got a response in the WP:RD/C (see archive) stating that This is a perfect example of something that is beyond the role of an encyclopedia article. The article (...) shouldn't really be duplicating or describing the official standard to that level of detail. Such content is prone to error, isn't really encyclopedic, and is difficult to verify, so I removed it. Below is the removed part in case anyone wants to support it with appropriate references or at least give it a more encyclopedic form and copy back to the article. --CiaPan (talk) 21:42, 18 May 2010 (UTC) Deleted “ A compound string from the NR203 GPS Receiver containing multiple messages. The actual messages decoded include: ZDA – Standard NMEA $..ZDA Time & Date message GLL – Standard NMEA $..GLL Geographic Position – Latitude/Longitude message NSV – NMEA message containing individual satellite information. Typical ASCII string $<CR><LF> MRK,0<CR><LF> ZDA,123336.8069,17,06,2001,13.0<CR><LF> GLL,4916.45,N,12311.12,W,225444,A,*1D<CR><LF> VTG,218.7,T,2.38,H,0.18,V<CR><LF> SGD,-1.0,G,-1.0,M<CR><LF> SYS,3T,9<CR><LF> ZEV,0.28745E-006<CR><LF> NSV,2,00,000,00,0.0,00.0,00,00,D<CR><LF> NSV,7,00,000,00,0.0,00.0,00,00,D<CR><LF> NSV,28,00,000,00,0.0,00.0,00,00,N<CR><LF> NSV,1,00,000,00,0.0,00.0,00,00,D<CR><LF> NSV,13,00,000,00,0.0,00.0,00,00,D<CR><LF> NSV,4,00,000,00,0.0,00.0,00,00,N<CR><LF> NSV,25,00,000,00,0.0,00.0,00,00,N<CR><LF> NSV,0,00,000,00,0.0,00.0,00,00,N<CR><LF> NSV,11,00,000,00,0.0,00.0,00,00,D<CR><LF> NSV,0,00,000,00,0.0,00.0,00,00,N<CR><LF> & Description Form Field Start characters $ 0 UTC of position fix ZDA,hhmmss.ssss,dd,mm,yyyy 1 Latitude in degrees/minutes llll.ll 2 Direction of latitude (N or S) 3 Longitude in degrees/minutes yyyyy.yy 4 Direction of longitude (E or W) 5 Number of SVs NSV 6 Satellite ID number NSV,n,… 7 Repeated for "n" sats End character & „ References

Closed. --CiaPan (talk) 15:05, 29 August 2021 (UTC)

Compatibility section

The Compatibility section is clearly just a commercial. I suggest that section be deleted. Its like saying "people who use" SPI-BUS, or PCI-bus or any technical standard. NMEA is so simple there is no reason to have this section. -cellurl — Preceding unsigned comment added by Cellurl (talk • contribs) 12:14, 24 March 2011 (UTC)

Checksum clarification

I've added some C code to clarify how the xor works for checksum generation. By looking at different forums, searching for the answer myself, I found that it was pretty unclear to most how the checksum could be generated. The question was how you could xor a string and not just two intergers. This is clarified now.--Tjringsmose (talk) 13:09, 28 September 2012 (UTC)

Thanks for the contribution. I do however encourage you to read WP:HOWTO and WP:OR and adjust the contribution to conform to these policies. -—Kvng 14:32, 1 October 2012 (UTC)

I do not think this constitutes original research, any more than any other illustration that is original work of a wiki user. The only thing I did was create a loop that would xor two bytes and step through a string. The output, which is easily reproduced, corresponds to all the sources. Tjringsmose (talk) 12:25, 2 October 2012 (UTC)

The code was unnecessarily complicated (could even say: obfuscated), thus too long. And it was incorrect – could produce wrong output. I have fixed it. [1]
Anyway in my opinion it's better to explain how the checksum is computed than to give the code, so I tried to clarify it a bit more. [2] The code is prone to many kind of errors and might be unreadable for people who don't know the particular programming language. On the other hand a clear explanation allows anyone to implement the routine in their favourite language/tool. --CiaPan (talk) 09:44, 4 October 2012 (UTC)

Shouldn't a clarification of something covered in http://en.wikipedia.org/wiki/Checksum appear in that article?? Checksum isn't just specially for to NMEA 0183 :-) 90.174.2.115 (talk) 18:55, 22 December 2017 (UTC)