No announcement yet.

C3D File format, force plates and analogue data

  • Filter
  • Time
  • Show
Clear All
new posts

  • C3D File format, force plates and analogue data

    I have been writing an application to view and analyse c3d files. A couple of questions have resulted:

    1) The type 2 force plate (Fx, Fy, Fz, Mx, My, Mz) can be used to present processed plate data (units N, N, N, Nm, Nm, Nm). The question: Is there a standard format in which the processed data should be presented in a C3D file? For example, Vicon Nexus can export force plate data as a text file where plate forces (not reaction forces) are presented in the 3D global axes system. The CoP is relative to the global axis and origin. The plate moments are also calculated relative to the global axes but located at the centre of the plate surface. The centre of the pate in the global axes, if required, is readily obtained from the plate corners. The C3D file however presents reaction force and reaction moments (not plate forces) in the local plate axes system. The location of the local plate axes relative to the plate centre has been placed in the plate ‘origin’ variables replacing the plate calibration data (A, B, Xo), I don’t think it should be placed here. Importantly thought, if there is not a standard format, then there is no way to determine what the processed plate data contains without knowing the specific peculiarities of the software that wrote the C3D file.
    2) Identifying EMG, loadcell, timing/trigger or other analogue channels? The Group ‘forceplate’ has members ‘used’ and ‘channels’ to readily identify and locate the plate channels amungst the analogue data. Are there similar groups such as ‘EMG’, ‘loadcell’ or ‘trigger’ with members ‘use’ and ‘channels’ to identify how many and where these respective channels are. Otherwise we are only guessing based on the name or the nature of the data.

    Thank you
    Allan Carman

  • #2
    The C3D file is designed to record data collected in the 3D environment - essentially this is 3D locations stored as XYZ coordinates together with some information about the measurement accuracy, and synchronized analog data samples. All 3D locations are referenced to a common origin - both 3D marker locations and the force plates. The force plate locations and orientations are defined by the FORCE_PLATFORM group parameters recording the individual platform corner locations as 3D locations referenced to the same origin.

    When the C3D format was created the standard method for recording force platform data was to sample the raw analog signals from the force plate amplifiers with an ADC, creating analog samples in synchronization with the video data - essentially recording the voltages generated by the force plate amplifier interface. The C3D file stores the force plate amplifier settings, the ADC configuration details and the force plate calibration details in the ANALOG:SCALE parameters (described on the C3D web site) allowing applications to process the recorded raw data values. By storing the raw data values, together with the signal scaling, users have the ability to determine the accuracy of the recorded information and if errors are detected when the data is processed then the scaling values can be updated and the problems fixed. The C3D file is essentially recording the data generated by the force plate together with scaling factors generated from the force platform manufacturers calibration records supplied with each force plate.

    The standard format for storing analogue data in a C3D file is that the data is stored as samples fully described by the ANALOG and FORCE_PLATFORM parameters. Normally we see processed force plate data stored as Fx, Fy, Fz, Mx, My, and Mz values with the associated analog scales set to 1 and the data stored as N and Nmm values but nothing describing the original data collection, it’s just processed data so the force and moment calculations have been performed without any record. Third party applications can export the stored processed values to ASCII text files but when the data stored in the C3D file was created by an undocumented calculation prior to the file creation there’s no record of the processing.

    In the days when raw data values were always recorded, I worked with a clinical lab that had discovered that their force plate data calibration data had been entered incorrectly after a force plate upgrade. But because the raw analog samples had been recorded for four months I was able to correct everything by just editing the C3D files to restore the correct analog scales values. Had they just stored processed data then the problem would have been very difficult to fix.

    The C3D file stores analog data values and includes support for ANALOG parameters that describe the data - you can create parameters that document EMG, loadcells, timing/trigger, goniometers, foot-switch and other analogue channels. So you can store data for example with the label “EMG03" and the description “Left Tibialis Anterior” - the environment basically expects users to look at the file, recognize the contents, and then chose what to do with the data. The data might be raw EMG data, or it might be envelope EMG data - the idea is that the data collection environment does the best job possible and the user has every choice to process the data - so if you are writing an application to process and display the data then show the user the data and let them chose what to do, “That’s an EMG channel, let’s determine muscle activity (on/off) and graph it relative to the ankle power” for example.

    The basic concept for C3D files is to record the data accurately (both numerically and accurately described) and give users all the processing options they want while allowing them to share their results with other users, allowing anyone to open the C3D file and make sense of the data - that’s my view based on conversations with Andy Danis and Steven Stanhope long ago.
    Last edited by Edmund Cramp; April 27th, 2021, 04:54 PM.


    • #3
      Thank you for the detailed reply. I would agree that the goal is to:

      “….give users all the processing options they want while allowing them to share their results with other users, allowing anyone to open the C3D file and make sense of the data.”

      If the force pate data is stored as raw voltages then there are clear advantages, as Edmond mentions, and would also be my preferred option for storing data. With all the information present in the C3D file to process the data and obtain the force, moment and CoP data you require.

      In presenting processed data, however, not all the information is present in the c3D file to interpret what has been presented. Applied forces vs reactive forces, plate axes vs global axes, CoP or moments relative to the plate surface center or a plate corner or the global axes origin. The only way I was able to decipher the processed force plate data in the C3D file was comparing results to the exported text file of the same data and knowing the force plate layout. Without any guidelines as to how processed data should be presented then the force plate data is not readily understandable or usable to anyone opening the data. When presenting processed force plate data my preference would be to firstly only present applied plate forces and moments and not reactive forces and moments and secondly to express plate moments relative an axes (local or global) located at the center of the plate surface. This would be sufficient for someone or software to determine the axes used and be able to present force, moment and CoP in which ever form or axes as required.

      At present there is no way to present the number or names of the EMG channels present in a C3D file ( or other types of analogue data). Using names is problematic with EMG channels seldom labelled EMG01, EMG02 but rather by their muscle location (Soleus, BicepFem). I would like to do more than let the user sort it out.



      • #4
        "At present there is no way to present the number or names of the EMG channels present in a C3D file ( or other types of analogue data). Using names is problematic with EMG channels seldom labelled EMG01, EMG02 but rather by their muscle location (Soleus, BicepFem). I would like to do more than let the user sort it out."

        The aim of the C3D format is just to store the original sampled data (3D locations as XYZ values and analogue data samples) together with parameters that describe the data. The ANALOG parameters LABEL, DESCRIPTIONS, SCALE, OFFSET, UNITS can describe the data and you can add more parameters if there’s something else you want to document.

        The LABEL is intended to be machine readable (e.g. EMG01) and the associated DESCRIPTION is human readable (e.g bicep femoris or bíceps femoral in Spanish etc.) – so if you are creating a processing environment you can reference the LABEL and display the DESCRIPTION to the users in the application creating the file that records the information. Unfortunately a lot of applications are not well written and store the same string in both the LABEL and the DESCRIPTION parameters. This is a result of modern applications written to create and process C3D data by programmers without any biomechanics lab experience. The C3D format evolved in the NIH biomechanics lab, written by FORTRAN programmers, under the direction of a professor of Kinesiology and Applied Physiology, working in the fields of biomechanics, human anatomy, and exercise physiology to collect and process biomechanics gait movement information for NIH clinicians and researchers working with many labs. So basically the C3D format can do the job, but programmers without any lab experience often fail to record all the information that users need.