Interview: Discussing Data Acquisition for World Cup DH with Nick Lester – Pinkbike

We caught up with Nick Lester, the team manager for Muc-Off Young Guns, who also happens to be an expert in data acquisition. In recent years, it has been growing in the World Cup pits, and now it seems like every bike is running data acquisition to some degree.

Talk us through what system you’re using on Heather’s bike.

So on Heather’s bike, we’re using the syn.bike system, which is relatively new. I believe Norco might have had it in 2022. Currently at a World Cup, as far as I know, it’s only us and Norco that use it. It’s not drastically different to other data acquisition systems other than the fact that I think it’s just better designed in terms of the packaging. It’s got more ways to measure certain chassis movements, which fascinates me. But fundamentally, it can still do the same job in terms of suspension set up, looking at position and speed and that sort of stuff and then there will be the addition of braking sensors as well.

I think the key point I wanted to come across here is the differences between this and, say, maybe a BYB. These sensors that you use aren’t the linear actuators. Where do you have them situated?

There are four. So we have one on each axle, one near the bottom bracket and one on the handlebars. They measure accelerations in three directions and rotational speeds in three directions as well. So, by using a combination of them you can look at all sorts of stuff with regards to chassis movement, handlebar movement, weight distribution, and then like I say, a combination of those, you can end up looking at oversteer, understeer, but also with the ones on the axles.

I’m in the process of trying to correlate the data from those with the linear potentiometers, which are the typical big sliding sensors because, for me, they can be quite noisy. They’re moving parts, so they wear out, and they have come off in the past. So if I can use the data from the accelerometers on the axles and do away with the linear potentiometers, then we have a much more streamlined system and much more rider friendly. They don’t have these big sensors hanging off stuff causing noises or whatever. That’s the main difference between this and the BYB. The other difference is the BYB has got brake data and this one doesn’t at the minute, but it will do.

I guess all of it correlates to each other. So the accelerometers you’re using allow you to almost validate that suspension information?

Yeah, to a certain degree. We can use it to do that. Then the goal is that I’d like to be able to remove the large linear potentiometers out of the equation because they’re a moving part. They wear out, and they are a point of failure. Like last year, we had a couple of times, during practice luckily, where the sensor had come off or come apart. So one of the big bonuses for me is trying to use the acceleration data from the axles. For example, collating, understanding the relationship between that data and the data from the potentiometers and then sort of doing away with the larger sensors. That’s what we use in the qualifying runs on Heather’s bike, we put it in like a qualifying trim where we take those big sensors off and then just use acceleration data.

Does the system run when you remove the big sliding sensors, the linear potentiometers? It’s not like you’re missing a big chunk of data is it? Or are you able to make up for it with the others?

That’s what I’m in the process of understanding is how the two work together. Right now, during the first day of practice is when we’re using the potentiometer data to get the bike set up. So understanding position and speed. And we can do that within 3 or 4 runs. We’ve got the bike at like 80% of the way there. And then the rest of it, we can use that data as well, but the rest of it is rider feedback. So as the rider picks up speed, we’re adjusting the bike for that. Then as the track evolves, we’re adjusting the bike for that, which you can do with rider feedback as long as the rider is pretty good at feedback. But I also have the benefit of using the Stendec system in the past, which didn’t have any potentiometers on it. So I started off using acceleration data at the axles, which is a bit of an advantage, I suppose.

The way the system’s mounted, especially the big sliding sensors, the linear potentiometers, you have to have those isolated from the bike on bearings, right?

That reduces the loads through them so they can operate with as little friction as possible and as little twisting as possible. So the data is as clean as it can be. So the ones on the fork and the shock are mounted with spherical bushings so the sensor can move around but not influence the data – it just helps them be less stressed by forces.

You almost want the sensor floating on the fork, the fork acting upon it, not it acting upon the fork.

Exactly.

They’re pretty special systems that you have. They’re bespoke for each frame size?

Yeah. On Heather’s bike, she has a medium. So this has a wiring loom that is specifically for her medium frame. Whereas Ralph runs an XL frame so his wiring looms slightly longer. Then a lot of thought’s gone in by Jeff, who’s the owner of syn.bike, a lot of thoughts gone into how we mount the sensors on the shock because we’re quite limited for space. But also, like I say, incorporating those spherical bushings so that the shock can be in the ideal place with as minimal loads influencing it as possible. Then we did a lot of work on where to position the logger and then where, you know, with all the measurements we needed to get the bottom bracket sensor in the right place. So it just tried to make it as clean as possible without sort of permanently integrating it in the frame, which is tricky with a carbon one.

With a carbon frame, it’s not ideal.

Not really.

You’ve got some pretty unique shapes on this frame as well. So that’s giving you some more challenges as well, right?

Yeah, it has. It’s required some drilling and tapping of certain bits to get sensors in the perfect location. But for the most part it’s just trying to make it clean so that, mainly for the rider, they can ride the bike as much as they can with the system on. So they get used to having a system on there, but not so much that they’re aware that these sensors are hanging off everywhere. Also, the Mondraker is a very good looking bike, so trying to keep it good looking with all these cables and sensors on is not easy. But it’s what we want to do. They’ve spent a lot of time designing this bike to make it look nice and then we go and stick a load of wires on it.

And it spends a lot of time with those wires on it too, right?

Yeah, it does. The plan for when we started, we’ve got a system for each rider and the plan is to try and run it all the way through practice, all the way through quali and typically the rules aren’t as crystal clear as they should be. But with the UCI ruling, it says that you can now run these systems in finals. But I’ve had issues with some commissaires who aren’t aware of that. So in order to reduce any potential issues, they come off after qualies. But even getting quality data is a step forward. That’s good to gauge how much harder the rider pushes from practice to quali and then you can get a rough idea of like a race setting if you like, for race runs.

How long did it take to develop the unique algorithms and tools behind your data acquisition system? It seems like gathering data is one thing, but making use of it is the hard part.

The tools I use I’ve developed myself, like the various dashboards and stuff like that. It does take a while because you’re trying to understand what I’m trying to work out, what data is important to me, and how to visualize that data so that I can quickly just slap the raw data in, get the visuals I need. But also the syn.bike software is pretty good too, so I can customize various graphs to show me what I want to see.

The histogram set of graphs makes it possible too see the whole run and suspension position and speeds and stuff like that. On a race day or a race weekend I can get the key information really quickly and make the adjustments I need. And then after that day, back at the accommodation or like even after the event when I’m at home, I can then take a deeper dive into it and understand what effect these changes have had on chassis stability or rider weight distribution or whatever. I’m trying to develop those things so that I can use them a bit more efficiently during a race weekend.

Do all the riders in your team embrace the data accusation approach, or do some find it challenging to adjust?

Not everyone gets on with it. Oriol probably uses it the least, but he’s one of these riders who’s quite happy with where his bike is. He doesn’t necessarily want to faff around with settings too much. And I sort of respect that. You know, I’m not trying to force this on everyone. It’s a super useful tool for me and Heather, and Ralph uses it when we’ve done a lot of off-season or pre-season testing with it, especially because he’s new to the Mondraker. So it’s really helpful to get the bike in a good spot for him quickly and help him understand how the bike works. But it’s difficult, especially when you know English isn’t the first language and the data is great, but it does also require a conversation with the rider to get the other side of the picture as well. But it’s a tool that everyone can use. Whether or not it’s for everyone is a different question.

How do you navigate the balance between what the rider feels and the data you’re presenting? Is it always a challenging conversation to have?

No, it’s not. Sometimes it’s great because the data does verify what the rider is feeling, and that gives them a lot of confidence. But when it doesn’t, when they’re saying the bikes do it or they feel the bike’s doing one thing and the data is suggesting that it might be doing something else, then the line of questioning to try and get to the bottom of it is trickier. It’s also quite a good way to educate as a rider, especially a junior rider, because they might not have done this sort of thing before.Then all of a sudden they’re doing runs with a purpose, like trying to think about what the bike’s doing when this is happening.

Or I might ask them, you know, how do you feel the bike behaves under braking and it’s not something they might have ever thought about before during a run. So it’s quite good for getting them to think about what’s happening with the bike rather than just going out and doing laps and saying, yeah, I had a great time.

Do you think it makes it a bit easier for them being able to see that visual graph? It’s not a abstract concept really, once you’re able to visualize it.

I don’t know, sometimes showing them graphs or showing them data makes the situation more confusing. They know compression and rebound, but they might not know what that looks like or sometimes I feel like that’s giving them too much information and just makes the situation worse. So I do show them a graph so I can show them what I’m talking about, when I suggest maybe we try this. But for the most part they’re feeling on the bike and their perception of what’s happening on the bike and then me either backing that up with what the data is saying or pushing back a little bit and saying, oh, maybe we actually need to do it. I find that a bit more useful than showing them a graph.

What we have spoken about so far has been data acquisition, not telemetry. There is a difference, right?

Yeah, there is. Data acquisition is recording and storing the data to review later, and telemetry is live data streaming from the bike.

Do you think we could ever see telemetry used in mountain biking?

Not entirely sure what benefit it would have in downhill because it’s not like you can make an adjustment on the move yet, or you or if you can, the rider has control of that anyway. Then the other issue is I’m not familiar with telemetry systems, so I don’t know how that data is transferred, what systems are used, how it’s secured. The other issue we have is that we’re usually in dense woodland. So I’m not sure whether that would pose a problem, but it would be interesting to see if and when that arrives what benefit it has.