Pausing track recording due to slow speed

David Ratajack shared this problem 4 days ago
In Progress

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 (4)


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!



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.


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.


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