The point of data acquisition systems like MI (RIP) & BYB is not to be prescriptive, it's to give you data figures that you can correlate with a ride feeling. The more testing a rider does with the system, the more they can start to know what number ranges work for them in certain conditions. Both those systems will give you some starting point ideas for some key metrics (i.e. front / rear dynamic sag, rebound speeds, etc.) but they're just a starting point. On top of that, they help give riders a better understanding of what specific changes will do to to the suspension, which might not have been obvious to them at first. Like, for me one thing they helped me realize was how much of an affect faster rebound has on dynamic ride height - like, I can leave pressure and comp alone on my fork, but if I speed up rebound, the fork will feel like it sits higher.
Then when the bike isn't feeling good, the rider can look at the various data metrics, and compare them to what they know feels good, and make the corresponding adjustments. Before data systems, the really good teams kept detailed notebooks with all their settings for each race, along with track conditions, so they could go back to them. They still do that, but this is better because the bikes & suspension are always changing, so they can try to replicate saved data for specific tracks/conditions.
Edit: one further point. These systems don't need to be accurate so much as they need to be consistent - the units or exact numbers aren't super critical, but a value from one run needs to mean the same thing as on another run.
Every time suspension/brake/drivetrain data acquisition comes up in mtb media there's a discussion of the hardware. Engineers, I'm sure you're valuable and wonderful people. But just...
Every time suspension/brake/drivetrain data acquisition comes up in mtb media there's a discussion of the hardware. Engineers, I'm sure you're valuable and wonderful people. But just for a minute accept the premise that these systems are 100% accurate.
The first question raised by anyone looking at these data should be "So what?"
How, and under what circumstances, do these data help you accomplish something? Look at that Syn screenshot from a few posts back. These data are dumb. There's nothing remotely prescriptive in this. And that goes for the screenshot that's supposed to be Seagrave's DA output, too. There're no performance metrics, there's no context (here we can make some assumptions that Seagrave's team actually does have this stuff in a system alongside the DA--rider notes, spotter notes, a profile of the track, timing, etc). Our premise was that the hardware is accurate, and so we accept that in the descriptive sense that these data are true, but these data are just the measures the hardware folks decided they could implement within the constraints on the product -- that's no guarantee that each or any of these will be useful, or that some other potentially more useful measurement wasn't left out.
Which should give everyone pause when this cottage industry of people trying to tune your ride according to these data pop up making a meal out of whatever is to hand. Dynamic sag? Every so-called average of a set of measurements is stupid if you're not careful about what gets included and not included in the set, and if you're not carefully looking at the distribution of the data. Balanced suspension is better? What exactly do you mean by balanced: max wheel speeds fore-aft in a given hit, mean wheel speeds fore-aft in a given hit, max shaft speeds fore-aft, mean shaft speeds fore-aft? What's your rationale for the choice? How close do to measures have to be to be considered balanced vs imbalanced? And what's the evidence balanced as you define it is better in the first place? Which performance metrics are you watching? Cause those aren't on this screen and likely aren't even captured by this system of hardware. So ask of the data, 'so what?'
It shouldn't just be scientists who are disappointed by pseudoscience. Put your engineering hat back on. Imagine turning in a report with your name on it making serious predictions about future performance using data like these. Imagine really building something that was really expected to perform and your reputation was at stake because people are actually going to check your work. You wouldn't trust this stuff. You wouldn't drive your family car over the bridge that mountain bike DA built. Believing in this stuff now isn't like generously incubating a technology that will later deliver even more; being unable to tell fake from real may slow the development of stuff that actually works, since you remove pressure to achieve real gains.
Engineers take the raw data, think through what they see, decide what is happening and make changes to the suspension. Then repeat the run and look at the data again.
That's where the engineering part comes in, you interpret the raw data, you don't need the software to tell you if it is good or not. What you see is what you get and it's on you to determine if it is indeed good or bad. Having raw values at least gives you some confidence you are seeing the real thing vs. "add x clicks" where you have no idea what that suggestion is based on other than the fact it comes from a black box.
People think MI folding is from general industry-wide turmoil? Any chance Spesh decided to go a proprietary, integrated way with it?
That is exactly what I predict is happening. I sort of alluded to it earlier, but now it's public knowledge that spesh was the backing company I'm pretty sure they want to keep the underlying technology for themselves. They might have genuinely intended for MI to continue as a separate product but changes in the Industry meant they had to cut anything that didn't directly benefit them. It's a big shame but judging by Rob's comments it sounds like a ruthless yet understandable business decision. The technology and code base can have a ton of use for all kinds of applications which are gaining popularity so I highly doubt specialized would just throw it away.
That is exactly what I predict is happening. I sort of alluded to it earlier, but now it's public knowledge that spesh was the backing company...
That is exactly what I predict is happening. I sort of alluded to it earlier, but now it's public knowledge that spesh was the backing company I'm pretty sure they want to keep the underlying technology for themselves. They might have genuinely intended for MI to continue as a separate product but changes in the Industry meant they had to cut anything that didn't directly benefit them. It's a big shame but judging by Rob's comments it sounds like a ruthless yet understandable business decision. The technology and code base can have a ton of use for all kinds of applications which are gaining popularity so I highly doubt specialized would just throw it away.
Ugh. Hate to hear that.
In this particular instance, I guess I’m left sincerely hoping some asian company reverse engineers / steals the hell out of this tech and it’s available outside of spesh bikes. Lewis Instruments here I come!
People think MI folding is from general industry-wide turmoil? Any chance Spesh decided to go a proprietary, integrated way with it?
From someone I know who until this year worked for Spec, it's just part of blanket cuts by the new (asshole) CEO. Told every division to cut x% (I heard 35%) regardless of profitability. Lots of their sub-programs/projects/sponsorship stuff got killed by that.
Y'all are making my point for me. No one is seeing raw data. If you don't understand how a mean is calculated beyond what you learned in primary school (summation x1, x2...xn) / n, and how meaning (ha ha) is made from it, then that could be a profitable place to start. If you don't understand how a given visualization of data emphasizes some and deemphasizes others, that could be a useful conversation. You're seeing edited, interpreted data. The idea of "key metrics" (thank you AndehM) is exactly what I'm talking about. Where's the evidence that they are "key"? If you know enough data science to be comfortable talking about looking for correlates, then you should know that the more data you look at the more false correlates you find, and you need the rest of the suite of tools from data science to deal with that, not more data. If you thought about the business of bringing some totally 'objective' measuring tool to market (bro it's just data to use as you see fit), you might understand that it only has value to the extent that customers think they can get some improvement out of it. Just read bike forums and you 'll see someone every week say they tried DA and now have a better setup. So it's not a useful distinction between a corny, overtly prescriptive product that hides the tuning algorithm from the user while giving suggestions, and these implicit descriptive-data-plus-the-tuning-guide-in-the-manual kind of algorithm. You may not realize it but they're bothinterpretive out beyond what the "raw" data really say, which is improper for the basic reason that no one has ever shown that any of these can be used in some combination to predict the stuff a rider actually cares about (e.g. traction, handling, speed) such that you can model the outcomes using only the DA-supplied metrics.
From someone I know who until this year worked for Spec, it's just part of blanket cuts by the new (asshole) CEO. Told every division to...
From someone I know who until this year worked for Spec, it's just part of blanket cuts by the new (asshole) CEO. Told every division to cut x% (I heard 35%) regardless of profitability. Lots of their sub-programs/projects/sponsorship stuff got killed by that.
Methinks that does not bode well for it ever being released as a standalone product...
Y'all are making my point for me. No one is seeing raw data. If you don't understand how a mean is calculated beyond what you learned...
Y'all are making my point for me. No one is seeing raw data. If you don't understand how a mean is calculated beyond what you learned in primary school (summation x1, x2...xn) / n, and how meaning (ha ha) is made from it, then that could be a profitable place to start. If you don't understand how a given visualization of data emphasizes some and deemphasizes others, that could be a useful conversation. You're seeing edited, interpreted data. The idea of "key metrics" (thank you AndehM) is exactly what I'm talking about. Where's the evidence that they are "key"? If you know enough data science to be comfortable talking about looking for correlates, then you should know that the more data you look at the more false correlates you find, and you need the rest of the suite of tools from data science to deal with that, not more data. If you thought about the business of bringing some totally 'objective' measuring tool to market (bro it's just data to use as you see fit), you might understand that it only has value to the extent that customers think they can get some improvement out of it. Just read bike forums and you 'll see someone every week say they tried DA and now have a better setup. So it's not a useful distinction between a corny, overtly prescriptive product that hides the tuning algorithm from the user while giving suggestions, and these implicit descriptive-data-plus-the-tuning-guide-in-the-manual kind of algorithm. You may not realize it but they're bothinterpretive out beyond what the "raw" data really say, which is improper for the basic reason that no one has ever shown that any of these can be used in some combination to predict the stuff a rider actually cares about (e.g. traction, handling, speed) such that you can model the outcomes using only the DA-supplied metrics.
Sir, this is a wendy's....
But in all seriousness for MI and Specialized is that someone buys the IP from them and then can recoup some of their development costs. The idea there being enough consumers who want suspension data AND are willing to put up with Specialize's BS is a pretty slim market. I'm still super hopeful MI still makes it to market since some bikes just wont work without it due to shock placement.
But snfoithat, you say, ride height is a fundamental -- it impacts steering angle, trail, available travel -- we know it's important!
Sure, provisionally let's say instantaneous ride height at the initiation of some feature matters. I'm on board. Let's take the example of a sweet right hand corner. The problem is that mean ride height means f-all. It is included in these softrware packages because it's easy to implement and there are a world full of lazy people who think they understand it because they learned to calculate mean in 5th grade.
We care about the instantaneous ride height at about 9.5 seconds. Because cornering. Fine. I care too.
How does putting all the ride heights from t=0 to t=9 into the sample from which we calculate the mean actually help? The bike is on different terrain; the rider's weight is located differently with respect to the bike; it's just not relevant. Why would you include it in your calculation of the mean? Why calculate the mean at all if we want to know about the ride height at 9.5s? If we only ran the DA from t=5 to t=10, the mean would be different, If we ran the logger for 5 minutes before the segment shown in schematic form here, it would be different. Choosing the time boundaries of the sample drives the number -- not the suspension settings! Aggregating data that don't belong together makes the insights worse, not better.
Zoom out to a 2ish minute DH test track kind of segment, and your data set of 120s @ 1kHz is going to contain tens of thousands of data points that have f-all to do with the what the chassis was doing at the initiation of a turn or whatever you are trying to tune for in a given session. See the problem?
Y'all are making my point for me. No one is seeing raw data. If you don't understand how a mean is calculated beyond what you learned...
Y'all are making my point for me. No one is seeing raw data. If you don't understand how a mean is calculated beyond what you learned in primary school (summation x1, x2...xn) / n, and how meaning (ha ha) is made from it, then that could be a profitable place to start. If you don't understand how a given visualization of data emphasizes some and deemphasizes others, that could be a useful conversation. You're seeing edited, interpreted data. The idea of "key metrics" (thank you AndehM) is exactly what I'm talking about. Where's the evidence that they are "key"? If you know enough data science to be comfortable talking about looking for correlates, then you should know that the more data you look at the more false correlates you find, and you need the rest of the suite of tools from data science to deal with that, not more data. If you thought about the business of bringing some totally 'objective' measuring tool to market (bro it's just data to use as you see fit), you might understand that it only has value to the extent that customers think they can get some improvement out of it. Just read bike forums and you 'll see someone every week say they tried DA and now have a better setup. So it's not a useful distinction between a corny, overtly prescriptive product that hides the tuning algorithm from the user while giving suggestions, and these implicit descriptive-data-plus-the-tuning-guide-in-the-manual kind of algorithm. You may not realize it but they're bothinterpretive out beyond what the "raw" data really say, which is improper for the basic reason that no one has ever shown that any of these can be used in some combination to predict the stuff a rider actually cares about (e.g. traction, handling, speed) such that you can model the outcomes using only the DA-supplied metrics.
I see what you're saying a bit more clearly now.
1) You have a point. If you leave the MI system running across flat ground or with a bunch of dead time, it does alter your results. You need to start/stop with some degree of promptness.
2) You're assuming that people aren't looking at the raw data! It's very easy to extract the data from the MI system and develop your own tools to analyze. It does take some work, but I would be really, really surprised if anybody using this at the world cup level isn't doing so.
Anyhow. With a fair amount of experience with the system, the built in tools can tell you a lot about certain things, and if you want to know more you can pretty quickly and easily dig further into it. As others have stated, it's all just data and it's up to the user to figure out what to do with it. For most, what MI spits out is more than enough. For other, they need to go deeper.
Edit - And to replyl to your other comment. Why does mean ride height matter? I assume you mean dynamic sag? I think it matters. Again, it's just one of many numbers, but if I have a dynamic sag of 25%, make a change and it's 26%, that tells me something. Now, did I change my spring rate or my rebound damping? What it means depends on what I chnaged. Again, it's all just context and feedback on changes. And you could dive in deep enough to look at what your ride height is heading in and out of a corner. It just takes some digging. But the data is there!
But snfoithat, you say, ride height is a fundamental -- it impacts steering angle, trail, available travel -- we know it's important!Sure, provisionally let's say instantaneous...
But snfoithat, you say, ride height is a fundamental -- it impacts steering angle, trail, available travel -- we know it's important!
Sure, provisionally let's say instantaneous ride height at the initiation of some feature matters. I'm on board. Let's take the example of a sweet right hand corner. The problem is that mean ride height means f-all. It is included in these softrware packages because it's easy to implement and there are a world full of lazy people who think they understand it because they learned to calculate mean in 5th grade.
We care about the instantaneous ride height at about 9.5 seconds. Because cornering. Fine. I care too.
How does putting all the ride heights from t=0 to t=9 into the sample from which we calculate the mean actually help? The bike is on different terrain; the rider's weight is located differently with respect to the bike; it's just not relevant. Why would you include it in your calculation of the mean? Why calculate the mean at all if we want to know about the ride height at 9.5s? If we only ran the DA from t=5 to t=10, the mean would be different, If we ran the logger for 5 minutes before the segment shown in schematic form here, it would be different. Choosing the time boundaries of the sample drives the number -- not the suspension settings! Aggregating data that don't belong together makes the insights worse, not better.
Zoom out to a 2ish minute DH test track kind of segment, and your data set of 120s @ 1kHz is going to contain tens of thousands of data points that have f-all to do with the what the chassis was doing at the initiation of a turn or whatever you are trying to tune for in a given session. See the problem?
May I have the chocolate Frosty please?
You're not wrong. But this is still fairly new technology for mere mortals so we are all learning a lot, and anyone who sticks with it will hopefully figure that out. Those who are looking for a quick answer will quickly give up and go back to making up hocus pocus tuning advice for their customers. But there are real insights to be learned from data and the more people do it the more they will understand the limitations, we just need to give them time to learn!
As for using average ride height - most software has the ability to trim data to any interval you like, removing flat sections or focusing on one part of the trail. Also like a lot of metrics it isn't much use from a single run, but as you make changes the number will shift (or not!) So while the actual value might not be relevant, if all else is kept the same then a change in that number makes it much more meaningful.
Sure, a lot of people are probably overlooking that right now, and expecting to maintain an average fork travel of 15% on super steep tracks because thats what they saw on their usual DH track. But we all need to be allowed to make these mistakes and keep in mind what we feel on the trail to decide if those values matter or not
But snfoithat, you say, ride height is a fundamental -- it impacts steering angle, trail, available travel -- we know it's important!Sure, provisionally let's say instantaneous...
But snfoithat, you say, ride height is a fundamental -- it impacts steering angle, trail, available travel -- we know it's important!
Sure, provisionally let's say instantaneous ride height at the initiation of some feature matters. I'm on board. Let's take the example of a sweet right hand corner. The problem is that mean ride height means f-all. It is included in these softrware packages because it's easy to implement and there are a world full of lazy people who think they understand it because they learned to calculate mean in 5th grade.
We care about the instantaneous ride height at about 9.5 seconds. Because cornering. Fine. I care too.
How does putting all the ride heights from t=0 to t=9 into the sample from which we calculate the mean actually help? The bike is on different terrain; the rider's weight is located differently with respect to the bike; it's just not relevant. Why would you include it in your calculation of the mean? Why calculate the mean at all if we want to know about the ride height at 9.5s? If we only ran the DA from t=5 to t=10, the mean would be different, If we ran the logger for 5 minutes before the segment shown in schematic form here, it would be different. Choosing the time boundaries of the sample drives the number -- not the suspension settings! Aggregating data that don't belong together makes the insights worse, not better.
Zoom out to a 2ish minute DH test track kind of segment, and your data set of 120s @ 1kHz is going to contain tens of thousands of data points that have f-all to do with the what the chassis was doing at the initiation of a turn or whatever you are trying to tune for in a given session. See the problem?
You're not wrong. But this is still fairly new technology for mere mortals so we are all learning a lot, and anyone who sticks with it...
You're not wrong. But this is still fairly new technology for mere mortals so we are all learning a lot, and anyone who sticks with it will hopefully figure that out. Those who are looking for a quick answer will quickly give up and go back to making up hocus pocus tuning advice for their customers. But there are real insights to be learned from data and the more people do it the more they will understand the limitations, we just need to give them time to learn!
As for using average ride height - most software has the ability to trim data to any interval you like, removing flat sections or focusing on one part of the trail. Also like a lot of metrics it isn't much use from a single run, but as you make changes the number will shift (or not!) So while the actual value might not be relevant, if all else is kept the same then a change in that number makes it much more meaningful.
Sure, a lot of people are probably overlooking that right now, and expecting to maintain an average fork travel of 15% on super steep tracks because thats what they saw on their usual DH track. But we all need to be allowed to make these mistakes and keep in mind what we feel on the trail to decide if those values matter or not
Spot on; I am trying to learn how my suspension actually works and what changing the settings does. I know what it feels like when I change stuff but don't have a good way to quantify it.
Having a repeatable way to measure what's happening and then correlating that to what I feel is what I care about and MI seemed to offer that. I've gone as far as I can w/ the (very rudimentary) ShockWiz and BYB is too big an investment for me atm.
Maybe I'm an outlier but I just want to understand what my fancy suspension is actually doing and how that changes with different inputs.
But snfoithat, you say, ride height is a fundamental -- it impacts steering angle, trail, available travel -- we know it's important!Sure, provisionally let's say instantaneous...
But snfoithat, you say, ride height is a fundamental -- it impacts steering angle, trail, available travel -- we know it's important!
Sure, provisionally let's say instantaneous ride height at the initiation of some feature matters. I'm on board. Let's take the example of a sweet right hand corner. The problem is that mean ride height means f-all. It is included in these softrware packages because it's easy to implement and there are a world full of lazy people who think they understand it because they learned to calculate mean in 5th grade.
We care about the instantaneous ride height at about 9.5 seconds. Because cornering. Fine. I care too.
How does putting all the ride heights from t=0 to t=9 into the sample from which we calculate the mean actually help? The bike is on different terrain; the rider's weight is located differently with respect to the bike; it's just not relevant. Why would you include it in your calculation of the mean? Why calculate the mean at all if we want to know about the ride height at 9.5s? If we only ran the DA from t=5 to t=10, the mean would be different, If we ran the logger for 5 minutes before the segment shown in schematic form here, it would be different. Choosing the time boundaries of the sample drives the number -- not the suspension settings! Aggregating data that don't belong together makes the insights worse, not better.
Zoom out to a 2ish minute DH test track kind of segment, and your data set of 120s @ 1kHz is going to contain tens of thousands of data points that have f-all to do with the what the chassis was doing at the initiation of a turn or whatever you are trying to tune for in a given session. See the problem?
You're not wrong. But this is still fairly new technology for mere mortals so we are all learning a lot, and anyone who sticks with it...
You're not wrong. But this is still fairly new technology for mere mortals so we are all learning a lot, and anyone who sticks with it will hopefully figure that out. Those who are looking for a quick answer will quickly give up and go back to making up hocus pocus tuning advice for their customers. But there are real insights to be learned from data and the more people do it the more they will understand the limitations, we just need to give them time to learn!
As for using average ride height - most software has the ability to trim data to any interval you like, removing flat sections or focusing on one part of the trail. Also like a lot of metrics it isn't much use from a single run, but as you make changes the number will shift (or not!) So while the actual value might not be relevant, if all else is kept the same then a change in that number makes it much more meaningful.
Sure, a lot of people are probably overlooking that right now, and expecting to maintain an average fork travel of 15% on super steep tracks because thats what they saw on their usual DH track. But we all need to be allowed to make these mistakes and keep in mind what we feel on the trail to decide if those values matter or not
Spot on; I am trying to learn how my suspension actually works and what changing the settings does. I know what it feels like when I...
Spot on; I am trying to learn how my suspension actually works and what changing the settings does. I know what it feels like when I change stuff but don't have a good way to quantify it.
Having a repeatable way to measure what's happening and then correlating that to what I feel is what I care about and MI seemed to offer that. I've gone as far as I can w/ the (very rudimentary) ShockWiz and BYB is too big an investment for me atm.
Maybe I'm an outlier but I just want to understand what my fancy suspension is actually doing and how that changes with different inputs.
None of this data equipment is perfect. It's just another metric to help set up the bike; we still need some input from the rider.
I'm trying really hard not to get baited by this conversation. I wanted to make this thread a positive place for us to come learn about how we can record data, learn more about reading data and using these systems. It's always a lot easier to tell everyone what you are doing wrong, rather than what some people are doing well and encourage them to keep learning about their hobby.
But snfoithat, you say, ride height is a fundamental -- it impacts steering angle, trail, available travel -- we know it's important!Sure, provisionally let's say instantaneous...
But snfoithat, you say, ride height is a fundamental -- it impacts steering angle, trail, available travel -- we know it's important!
Sure, provisionally let's say instantaneous ride height at the initiation of some feature matters. I'm on board. Let's take the example of a sweet right hand corner. The problem is that mean ride height means f-all. It is included in these softrware packages because it's easy to implement and there are a world full of lazy people who think they understand it because they learned to calculate mean in 5th grade.
We care about the instantaneous ride height at about 9.5 seconds. Because cornering. Fine. I care too.
How does putting all the ride heights from t=0 to t=9 into the sample from which we calculate the mean actually help? The bike is on different terrain; the rider's weight is located differently with respect to the bike; it's just not relevant. Why would you include it in your calculation of the mean? Why calculate the mean at all if we want to know about the ride height at 9.5s? If we only ran the DA from t=5 to t=10, the mean would be different, If we ran the logger for 5 minutes before the segment shown in schematic form here, it would be different. Choosing the time boundaries of the sample drives the number -- not the suspension settings! Aggregating data that don't belong together makes the insights worse, not better.
Zoom out to a 2ish minute DH test track kind of segment, and your data set of 120s @ 1kHz is going to contain tens of thousands of data points that have f-all to do with the what the chassis was doing at the initiation of a turn or whatever you are trying to tune for in a given session. See the problem?
You're not wrong. But this is still fairly new technology for mere mortals so we are all learning a lot, and anyone who sticks with it...
You're not wrong. But this is still fairly new technology for mere mortals so we are all learning a lot, and anyone who sticks with it will hopefully figure that out. Those who are looking for a quick answer will quickly give up and go back to making up hocus pocus tuning advice for their customers. But there are real insights to be learned from data and the more people do it the more they will understand the limitations, we just need to give them time to learn!
As for using average ride height - most software has the ability to trim data to any interval you like, removing flat sections or focusing on one part of the trail. Also like a lot of metrics it isn't much use from a single run, but as you make changes the number will shift (or not!) So while the actual value might not be relevant, if all else is kept the same then a change in that number makes it much more meaningful.
Sure, a lot of people are probably overlooking that right now, and expecting to maintain an average fork travel of 15% on super steep tracks because thats what they saw on their usual DH track. But we all need to be allowed to make these mistakes and keep in mind what we feel on the trail to decide if those values matter or not
Spot on; I am trying to learn how my suspension actually works and what changing the settings does. I know what it feels like when I...
Spot on; I am trying to learn how my suspension actually works and what changing the settings does. I know what it feels like when I change stuff but don't have a good way to quantify it.
Having a repeatable way to measure what's happening and then correlating that to what I feel is what I care about and MI seemed to offer that. I've gone as far as I can w/ the (very rudimentary) ShockWiz and BYB is too big an investment for me atm.
Maybe I'm an outlier but I just want to understand what my fancy suspension is actually doing and how that changes with different inputs.
I'm in the same boat. Bought a Shockwiz when I bought my first set of fancy clicker suspension (Lyrik RC2, Super Deluxe RCT at the time, what then became the Ultimate level with MY20) and wanted a 'backup' to figuring out all the clickers. Turns out I'm REEEEEEEEAAAAAAALLY bad at feeling the stuff. A friend of mine mentioned his fork feels very stiff. Take away a click of HSC, lower the pressure, add a token, bam, much more happy. On a different Lyrik ultimate, "I can hardly see, I'm shaken around" -> take away a click of HSC and instantly it's much better. I do have some ability to give advice, but when it comes to me, I'm either too lazy or don't feel anything. So I'd like something more than a Shockwiz to be able to see what's going on with my suspension, but I don't want to drop BYB levels of cash.
Well, when I say 'I'd like to see what's going on', I should really just go out and ride more
I think that's awesome! What a great change in the tone of this conversation. My name's Matt and I like mountain bikes too -- pleasure to meet you. You don't need to know this because the substance of the argument is already laid out, and I don't think the messenger is something we should pay so much attention to. But after I got laid off from my last job as a bike mechanic I got an advanced degree in biology (physiology), and for many years now I've taught a course at university for sports science and nursing students where we attach sensors (e.g. force, electrical potential) to human subjects and do data acquisition and analysis. It's a lot of fun 🥳
The reason for me to add my piece to this thread isn't to try to dunk on someone who forgot high school level descriptive statistics. It's because the biggest voices in this space aren't people who just want to learn, it's bloggers and influencers and "tech editors" who are sometimes full of shit, and you can see the evidence of their bad work embedded in what regular mtb people write in places like Vital. The biggest voices in this space aren't pro race teams like Canyon Factory Racing (callback to Seagrave and Co.) or professional suspension tuners who knew their trade before DA even came on the scene -- have you noticed they are pretty cagey about telling everyone just how they use this stuff? They have their reasons not to blab everything they know.
I'm not really interested in what the tool could do under some perfect conditions; I feel like I have a reasonably good handle on that -- I'm interested in how it's really being used by amateurs and how it's being talked about, because I think that matters.
And dynamic sag(TM) (it just means "mean") is the worst -- the worst! -- "metric" you could be focusing on in this exploration of ride-feel correlations (ugh). Like I said, that is a UI/UX (also, ugh) problem, not a suspension problem. We can make a spreadsheet together if you absolutely have to see more numbers. 🤢
The point of data acquisition systems like MI (RIP) & BYB is not to be prescriptive, it's to give you data figures that you can correlate with a ride feeling. The more testing a rider does with the system, the more they can start to know what number ranges work for them in certain conditions. Both those systems will give you some starting point ideas for some key metrics (i.e. front / rear dynamic sag, rebound speeds, etc.) but they're just a starting point. On top of that, they help give riders a better understanding of what specific changes will do to to the suspension, which might not have been obvious to them at first. Like, for me one thing they helped me realize was how much of an affect faster rebound has on dynamic ride height - like, I can leave pressure and comp alone on my fork, but if I speed up rebound, the fork will feel like it sits higher.
Then when the bike isn't feeling good, the rider can look at the various data metrics, and compare them to what they know feels good, and make the corresponding adjustments. Before data systems, the really good teams kept detailed notebooks with all their settings for each race, along with track conditions, so they could go back to them. They still do that, but this is better because the bikes & suspension are always changing, so they can try to replicate saved data for specific tracks/conditions.
Edit: one further point. These systems don't need to be accurate so much as they need to be consistent - the units or exact numbers aren't super critical, but a value from one run needs to mean the same thing as on another run.
Engineers take the raw data, think through what they see, decide what is happening and make changes to the suspension. Then repeat the run and look at the data again.
That's where the engineering part comes in, you interpret the raw data, you don't need the software to tell you if it is good or not. What you see is what you get and it's on you to determine if it is indeed good or bad. Having raw values at least gives you some confidence you are seeing the real thing vs. "add x clicks" where you have no idea what that suggestion is based on other than the fact it comes from a black box.
People think MI folding is from general industry-wide turmoil? Any chance Spesh decided to go a proprietary, integrated way with it?
That is exactly what I predict is happening. I sort of alluded to it earlier, but now it's public knowledge that spesh was the backing company I'm pretty sure they want to keep the underlying technology for themselves. They might have genuinely intended for MI to continue as a separate product but changes in the Industry meant they had to cut anything that didn't directly benefit them. It's a big shame but judging by Rob's comments it sounds like a ruthless yet understandable business decision. The technology and code base can have a ton of use for all kinds of applications which are gaining popularity so I highly doubt specialized would just throw it away.
Ugh. Hate to hear that.
In this particular instance, I guess I’m left sincerely hoping some asian company reverse engineers / steals the hell out of this tech and it’s available outside of spesh bikes. Lewis Instruments here I come!
From someone I know who until this year worked for Spec, it's just part of blanket cuts by the new (asshole) CEO. Told every division to cut x% (I heard 35%) regardless of profitability. Lots of their sub-programs/projects/sponsorship stuff got killed by that.
Y'all are making my point for me. No one is seeing raw data. If you don't understand how a mean is calculated beyond what you learned in primary school (summation x1, x2...xn) / n, and how meaning (ha ha) is made from it, then that could be a profitable place to start. If you don't understand how a given visualization of data emphasizes some and deemphasizes others, that could be a useful conversation. You're seeing edited, interpreted data. The idea of "key metrics" (thank you AndehM) is exactly what I'm talking about. Where's the evidence that they are "key"? If you know enough data science to be comfortable talking about looking for correlates, then you should know that the more data you look at the more false correlates you find, and you need the rest of the suite of tools from data science to deal with that, not more data. If you thought about the business of bringing some totally 'objective' measuring tool to market (bro it's just data to use as you see fit), you might understand that it only has value to the extent that customers think they can get some improvement out of it. Just read bike forums and you 'll see someone every week say they tried DA and now have a better setup. So it's not a useful distinction between a corny, overtly prescriptive product that hides the tuning algorithm from the user while giving suggestions, and these implicit descriptive-data-plus-the-tuning-guide-in-the-manual kind of algorithm. You may not realize it but they're both interpretive out beyond what the "raw" data really say, which is improper for the basic reason that no one has ever shown that any of these can be used in some combination to predict the stuff a rider actually cares about (e.g. traction, handling, speed) such that you can model the outcomes using only the DA-supplied metrics.
I’m going to MSA this week. I’ll keep my eyes pealed for any new systems being used by the teams!
Methinks that does not bode well for it ever being released as a standalone product...
Sir, this is a wendy's....
But in all seriousness for MI and Specialized is that someone buys the IP from them and then can recoup some of their development costs. The idea there being enough consumers who want suspension data AND are willing to put up with Specialize's BS is a pretty slim market. I'm still super hopeful MI still makes it to market since some bikes just wont work without it due to shock placement.
But snfoithat, you say, ride height is a fundamental -- it impacts steering angle, trail, available travel -- we know it's important!
Sure, provisionally let's say instantaneous ride height at the initiation of some feature matters. I'm on board. Let's take the example of a sweet right hand corner. The problem is that mean ride height means f-all. It is included in these softrware packages because it's easy to implement and there are a world full of lazy people who think they understand it because they learned to calculate mean in 5th grade.
We care about the instantaneous ride height at about 9.5 seconds. Because cornering. Fine. I care too.
How does putting all the ride heights from t=0 to t=9 into the sample from which we calculate the mean actually help? The bike is on different terrain; the rider's weight is located differently with respect to the bike; it's just not relevant. Why would you include it in your calculation of the mean? Why calculate the mean at all if we want to know about the ride height at 9.5s? If we only ran the DA from t=5 to t=10, the mean would be different, If we ran the logger for 5 minutes before the segment shown in schematic form here, it would be different. Choosing the time boundaries of the sample drives the number -- not the suspension settings! Aggregating data that don't belong together makes the insights worse, not better.
Zoom out to a 2ish minute DH test track kind of segment, and your data set of 120s @ 1kHz is going to contain tens of thousands of data points that have f-all to do with the what the chassis was doing at the initiation of a turn or whatever you are trying to tune for in a given session. See the problem?
May I have the chocolate Frosty please?
I see what you're saying a bit more clearly now.
1) You have a point. If you leave the MI system running across flat ground or with a bunch of dead time, it does alter your results. You need to start/stop with some degree of promptness.
2) You're assuming that people aren't looking at the raw data! It's very easy to extract the data from the MI system and develop your own tools to analyze. It does take some work, but I would be really, really surprised if anybody using this at the world cup level isn't doing so.
Anyhow. With a fair amount of experience with the system, the built in tools can tell you a lot about certain things, and if you want to know more you can pretty quickly and easily dig further into it. As others have stated, it's all just data and it's up to the user to figure out what to do with it. For most, what MI spits out is more than enough. For other, they need to go deeper.
Edit - And to replyl to your other comment. Why does mean ride height matter? I assume you mean dynamic sag? I think it matters. Again, it's just one of many numbers, but if I have a dynamic sag of 25%, make a change and it's 26%, that tells me something. Now, did I change my spring rate or my rebound damping? What it means depends on what I chnaged. Again, it's all just context and feedback on changes. And you could dive in deep enough to look at what your ride height is heading in and out of a corner. It just takes some digging. But the data is there!
You're not wrong. But this is still fairly new technology for mere mortals so we are all learning a lot, and anyone who sticks with it will hopefully figure that out. Those who are looking for a quick answer will quickly give up and go back to making up hocus pocus tuning advice for their customers. But there are real insights to be learned from data and the more people do it the more they will understand the limitations, we just need to give them time to learn!
As for using average ride height - most software has the ability to trim data to any interval you like, removing flat sections or focusing on one part of the trail. Also like a lot of metrics it isn't much use from a single run, but as you make changes the number will shift (or not!) So while the actual value might not be relevant, if all else is kept the same then a change in that number makes it much more meaningful.
Sure, a lot of people are probably overlooking that right now, and expecting to maintain an average fork travel of 15% on super steep tracks because thats what they saw on their usual DH track. But we all need to be allowed to make these mistakes and keep in mind what we feel on the trail to decide if those values matter or not
Spot on; I am trying to learn how my suspension actually works and what changing the settings does. I know what it feels like when I change stuff but don't have a good way to quantify it.
Having a repeatable way to measure what's happening and then correlating that to what I feel is what I care about and MI seemed to offer that. I've gone as far as I can w/ the (very rudimentary) ShockWiz and BYB is too big an investment for me atm.
Maybe I'm an outlier but I just want to understand what my fancy suspension is actually doing and how that changes with different inputs.
None of this data equipment is perfect. It's just another metric to help set up the bike; we still need some input from the rider.
I'm trying really hard not to get baited by this conversation. I wanted to make this thread a positive place for us to come learn about how we can record data, learn more about reading data and using these systems. It's always a lot easier to tell everyone what you are doing wrong, rather than what some people are doing well and encourage them to keep learning about their hobby.
I'm in the same boat. Bought a Shockwiz when I bought my first set of fancy clicker suspension (Lyrik RC2, Super Deluxe RCT at the time, what then became the Ultimate level with MY20) and wanted a 'backup' to figuring out all the clickers. Turns out I'm REEEEEEEEAAAAAAALLY bad at feeling the stuff. A friend of mine mentioned his fork feels very stiff. Take away a click of HSC, lower the pressure, add a token, bam, much more happy. On a different Lyrik ultimate, "I can hardly see, I'm shaken around" -> take away a click of HSC and instantly it's much better. I do have some ability to give advice, but when it comes to me, I'm either too lazy or don't feel anything. So I'd like something more than a Shockwiz to be able to see what's going on with my suspension, but I don't want to drop BYB levels of cash.
Well, when I say 'I'd like to see what's going on', I should really just go out and ride more
I think that's awesome! What a great change in the tone of this conversation. My name's Matt and I like mountain bikes too -- pleasure to meet you. You don't need to know this because the substance of the argument is already laid out, and I don't think the messenger is something we should pay so much attention to. But after I got laid off from my last job as a bike mechanic I got an advanced degree in biology (physiology), and for many years now I've taught a course at university for sports science and nursing students where we attach sensors (e.g. force, electrical potential) to human subjects and do data acquisition and analysis. It's a lot of fun 🥳
The reason for me to add my piece to this thread isn't to try to dunk on someone who forgot high school level descriptive statistics. It's because the biggest voices in this space aren't people who just want to learn, it's bloggers and influencers and "tech editors" who are sometimes full of shit, and you can see the evidence of their bad work embedded in what regular mtb people write in places like Vital. The biggest voices in this space aren't pro race teams like Canyon Factory Racing (callback to Seagrave and Co.) or professional suspension tuners who knew their trade before DA even came on the scene -- have you noticed they are pretty cagey about telling everyone just how they use this stuff? They have their reasons not to blab everything they know.
I'm not really interested in what the tool could do under some perfect conditions; I feel like I have a reasonably good handle on that -- I'm interested in how it's really being used by amateurs and how it's being talked about, because I think that matters.
And dynamic sag(TM) (it just means "mean") is the worst -- the worst! -- "metric" you could be focusing on in this exploration of ride-feel correlations (ugh). Like I said, that is a UI/UX (also, ugh) problem, not a suspension problem. We can make a spreadsheet together if you absolutely have to see more numbers. 🤢
MSA Data Bits
Post a reply to: Suspension Data Acquisition