yep - definitely do longer . steps to allow levels to stabilise. Marco suggests 6-8 min steps and every time I’ve seen people here use shorter steps they also seem to get strange numbers. Have a look at his suggested protocol in this post.
For all of these tests, very much need longer times at each step. Throw away anything you have read or done with three minute lactate (or other) tests with short times at each power level.
For LT1, this power level is well within the ability to ride for a long time. Set up a workout with 8-10 min steps with 10 watt changes. Do the ride as a workout and get good data.
For example, if you think your LT1 is 180w and you have an FTP around 240-250w, then plan to ride steps at 150-160-170-180-190-200-210. That’s a good workout and you should get good data.
FWIW, and slight tangent, even the classic ten min steps MLSS test aiming for -10w, MLSS, and +10w as a bracket doesn’t work well.
I don’t like to test much. So if I’m going to test, I try to make the protocol rock solid. Saves time in the end.
1 Like
I recommend you guys do this test by HR rather than power.
You can start with an estimate. San Milan suggest the talk test. Seiler recommends 65% of HRmax.
Warm-up, get your HR in that range and see where DFA a1 is. Go 5 beats higher or lower depending on the reading.
Once you find your DFA a1 heart rate, you are there.
I’ve found that actual power at DFA a1 will fluctuate with freshness. If I’ve had a rest days or some easy riding prior, I’ll get a higher power at DFA a1. If my legs are cooked, I’ll put out 20-25 watts less at DFA a1.
1 Like
Phil, I did this exact experiment a couple of years ago with the same kind of results. After 6-7 weeks of this training, I was breaking Strava PRs left and right and riding stronger than ever. I continued this type of training for 13 weeks, peaking at 13 hours per week, and unfortunately didn’t see further gains.
I’m happy with the experiment but really wish I had switched gears to a sweet spot or threshold block after the 7 weeks.
This kind of training definitely increased my durability and overall endurance.
2 Likes
Hello,
in my DFA Alpha 1 records i can see some extrasystoles, especially when my puls / power changes (goes up or down). In this example i did a 3 minute All-Out effort.
The green line is the power output, and the black dots are the RR-Intervals (millisecounds between heart beats).
Still have been at the doctors and everything should be ok so far with my heart. Extrasystoles are “normal”.
Anybody of you recognizes something like this?
New data field
available for 520 Plus, 530, 820, 830, and 1030 variants.
5 Likes
Thought I should point out that alpha 1 isn’t just for finding lt1 threshold but can also be useful to track fatigue
https://physoc.onlinelibrary.wiley.com/doi/full/10.14814/phy2.14956
Another reason why I’d love tr to be able to do the recording and calculations in the app to help train the model. (Not saying it should be exposed in the UI as I do see the issue with overwhelming the user with data for those who aren’t data geeks)
Also implemented here:
@Nate_Pearson what’s the chance you could do this in tr? Could be useful for red light/green light, well to end the workout early or flag that the prediction was wrong if they got a green light
4 Likes
Doesn’t TR need to be recording RR interval first? I thought that they had updated it to record it, but I didn’t see it when looking through the settings the other day. My .fit files exported to garmin don’t have it, so Kubios cannot do any analysis on the TR files.
1 Like
these are too vague or too low. Better to do the ramp test.
This is true and very key, but with enough long sample you get a sense of the range.
They don’t. This is not really a simple ask as getting good data isn’t simple.
-have to use ble over ant+ (so need some way to tell users which option they should pick which is more a UX problem)
-have to identify which strap is being used to record with. Mix of a UX problem in telling users which brands they should buy and a data issue to handle the data from different sources differently
-positioning the strap is not so easy. Need so way to inform users that while they get good hr data their hrv needs better positioning
- with recorded data need to flag if it has bad data in it so should be ignored
That’s all before doing the actual calculations are done
does apple support ant+? Samsung does not any more, so I needed to upgrade to a Bluetooth strap just to get hr data after upgrading from my old s7. I say this since tr is talking about using hrv, but the reality is that they are probably a long ways off.
Tr has made no announcement that they will measure hrv directly in the app. (Hence my post above) Even if they did add support it will take awhile to do something with the data. Even if they did something with the data, it’s just one data point so you won’t need it even if it helps get it to understand you better. Plus the data can help train the model so the model can work better for everyone (other things may corralate with the measurement) the same as how everyone doesn’t need to be measured in a metabolic cart to take advantage of the data.
Apple never directly supported ant.
If you want to support hrv just get a polar h9 or h10 as your new strap
This is on the list of things to try and feed into models.
I did a fair amount of DFA alpha 1 training for Cape Epic but I used a separate app with TR at the same time.
We just hired 2 more data engineers who’ve been on for about a month. Basically, it’s just a manner on how fast we can do things. But the team is super smart, they are aware of all of this, and they are methodically working through their ideas.
This makes me think though that we should start recording this pretty soon so that we can have lots and lots of data when we start.
Edit: I just asked if we could schedule doing the work to record this data. The goal would be to start the work to record it in about 2 months.
But that doesn’t mean we’ll hit that as priorities change.
11 Likes
Muscle Oxygen blog has tons of great info, and they specifically reference a collection method in this post that another app upgraded to recently:
" The HRV software needs to first “detrend” the data. This has nothing to do with “detrended fluctuation analysis”, AKA “DFA”. The detrending of RR data is done to remove “stationaries”. These are slow changes in beat pattern from other causes. If they are not removed properly, the DFA a1 will appear more “ordered” than it should be and a bias upward will be seen at very low values (for example a true a1 of .4 may appear as a .6 or higher). This has been the bugaboo of some of the other software approaches including the initial python related packages. For instance, Runalyze was somewhat inaccurate before they enhanced their approach to using the “smoothness priors” approach of Kubios. HRV logger does not use the “smoothness priors” of Kubios fame method either. The issue is worse for recordings with more stationaries of course - so YMMV. We saw very good accuracy with HRV logger in the Frontiers study, but in my personal use, it is not there. After a fair amount of work, Fatmaxxer has been significantly upgraded to use the Kubios method of “smoothness priors” . Despite the calculation load, the speed is not affected even with a re-computation of every 5 seconds"
Original paper referenced for “smoothness priors”: An advanced detrending method with application to HRV analysis - PubMed
1 Like
If you guys need specific types of data generated, put out the word. Am sure you’ll get some volunteers, probably too many of us, to help out.
2 Likes
Yah, I think it’s pretty exciting.
I would love to use it to drive aerobic wattage/progression levels.
And if it could also be used to drive Redlight/Greenlight with HRV that would be even cooler.
It would solve a lot of problems in one swoop. And we wouldn’t even have to explain the details to the Athlete. Just do all the heavy lifting on our side and tell them what to do.
It goes with one of our supporting brand promises: We handle the details so you don’t have to.
9 Likes
I just uploaded my data to see what they recommend and it is…uninspiring. The heuristic of avoiding anything with the explicit label AI, is undefeated.
Yes. All you need is the timings now. Well, as long as you have the meta data to go with it so you know if it should be discarded or at least given way less weight if it comes from a source that is likely less reliable. How to process the data is easy to work out later during the summer when you have less data coming in as I’m guessing your app is more heavily used in winter.
If you can start to record the data as soon as you connect to the heart rate strap and for as long as you can after if you’ve seen the work of how workout intensity can be measured by hrv change from before to after. (I.e. there should be data from before you start the workout and after the workout is over). Maybe record a session from the moment it connects till the moment the workout starts and the moment after the workout ends till shutdown or disconnect of the sensor. The server can piece together the three parts so don’t have to extend how you record a workout. The after a workout recording may have to be sent the next time the app is launched to maximize the time you can record and not block the user from quitting. Obviously this change should wait till after you record r-r intervals as this requires a change in the way the app starts and ends recordings.
1 Like
The polar HR strap doesn’t give me the running metrics that the garmin does. I got the garmin Pro, but to be honest tracking DFA 1 alpha doesn’t seem really very convenient at all, so I am not sure of the effectiveness. One could track respiration rate in a gentle ramp as well.
Kinda surprised people are spending so much time to figure out LT1, when if youre trying to train under LT1, there’s really no reason to overthink it. I would expect this much discussion on lt2 as that is quite the black box.
3 Likes
LT1 ends up being very relevant, specially when you develop it and it’s very close to LT2.