Interview: Discussing data collection for the World Cup DH with Nick Lester

We met with Nick Lester, manager of Muc-Off Young Guns, who is also an expert in data mining. It’s been on the rise in the World Cup pits in recent years and it now seems like every bike is collecting data to some extent.

Tell us about the system you use on Heather’s bike.

So on Heather’s bike we use the syn.bike system, which is relatively new. I believe Norco could have had it in 2022. As far as I know, currently in the World Cup we and Norco are the only ones using it. It’s not drastically different from other data collection systems except that, in my opinion, it’s just better designed in terms of packaging. It has more ways to measure certain chassis movements, which I find fascinating. But basically it can still do the same job in terms of setting up the suspension, checking position, speed and things like that, and then brake sensors will be added as well.

I think the key point I wanted to make here is the differences between this and, say, BYB. These sensors you are using are not linear actuators. Where did you get them?

There are four. So we have one on each axis, one near the bottom bracket and one on the handlebar. They measure accelerations in three directions and rotational speeds also in three directions. So, using a combination of them, you can look at all sorts of factors related to chassis movement, steering movement, weight distribution, and then, as I say, the combination of these elements can end up with oversteer, understeer, but also with those on the axles.

I’m in the process of trying to correlate data from linear potentiometers, which are typically large sliding sensors, as they can be quite noisy in my case. These are moving parts, so they wear out and have fallen off in the past. So if I can use data from accelerometers on the axles and dispense with linear potentiometers, we will have a much more streamlined system and much more driver-friendly. They don’t have these big sensors that hang things that make noise or anything. This is the main difference between this and BYB. The other difference is that BYB has brake data and this one doesn’t at the moment, but it’s enough.

I think it’s all related. So the accelerometers you use allow you to almost verify your suspension information?

Yes, to some extent. We can use it for this. The goal is therefore to remove large linear potentiometers from the equation because they are the moving part. They wear out and are a point of failure. Just like last year, fortunately we had a few times during training where the sensor became detached or fell apart. So one of the biggest benefits for me is trying to use the acceleration data from the axle. Like collating, understanding the relationship between that data and the data from the potentiometers, and then kind of giving up on the larger sensors. This is what we use for qualifying runs on Heather’s bike. We rig it like a qualifying trim where we take these big sensors off and then use the acceleration data.

Does the system work with the large sliding sensors and linear potentiometers removed? It’s not like you’re missing a big chunk of data, right? Or maybe you can make up for it with others?

I’m just in the process of understanding how these two things work together. Right now, on the first day of training, we use the data from the potentiometer to configure the bike. So understanding position and speed. And we can do it in 3 or 4 rounds. The bike is already about 80% done. And we can also use the rest, but the rest is cyclists’ opinions. As the cyclist gains speed, we adjust the bike accordingly. Then, as the track develops, we adapt the bike to that, which can be done based on rider feedback, provided he can respond well to feedback. But I also have the advantage that in the past I used a Stendec system that did not have any potentiometers. So I started by using axle acceleration data, which I think has some advantages.

The way the system is mounted, especially the large sliding sensors and linear potentiometers, must have these components isolated from the bike on bearings, right?

This reduces the loads passing through them so they can operate with as little friction and twist as possible. This keeps the data as clean as possible. So those on the fork and shock are mounted with spherical bushings so the sensor can move but has no effect on the data – it just helps with less force loading.

You almost want the sensor to float on the fork and for the fork to act on it, rather than it acting on the fork.

Exactly.

These are quite special systems that you have. Are they custom made for each frame size?

Yes. On the bike, Heather is medium. It has a wiring harness specifically for her medium body type. While Ralph has an XL frame, so his wiring is a bit longer. Next, Jeff, who owns syn.bike, put a lot of thought into how we mount the sensors in the shock because we have quite limited space. But also, as I say, the use of these spherical bushings so that the shock absorber is in the perfect place with the least impact on it. Then we did a lot of work on where to put the recorder and where, you know, making all the measurements that we needed to get the bottom bracket sensor in the right place. So they just tried to make it as clean as possible without permanently integrating it into the frame, which is difficult with a carbon frame.

It’s not perfect with the carbon frame.

Not really.

You also have some very unique shapes on this frame. It also gives you more challenges, right?

Yes, it does. Some drilling and tapping bits are required to place the sensors in the perfect location. But mostly we just try to clean the bike so that it’s mainly for the cyclist to be able to cycle as much as possible with the system on. So they get used to having the system there, but not enough to realize that these sensors are hanging everywhere. Plus, the Mondraker is a very good looking bike, so keeping it in good condition with all those cables and sensors is not easy. But that’s what we want to do. They spent a lot of time designing this bike to make it look nice, and then we attached a lot of wires to it.

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

That’s how it works. At the beginning we planned to have a system for each player and the plan is to try to apply it in training, qualifying and usually the rules are not as clear as they should be. However, the UCI ruling states that these systems can now be used in finals. But I had problems with some commissioners who were not aware of this. So, to reduce potential problems, they are eliminated after qualifying. But even getting high-quality data is a step forward. It’s a good idea to gauge how hard a rider is pushing from practice to qualifying, and then you can get a rough idea of ​​what the race setup looks like, if you will, for race heats.

How long did it take to develop the unique algorithms and tools behind the data collection system? It seems that collecting data is one thing, but using it is the difficult part.

The tools I use I developed myself, such as various dashboards and the like. This takes some time because you’re trying to understand what I’m trying to develop, what data is important to me, and how to visualize it so that I can quickly just drop in the raw data and get the visualizations that I want to need. But the syn.bike software is pretty good too, so I can customize different graphs to show me what I want to see.

A set of histogram graphs also allows you to check the entire mileage, suspension position, speed and the like. On race day or during a race weekend, I can get key information very quickly and make any changes I need. And then when I get back to my accommodation or even after the event when I’m at home, I can dig deeper and understand what effect those changes had on chassis stability, driver weight distribution, or whatever. I’m trying to develop these things so I can use them a little more effectively during the race weekend.

Are all members of your team adopting a data-led approach, or are some finding it difficult to adapt?

Not everyone can handle it. Oriol probably uses it the least, but he’s one of those riders who is quite happy with where his bike is. I don’t necessarily want to mess with the settings too much. And in a way I respect that. You know, I don’t want to impose this on everyone. This is a very useful tool for Heather and I, and Ralph uses it when we do a lot of testing with him in the off-season or pre-season, especially because he is just starting to use Mondraker. Therefore, it is very helpful to quickly place the bike in its appropriate place and help you understand how the bike works. However, this is difficult, especially when you know that English is not the first language and you have great data, but it also requires talking to the driver to see the situation from the other side. But it is a tool that anyone can use. Whether it is for everyone is another matter.

How do you strike a balance between the cyclist’s feelings and the data you present? Is conversation always a challenge?

No, it’s not. Sometimes this is a great solution because the data verifies what the cyclist is feeling, which gives him great confidence. But when that doesn’t happen, when they say bikes do this, or they feel a bike does one thing and the data suggests it can do something else, then the line of questioning aimed at getting to the heart of the problem is more difficult. It’s also a pretty good way to educate the rider, especially a younger rider because they may not have done this type of thing before. Then suddenly they’re running with a purpose, like trying to think about what the bike is doing when it happens.

Or I could ask them, you know, how you think the bike behaves when braking, which is not something they might have ever thought about before while running. So it’s quite good to get them thinking about what’s going on with the bike rather than just going out and doing laps and saying, “Yeah, I had a great time.”

Do you think this will make it easier for them to see this visual chart? It’s really not an abstract concept if you can imagine it.

I don’t know, sometimes showing them charts or data makes things more confusing. They know compression and rebound, but they may not know what it looks like, and sometimes I feel like it gives them too much information and only makes things worse. So I show them a chart to show what I’m talking about when I suggest we try this. But for the most part, they feel the bike and their perception of what’s happening on the bike, and I either back it up with data or I kind of step back and say, “oh, maybe we should actually do that.” Do it. I find this a bit more useful than showing them a chart.

So far we have talked about data acquisition, not telemetry. There is a difference, right?

Yes Sir. Data acquisition is the recording and storage of data for later review, and telemetry is the transmission of live data from the bike.

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

I’m not entirely sure how much benefit this would have on descents as it’s not like you can make adjustments on the move yet, either you or if you can, the rider has control over it anyway. Another issue is that I don’t know anything about telemetry systems, so I don’t know how this data is transmitted, what systems are used and how it is secured. Another problem is that we usually stay in dense forest. So I’m not sure this would be a problem, but it would be interesting to see if and when it happens, what the benefits would be.