I think Shane was referring to his video that Wade cited in the original post in this thread: he had connected a Roam 3 and a BiNavi to the same power meter and went for a ride while dual-recording.
This was with the old SRM speed sensor. Here’s a histogram of speed as recorded by the old SRM head unit from about an hour of riding. Notice the pattern that looks like a comb with missing teeth. This was for one SRM/head unit, so I asked on the old Wattage List for riders to examine their own SRM data for specfic speeds and got several responses, all saying that combing back through years of data, they saw the same missing tooth pattern. At the time I thought it was just an oddity of ADC or DAC conversion, but I hadn’t yet come up with VE, which depends on acceleration. The reason why I recommend a speed sensor over GPS now is exactly because GPS speed readings are noisier than wheel speed sensors.
1 Like
One other point: you all have been following the Romandie Feminin DQ fiasco? As @caley_fretz explains, it’s really about data fidelity and who owns those data. It turns out I’ve been examining speed and power data from riders during the same race and making comparisons across riders, and I think I can spot some revealing things. I’ve been doing that without exact GPS data but GPS data would make it simpler. Sometimes I can tell that a rider’s PM must be off, and I’ve had to exclude that rider’s data.
My point is that PM consistency for an individual for training purposes is probably good enough, but if you’re measuring an individual’s drag, or if you’re trying to uncover relative performance or relative behavior across individual riders, accuracy is pretty important.
3 Likes
Another scenario that impacts the small group of inclined people, are those analyzing Aggregate Power Data of tens of thousands of users. The Discord had noticed that intervals.icu has on-by-default filters in place that “automatically detect power spikes over time”, which a decently trained anaerobic phenotype could easily trip and have their ride hidden from their training history, and consequently the aggregate user data. The threshold is very conservative – 30% or more above FTP over some X minutes.
We learned what motivated intervals.icu, was that some PMs have really bad power spikes, presumably when some are low on battery. This trashes not just your own dataset, but also the whole global dataset. Their % based on FTP used to be 20%, but lots of users complained so it was bumped to 30% (which people still trigger)
The more I look at interval’s aggregate data, the more it is apparent there are other filters being applied to make their final presented dataset as hygienic as possible. Not their fault at all, but a consequence of 1000’s of sensors out in the field, of which some are very noisy and polluting the global dataset. And it is unreasonable to expect every user to be hygienic with their data themselves, let alone know how to identify and correct anomalies.
…. btw….
I get that the prevailing use case for PM owners is to glance at their own data, and maybe their friends’ Strava. I get the use case I brought up above is far more esoteric, but it’s one of those things where if everyone’s Sensors and the pipeline that delivered the data streams to the final database worked near-flawlessly, then aggregate data would be far less unwieldy. I imagine large aggregates like TrainerRoad or even coaches working exclusively with online-clients have their own version of this, too.
But Noise & Loss gonna Noise & Loss.
3 Likes