Topics

Hello,

On my ICS SGS2, I used to have Locus's data directory on my external SD card ("/mnt/sdcard/external_sd/Locus"). As of the latest update, however, Locus ignores that location and creates a new directory on the internal SD instead. As the internal SD is VFAT, I also can't simply symlink the actual directory there.

So, my question is, has there been some intentional change to how Locus handles its data directory (nothing in the changelog), and how can I get it to use the external SD again?

Hello,

When NMEA logging is enabled, Locus will currently write a single NMEA file per day (named after the date), even when recording separate sections (i.e., stopping track recording intermediately and recording another track later on the same day).  This will yield an NMEA log with gaps, and if I want to put the logs to use to, e.g., evaluate the individual sections, I'll have to split the file manually.

Would it be possible to change this behavior in such a way that a separate NMEA log is written per recording?  Locus might, for example, suffix the file name with an incremental number.  You might even choose to start adding that suffix only if the suffix-less file already exists, which would keep the current naming scheme for the first (and possibly only) track per day.


Thanks,

Marco

Hello,

I've found that Locus will hang when I stop track recording via the widget and select "Delete" on the save dialog.  When doing so, the entire device becomes unresponsive for extended periods of time, even making killing Locus tricky.  And even after that has been achieved successfully, Locus will immediately restart, continuing to record the track and stall the device.  This does not happen when doing the same via Locus's internal track recording bar.

This is with current Locus Pro on a Samsung Galaxy S II with ICS (Android 4.0.3), custom ROM and kernel.


Marco

Hello,

Hunting for a confluence today, I noticed that Locus may display minute values of 0.000 as 60.000 (certainly due to rounding or some floating-point peculiarities similar to the existence of both positive and negative values of 0) — I'm attaching screenshots evidencing this.  Would it be possible to apply some logic specifically correcting 60' to 0, at least on the GPS screen'?  Of course it's not a matter of any importance, but obtaining proof of visiting confluences is made 75% harder this way.  

I've observed multiple times that Locus Pro names NMEA logs it creates after the date of the day before (I'm in MET).  In fact, it always does this for me -- can anyone else confirm this?

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.