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)
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
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.
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.
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.
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”
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.
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
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.
