GPS speed vs sensor speed

Good day David,

for the test, if received GPS location should be stored in recorded track or not, Locus Map correctly compares the best available speed. In case, you have connected speed sensor, it really should use this speed value and not the speed from GPS. As I see, the threshold is currently defined as 0.25 m/s, so yes, it is 0.9 kmph as you wrote.

Give a try to "record only when moving" option to confirm that problem is really here.

Btw. is this happen also when the screen is turned on and Locus Map is visible? Just asking if there can't be any influence of some system battery optimization.

Hi, Menion,

Well, I left the "Record only when moving" setting "off" and fortunately, I'm seeing the behavior that I desire. The "moving" timer is stopping only when I'm truly stopped, but Locus is still producing data based on the overall ride time (i.e., including stops). In this way, I can assess my performance with or without stops. Honestly, I don't understand why things are working this way -- it's really contrary to what I expected the behavior to be based on the words, "Record only when moving." But, now that I know how this switch is programmed to perform, I understand how to make the correct selection for my needs. I didn't have a super steep segment on my ride today on which to test the low speed threshold of "moving," but I think Locus will work as I'd like even in those instances. I'll report back if I discover that's not the case.

As always, thanks for your ongoing assistance!

Hello David,

interesting. I'm rather checking app code once more and this really should work. In case, there is speed from "speed sensor", it should be used for detection if you are moving or not. Btw. are you using latest Locus Map version from Google Play? There were some changes that may affect this, maybe a half year back.

Anyway if it works for now > perfect.

Hi, Menion,

I did update Locus Maps recently and the "App Information" screen tells me that I'm on Version 3.37.1. We've had rainy weather here, so I haven't had any additional opportunities to do some testing, but the app seems to be doing what I'd like it to at this time. I'll report back if I find out otherwise. Thanks so much!

Hi, Menion,

Regretably, I noticed my ride-time field pause when on steep climbs again today. To my best knowledge, this still seemed to be happening when my speed went below ~3.0 mph on some rocky, rooty climbs. I wish I could provide more certainty on the threshold speed below which this seems to occur, but it's difficult to spend much time gazing at the GPS screen during these difficult efforts. When I got to the top of one of the climbs, I did stop, and while stationary, lifted the front wheel off the ground and spun the tire. The speed field responded as expected, so it still seems that I'm getting my speed data from my wheel hub speed sensor (and NOT the GPS signal). To reiterate, the "Record only when moving" setting is still "Off."

Any ideas or advice? Could there be another setting that's wrong based on the recording behavior that I desire (i.e., pausing only when stopped, but not "slow")? If there is any more information that I can provide, I'd be glad to do it. Thanks!

Good day David,

I'm not quite sure why this does not work as it should to be true, interesting. It should help if I may simulate it on own device.

If possible, please enable before your next ride in app settings > GPS & sensors > NMEA recording > Track recording.

With this setting enabled, next time you will record a track, LOcus will write GPS data into Locus/data/nmea directory. After you arrive home, send me please content of this directory. With this NMEA file, I should be able to simulate your ride. It won't include data from sensors, but I believe it won't be a problem because there should definitely be at least some GPS movement. Thank you.

Hello, Menion,

I think I can provide the track recording as you've described. I'd like to do the recording at one of the two trail systems at which I've noticed this issue so far (they have steep, rocky climbs). With rain forecasted (again!) for the next few days, it may take me a bit of time to capture a suitable track, but I'll send the contents of the Locus/data/nmea directory as soon as I'm able to do so. Thanks, again!

Hello, Menion,

I saw a break in the rain here, so I was able to capture a ride as you've requested. I have my map setup to display grades of >=6% in a different color (usually appears as light blue/aqua). One thing that may be of interest is that it seems like the track displayed on the map goes back to the "normal" dark blue color (in realtime)during the periods when I'm moving but the ride timer is paused. Unfortunately, there's only one trail in this park, so it requires an "out and back" track. The "return" part of my ride tends to obscure the outbound part of the track, which has most of the climbing/pauses the I mention in my notes below. Perhaps by zooming in you can see the inbound and outbound tracks separately to observe the color changes during climbs and the related pauses of the timer. NOTE: Post ride, I've been unable to see obvious breaks in the climbs by viewing the map of the ride on my device, although some of the pauses came at the end of climbs, so the "recovery" blended in with the end of the hill (grades <6%).

This pausing of the ride timer still seems to suspiciously point to my going below some speed threshold. It appeared that I could provoke a time pause by dropping to ~2.5 mph or slower per my screen's hub-generated speed field. On the other hand, the timer sometimes seemed to resume its normal operation for no apparent reason linked to the speed field (i.e., it sometimes resumed despite the fact that I continued to move at <2.5 mph). Also, I noticed that the grade% reported on screen seemed notably more jumpy (e.g., 2%, 14%, 6%, 21%, 3%, etc.) in proximity to ride time pauses than during times when I was moving more quickly, when it seems to generally change only by small amounts, 1-2% at a time.

Here are the points at which I saw the ride time field pause: At 20:17 (for maybe, 5 secs?), 20:42, 20:51; track seemed to lose the special coloring for >6% grade; 31:23; 37:54 (for 6-8s?); 39:14 (again, longer, for ~6-8s); 41:02 (short, only 2s?); 45:02 (for ~6s?, was moving ~2.5 mph, track color showed clear “break” in realtime despite the fact that the steep grade continued essentially until I reached the road); 45:41 (~2s?). These are all from outgoing parts of the ride; there probably were other ride timer pauses that I didn't see.

One final interesting observation: In Locus Pro, the "Track Time" (total) = 2:00:56, and the "Track Time" (Movement) = 1:10:10 (I stopped at several points to trim some low hanging tree branches :)); having uploaded the file to Strava, it lists the same data as 2:00:56 (total time) and 1:18:14 (moving time). So, the moving time was a little over 8 minutes shorter according to Locus Pro?? I've seen this kind of discrepancy before.

The NMEA file seemed to load (saw a progress bar), but as there is no evidence of the loaded file (an icon, etc.), I'm not sure that it's available to you. If not, please notifiy me, and I'll try uploading again. Thanks for your assistance, Menion, and I look forward to hearing whether your simulation can explain the apparent ride time pauses.

Hello David,

thanks for the precise testing and description of the problem.

Seems that file wasn't attached correctly, so please try it once more or just send it on email locus.map@asamm.com. Maybe pack it into zip if possible, it will reduce the size of this text file a lot. Thank you.

Menion,

I tried to reattach the file via the "Attach a file" link, but it still didn't appear (I figure that it failed again). So, please see your email for a zipped version of the file. Thanks so much!

Hi, Menion,

Have you been able to determine anything more from the zipped NMEA file that I emailed you last Friday (May 3rd)? Thanks.

Good day David,

thanks for the nmea file. I'm trying to replay your recording on own device thanks to this log, but unfortunately no issue happen. I see correct recording with small elevation jumps as visible on the screenshot.

My base color is set to black, so there should be black areas in case of missing, zero, speed.

Anyway, this simulation I use is not 100% precise so the situation you had in reality may differ.

I'm sorry, but I'm still not sure where is the problem, if some system optimization, if incorrect algorithm in Locus that drop some data, do not know. And seems that without proper simulation on own bike, it is impossible for me to fix it. I'll be watching it more carefully during own recordings, but for now, I'm sorry, I have no solution for you. Thanks for understanding.

Hi, Menion,

Thanks for attempting to test for the behavior that I've noticed. I hope you checked later in the ride around the times that I cited as the segment of the trail in your screenshot is relatively flat ground and didn't show any strange behavior when I rode it live, either. it's the slow, steep (15%+ grades), rocky climbs during which the ride timer stops unexpectedly.

Hello,

yes I let Locus "play" your NMEA file for a longer time. Problem with these NMEA files is they do not simulate real app behavior on 100%. There is no exact timestamp when certain line was created so app cannot simulate what happens to you 1:1.

Sorry David, but I do not know what exactly happen on your device.

Only what I may suggest is to try check

• battery optimizations in your device as we describe here
• try recording with a profile where you set distance: 1m, time 1s, condition? ANY, only when moving: off. This should guarantee that really all GPS locations should be stored in all cases.

Sorry, I do not have the perfect solution here. I'll keep the problem with slow moment & recording in my mind and let you know if I find something useful. Thanks for understanding.

Menion,

Regarding your recommended recording profile, some of your directions are unclear:

(1) if by "set distance" you mean the setting under Track Recording-Recording Profile-Distance Interval," when I try to enter anything less that 33 feet, it blocks me from entering any values, and I get an error message saying, "Value is below recommended minimum 33 ft." How should I proceed?

(2) Under "Time interval," this is already set to 1 second.

(3) Under "Trackpoint recording condition," the choices are "Distance AND time (both)", or "Distance OR time (one)." Which one do you consider "ANY"? (I assume the "OR" choice, which is the current setting)

(4) "Record only when moving" is OFF.

I'd like to try your recommended settings if you would kindly clarify what you mean.

BTW, I ran Locus in parallel with a Garmin ETrex 35T today, and Locus paused at times on steep grades, while the Garmin didn't.