 ## How easy is it to stumble over acceleration and deceleration?

Mar 11, 2022 | ACADEMY, WEBINAR

We had a look at the match data of a Serie A player. We analysed accelerations and decelerations by using the standard criteria (acc above a threshold of ± 2.5 m/s² for more than a minimum time, which duration is above 0.5 s).

In the following figure, there are the number of accelerations (green) and the number of decelerations (red) above ± 2,5 m/s². Each bar represents a duration category. From the acceleration side (right, green), the 3 dark green bars are respectively:

• 15 accelerations that last from 0.5 to 0.75 seconds;
• 14 other accelerations that last from 0.75 to 1 s;
• 3 accelerations that are longer than 1 s.

Altogether, at the end of the match, the accelerations above 2,5 m/s² and that last more than 0.5 s are 32.

On the deceleration side (left, red), the dark-red bars are respectively:

• 18 decelerations that last from 0.5 to 0.75 s;
• 14 decelerations that last from 0.75 to 1 s;
• 5 decelerations that are longer than 1 s.

The sum of these bars is the total number of decelerations at the end of the match that is equal to 37.

What about the light-coloured bars? What do they correspond to?

They are the accelerations (in green) and the deceleration (in red), that are still above the threshold of ± 2,5 m/s² but do not last long enough to be counted in the total number of accs/decs (i.e. duration < 0.5 s). The question is: is it OK to forget about them? They are much more numerous than the events we counted, as you can see.

We tried to play a little with the acceleration threshold and the minimum time, just to understand how a small change leads to a very big difference in the outcome. On the lower right, we reported the results we saw. The acceleration threshold is ± 2.5 m/s² and the minimum time is 0.5 s. What happens if we decrease the acceleration threshold to ± 2 m/s² by leaving unchanged the minimum time (top right panel)? We will get a number of events that is almost twice the acceleration and the deceleration that we have seen before, with just a small decrease of the threshold by ± 0.5 m/s².

Differently (lower left panel), what happens if we decrease the minimum time from 0.5 to 0.4 seconds by leaving unchanged the acceleration threshold? We will again get, as a result, an increased number of events (both accelerations and decelerations) but, in this case, the increase is 30%.

The last combination consists in both changes at the same time: decreasing the acceleration/deceleration threshold from ± 2.5 m/s² to ± 2m/s² and reducing the minimum time from 0.5 to 0.4 s. By doing so, we get almost 3 times the number of events obtained with the standard settings.

This raises more than one question about the criteria to define an acceleration/deceleration event since we can play with both the threshold and the minimum time without finding a convincing reason to choose one over the other.

1) about threshold. What happens above 2.5 m/s² that doesn’t happen below? In other words, what’s the point of choosing 2.5 m/s² instead of 2.0 or 3.0? It’s clear that this is an arbitrary threshold because there is no physiological explanation that can help justify the choice in a convincing way.

2) about duration. A minimum time was perhaps necessary at the beginning to exclude spurious accelerations/decelerations peaks that could have affected the total amount of events counted; nowadays, with an ever increasing sampling rate of the devices and a greater attention to filtering techniques, it is more difficult to think of the same type of need. However, there is still the issue of how long an acceleration has to last in order to be considered “an acceleration”. It might sound like a play on words, but the numbers we saw earlier say a lot about the impact of such changes on the total number of accelerations detected. In short, how long does an acceleration take? This apparently simple question is very hard to answer.

3) about starting speed. We haven’t said anything yet about the starting speed from which an acceleration phase begins. However, this is one of the most critical points when we deal with acceleration. The best way to clarify this point is to make a simple example (see the figure below): let’s consider a player who performs two similar accelerations. 1. the first (green) allows him to reach an acceleration peak of about 1.0 m/s² starting from a speed of about 2.0 m/s; if this is the case, the achieved acceleration represents only a very small fraction of the player’s potential indicated by the individual Acceleration-Speed Profile (ASP – red line);
2. the second (blue), despite the same acceleration time course, starts from a speed of about 6.0 m/s which is a completely different context; this condition forces the player to use his full potential in order to reach the best accelerations possible at those specific speeds (about 6-9 m/s), as indicated by his individual ASP.

So the lesson is: it’s difficult to define the criteria to detect an acceleration event in terms of acceleration threshold and minimum duration because, in both cases, the selected references seem to be entirely arbitrary. Even though we can live with this random choice, that still doesn’t solve the starting speed dilemma: the same acceleration could be a very easy or a maximal one, depending on the speed at which it occurs. Unfortunately, however, by using acceleration alone, we are not able to distinguish one from the other. This means that we can take into account some ‘easy’ acceleration that reaches the threshold but is far from the peak possibilities of the player, only because it’s performed from low speeds; on the contrary, we lose along the way some ‘strong’ acceleration that is below the threshold but able to carry the player very close to his maximal potential (this kind of acceleration occur mainly from moderate to high speeds).

Dealing with accelerations to understand the performance can be quite complicated if we don’t take these aspects into consideration. For this reason, it’s always a good idea to handle accelerations and decelerations with care while monitoring our players.

In the near future, we will propose an alternative way to fill this gap and make the most of the information that these types of events make available to us.

Author: Cristian Osgnach

Related Contents
Related Contents