Pausing track recording due to slow speed

Hi, Menion,

I'm assuming that your lack of a response to my above note is because you're tied down with v3.38.x - 3.39 bug fixes. Could you kindly just give me a quick response as to whether you'll eventually be needing more ride files/"tracks" from me? Do you have an estimate of when you'll be available to look into my issue?

Also, I see that 3.38 is now available in the Amazon AppStore. I've noticed that some of your users have reported display problems for certain maps during the rollout. I'm currently using the latest LoMaps or VEC map for the state of New Jersey, USA. Do you think the 3.38 update is now stable for using LoMaps or VEC? 3.37.2 displays New Jersey correctly, so I can wait to update if there are still some lingering issues.

Thanks

Hello David,

sorry for the delay in my response. I'm still working of bug-fix versions, currently in preparation is 3.38.7, hopefully last.

Anyway, let's move with this problem a little. I've prepared special Locus Map Free version (simply install it on your device next to current Pro version).

After the start, enable Expert settings . Then in Expert settings (at bottom of the app settings), enable "Log to file" option. Since this moment, Locus Map will record all own logs into Locus/logs directory. You may check it if files are created there.

So with logging enabled, start Locus Map, check if all is set as you need and give the short ride a try. If you nice mentioned problem, just please remember an aproximate time when it happens, so it is easier for me to find out the reason. After you return home, please send me this log files together with exported GPX file of your ride. Thank you very much!

Menion

Hi, Menion,

I've loaded the special Locus Map version, but this is going to be a struggle. I've told friends that I really like Locus Map Pro, but if I ever had to reproduce the changes that I've done to the settings, I wasn't sure it would be possible (short of taking the time to copy the entries on every settings screen, then going to the new version and reproducing each of them there). If it's possible, it's going to take hours of work. I foolishly wasted about 4 hours this morning driving to a park, then riding with the "stock" special version. It took nearly an hour to get my sensors to connect. I had the same problem I had when I first purchased the program: getting into an infinite sensor search loop. Of course, there were no unexpected pauses during slow, steep ciimbs, but the (special) program that I was using bore little resemblance to my "regular" Locus Map Pro, so the "test" didn't prove much. To get Locus to look and perform as best as possible for my needs, I've probably had to make dozens of "tweeks," and they're scattered all over the program.

So, if I can carve out the time to try to make the two versions equivalent, I wiil, but it may not be happening soon. It's too bad the settings can't be saved such that they could be exported to a new version of the program. I'm really disappointed, but I guess that's where we stand.

Good day David,

based on your description, it looks like the problem may be in the settings because the new version worked correctly? Interesting.

Anyway, there is a very simple method of how to transfer settings from one app to second. Open your older LM Pro and in Menu > More > Backup manager, do the backup of your settings. And then open LM Free and in the same menu restore your settings. After app restart, all should be set as in your Pro version.

Hope this will work.

Hello, Menion,

Well, that's a relief to know that there's a simple way of transfering all of my current settings to the "test" version of Locus. This will save me HOURS of work hunting down all of the "tweeks" that I've done to the program!

Yes, I think your speculation is correct -- it appears as if a "completely stock" version of Locus doesn't show the tendency to pause on steep climbs. There must be something in the combination of changes I've made to the "stock" settings (of which, as I've already mentioned, there are MANY) that is creating a strange case that may induce pauses. Now that I know how to transfer my settings to the "test" Locus version, let me see if I can get a file to you that shows pauses. Thanks for the clarification!

Hello, Menion,

NOTE: I'm selecting the GPX file to attach and as happened once before, I don't see it appearing as an attached file (shows it downloading...progress bar shows "complete," ...-> no file appears). I've just tried to send the file via your email address (locus.map@asamm.com), and that seemed to work. Kindly check you Inbox for the file.)

I rode a ride a couple of days ago and was unable to confirm any ride time (moving) pauses. On my ride yesterday, however, I saw numerous spots where the moving timer seemed to pause, but my bike was still moving (climbing). Using the ride time (moving) timer, the pauses occured at 25:48 (~39:00 on the "overall" file timer...), 26:39, 36:23, and 39:30. There are probably other pauses in the file, but I thought this would provide a good sampling of the issue.

Regarding the log file for this ride, I now have 10 files in the Locus/logs directory (they appear to all be .txt files). I don't see any obvious date imbedded in the file names for these files, however, so I can't tell which file(s) is related to the GPX file of interest. I also used a text editor to view the content of the files and I still couldn't find a discernable date for the files. Some are longer (>1000 lines), and some are shorter (<100 lines -- I suspect those aren't the key files). Is there a single file that you need? How do I determine which one is the one that you need to see?

Good day David,

thanks for testing and your patience. If possible, pack all these log files into zip and send them on our locus.map@asamm.com email as well. I'll look on them and for sure find a correct place with some, hopefully useful, info. Thanks!

David, I'm looking into GPX track and this is really weird.

In track editor is visible point 1656 recorded in 14:01

During the next 10 minutes, the app records another 650! points during maybe 20 meters.

---

Seems you use also speed sensor connected to Locus Map right? Because in GPX file are registered speed values. Point 1656 seems to be on line 21411 in the file. And since few points later, all of the mentioned 650 points has speed value 0 from the speed sensor and, which is even more interesting, all have exactly! same coordinates!

Speed is ok from my points of view for the speed of 40 m/10 min, but the same coordinates are really weird. Usually GPS jump meter on left, the meter on right, but never stay calm on a single place. Here is only single settings in the app that may partially affect it: settings > GPS & sensors > Location filter. So rather disable it if it is enabled.

Did not tested other breaks in the recording.

Only, more a technical problem here is that you probably set parameters to 1s/1m and "any" in track recording profile. This means that the app really records every tiny location. The result is track with a really huge number of trackpoints and many of them are identical.

Menion

Hi, Menion.

I've just sent your email address a zip file containing all 13 files that I currently have in my /Locus/log directory. Hopefully, you'll be able to properly access the log files contained within the zip file.

I think I can address some of your points above:

- I believe that I have an explanation for the "weird" data at point 1656. During my ride, a pedestrian stopped me to ask about the trail conditions that I had encountered during my ride (looks like that happened at about point 1656). We probably stood stationary while talking for about 10 minutes. With a little GPS drift, I'm guessing that you might see 20 meters of "movement"/artifact. Please note that there are several places during the ride where I stopped for various reasons, e.g., equipment problems, consuming fluids, catching my breath, or using my phone to record the times at which I was seeing the pauses in the moving ride timer (while stil moving). I'd focus on the times that I mentioned in my earlier note to zero in on the "pauses" that shouldn't have been recorded as such -- I was definitely moving at those points. I can't be absolutely sure (as it's difficult watching a computer screen while climbing slowly up a steep, rocky hill), but the "pauses" seemed to last from ~2-10 seconds at the time points I've mentioned above.

- As it turns out, the change you thought might help (Settings > GPS & Sensors > Location filter) is already set to "No filtration."

- I've set the track recording profile parameters to 1s/1m and "any" (= Distance OR Time (one)) because when I previously used a Garmin GPS device, the user manual said that using less than a 1-second recording profile (they call it "Smart Recording") increasingly cuts off/truncates distance on twisty mountain bike trails...which describes a lot of my riding. That's also why I've recently used a hub speed sensor as I found that using GPS tracking (only) yields about a 5-10% distance shortfall during a ride. Do you still feel that using 1s/1m/"any" is a bad idea for me (i.e., the downside of having so many track points is worse than than the loss of distance accuracy)?

- From the log files and after reading the points I've made above, by any chance do you see evidence of or suspect a faulty speed sensor? There's no battery level indicator that I know of, so, could the battery be getting weak? I have more than one speed sensor so I could swap the current one for another one, or put in a new battery if there's reason to do so.

I look forward to your thoughts on whether the log files have provided any clues as to the source of the slow-speed "pauses." Thanks!

Good day David,

thanks for the explanation of the problem I found. Oki, pedestrian make sense.

So I'm checking the first time you mentioned.

In 14:12:46 happens a break (time of record is 38 min, 57 sec). In the GPX file, it is on line 30224.

Since that moment, until 14:13:29, there is no change in coordinates! but speed sensor reports speed around 1m/s.

And from then until 14:17:11, there is even no speed from sensor!! so there really is almost 5 minutes break where coordinates do not change, most of the time also speed sensor return no value and changed distance on the map is again around 20 meters!

David, I'm a little desperate, because I do not know how may I help here. This can't be affected by any parameters in Locus Map. Your GPS simply does not report any movement when you standing still. And based on speed sensor, you really stand still (20 metres per 5 minut).

Because you recording trackpoints every second, you may nicely see speed values from GPS and speed values from the sensor on the chart. There is clearly visible that speed sensor recorded speed a minute longer, but then also stopped.

Sorry David, but I may only suggest to try different app (just for sure, but I'm worried results will be same as this is not affected by app itself), or better try a different phone if possible, because this seems to have some kind of over-optimized GPS that simply ignore slow and small movements. Which is ok in most cases and compare to other GPS recordings I saw, your seems to be very smooth and without big GPS mistakes.

Thanks for understanding.

Menion,

I'm afraid that your comments, again, don't make much of a point. What I find particularly upsetting is that you don't seem to be reading all of the notes that I'm sending. This makes me wonder why I'm taking all of this time to report information to you...and, believe me, I've invested a LOT of time recording these tracks, sending you the files as you have requested, then providing detailed information on how to find the places in the files where I've noticed strange behavior. Let me explain further:

1) You say that at 14:12:46, you see a "break" in the file. I don't find that at all surprising as that's where I told you I saw my ride timer (moving) pause without reason.

2) You then say that until 14:13:29 (= 43 seconds in real time, not moving ride time, which has stopped at this point), the speed sensor continues to report a slow, but definitely moving speed, while the GPS reports no change in coordinates.

But why is that surprising? Despite the fact that I have a speed sensor installed and selected, It sounds like Locus Map uses the GPS signal to determine movement rather than the more accurate speed sensor (which I purchased to overcome the inherent inaccuracy of GPS-based speed measurement). Since GPS accuracy is probably, at best 3 meters, and more likely in the range of 5-6 meters, if I'm only climbing that monster hill at ~1m/sec with a 1-second sampling rate, consecutive coordinate measurements by the GPS sensor can no longer see movement (it's lost in the measurement error -- and I'm sure that you know this). And, my guess is, when the GPS sensor can no longer see movement, it instructs the ride timer (moving) to stop, creating this weird situation where the ride timer (moving) is stopped, but the bike/hub speed sensor is still reporting movement.

You can see from your graph above that just before the 39 minute mark (at 38:57, to be exact), my speed goes below the ability of the GPS to see speed, and it drops off to zero like a stone. There are no current consumer devices with a GPS accuracy better than 3-6 meters (another thing that I'm sure you know), so the fact that no movement is detected at slow speeds isn't a unique hardware issue related to my device; the choice to use the GPS sensor to detect movement instead of the better/more accurate hub speed sensor, however, is a software decision.

3) You then continue by saying (and this seems to cause you the greatest concern) that, "...from then (14:13:29) until 14:17:11 (just under 4 minutes), there is even no speed from sensor!!" If you had read my previous note, you'd know that "...there are several places during the ride where I stopped for various reasons, e.g., equipment problems, consuming fluids, catching my breath, or using my phone to record the times at which I was seeing the pauses in the moving ride timer (while still moving)." So, yes, I saw the ride timer (moving) pause at 14:12:46, the pause continued for no reason (as I was moving) until 14:13:29, at which point I stopped to record the time of the event in a note on my phone, so I could provide you with accurate data. Apparently that took me until 14:17:11, or a little short of 4 minutes.

It all makes sense, yet you're suggesting that this is proof my device is "over-optimized GPS that simply ignore slow and small movements." No, as I said in my last note to you, I was genuinely stopped to record the exact time of the ride timer (moving) pause. If you check the ride log at the other times I reported seeing pauses, I'm sure that you'll see the same pattern: timer "breaks" (goes to zero despite movement), speed sensor continues to record while GPS coordinates don't change, then the speed sensor reports no movement as I've stopped to record the time of the problem. I'm not using an "over optimized GPS" -- and I don't know where you could even get one as there are none available (as a lawyer once explained to me, by law here in the U.S.to discourage use of GPS for terrorism or other illegal activity).

Menion, you've told me that you want to find the cause of this pausing behavior, but your actions and comments to me seem to say differently. I don't know for sure what your motive is for trying to deceive me, but it's not a good one. This is a real shame, as I truely like a lot of things about Locus Map, and in many respects, it stands well above its competitors.

Good day David,

sorry to upset you, but be sure I read your comments, no matter that I already spend few hours on this single-user-unique problem.

Four days ago you wrote "the pauses occurred at 25:48 (~39:00 on the "overall" file timer...)". So I was checking this moment. You mentioned that you made some pauses, but I definitely not expected that it took you 4 minutes to record a time, that's why I stuck on this unexpected break. Oki, so the problem is this 43 seconds between when GPS does not report any time, but the sensor did.

We are here in the world of "bike", where 1m/s speed is not so usual. Anyway, around 3/4 of Locus Map users use it for hiking as well. And here app works with even slower speeds. Fact that traveled distance between 1 second is lower than hardware accuracy does not mean that the device will ignore the moment. Speed is usually computed as a function of more previous received locations, not just last two. I'm looking on some my hike trips and seems that even in hills with speed around 0.5m/s app records data.

When we started with this problem, it looked that Locus Map simply does not record received locations and because of that, visible "time" is not changing. But in the send GPX file and also in logs is visible, that with your "record all" profile, all received coordinates are correctly recorded. So time should change in this case correctly because it is generated from the start time & last recorded point. Because of this "record all" settings, speed from the sensor does not have influence here.

So, I can't help myself, but I still see the main problem in the GPS unit. It simply does not correctly report changes in coordinates. If you moved during mentioned 43 seconds for around 30 - 40 meters and GPS unit report only one change in coordinates during that time, it is really weird. It is far above the expected GPS accuracy.

---

Anyway, with settings 1m/1s/any, I'm not sure I see a problem.

• recorded time and distance should be correct
• visible track time should be changing in panels because GPS still send (same) coordinates
• if you in the dashboard or track recording panel set "Speed (sensor)" field, you will see your sensor speed that reflects the real value
• in the track chart, it is also possible to display speed from the sensor and not based on GPS

Mentioned "record all" settings is usually not ideal as it on most of the devices cause something like this (image below), which for my surprise is not happening on your device (and because of this I called it "over-optimized GPS" > not because of accuracy but because it filters out too much noise).

Hope my explanation is clear and makes sense.

Best regards,

Jiří M. aka Menion