I just began testing iCE and it looks great!
I connected it on my boat network to iKommunicate over UDP. I am located at longitude W073 21.705’ - the message doesn’t have a leading zero, so iCE interprets it as 732 degrees instead! I am attaching two screenshots
Let me know if you need further info.
(New users can only attach one image… you’ll have to take my word that the message received was: $GPGLL,4054.377930,N,7321.704102,W,150151 - maybe not the exact message, but captured with WireShark)
The NMEA 0183 specification requires the leading zero in this case, so technically that sentence is invalid and should probably be ignored. However, we’ll consider the ramifications of accepting it… (It certainly should NOT result in a longitude of 732°W and we will fix that one way or another!)
Are you receiving a checksum with this sentence? (It’s the part after an asterisk…your other sentences have them, but I can’t tell from the screenshot if your GLL sentence has one.) It would be easier to justify accepting the malformed longitude if we could verify the checksum as that would mean we received the complete sentence and didn’t miss a digit.
Yup, there is an checksum, and I’m guessing it is OK or else you would probably throw the whole message out. FYI, I also tried an iOS App Seaiq which has a NMEA server option and it also sent the message without the leading zero. Must be an east coast thing to leave it out as we only have 2 significant digits of longitude!
In any case, using the decimal point to separate the fields will leave out any ambiguity.
By the way, I just took a boat ride, and used Location Services for position, but UDP for everything else. Worked well; got AIS targets, wind speed, depth, etc. captured a track. very cool!
I just tested Build 52 on a 60nm run yesterday, and can confirm that this bug was fixed. Thank you!
