It would be great to have heart rate AVG and MAX supported in dashboard, track statistics and track recording panel.
HR is one of the options to display in Chart. It would be nice to have Max HR included on the Information sheet.
+ time in zone, over zone, under zone (and zone definition :-) )
I'm glad to announce, that fresh new 184.108.40.206 Beta version has support for heart rate max and average values for Dashboard and for track statistics.
As well as on the statistics page of track details.
Yeah. Pls add this stat. Thanks.
Yes, please add it, it is vital information.
My idea of "HR AVG and HR MAX in track overview" has been merged into this theme. I'm not sure if it's correct.
Dashbord is something that shows information DURING activity.
Track overview is something that shows review of my FINISHED recorded activity (distance, moving time etc.).
Or I don't understand the term "dashboard" well.
Anyway, both features would be useful!
+ time in zone, over zone, under zone both in absolute time and percents of elapsed time (and zone definition )
zone 150-160 BPM
under zone 1h (20%)
in zone 3,5h (70%)
over zone 0,5h (10%)
(with total time 5h)
Dashboard, track statistics screen, track recording side panel ... all three places use exactly same system. So generally it should be about adding support for hr max/hr avg. When such support will be added, it will be available in all three "screens".
EDIT: I've improved this idea description a little bit, thanks.
I have another idea, after yesterday ride :)
HR AVG in movement and HR AVG total. Just like TIME/AVG SPEED in movement and TIME/AVG SPEED total.
When i record a track with HR Statistic and the recording was stopped. That was very Useful to see the HR-AVG and HR-MAX in the Summary Screen. And later in the Trackinfo or Statistic Data.
And don't forget the API, thanks. :-)
I really need HR-AVG, HR-MAX and actual heart zones displayed on the dashboard. I love Locus Pro, but many others apps have heart zones. I know its nice addon alarm, but I need a info on dashboard.
What about periodic updates for addons?
Already implemented. There were anyway some changes, so it will need update of an API library - it's anyway not yet published.
When will the API changes be published? Would love to see my HR on the RFLKT.
Because whole feature is still in testing stage, I'll publish changes in API probably in same day as new final version. So probably in the end of next week.
Hi Menion and Locus Team.
We are very glad that You started working on the implementation of HRM statistical data .
I made a few tests on the workouts and I have the following results:
The value of the maximum HRM is OK.
In calculating the average HRM error occurs. The result are too small.
I suggest that the value of the energy present in the KCAL unit, which is more useful.
For full satisfaction, we very much needed the time and the percentage of the training in zones. It would be great if it was possible to determine a 3-6 heart rate zones.
thank you for a tests, really appreciate it.
Average values in HRM monitor are somewhere directly visible to You? I compare average values also with Endomondo and found similar difference, but I was almost sure, that I compute average value correctly.
My method now, is compute number of beats during whole record and time when beats were measured and divide of them is number of beats per minute. May you suggest any better method? I'll rather check if there isn't any numerical problem.
Calories - change units in settings > units ;).
And zones ... http://help.locusmap.eu/search/tag%3Aheart+rate+zones , maybe next time
Yes, I have an independent measurement and reading. I use a heart rate belt with dual mode wireless connection: BLE 4.0 and 5.3 kHz (open signal) to the heart rate monitors.
Hmm, other method? Ok, I will arrange some more tests :-)
Of course units in settings, thx :-)
Yes, yes, yes next time :-)
It must be an error in the method of calculation. I analyzed the file gpx and I calculate the average of a classic:
totalsum recorded HRM value divided (The number of entries in the database minus the blanks).
And does it make sense to just sum measured HRM values and divide it by number? For me not. What if time between your recorded values is not same. Like "15 s > 100 bpm, 30s > 100 bpm, 120s > 150 bpm". What you do is simple (100 + 100 + 150) / 3 ~ 117 bpm .
But what I do, is compute number of beats per intervals, like 25 bp in first 15 sec, 25 bp per another 15 sec, and 225 bp per last 90 seconds. Result is 275 bp per 120 seconds =~ 137 bpm . For me it is more logical then simple average. It's still of course inaccurate in case, gaps between recorded values and bigger, but ...
You have a mistake in the first calculation. You have to count every single 15s split with the same weight:
15 s > 100 bpm
30s > 100 bpm
45s > 150 bpm
60s > 150 bpm
75s > 150 bpm
90s > 150 bpm
105s > 150 bpm
120s > 150 bpm
and then you get (100 + 100 + 150 + 150 + 150 + 150 + 150 + 150) / 8 = 137,5
The mistake is that you pretend that 30s split with 100bpm has the double weight (counted twice) than 90s split with 150bpm (counted once). If you use correctly counted average, then you get the same result, both methods are equal. You didn't study physics much, right? ;-)
Wait wait ... first calculation was based on what @robot hack wrote
and what probably other web pages do. What I suggest is close to what you wrote. It's just simply not possible to separate measured values to exactly same 15s long intervals as in this example. But it's possible to separate it to 1sec intervals as I wrote in second part of my answer above.
So I don't get you last sentence, because you get same result as I ;).
you don't get me. Every trackpoint has absolute and relative time and hr value:
t1a = 0s, t2a = 1s, t3a = 3s, t4a = 5s.
t1r = NULL, t2r = (t3a-t1a)/2 = 1.5s, t3r = (t4a-t2a)/2 = 2s
then you count AVG HR:
( t2hr*t2r + t3hr*t3r )/( t2r + 3r )
I pretend you use cleared values (only trackpoint with some reasonable hr and interval value).
Robot hack supposed that you use fixed TIME interval for recording (which is most common), so in the example he gets some value every 5s (or so). Then using common average (sum of values)/(count of values) does make quite a good a sense.
This helps to avoid problems with distance interval - when riding slower, you give more weight to the HR value. If you stop, you don't use that HR value (the interval is not symetric at all).
Now that there is support for avg HR, how about a quick detour to avg cadence? ;)
Menion wrote: ..."What if time between your recorded values is not same."...
I think that there is no such possibility. All the devices and applications that I have tested so far record values within a defined interval (do not record if there is a break or no connectivity - null) - Locus too (Recording profiles / Time interval).
If you count the time a certain value of heart rate, and it occurs many times during training in the calculations give the result as a weighted average of the increased predominance of the values which can underestimate or overestimate the value of the average.
I do not know if I wrote understandably, higher mathematics ;-)
Well, simple example:
- Locus record values based on time, but also based on distance. You set recording based on 10 metres ( or as is default value in basic profile - 2 second + 10 metres).
- you run as crazy around 170 bpm, value is recorded and you stop your interval and need to take some break. And this break my take for example five minutes. During that time, no point will be recorded and your heart rate lower to 100 bpm. But, in your calculations as simple average, both values (170 and 100) will have save weight as all other recorded points. In my calculations, they will have a lot higher value.
Simple example: 1 km, interval of recording set to 100 m
- first kilometer: slow movement, 130 bpm, 6 min/km
- second kilometer: fast movement, 170 bpm, 3 min/km
Your method: (10 * 130 + 10 * 170) / 20 = 150
My method: (6 * 130 + 3 * 170) / 9 = 143 ( total number of beats per 9 minutes of run )
And I'm sure that my method is a lot more precise, isn't it?
Look at it this way. I'm going by bike at a speed of 20km/h
Simple example: 2 km, interval of recording set to every 2s (Recording Conditions / Distance OR time ONE)
- first kilometer: slow movement, 130 bpm,
- second kilometer: I'm going uphill , 170 bpm
I will pass the distance 2 km in time of 360 s and Locus register me 180 measurements.
My method: (90 * 130 + 90 * 170) / 180 = 150
Suppose that I stopped driving. The heart continues to work which is saved. Your method loses this data (recording set to 100 m) and underestimates the average.
Hmm in case of your example, "my method" won't be a problem.
Because in :
- first kilometer, you will have 4.33 beats per 2 seconds
- second kilometer, you will have 5.66 beats per 2 seconds
so final value: (90 * 4.33 + 90 * 5.66) / 6 = 900 / 6 = 150 ;)
explanation: 90 2-seconds intervals with 130 bpm + 90 2-seconds intervals with 170 bpm
So, it looks that it covers both options.
In case you stop, then it just depends on your recording parameters. If you will use condition based on distance, then yes, you loose data. But it has nothing to do with average heart rate value. In case of condition based on time, then average will be correctly computed because it's just based on number of beats per time.
Hey, dudes, have you ever heart about fractions (zlomky in Czech)? Did you knew that ((90 * 130 + 90 * 170) / 180) = (90 * (130/30) + 90 * (170/30)) / (180/30) = (90 * 4.33 + 90 * 5.66) / 6 ? Elementary mathematics. What are you arguing about? :-D
Well, thanks for introduction to elementary mathematics Hrabosh. And the point?
Well, you present here your skills with mathematics, which are probably better then mine, anyway you just confirm results I compute. So if you don't mind, I close this mathematics lectures for now, because you just confirm that I compute it correctly, thanks.
The point is that your argue is poitnless, you're writing the same, just in other words.
I'm just saying that you and Robot Hack are writing the same, I'm not confirming that you're computing it correctly.
Your "interval" approach would work well in the case when you detect all beats (in the interval). But in reality, you don't get all beats (interference with others hrmeters, dry skin, weak battery, slipped belt). Then you have systematic mistake (you underestimate the real HR). Less likely, but also possible, you get beats from other hrmeters (but you can ommit that for statistics).
I'll send example and explanation in the evening.
But I know this. I was just confirming that method I describe, gives same results.
Your "interval" approach would work well in the case when you detect all
beats (in the interval). But in reality, you don't get all beats. Then you have systematic mistake (you underestimate the real HR).
Of course agree. And suggestion how to compute average HR value more "precisely" when you have missing data? Your weight average gives exactly same results as my "weird intervals". So it is not a "better solution".
What do you think about this kind of calculation?
It is based on time (distance has no matter), with missing data example.
HR AVG = total sum / total seconds = 5600 / 38 = 147,36
Hello bartel6, this is almost identical to what I do now. Method is little bit different, result should be exactly same. Thanks for opinion.
Dumb question: why you don't want to calculate HR value for every hearbeat and then use that value (to get median or "average value with standard deviation, remove exceeding and recalculate average")? This allows you to save HR (closest HR or average of in between) in trackpoint and export it to gps ( garmin extension http://www8.garmin.com/xmlschemas/TrackPointExtensionv1.xsd ) which is supported by Strava as well (hr for heartrate).
Than, moreover, you can calculate AVG HR for each split and display HR in graph.
HR values are exported to Strava and other service for a few years already.
HR values are also for quite long time visible in track charts.
So sorry, I do not understand question.
I've rememember that because I was slightly confused. If you have HR values, why don't you simply use common statistic methods to get AVG HR and you count heartbeats in weird intervals instead? Well, you should weight them according to time interval that one trackpoint covers, but that's all. The only question is that if you should display median, average or both.
lets have record like this:
# | absolute time | received? | interval | validated inteval
1. | 1s | ok | 0,5 | not used (asymetric inteval)
2. | 2s | ok | 1 | 1
3. | 3s | ok | 3 | not used (asymetric inteval)
4. | 4s | NULL (not detected or missing trackpoint) | | not used (no value)
5. | 5s | ok | 3 | not used (asymetric inteval)
6. | 6s | ok | 1 | 1
7. | 7s | ok | 1 | 1
8. | 8s | ok | 1 | 1
9. | 9s | ok | 1 | 1
10. | 10s | ok | 0,75 | 0,75
11. | 10,5s | ok | 0,5 | 0,5
12. | 11s | ok | 0,5 | 0,5
13. | 11,5s | ok | 0,5 | 0,5
14. | 12s | ok | 0,5 | 0,5
15. | 12,5s | ok | 1,5 | not used (asymetric inteval)
16. | 12s | NULL (not detected or missing trackpoint) | | not used (no value)
17. | 12,5s | ok | 1,5 | not used (asymetric inteval)
18. | 13s | ok | 0,5 | 0,5
19. | 13,5s | ok | 0,5 | 0,5
20. | 14s | ok | 0,5 | 0,5
21. | 14,5s | ok | 0,5 | 0,5
22. | 15s | ok | 0,5 | not used (asymetric inteval)
The correct value is 22/0.25 = 88 BPM.
if you just count all beats and you divide it by the elapsed time (or you split the time into intervals, it doesn't matter), you get 20/0.25 = 80 BPM
if you take AVG interval, you get 86 BPM (60/average_interval), which is more accurate. This avoids problems that arises with missing trackpoints when you use "distance" setting and you stop moving for a while.
is is possible to format table somehow?
Moreover you don't have to keep separate data for HR, you can grab it from gpx:
interval = 60/current_BPM (you save that value with each trackpoint) and then you're completely independent on gaps between trackpoints.
I have done some testing on the analog measurement of pulse and tested as well as services Strava, Runtastic, Endomondo, Sportypal on GPX file. The results indicate that all the tools count results using a simple average. I suggest you adopt this standard in Locus so that the analysis of the measurements, there were no differences. You can also post together a calculation that you think is more accurate.
Now the much-anticipated feature is the measurement of the heart rate in zones all extremely her waiting on this :-)
Now, I'm waiting for heart zones. But really thank you for new features.
One more thought: Locus displays avg speed and mvmt speed. It would be fine to HR values in the same manner (I don't pause recording during lunch, since I remember to resume it).
Hello Hrabosh, interesting thought. I'm anyway not sure, if such fields will have expected effect.
I use Locus for sport activities for a very long time and I use HRM device only for training. Then there are usually very short, or no, pauses and so these values are not useful for me. If you use HRM even during lunch, then I think it's quite unusual :).
More I think about it, less I like adding such values to dashboard. Sorry.
I wanna see you doing Praha - Praděd (approximately 270km) on bike in one shot without lunch and pee stops. Ok, it was just leisure trip ;-) So what about Krušnoton 250km/4.900mup without stops at buffets :-) Cycling (both road/mtb) lasts for hours and it is very common to have breaks, especially when not in race pace. That's why you display avg and avg-mvmt speed.
Well sure, agree. I just can't imagine that I'll wear for two days trip on my chest heart rate monitor, that's all. I just expect that mainly HRM devices are for some planned sport trainings, not for common wearing.
Comments have been locked on this page!