Suspension Data Acquisition

How does one read those charts? I mean, I know what they're showing but there's a lot of data density there. Is the shape of the envelope what you're looking at?

Yeah mainly the shape of the lower envelope in the first image compared to the second. 

Yeah the shape of the curve can tell you how damped it is, eg an overdamped system might peak quite early in the travel then slow down while an underdamped bike will stay high or even accelerate further in to the travel. Can also be used to see how ramp up or bottom out systems are working and also rebound damping. Peak rebound speeds normally happen just after it reaches bottom out and is extending, so you can see if low rebound speeds are being caused by too much damping or if it isn't reaching far enough in to the stroke to be generating those speeds. Or if you are getting high speeds closer to the middle of the travel on the return stroke, it would probably be a sign of a soft spring using excessively light damping to achieve those speeds

Honestly I find the BYB plots quite messy and hard to see/filter the data clearly, I wish there was an easier way to customise the views in the software. I've used heatmaps in the past to show a similar thing because you can show the density a lot clearer and it doesn't get lost in a stack of lines. This is one example, the colourscale needed some work but I felt like it packed more info in to one view

Jumping in to make a couple of points.

1. You can't actually compare the first image to the second and reliably deduce an answer for most questions as you have said they are different trails, different riders, different suspension and surely different settings/setups, different durations and different environments. It doesn't help that the plots are different scales. These 2 images show absolutely everything different (maybe the ambient temperature was the same???), and so any difference in output could be from any difference in input.
2. Just because something is obvious to see in the plots, doesn't mean there's an obvious reason/fix. "Obvious from the second image that the rebound in the rear could do with speeding up". That is not a fact. The fact is that the front/green sensor sees higher rebound speeds than the rear/white sensor.

When you make comparisons you generally need to know what questions you're asking before you record your data, so that you can setup the inputs to give you outputs showing what you're wanting to compare. 

I'll take a stab and say that the trail in the first image had a lot more jumps. This is another factor that can make the plots look different without giving helpful info - why does it matter what the suspension/wheels are doing when they are airborne?

Duration (imagine a 2 minute vs a 5 minute descent/recording) is such a simple difference that changes what looks obvious, plus once you have too much data (too long duration) the plot gets overwhelmed and you just see a solid colour.

As @TheSuspensionLabNZ has pointed out, a heatmap helps give more understandable data. Even just having each plotted point mostly transparent is a simple improvement as you don't so quickly lose the data into a solid mass (limited to the scale of a single colour rather than across many like the heatmap). At least go the scatter over the line plots in BYB when trying to analyse so you're only seeing known data, the line versions are better when explaining what the data is recording.

Hi, 

New to telemetry, slowly learning but mainly leaning on BYB's auto tune function. Getting back into MTBing is a bit of a midlife crisis thing for me so I three years back on a bike and I still don't have a great feel for suspension. My feel is it's working or it's not hence the telemetry. 

I have been learning a lot through the auto tune function in BYB but I don't have the confidence to deviate too much so I was wondering how people felt about the auto tune suggestions for gravity / DH? It seems very much the school of fast, very little low speed compression with some high speed damping to balance. I am curious to if people deviate from the auto tune suggestions and if they think there is a better direction? I'm in SoCal so riding hard pack, dry, dusty, riding gravity / DH. Any suggestions would be greatly appreciated and would be amazing if anyone was willing to share numbers they like to hit.

My second question is I am curious to trying a damper first approach but I don't really know what direction to go in compared to BYB's suggestions. Is everything damped or does the rebound stay fast and only the compression is slowed? Again if anyone was willing to share any numbers in what they think is a good direction that would be amazing! 

Thanks!!!

OK, interested to see how y'all read this data. I've put my own conclusions and proposed tuning directions at the bottom...

Rider is a local first-year elite enduro racer who was top of the heap in U19s. Bike is a 2026 megatower with a Zeb and Super Deluxe coil. Trails are typical Perth Hills goodness: short, rough, rocky and moderately steep. Logged on my logger and visualized on data.syn.bike.

Summary stats for the three runs:


 

Graphs are pretty similar across the runs; this set is typical:

What stands out to me:
-Generally running pretty firm, especially in the front. Dynamic sag ~20% (F) / 25% (R). 
-Peak rebound speeds are very quick (but would come down a bit running softer spring rates).
-Rear compression max speed is very high, and the rear uses more travel than the front, even allowing for increased dynamic sag in the rear.
-Rear displacement histogram is skewed to the right relative to the front.

I wouldn't suggest changing anything until I'd talked to the rider about it, but my suggestions would be:
-Softer spring rates, esp. in the front
-More high speed compression damping in the rear.

Thoughts?

Here is my opinion (not saying in any way or form that it is the correct one):
 

• I agree, the setup looks pretty stiff on the air side of things.
• The compression speeds for both, the rear and the front seem pretty high to me. Are you sure that those are "good reads" or could the max be some sensor spikes? Had the same on my logger in the beginning and needed to crank up the filtering a bit.
• I think I would try 5-10 psi less in the fork and a 25-50 lbs softer spring in the back and see how the dynamic sag changes. If those get a bit higher I would then try to add some clicks of LSC and HSC to both shock and fork

All of that only, if the rider feels harshness. If not, he/she may just likes a pretty stiff setup. Then I would only add the LSC and HSC to give more platform to push from = gain more speed from pumping and setteling quicker after hard impacts.

Yeah  I was going to pretty much say the same things as @Treloid - both ends look pretty stiff, average position wouldn't be completely out of possibility on a WC DH bike but for enduro its very firm. 

And the peak speeds are definitely excessive - again a DH bike might peak around 8m/s, and very high compression speeds for enduro would be around 7. I remember Darren at Push saying somewhere the highest he has seen on a world cup was 9m/s. Rebound too - typically stiff springs with generate high rebound speeds and lower compression speeds but the fact that both are very high is probably some kind of noise in the sensor

I used to use a butterworth low pass filter to remove noise above around 30Hz, but eventually found I was just getting random dropouts where the sensor was reading 0 for a sample or 2. I would just snip those samples out and everything came back down to normal levels. If theres too many successive dropouts it would need slightly more careful smoothing, but it also means a problem with the sensor that needs fixing so I spent more time focussing on that instead

Now that's interesting. That data is filtered at 100Hz. Filtering at 30Hz brings those speed peaks down a lot - around 2000 in rebound, 3500 front compression, still ~6000 rear compression.

Trap for the unwary there.

Yup that sounds much more realistic! Proportionally the fork does look much stiffer, hence the compression speeds looking very low so I would soften that and/or reduce tokens first. The shock is maybe closer to optimum

To find out where the frequency cutoff is, you can run an FFT analysis and see where the signal drops away - typically suspension stops fucntioning somewhere around 20-30Hz (friction an inertia makes it hard to respond faster than that) so if theres noise or errors you will see the random spikes above the point where the rest of the data has tapered off. Set your filter somewhere just above that (or find the source of the noise and fix it). You can use a bandpass filter or just note which peaks disappear and see if there's a common condition - eg a damaged/bent potentiometer will have gaps that cause the output to drop to 0 instantaneously partway through the stroke. But interference and other noise can be a bit more random

"Honey, I shrunk the DAQ!"

First testride with the new Trazer V2.2 and the new Sensors.

About 50 % smaller

Trippled Battery capacity 

Standalone USB-C charging port

Beeper for UX support

Two Buttons with LED

Front Sensor is now a "standard" linear potentiometer with a carbon tube "casing"

Re-designed rear sensor that now has a bearing instead of plastic on plastic with small air gaps.

Works great!

Edit:

Another overlay video for those interested. Also with a pretty stiff fork setup regarding dynamic sag (21%) ;-)

https://youtu.be/1LCTslCTWLQ?is=856_7CwAul5PZ51R

So I spoke with one of our better local tuners and he kept mentioning the BYB position velocity graph so here it is.

I am yet to understand how to properly read into it, I have been looking mostly into the Damping pyramid so far.

I agree with @TheSuspensionLabNZ that the BYB traces can be very hard to read, so I added the option to show it as a heatmap too

I also added video support that syncs with the telemetry timeline. This was super important to me and I bought my first ever action cam for it! Especially on a longer rides I had no clue what was causing many of the events. I could deduce based on impact force and GPS position, but now I know if it was a landing or a berm or breaking or whatever.

I strongly suggest that people are very careful when comparing the numbers between different telemetry systems, especially with the homegrown ones. Relatively minor filtering/grouping/binning changes lead to very different speeds and graphs and there isn't a "true" one.

For example there can be a big difference what "average" speed is, depending on how is it calculated. My app supports both the MotionIQ way - stroke-peak averaged, which counts each stroke once by peak velocity and peak travel and what I believe is the BYB way - sample averaged, which counts every sample inside compression and rebound strokes. The stroke-peak averaged produces twice the numbers of sample averaged. The BYB tuner was very confused, when I was explaining the speeds I am seeing.

Nobody works with raw numbers either. I have inherited from Tamás a Savitzky-Golay filtering of suspension speeds. Velocity is the first derivative of travel, which amplifies high-frequency noise, so this filter trades responsiveness for noise rejection. On the same data, no filter gives me 509 mm/s rebound, while 50ms (the default) is 466mm/s.

There is a lot of processing and nobody tells you what they do with the data before they show it to you.

That presentation of MI data looks way better than the original.

Wow, your App looks really good and user friendly! 😍 Was just a bit confused at first because you use orange and blue exactly in the opposite way I do 😁 I really like the dynamic sag display, might steal that idea 😉 Also really like the "Rider feedback" and pitch idea, those seem for sure hard to calculate.

Another question to all of you based on a discussion with a friend:

Since almost all bikes have a progressive leverage curve, the wheel travels more tha the shock (percentwise) especially in the beginning of the travel. Now the common knowledge seems to be to set the static SAG to 20% front and 30% rear (shock). But wouldn't that mean that everyone without telemetry is running something like 35% Sag at the wheel? 

Do you guys compare the SAG values of the fork and shock or front and rear wheel?

How do you calculate the LSC/HSC and LSR/HSR values? 🤔

I try to use sag at the wheel whenever possible, if you have the leverage data. Same for velocities and every other metric really since that is the more "true" value that the rider feels and can be compared to the front (not that they will be the same, but can be compared fairly) 

The amount of wheel sag to shock sag can also vary wildly - even for 2 bikes that are progressive overall, 30% sag at the wheel could mean anything from 20% to 35% at the shock! Hence why the Commencal V4 had crazy low recommended sag figures under 20% - it was so progressive thats what it took to get 25-30% at the wheel. 

And great looking app @carlinojoevideo ! The charts are super clear and those 3D histogram bars work really well, that kind of data can get easily lost but thats very clean!

Glad to hear you're doing the same :-) In my mind it works like " I don't care what the fork/shock is doing as long as the wheel is doing what it should"

I was asking because SC recommends 29-31% Sag at the shock for my bike, but this gives me about 35-36% at the wheel. To balance this with the fork makes the fork riding very deep and not supportive. I ended up with a pretty good feeling setup with 21% static at the front wheel and 30% static at the rear wheel.

The 30% wheel sag in the rear mean ~23% on the shock.

Hey I’ve been cruising through this thread and just at first glance it seems pretty technical. I love doing bike setup for myself and friends, is telemetry pretty easy to understand once you’ve actually got your own data, or do you need to have a technical background to actually get any use out it? Looking to pick myself up a new toy.  

I dont want to scare people away, but also not set them up for failure but its definitely not easy - you dont need a technical background but you need a lot of patience in the beginning g to understand what it all means. Ie making lots of changes while riding the same track and observing the difference in data. Then ride a different track with the same settings and see how it changes again - its easy to think you are seeing things in the data and get led astray, it is very powerful but it is just one tool or feedback to be used in conjunction with what the rider is feeling 

Would you say around 40 hours of testing is enough time to become reasonably proficient? Or is it something I’m going to have to sink 100+ plus to actual be able to use it to improve setup? Cheers!

Yeah I was going to say about the same - I was thinking 10 hours as in 5 rides + an hour of sifting through the data each and you should start to see some patterns. I would recommend only doing a handful of short runs and make one big change each time, noticing whether the bike felt good or bad and the kinds of things you noticed - eg bottoming out, wallowing, harshness/no grip. Make notes about each change and carefully track which recording matches each change. Sometimes the data will be different but felt the same to you - other times it will feel different but the numbers don't look wildly different. 

Mostly look at damper position first - average, max and distribution and then look at damper speeds. You'll see that changing spring rate also changes damper speeds so keep an eye on which way those go with each adjustment 

Quite so: there's a fundamental difference between those methods. Characterising each stroke (which my system does, by the way) carries another set of gotchas: what counts as a stroke? Real suspension data doesn't look like a neat sine wave. You need to allow for some hysteresis near the stroke end points: if you use a strict 'velocity crosses zero' test for stroke end you end up with loads of tiny strokes with no useful information.

Practically, this means you have to set a threshold for what counts as 'no movement'. I use 30mm/s (but configurable). On data.syn.bike it's explicitly called out as a setting in the UI, which I like.

There's a fine balance here between being honest about your analysis and exposing so much that your users go, "aargh, too complicated".