Messages

For the record, here's a link to the AOSP bug: //http://code.google.com/p/android/issues/detail?id=21163.

Thinking further about this, I have a feeling that this may be related to an Android feature where the system uses sensory data in order to "improve" positioning.  This would explain why (only) such fields as coordinates, elevation, and heading are affected.  I guess I'll file a bug with Google.

Thanks again!

OK, thanks for the clarification.  Yes, I do use the phone's internal receiver and now understood that you receive all location-/GPS-related information via Android APIs, thus completely bypassing the NMEA generated by the receiver (aside from writing it to the log file).

I forgot: If this is true and the "comma sentences" are the same ones received and parsed by Locus, how come Locus ends up with valid positions?  I'd expect its parsing to fail as well due to the illegally-formatted sentences.  Can you confirm that Locus's parser will correctly parse, e.g., GPGGA sentences such as the one on line 497 of the paste?

This means you do not in particular reassemble/output sentences field by field?

If this is so, the issue really must be with the underlying infrastructure.  I guess I'll have to Google some more in order to determine whether this has cropped up for others (and unrelated to Locus) as well.

Thanks.

Hello,

I use (up-to-date) Locus Pro with NMEA logging enabled, which works well -- in principle.

Yesterday, it recorded an NMEA log in which at some point, the decimal delimiter within sentence fields changed from "." to ",".  My device is set to German, where a comma is the default decimal delimiter.

I can't imagine that my Samsung Galaxy S II's SiRF receiver is outputting this directly; rather, I assume Locus Pro "touches" the sentences received, having locale issues come into play.

I've uploaded the NMEA log in question to PasteBin at //http://pastebin.com/V4TUi74y.  The change in delimiter occurs at line 497 (first bad sentence: "$GPGGA,122258.000,5048,039769,N,1056,270082,E,1,06,2.0,338,8,M,47.7,M,,*66").  For reasons of brevity, I truncated the file at 1,000 lines.

The issue makes it impossible to process the resulting NMEA log, and fixing things up e.g. using a script is non-trivial due to commas being field delimiters in NMEA.