This AiM Solo data shows speed (black) and braking G (green) for a portion of a lap. The area from 7400 feet to 8100 feet (as shown along the bottom of the graph) is a hard braking zone; note how speed is decreasing rapidly, and that a more positive braking trace indicates harder braking. This AiM Solo data shows speed (black) and braking G (green) for a portion of a lap. The area from 7400 feet to 8100 feet (as shown along the bottom of the graph) is a hard braking zone; note how speed is decreasing rapidly, and that a more positive braking trace indicates harder braking.

Ride better using data acquisition: Braking

Written by  on Thursday, 20 September 2012 09:40

Another data channel that shows a significant amount of information about the rider's habits - and is easily generated in almost any data acquisition system - is braking G. This channel shows actual deceleration in units of g, as opposed to brake pressure, which shows what's happening at the lever but requires an additional sensor.

The braking G channel can be calculated from a number of sources. Taking the derivative of the speed channel (yes, calculus does come in handy sometimes) is one method. Another is to use the data provided by the internal accelerometer that most data acquisition systems have. Or GPS longitudinal acceleration can be used, a channel found on many of the GPS-enabled lap timers currently available. The data shown here is from an AiM Solo GPS-based lap timer, with the braking G channel created using AiM's Race Studio software. The raw GPS longitudinal acceleration data does show braking force, but manipulating the data to show just deceleration and make braking a positive value makes it much easier to visualize what's actually happening on the track.

There are several areas of interest in the braking G channel. Foremost is the maximum value, which can range anywhere from .8 g (a street bike with street tires on moderately abrasive pavement) to 1.3 g (a race bike on race tires at the track). At the beginning of the braking zone, the data trace should ramp up smoothly to its maximum, at a rate of about 1 g per second. This value represents the time it takes for the bike's weight to fully transfer to the front tire for maximum braking; a slower rate indicates the rider could be getting on the brakes quicker. The point of maximum braking should be early in the braking zone, as shown in the graph by the red triangle at approximately 7500 feet. Braking at higher speed is much more effective than at lower speed, so the earlier you can get to maximum deceleration in a braking zone, the better.

Note that if the braking zone is short enough, the rider may not be able to reach the maximum value seen in a longer braking zone before having to release the brakes to enter the corner. For example, at the end of a short straight, braking G may increase to just .4 or .5 g before decreasing to zero at the corner entry - there is just not enough time/distance to get to maximum braking. Through the middle of the braking zone, the top of the trace should be smooth and remain close to the maximum value.  In the attached graph, the rider holds a steady .85 g of braking for 250 feet before beginning to release the brakes.

When the brakes are released near the entry to the corner, the braking trace should smoothly reduce to zero. The rate of release depends on the type of corner and the rider's style, but the trailing edge should be smooth with no bumps or dips. If desired, further math channels can be generated to graphically display how quickly the brakes are applied and how smoothly the rider holds the maximum and releases the brakes.

Deviation from this ideal shape for the braking G data trace - a smooth increase to maximum, constant in the middle of the braking zone and a gradual taper to zero at the corner entry - requires further investigation to find whether the cause is a particular characteristic of the track, something involving bike setup, or an aspect of the rider's style.

Read 4666 times
Last modified on Thursday, 20 September 2012 09:43
Published in Andrew Trevitt

IM Admin

/ This email address is being protected from spambots. You need JavaScript enabled to view it.

back to top