Apparent locale issues in NMEA output

[curio]

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.

[Menion]

hello,
  this is really not problem on Locus side. I'm looking on NMEA code that save messages from internal GPS or Bluetooth GPS, and there is no code that do something with it. It's source data that I send directly into file. So if there are some issues with messages, it have to be problem in phone system, not in Locus

[curio]

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.

[curio]

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?

[Menion]

it's quite simple

if you use internal phone GPS
----------------------------------
then I do not use NMEA messages. I only forward them to file if you enable saving in settings. For location and some other variables (accuracy etc.) exist another function within android system, that do this for me. So I at the end only take final location and work with this.

if you use external bluetooth GPS
---------------------------------------
then I have to receive data from NMEA files, so If there is any problem in saved NMEA file, then also Locus should have problem with parsing. But seems you use internal GPS right? Also when I parse data from external GPS, I firstly save NMEA message to file and then do parsing, so there is no chance to modify sentences before save

hope you understand me well ...

[curio]

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).

[curio]

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!

[Menion]

you're welcome. It's possible that google improve location by it's new system as you wrote and after that it generate NMEA message that can Locus receive. And there is some new mistake ...

[curio]

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

[Menion]

perfect