Pausing track recording due to slow speed

David Ratajack shared this problem 2 months ago
Closed

I see that this question has officially been "answered," but I have an "edge case" to report that I don't understand based on the above discussion (along with some comments in related threads). During my mountain bike ride today at a particularly hilly and rocky park, I noticed that during many of the long, steep climbs, Locus appeared to stop recording (the moving/ride timer didn't advance -- it was paused). This seemed to happen when my speed dropped below about 2.5 mph (~4km/hr). I use a Garmin ANT+ hub-mounted speed sensor on my front wheel. In my Mountain Bike Profile, there's a check mark next to the "Speed" item under "Sensor," and not under "GPS." For this ride, I had "Record only when moving" checked/selected. If I recall correctly from another threadposting, the threshold for defining "stopped" was described by a Locus representative as being only .9 km/hr.

Years ago, I may have been able to sustain a greater speed during climbs of this type, but at 64 years old, that ain't happening -- these are already near-maximal heart rate events for me! In fact, one way I can sometimes tolerate climbing such steep/difficult trails is to intentionally slow down in an attempt to manage my heart rate (i.e., avoid "blowing up"). On days like today, this may mean climbing at only 1 or 1.5 mph. With a hub speed sensor, though, I should still be generating a positive (>0 mph) speed, and even 1 mph is ~1.6 km/hr, greater than the stated "stopped" threshold of 0.9 km/hr.

So, why is the timer pausing when, despite the relatively low value, there's a non-zero current speed coming from my hub sensor greater than the "stopped" threshold (I fully understand why a higher threshold speed must be used when depending on GPS speed for "pauses")? With the timer paused, I'm curious to know whether I'm missing some other data like "Energy" (kcals burned)?

For now, I've unchecked "Record only when moving" to evaluate how this affects things during my next ride. I suspect, however, that this will seem like a poor work-around as it will reduce the validity of comparing my average data from one ride to another due to variable stop time. Thanks for any clarification or advice that you can provide.

Comments (17)

photo
1

Good day David

firstly, I have moved our discussion to the separated topic (to not hijack old topic with a little different problem). I hoped that this tool help desk correctly moves also our discussion, but seems no. So just reference to the old discussion is here.

---

Sorry for not-precise description. All seems to be set correctly in your case.

"Time interval" set to 1 sec and "Track recording conditions" set to "Distance OR time (one)" are crucial.

We are currently preparing a new version 3.38 (will be published next week). There probably won't be anything that may help here, but you may give it a try.

If there still be same problem and you will want to solve this problem with Locus Map (instead of looking for any alternative application that may work correctly), let me know. I'll then prepare special app version that will print me all necessary information into a log text file so I should hopefully clearly see what exactly is a problem.

Thank you for your patience!

Menion

photo
1

Hi, Menion,

I'm going to try the 3.38 update to see (as unlikely as it may be) if it might fix this issue ("try the easiest things first"). I've invested many hours during the troubleshooting of this concern, so if 3.38 doesn't correct it, I'm certainly willing to continue the process through use of a log text file. I have to admit, I thought we were at the "end of the road" after your last message and was thinking that i'd probably have to abandon Locus -- I'd really like to continue using it, however (WITHOUT losing 5-10+% of my rides). So, let me get back to you after the release of 3.38 and see where things stand...and thanks for continuing to support me as I know you have many other issues on your plate!

P.S.: From your recent recommendation, it sounded like 1 meter is a valid entry for the "Distance Interval" if using metric measurements; I'm confused that, as a user of Imperial measurements, I seem to be limited to 33 feet (almost 10 meters)! It just seems like that can't be good. Why the big discrepancy? Thanks.

photo
1

Hello David,

there is always a lot of work to do, but in this case it is my interest to reveal this mystery because I can't understand why there should be any problem :). But special version may really help here. I just need to publish new version (plus probably some bug fix because we made quite a lot of change = quite a lot of new problems).

About 10 meters ... "Distance interval" has defined 10 meters as minimum recommended value. If you insert value below 10 meters, you see a warning, but you may still save this value. Minimum value just can't be 0.

photo
1

Ok, Menion, let's revisit this after you've released the new update and fixed any related bugs.

photo
1

Hi, Menion. It's been about a month since we last spoke. Have you been able to get the new release of Locus Map to the point where you can afford to devote some time to the "slow speed-> timer pausing" question? Also, when we get to that point, will you be needing addition ride files from me to conduct your examination? Thanks!

photo
1

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

photo
1

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

photo
1

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.

photo
1

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.

photo
1

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!

photo
1

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?

photo
1

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!

photo
1

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

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

/e7dde4627695edc91c824adac80df5ed

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

/5e9943d99649dddb1685f1ddd224c846

---

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

photo
1

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!

photo
1

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.

/292149279ea64639e77a775cc712a9f4


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.

photo
1

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.

photo
1

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

/dd39172af07092e05db9c020fe5673fa


Hope my explanation is clear and makes sense.

Best regards,

Jiří M. aka Menion

photo