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
- Garmin recorded HRV data (via ANT+)
- 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.
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ā¦
- H10 BLE + FatMaxxer (does it output a FIT file? it would be A LOT simpler to just plonk it down to RunAnalyze then)
- H10 BLE + Garmin
- 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
- H10 BLE + Garmin 1
- H10 ANT+ AlphaHRV
- H10 ANT+ Garmin 2
- 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
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.
I think I know the answer will be no but here goes anywayā¦is there a way of getting the data into an Edge 520 to get the data onto a post ride chart in intervals.icu? By that I mean even via a download of a csv from Fatmaxxer or HRVLogger.
Not everyone is following up on this thread as actively as I do, so Iāll make a quick wrap-up to avoid confusion.
- The RR stream in the HRV field from the FIT file is the one recorded by the Garmin itself when the option is enabled in the settings of your unit. Coming from the source that is paired as a std HRM, be it BLE or ANT+.
- I donāt know yet if the AlphaHRV IQ app records its own RR stream though and if it is, where it resides. I sure hope itās not overwriting the HRV fieldā¦ The a1 value is for sure in another dev field and already displayed in Garmin Connect and Intervals. Edit: The RR from the app is not in the FIT file. Tested on version 0.9.9
- If both RR streams were available in the FIT, that would make it very easy to compare signal quality between BLE and ANT+. The app has 2 fields in the dev section: Alpha1 Raw and Alpha1. I have no idea what the RAW means
- Post-ride calculation of DFA-a1 in Intervals is already on davidās todo list and will probably use the code from Fatmaxxer because itās the easiest one to integrate (Java)
I think that a post-ride analysis should be done the Kubios way (smoothness priors filter) because Kubios remains the goto software for this analysis. Post-ride means that it will be done on a desktop, tablet or phone and these devices have enough processing power to do it.
AlphaHRV is a blessing when it comes to real-time calculation and display of the a1 metric. Itās much easier to have it directly on your sports-unit iso. running on a seperate phone. It can be very helpfull to keep you at the correct intensity on outdoor Z2 rides. Itās no big problem if it is slightly off and letās be honest, it will never exactly match the other apps simply because it has not only another preprocessing filter but also another measuring window (200 beats iso 2 min)
Determining tresholds is another story. Iām already using a1 for a couple of months during indoor rides where I have Fatmaxxer running on my phone. I know my VT1 point pretty well now. Iām not using it for VT2 though. Still I think that tresholds should be determined post-ride after following a good protocol for this kind of thing. And that is still a debate. Ramp or step, increase per step, step duration, ā¦ But then again, why determine tresholds in bpm or Watts if you can have a1 in realtime? Just use a1 directly during your Z2 rides for intensity discipline and you will not be dependent on tresholds that need retesting when your FTP has grown or your fitness has improved and VT1 was pushed up.
Do you happen to know if this is possible in an Edge 520?