HRV-Guided Training

The reason for pairing it twice is because I’m pretty sure (I didnt check the SDK API) you can’t get HRV data from the strap thru Garmin’s SDK API for Connect IQ). When the app connect directly to the strap, you can get whatever the strap is transmitting w/o going thru the SDK.

Yeah… That’s what I read tho i have no way to test since I don’t have a H10 and my Tickr has only 1 BTLE channel so can’t compare… Although now that you mentioned the diff pairing method for the CIQ app, it might be workable to upload the same workout data to RunAnalyze (Garmin - BLE HRV and Garmin-CIQ App - ANT+ HRV). Something to think about for me.

anyhow, I stumbled upon this nugget of info. I found out that GoldenCheetah now also is able to process DFAa1 data. (not sure about live view) but it’s available for Post-Analysis…

No clue(at all) what all this means, but this is the same workout I put into RunAnalyze (I shared in an earlier post)

ANT+ HRV Data

BLE HRV Data

So… RunAnalyze shows that the HRV data is cleaner on ANT+ but the DFAa1 plot seems like the opposite.

The BLE on the other hand, RunAnalyze shows a larger variation but is a lot cleaner on the DFAa1 plot.

Care to share your thoughts?

Or should I be doing some “test” workout to get the proper data?

Like this workout from here:

Today I found out how exactly @Andreas_Fitz was getting the DFA-A1 plot from RunAnalyze. (Didnt know about it until I dig)


Bluetooth



ANT+

It’s interesting to see that ANT+ while having a cleaner visual, graph wise, actually has only ~5% valid Points (which I presume based on the data being shown, any window size of 120s > 3% artifact is invalid)

TBH - I still have no idea what to make of this data

1 Like

… just for interest …
yesterday i did a ride and my average DFA Alpha1 from Runalyze (Garmin + BLE) was 0,97.
runalyze

from the new alphaHRV app (via ANT+) my average was 0,89… so 8-9% difference

I also had one heart extracystole at the end of the ride, and here the DFA Alpha 1 from alphaHRV app drops immediately from 1.0 to 0.4… so the “artefact” isn’t corrected.
This doesn’t happen in runalyze (Garmin + BLE), it’s corrected here.

How did you get the DFAAlpha1 chart to show in Runalyze, and is it Runalyze analysis of Garmin HRV data or just the data field data from IQ Connect?

if the fit file records HRV data (must be enabled on the garmin device) then you can see it in runalyze, an runalyze analysis it itself.

This is RunAnalyze analysis of

  1. Garmin recorded HRV data (via ANT+)
  2. BreakAway App Recorded HRV Data (via BLE)

I’ve not played around w/ DFAAAlpha1

Pick an activity, then on the right hand side, the “magic marker(?)” icon.
See the “aerobic threshold estimation”

That’s what you click. (took me a while to search for it as well as I don’t use this site)

I had a very similar result last Thursday with version 0.9.6. DFA-a1 was overall about 0.1 lower then what Fatmaxxer displays and 4 artefacts detected by Fatmaxxer were not detected by the app. Fatmaxxer ECG strips showed 3 of them as movement artefacts and one APC.
I haven’t tested 0.9.8 yet because i got sick on Friday. Planning to test it this evening with Soft Kalman filter as suggested by the author and by Bruce Rogers. Artefact correction should work in 0.9.8 and preprocessing for detrending improved.

@MedTechCD the twitter guy is the developer?
ALso I tot I just read this (my) morning that Bruce says the “soft kalman” is not good?

Can you please help to point out where this is? I am not familiar and definitely do not know where is the 1.04 to 0.4

What is typically mentioned for Garmin/Polar H10 is that there are a lot more dropouts when using ANT+. Thus no RR at those moments. Less data is maybe the reason why it “looks” cleaner.
I’m not sure if the Alpha HRV app stores the RR series. If it does, I can send you a FIT with RR data from the H10 to Edge in BLE, and RR from H10 ANT+ to the IQ app? And even the RR csv from Fatmaxxer with H10 in BLE running simultaneously.
That should be an excellent comparison of the different RR streams.

1 Like

Post has been updated for version 0.9.8 on 14/2.

  • Update 2/14/21 - The artifact issue has been resolved! Above for historical interest only

it also states these at the bottom of the chart

  • The first attempt was too weak a filter, the second, too strong.
  • This is a work in progress - keep checking back
    which is why i tot that “soft kalman” is not the recommended

I was thinking - since the H10 has dual BLE channels, how about…

  1. H10 BLE + FatMaxxer (does it output a FIT file? it would be A LOT simpler to just plonk it down to RunAnalyze then)
  2. H10 BLE + Garmin
  3. H10 ANT+ AlphaHRV

then on another day, exchange 2 and 3 so that we get BLE+AlphaHRV and BLE+Garmin

OR… if you have another Capable Garmin Device

  1. H10 BLE + Garmin 1
  2. H10 ANT+ AlphaHRV
  3. H10 ANT+ Garmin 2
  4. H10 BLE + AlphaHRV

if really curious about ANT+ vs BLE.

Sorry for droning on… curious only since I don’t have A HRM that can do more than 1 BLE channel. lolz

1 Like

Search “colab” in this thread. It was the first implementation available to the public. Only post-ride and fixed (not rolling) measurement window of 2 min.

Fatmaxxer only has csv file output and it will not be synched automatically. I always startup Fatmaxxer first on my phone and after the initial 2 minutes of acquiring data, i start my Edge.
To align them, you would need to throw away the first 2 minutes.
Fatmaxxer stores 4 csv files. One with the RAW RR values, one with the “features” which are the HR, calculated A1, artefact % and some other stuff, one with 10sec ecg strips around every artefact and a log file.

Yeah… I’ve played around with that python code and tried to do something w/ it to plot, but at that time, I was not proficient in the python code to generate the plots so I didn’t follow thru.

The GoldenCheetah code seems to do the same thing as Marco’s Colab code.

Oh… that’s… too bad. Throwing away the 2min is not an issue. I do wonder how much work involved in throwing away and aligning them tho. (I’ve done my fair share of recording data on multiple devices and joining the data - using HR as the “1 data to sync them all” since ANT+ can connect to multiple devices)

That’s the preprocessing/detrending of the RR series and probably responsible for the overall lower output values. Artefact correction should work now.
The dev recommends Soft Kalman. There is now also a custom Kalman to experiment with. You need another good dfa-a1 app to compare with.

i’ve been reading too many articles on DFAa1 today and i’m pretty sure by now that I’m a bit confused.

I also just read this w/ interest, but my interest waned a bit when I saw the price (USD180) and that it only has 1 BLE channel (and no ANT+)

re: articfact correction, Bruce ROgers also states that it’s better to NOT have artifacts in the first place, (Muscle Oxygen Training: HRV artifact avoidance vs correction, getting it right the first time) which was why the data from that MoveSense HR+ is intrigueing. Having said that, what’s the point of that strap/device if the Masses (people) are using the normal Garmin HRM-Pro / Tickrs / Polar HRm?

I’m looking at fatmaxxer github but I don’t have an android device.
I’m have a Garmin and I can play w/ AlphaHRV1 so I guess this would be the best bet comparison wise.

To check accuracy of the a1 values from AlphaHRV app, you need an app that uses the Kubios Std way of calculating. Every app is getting compared with Kubios to check the accuracy.
In your case, you could check against AIEndurance or Runalayze. Don’t know if you need/have subscription.
In the case of the IQ app, it is important because the Kubios calculation can’t be done on most head units/watches. Not enough processing power. That’s why there are some attempts to do preprocessing with other filters that are less demanding in processing power.
i will check if the RR stream from the app is stored in the FIT because if it is, I could run it through Fatmaxxer and create a second Feature file from that data. Then I can compare the original a1 from Fatmaxxer with the post ride calculated one from the app. Fatmaxxer accepts RR streams in csv format to reanalyze.

Artefact correction is considered “the easy part” :grinning:
And of course, if you can avoid artefacts, that’s the best way. But I do have an APC every now and then. And I’m having a lot of trouble sitting still on my bike to avoid movement artefacts. I almost always have a couple artefacts on a 1 hour ride.

2 Likes

Thanks for the interest all of you are showing on alphaHRV. It’s still a beta app and I am working hard to provide a final fully validated version as soon as possible.
It’s not easy to make real time DFA in a Garmin device.
Feedback from all current users is being really helpful to reach the goal asap

3 Likes

I have checked the fit file from Garmin and I think the RR stream is included in the fit file, in a separate section named HRV. Would be great if anybody having access to one of the mentioned tools with Kubios calculation to verify the quality of alphaHRV data field on Garmin devices.

@David is there anything on your ToDo list to implement DFA calculation in intervals directly if the RR stream is included in the source (.fit) file?

I am a colleague and collaborator of Íñigo Tolosa, I have been doing many tests with DFA for more than 7 months and comparing it with laboratory tests, we have done fatigue tests and I have been studying the “physiology” of alpha-1 for quite some time.
I have been doing physical training with volunteers for 7 months and I have obtained spectacular results. You have to be clear about how to use alpha-1 and how to extract the thresholds, you can’t extract them with a normal training, you have to do a special test with a watts stability, otherwise the data could be wrong.
If you have any questions please do not hesitate to contact me.
If the developer of intervals wants to incorporate the detection of thresholds I am willing to collaborate with him in the methodology and in the use of script.

2 Likes