@Inigo_Tolosa Are you ok if I mention this app on other cycling forums ?
Sure, you can talk about it anywhere
It’s already discussed on a few other cycling-based forums.
Now I’m confused. Inigo is saying steps and you are saying a ramp. Also I’m not sure what the =3s means. Is that 3sec average on the Garmin?
There´s a bit of confusion posibly caused by language barrier. But I´m quote sure.
This post confirms
New AlphaHRV version - #20 by Luisma_Gallego_Soy_P
Earlier in the thread this was shown:
I’d just like to be clear that we are on the same page re terminology. I’ve always thought that was a step test.
I explain a bit what we are testing and what has worked best, the ramps are a bit unrealistic as we do not stabilise heartrate or rr or a1. There is an rr-lactate correlation, so we have decided to do 5 minutes with a 10% increase in ftp starting with a very gentle 10-15 minute warm up (40% FTP), we can either do that climb or 0.5w/kg per step. With this we manage to stabilise heartrate and watts for a period, rr reaches a moment when in the same step the tendency changes and that is where we detect the first threshold, normally there is usually a change in the tendency of rr and a1, the tests carried out with lactate have corroborated this, in ventilatory threshold we have seen that there is also a very good correlation, unfortunately we do not have many ventilatory tests due to the cost they have.
I have been doing the test using the Xert workout player but record separately on my Garmin 1030. I set the lap function at 1m30secs and do a minimum of 4.5mins. If my average heart rate for the last1.5 mins is not equal to the previous I do another 1.5 min. I do this to get the heart rate to stabilise as much as possible. At some time I’ll try doing a ramp (climb) rather than a step to see if it make a difference to me.
Imagine that it is a lactate test. In a ramp test, as the values that are constantly rising, the cut-off may be somewhat high compared to a test where we can stabilise the parameters and the change in trend occurs because it is really happening and not because of an uncontrolled increase in intensity.
I will do that during the course of the week and get back to you - having an initial look at it over the weekend the BR of alphaHRV looked to be too high, but will have a closer look and confirm back.
After reading Bruce Rogers blog it seemed to me that the best practice to lower the artefact rate is to connect the chest strap to the data field via ant+. Can someone confirm this?
YES. For the alphaHRV IQ field connection, ANT+ is considered best.
For the Garmin HRV option (RR stream), BLE must be preferred because Garmin itself seems to have hickups when using ANT+ resulting in quite a lot of dropped beats.
So that turns out well, you can have both Garmin RR stream and alphaHRV with the best working connection.
I forgot to mention: I use the data field on an Edge 530 (ant+ to the data field and BT to the head unit) and in a couple of occasions I got the data field that has stopped working. Is there a way to restore the data filed while riding? Attached is a screenshot to highlight the problem (failure has occurred at the end of the session)
I think that some clarifications about BLE and ANT+ hen working with HRV data are required.
First, the HR monitor calculates RR intervals in the same way regardless the communication protocol you want to use. Quality of the RR measurements depends only on the hardware you wear.
Then, transmission of this information from the HRM to the paired device happens in a different way depending on the selected protocol:
- BLE: the HRM transmits every second the RR-int corresponding to all beats (up to 6) happened in the last second. So it could send information corresponding to HR around 360 bpm
- ANT+: only RRint from lst beat is sent in each message. Frequency of these messages is set when you start the communication between the HRM and the device. It can go from 1 to 4 Hz. Setting the frequency at 4 Hz allows to send information up to HR around 240 bpm without missing beats (enough for human beings)
Bad reputation of ANT+ is due to Garmin using low frequency for transmission when using this protocol. In this case it is enough for HRV analysis at resting condition (purpose of all HRV metrics provided by Garmin), but it will miss lots of beats when exercising. So, RRints natively recorded by Garmin under ANT+ are not valid at all for further DFA and you have to go to BLE.
In case of alphaHRV, comunication is directly managed by the app and frequency is set to 4 Hz to avoid missing beats. Comparing results from both BLE and ANT+ in that way has shown same results.
So, there is no issue related to ANT+ itself, but to native use of ANT+ by Garmin.
Any app (Garmin, android, iOS desktop) recording RR intervals under ANT+ can get same results as using BLe if frequency is correctly set.
Nice, I knew it wasn’t working well and it was a problem with Garmin itself, but I never gotten the tech explanation. Now I know exactly what is wrong
Thank you very much for the insightful explanation
Seems time to grab a new H10 (monitor), do you agree?
and a Dual Garmin strap… kkkk
I got the H10 but not the Garmin strap…
Except you lose all the extra dynamics values from Garmin’s HRM Pro (and plus). So it means remembering to switch it back before I do a run or ski. And then back again to do this analysis. Not world ending; but a bit annoying.