Welcome back to Basics of Biomechanics, a series of blog posts covering foundational topics in the field using practical, data-driven examples. In this post we cover a fundamental aspect of biomechanical analysis: working with time-series data or signals.
Signals are the bread and butter of biomechanical analysis. Since these are the streams of information that are used to visually review our experiments and generate biomechanical outcomes, it is important to fully understand them. One basic categorization of signals is that some are measured while other signals are calculated. To explore this briefly, let us return to the jump analysis example from the previous blog post on analyzing time and assume that we have already completed the event detection and phase segmentation. If you have not yet read this post, please consider doing so before continuing.
The vertical ground reaction force curve shown above is a measurement signal originating from the force-instrumented treadmill shown in the video. For a typical jump analysis, several additional signals are generated from the measured force signal to extract biomechanical parameters related to jump performance (details will be given in future posts). For example, the calculated signals might include estimations of lower-limb power and centre of mass velocity and position as shown below (note that while most signals are calculated for the whole timeline, these jump related signals are only calculated from jump initiation to landing).

For effective interpretation, it is important to know where each of your signals comes from i.e. the sensor system that recorded them, or the mathematical equations that produced them. This knowledge enables you to have an appropriate level of confidence in your data. For example, measured signals potentially contain a number of types of sensor noise and uncertainty related to the underlying sensor technology that need to be kept in mind, e.g. our force signal might be contain drift error over time. Similarly, calculated signals might rely on certain modelling assumptions e.g. perhaps our equations assume that the jump is executed in a perfectly vertical direction. Some signals are inherently more reliable and accurate than others, and knowing the underlying reasons for this makes it easier to diagnose and solve any issues as well as to select the best signals for your analysis.
Challenge #1: can you think of a few more possible sources of error to consider for the force signal? What about the calculated signals? Should this influence how many decimal places we analyse and report for outcomes?
Beyond knowing the source and general uncertainty levels of your signals, it is necessary to familiarise yourself with their other characteristics.
Signal characteristics
A line plot of any data signal immediately shows us how the signal value evolves over time. However, the shape of the signal curve is not very useful without further information. Firstly, we need to know more about the vertical axis characteristics. What type of information is it (an angle, a force, a distance) and what are its units? Is it a scalar quantity (e.g. speed) or a vector with a particular direction (e.g. an angular rotation about a specific axis, or a force or distance along a certain dimension)? Is this a one-dimensional quantity or part of a multi-dimensional quantity (e.g. 2D pressure distribution or 3D linear acceleration)?

For signals that have a direction, it is also very important to understand the signal polarity and zero-level. This is particularly relevant for musculoskeletal modelling data where these attributes may differ between technologies based on convention. For example, when analyzing knee joint sagittal plane angles it is important to know whether an increase in the signal value implies an increase in knee flexion or knee extension. It is also crucial to know what joint position is referred to by the zero value.
Challenge #2: Can you figure out the type, polarity and zero-level of all the jump analysis signals above?
The second set of information we need to know for each signal relates to the horizontal axis properties. Any measurement signal is sampled by the sensor system at its native frequency – this is the number of samples measured per second, reported in Hz. Another way to think of it is that each measurement device measures its own time signal (this signal is often available in the recording file). The zero value in this signal usually represents the start of the recording. Typically in simple experiments involving only a single data source, all measured and calculated signals remain at the native frequency because there is only one timeline. However, any signal’s frequency can also be artificially increased (this is called up-sampling) or decreased (down-sampled) afterwards using resampling (decimation or interpolation) techniques within a biomechanical processing pipeline. This is also done when signals are segmented into time-normalised curves (the timeline becomes 0-100% of a movement phase). This topic will be covered in later posts.

In multi-device setups, signals may have different native frequencies. This is inconvenient when wanting to perform calculations involving multiple signals that contain different numbers of sample values for a given period e.g. inverse dynamics modelling using an optical motion capture system and a force plate. In this case, signals are typically resampled to a common frequency. The downside of resampling is that is does (often only very slightly) change the shape and values of the original data. For example, if we extract the peak landing force in our jump analysis from the native frequency signal and the common frequency signal, it would not produce exactly the same value.
Challenge #3: how might the accuracy of our countermovement jump results be affected if we performed our event detection and segmentation using the reference video, and then later realised it was captured at 30 frames per second and our force signal data had a frequency of a 1000Hz? Clue: how would you determine if the video frequency is fast enough?
Another challenge in multi-device biomechanics is that the native timelines of signals may be desynchronised. Even signals recorded in the same acquisition software with a single “start button click” may start recording at slightly different times (sometimes more than 250ms apart) due to issues such as USB delays. Therefore, beyond resampling signals to a common frequency, it is necessary to align a shared synchronization event rather than their zero-points (shift the signal curve left or right on the timeline) so that they are time synchronised. This is illustrated below for two signals that are initially desynchronised as illustrated by the vertical red line that represents a specific moment in time. The common timeline zero-point typically approximates when the last device begins recording.

Challenge #4: how might our interpretation of our countermovement jump results be affected if we performed our event detection and segmentation using the reference video, and then later realised it was desynchronised by 100ms from our force signal?
Conclusion
Time-series data signals are the the cornerstone of biomechanical analysis. All users of biomechanical data would benefit from a deep knowledge of the signals they are using in their work. Not only is it important to know how the signals are produced, but it is also critical to understand how they are processed together when combining multiple devices.
How familiar are you with the signals that you are using in your biomechanics work?
Please leave a comment if you have a contribution or question!
Brilliant! Thank you.
Very nice idea to present basic biomechanics and science in this manner. I like it. Surprising that this idea stated above, “One basic categorization of signals is that some are measured while other signals are calculated,” needs a little reinforcement now and then. I hear once in a while something like, “We measured joint torque…” which is incorrect. Of course anyone can make this error now and then but info-presentations like this will hopefully reduce its frequency. Thanks, SASB.