What Is Motorcycle Data Acquisition — and What Can It Actually Tell You?

So what is data logging?

At its simplest, data logging is recording information over time.

A sensor measures something.

A device records it.

You look at it later.

That might be engine speed, throttle position, GPS speed and position, brake pressure, suspension position, wheel speed, gear position, engine temperature, lambda, acceleration or lean-rate information.

The result is a series of measurements stored against time.

For example:

Throttle position = 72% at 14.382 seconds.

Not especially exciting on its own.

But record that measurement many times every second alongside speed, RPM, brake pressure, suspension movement, wheel speeds and GPS position and suddenly you have a detailed record of what the motorcycle and rider were doing around the lap.

That is where things become useful.

What is a data logger?

A data logger is the device doing the recording.

Something like a GPS lap timer is a relatively simple example.

It may record position, speed, acceleration, lap time and sector time internally and allow that information to be downloaded after the session.

More sophisticated motorcycle data loggers can communicate with the ECU over CAN bus, acquire analogue and digital sensor signals and combine all of those channels against a common time base.

Now we might be recording:

RPM + throttle + gear + wheel speeds + brake pressure + suspension position + GPS + IMU + engine parameters

at the same time.

The important point is that the logger is not the analysis.

It is collecting evidence.

A very expensive logger fitted to a badly instrumented motorcycle can still produce extremely expensive nonsense.

What is data acquisition?

Data acquisition — usually shortened to DAQ — describes the complete process of measuring, collecting and recording information from the motorcycle.

That means considerably more than simply owning a data logger.

A proper motorcycle data acquisition system includes things such as sensor selection, wiring, signal conditioning, CAN communication, ECU channels, analogue inputs, digital and frequency inputs, GPS or GNSS position, sampling frequency, calibration, signal resolution, synchronisation, logging hardware and analysis software.

In other words:

The logger is one component of the data acquisition system.

Think of the difference this way.

A camera records an image.

That does not mean photography is simply the act of purchasing a camera.

Likewise, fitting a logger to a race bike does not automatically give you a useful DAQ system.

You need to decide what you are trying to measure, why you are measuring it, how accurately you need to measure it and what decision you intend to make from the result.

Otherwise you are simply collecting numbers.

Engineers already have enough numbers.

We do not need decorative ones.

And what is telemetry?

Now we arrive at the word that gets abused most frequently.

Telemetry is the remote transmission of measurement data.

The key word is:

remote.

If a Formula 1 car sends live information back to engineers while it is circulating, that is telemetry.

If a spacecraft sends measurements back to mission control, that is telemetry.

If a motorcycle records information internally and somebody plugs a laptop into it when the bike returns to the garage…

that is not telemetry.

That is data logging.

Or, more broadly, data acquisition.

Telemetry can form part of a data acquisition system, but the terms are not interchangeable.

The distinction is particularly relevant in motorcycle racing because most race-bike engineering is performed using on-board data acquisition rather than continuous bike-to-pit telemetry.

The motorcycle records the evidence.

The engineer studies it when the bike returns.

Bad data in. Bad decisions out.

There is an old rule in computing and measurement systems: the output can only ever be as trustworthy as the information going in.

For race engineering we can shorten that slightly:

Bad data in. Bad decisions out.

A sensor does not become correct merely because the graph it produces looks convincing.

If a suspension potentiometer is incorrectly calibrated, a wheel-speed circumference is wrong, a brake-pressure sensor has a poor zero offset or two channels are being sampled at inappropriate rates, the logger will faithfully record the wrong answer.

Often to several decimal places.

Which can make it look wonderfully scientific.

This is why sensor calibration, signal quality, sample rate, channel synchronisation and installation quality matter.

If you intend to calculate further information from recorded channels — wheel slip, suspension velocity, pitch rate, throttle rate or other maths channels — the quality of the source data becomes even more important.

Mathematics does not repair poor measurements.

It simply processes them more efficiently.

Why record data at all?

Because human perception is excellent at some things and terrible at others.

A rider might say:

“I feel like I’m losing loads of time on the brakes.”

The data may show they are actually braking later than the faster rider but releasing the brake 40 metres earlier.

Or:

“It keeps spinning on corner exit.”

Wheel-speed data may suggest very little actual slip but reveal an aggressive throttle application that is upsetting the chassis.

Or:

“The forks are bottoming everywhere.”

A correctly installed suspension potentiometer may show that they never reach the end of the available travel.

None of this means the rider is wrong.

It means rider feedback and measurement describe different parts of the same problem.

The rider tells us what the motorcycle feels like.

The data tells us what the motorcycle did.

Good race engineering uses both.

What data acquisition do I actually need?

This is where people frequently make data acquisition far more complicated — and expensive — than it needs to be.

You do not need a MotoGP electronics truck to improve your riding at a Tuesday evening trackday.

The correct system depends on the question you are trying to answer.

Level 1: You might already own a data logger

Basic motorcycle data logging can begin with something as simple as a GPS-equipped action camera.

Compatible GoPro cameras, for example, can record metadata including GPS information, accelerometer data and gyroscope data alongside the video itself. With appropriate software, that information can be synchronised with the footage and turned into a surprisingly useful rider-analysis tool. GoPro GPMF documentation

Now the video does more than show that your elbow was nearly down.

We can start looking at where the motorcycle is on the circuit, how speed changes through the lap and what the rider is physically doing at the same time.

For a trackday rider this can be a very effective starting point for relatively little additional outlay.

Video combined with GPS speed and position is useful for looking at racing line, braking points, corner speed, throttle timing inferred from acceleration, rider movement and consistency.

It is not a full race-bike data acquisition system.

It doesn’t need to be.

If the objective is rider coaching, start with information that helps coach the rider.

Level 2: A proper GPS lap timer

The next step is a dedicated GPS lap timer with an internal accelerometer and gyroscope.

Devices in this category do something extremely useful that a camera normally does not:

They communicate information back to the rider.

Current lap.

Best lap.

Sector performance.

And, particularly importantly:

predicted lap time.

“Am I up on my best lap?”

That is an extremely powerful piece of information.

A rider can experiment with a slightly different line, carry another few kilometres per hour of roll speed, change where they release the brake or alter an acceleration point and receive immediate feedback on whether the change appears to have improved the lap.

This begins to turn the timing system into a test tool rather than merely a stopwatch.

A device such as the AiM Solo 2, for example, combines a 25 Hz GPS/GNSS receiver with a 100 Hz six-axis inertial platform and configurable lap-time display. AiM Solo 2 specifications

At this point we have already got enough information to do meaningful rider coaching.

And we still haven’t connected anything to the motorcycle.

Level 3: Add the ECU

Move to something such as an AiM Solo 2 DL and another layer becomes available.

The DL version can communicate with compatible ECUs through CAN bus, RS232 or K-line, allowing ECU channels to be recorded alongside GPS and inertial data. AiM also supports external analogue expansion on the Solo 2 DL. AiM Solo 2 DL specifications

Depending on the motorcycle and ECU, this can give us channels such as engine speed, throttle position, accelerator position, gear, temperatures, pressures, ignition information and other control-system parameters.

Now instead of seeing only:

the motorcycle slowed here

we may also see:

the rider closed the throttle here, selected this gear, reached this minimum speed and reopened the throttle here.

That extra information creates significantly more confidence in the analysis.

GPS tells us where and how fast.

ECU data starts telling us what the rider and powertrain were doing.

Viewed together in software such as AiM RaceStudio, this is already a powerful rider-coaching package.

For many trackday riders and club racers it may be all they ever need.

That point is worth repeating.

Buy the data acquisition system required to answer your question — not the one with the longest specification sheet.

Rider analysis and motorcycle analysis are not quite the same thing

GPS position, speed, acceleration, throttle position, RPM and gear can tell us an enormous amount about how the rider is operating the motorcycle.

But eventually we reach a different question:

What is the motorcycle itself doing dynamically?

Now we begin wanting measurements such as:

• front suspension position
• rear suspension position
• front brake pressure
• rear brake pressure
• front and rear wheel speed
• steering position
• tyre temperature
• additional pressures and temperatures
• lambda
• ride-height or distance measurements
• and potentially other chassis or control-system channels

This is the point where the job changes.

We are no longer simply looking at where the rider brakes.

We may want to know how quickly the fork compresses during that brake application, how much travel remains, what the rear suspension is doing simultaneously, how the wheel speeds behave, what happens during brake release and how the chassis responds when drive torque is applied.

That requires more sensors.

And more sensors require suitable inputs, suitable sampling rates and enough logging capability to record the information properly.

This is where sampling rate starts to matter

Not every measurement needs to be recorded at the same frequency.

A slowly changing engine temperature channel does not need the same sample rate as a suspension potentiometer being used to calculate damper velocity.

This is where DAQ system architecture becomes important.

As systems grow we start thinking about:

sampling frequency, analogue-to-digital resolution, CAN bus bandwidth, channel count, frequency inputs, logger throughput, sensor excitation, signal filtering and channel synchronisation.

This is also where the slightly vague phrase “the logger isn’t fast enough” needs some engineering discipline.

There is no single magic “logger speed”.

Different limitations can exist in different places.

The CAN network has a communication rate.

The ECU may only transmit a particular channel at a certain frequency.

An analogue input has a maximum sampling frequency.

The logger has processing and storage limitations.

The sensor itself has a physical response and bandwidth.

And the analysis you intend to perform determines how much of that matters.

If you are recording coolant temperature, 1,000 samples per second would be enthusiastic.

If you are trying to differentiate suspension position to calculate shaft velocity, inadequate sample frequency or noisy measurement suddenly becomes considerably more important.

The question is not:

“How fast is my logger?”

The better question is:

“Is the complete measurement chain appropriate for the phenomenon I am trying to analyse?”

The lecturer is back.

Level 4: Dedicated race data acquisition hardware

This is where more capable motorsport loggers start to make sense.

Systems such as AiM EVO-series loggers, MoTeC L120/C125 systems, 2D Stickloggers and Race Technology DL1/DL1 Pro systems provide the ability to build significantly more comprehensive data acquisition installations.

The exact architecture varies between manufacturers.

For example, an AiM EVO6 provides dedicated analogue channels, speed inputs, ECU communications, a second CAN network and an internal inertial platform. AiM EVO6 specifications

MoTeC’s L120 supports multiple CAN and serial communications with expandable I/O, while a C125 can operate as a display and, with the appropriate logging options, a configurable data logger and analysis platform. MoTeC L120 specifications MoTeC C125 specifications

2D’s Sticklogger family provides CAN logging alongside analogue and frequency inputs, with higher-specification variants supporting high-rate acquisition and online calculation channels. 2D Sticklogger specifications

Race Technology’s DL1 Pro architecture similarly provides multiple analogue and frequency inputs alongside CAN capability. Race Technology DL1 Pro specifications

These systems allow the data installation to develop into something capable of measuring the motorcycle dynamically rather than simply recording lap timing and rider inputs.

And this is where channels such as suspension potentiometers, brake-pressure sensors and independent wheel speeds become especially valuable.

Not because more traces automatically make somebody a better race engineer.

They don’t.

But because the right measurements allow specific engineering questions to be tested.

What can you actually learn from motorcycle data?

Quite a lot.

At the simplest level, GPS data can show lap time, sector time, racing line, vehicle speed, braking zones, acceleration zones and minimum corner speed.

Add ECU information and we can begin analysing throttle application, engine speed, gear selection, engine-braking behaviour, shift strategy and relevant electronic-control activity.

Add wheel speeds and brake pressure and the picture becomes clearer again.

Add suspension potentiometers and now we can examine the behaviour of the chassis itself.

Suddenly we can investigate questions such as:

• Is the rider losing time because of technique or motorcycle setup?
• Is the motorcycle struggling on entry, mid-corner or exit?
• Is a suspension change actually producing the response we expected?
• Is the rider braking later but giving the time back during brake release?
• Is wheelspin limiting acceleration, or is the rider simply not requesting full throttle?
• Is the motorcycle using the available suspension travel?
• How quickly is the suspension moving?
• Is a geometry change improving one phase of the corner while compromising another?
• Has an electronics or engine-calibration change actually improved acceleration?

The more appropriate information we record, the better our opportunity to separate opinion from evidence.

Notice the word appropriate.

More channels do not automatically mean more understanding.

Twenty useful channels are considerably more valuable than two hundred channels nobody looks at.

Data does not tell you what to change

This is important.

A graph does not contain a small arrow saying:

ADD TWO CLICKS OF COMPRESSION.

Data shows behaviour.

Engineering determines the mechanism behind that behaviour.

Suppose rear-suspension position shows the motorcycle compressing significantly during acceleration.

That does not automatically mean:

fit a stiffer spring.

The behaviour could involve spring rate, preload, damping, anti-squat geometry, ride height, gearing, throttle application, track gradient, tyre behaviour — or some combination of them.

The measurement tells us what happened.

Engineering analysis attempts to determine why it happened.

That distinction is the difference between using data as evidence and simply staring at coloured lines until inspiration occurs.

Where Antrieb Race Systems fits

A useful motorcycle data acquisition system begins before the first lap is recorded.

The first questions should be:

• What are we trying to understand?
• What information do we need to measure it?
• What hardware is appropriate?
• How should it be installed and configured?
• What sample rates and channels do we actually require?
• And once we have the data, what engineering decision are we trying to make from it?

Antrieb Race Systems can support that complete process — from data acquisition hardware selection, supply, sensor installation and logger configuration through to motorcycle data analysis, rider coaching and trackside race engineering.

For a trackday rider that might mean getting useful information from a GPS lap timer and learning how to analyse it.

For a club racer it might mean integrating ECU CAN data, improving the logging installation and adding brake pressure or suspension measurement.

For a race team it may mean a more complete acquisition system used to investigate rider performance, chassis behaviour, engine and electronics calibration and motorcycle setup throughout a race weekend.

The scale changes.

The principle does not.

Measure the right thing.

Measure it properly.

Understand what it means.

Then make the decision.

Because the objective is not to collect more data.

The objective is to make better decisions.

The useful definition

If you remember nothing else:

And calling every squiggly line on a laptop “telemetry” will continue to annoy engineers for the foreseeable future.