Open dgeenens opened 7 years ago
I believe the target feedback need to be configured with a span to give reasonable feedback first, quite unstable as it is. Some hysteris is needed.
@gerhardol What do you mean by "reasonable feedback first"? Do you have specific ideas on how to change that (e.g. regarding the hysteris?)
@davidedelvento
I find the instant speed feedback is more or less useless in any GPS based product aimed for running. Footpods are better. I just use km pace w GPS.
The GPS pace is very unstable, it is hard to say what is the current pace. Smoothing can be applied but then reaction to pace change is very slow. I do not have a good solution for finding current pace. Better smoothing (and hysteresis for reporting) is one thing, maybe the accel/gyro in phones can be used as a supplement.
Mmm, I actually just got a new Samsung J3 (2016) and used it today for the first time. I've found the instant pace (announced by audio cues) extremely accurate, much more than I expected. Note that I ran (like I always do) in areas which have an excellent view of the sky (however other phones were not this accurate). So maybe your experience is related to the hw you used or the view of the sky you get? Footpods do not work well for me because I have a length of the step very variable depending on circumstances, so guessing the speed from the cadence is often totally off.
If I look at the unsmoothed pace graph of the run I mentioned above, I do see a few spikes (on average one spike every two minutes). I don't recall if I slowed down that much (or even stopped) during the recovery steps, so I don't know if they are real, or just noise -- however the audio cue has always been exact. If I were to find a problem with it, is that I was doing strides (intervals at increasing, not constant, speed) and the audio cue was telling me other things before the current pace, so by the time I've got the cue the pace was not instant anymore, but "too slow" probably because it was exact when the audio cue had started and I was accelerating very rapidly.
In conclusion, I think this feature request can be useful to some (and others can always turn it off).
Sure, feedback can be added. With a good GPS in a good position, good coverage and higher speed then target pace may be working OK. Not so for me. I have hopes for Galileo improving the accuracy.
However, there are already issues that the feedback is unstable, adding more feedback could give even more questions. The "stride" scenario is extremely hard to handle but points to a smoothing algoritm other than averaging should be used.
Sure, Galileo could make a difference, but as I said, I'm satisfied with the J3 which uses only GPS (not even GLONASS, does yours?)
Regarding the "stride" scenario, again, it was not really "instant", but once I understood that, it was fine. In fact, the same issue happened at the end of the stride, when it announced what was basically my "top speed", but I've got the message when I had just slowed down considerably. So I think for stride "everything as is" is just fine. Even with infinite accuracy, there is no way that a target pace cue for the stride would work, since pace is so quickly variable: by the time the audio cue says anything, it's already out of date. It might work on the display, but who wants to look at the display while accelerating very quickly? Not I.
What I believe this "target pace audio cue" feature request would be useful for are case like the following: you have a long time going at the same pace (say, a marathon). If you don't hear any cue you wonder: did my phone died, my headset died, the GPS signal has been lost, did runnerup thought I stopped or pause or has it been killed by the OS because of an OOM? Or am I simply going great at my target pace? Actually an audio cue for GPS (location) signal lost might be useful, in addition to the one for when there is a stop/pause (which I think is already available).
Maybe one could achieve the same goal by setting an audio cue for the last x minutes with the average pace for that time, however that would simply tell "your pace is y", and then you have to mentally think if that's your target for that section of the run (which might be complicated for a marathon, e.g. if you want to use runnerup to force you not to have a negative split). Whereas this feature would automatically tell you if your pace is on target (or not, if one enables the existing "speed-up, slow-down" cues).
Glonass: My Sony Z3 has GLONASS, It may not give any improvement though, it should only be activated at tricky situations too. I had a Garmin 920XT, the accuracy may even decrease with Glonass. I did not test much but other users have reported the same. (I do not get locks on Beidou either, unknown why even if they are the strongest.)
The GPS on the Z3 is decent, but I wear it close to the body in the backpacket or jacket front pocket so not optimal. I primary use the phone as a data logger.
For the feedback: All presentation will require smoothing so in a stride scenario the announcement will be delayed. An algorithm other than averaging may decrease the delay. Just setting the averaging period could be good enough.
Assuming that the target pace measure is stable enough (which my personal preference is that someone look into first, maybe just averaging), there is still criteria for how to announce on-target pace. How often etc.
For someone interested in this: Implement and make a pull request, Jonas accepts most of them (eventually).
Right now, you can hear when you need to accelerate or decelerate to stay on your target pace. It would also be nice to hear your pace when you're on target so that it's easier to stay on target and you don't need to accelerate or decelerate that often and thus have a much smoother pace.