P10010: Motion Tracking Sensor
/public/

Data & Communication

Table of Contents

Step 1. Clarify The Problem

According to the customers, the device should obtain and measure the angles formed by a person's lower back and limbs. For example, bending an arm at the elbow -- the device should measure the angle between the forearm and upper arm, where the vertex is at the elbow. All of this data, ideally, will be stored in a binary format called C3D.

The data from the sensors must be sampled at a frequency that is high enough to register quick motions, but not so fast that there is a lot of unnecessary data. The device that Dr. Sarah G. currently has, samples at a frequency of 200 Hz. Dr. G. has mentioned that our design does not need to sample nearly that fast. The benefit of sampling at a slower rate is the acquisition of fewer data points and thus the storage requirements are reduced.

After the data is sampled, it needs to be processed and stored in the C3D file format and transmitted to a PC. The MCU/PC interface may be wireless (bluetooth?) or wired (USB?).

Step 2. Search Externally

Data Storage Format

C3D - The 3D Biomechanics Data Standard

C3D User Guide

Visual3D Software from C-Motion

Data Transfer to PC: USB vs. Bluetooth

Bluetooth 2.1 + EDR has a theoretical max speed of 3 Mbit/s citation req'd, or 375 KByte/s. Even if the theoretical max speed was maintained, it would take at least 45 minutes to transfer 1 GB. calculations to be added USB 2.0 has a theoretical max speed of 400 Mbit/s, or about 47 MByte/s. Obviously, those speeds are never obtained; something like 5 MB/s is more reasonable. Assuming 5 MB/s, it would take about 3-4 minutes to transfer 1 GB of data. calculations to be added

In terms of interfacing to a microcontroller, a USB interface, while not trivial, is not overly complicated. It is essentially serial data with timing constraints, which are taken care of by the USB controller chip. Also, USB is very cheap in comparison to Bluetooth. perhaps research bluetooth interface

Step 3. Search Internally

Preliminary code concepts/ideas:

The data acquisition code that will be running on the microcontroller should be able to sample each sensor at some rate (sampling rate) and store the data in some sort of buffer in memory. After a number of data samples have been acquired, another module must simultaneously analyze the data using geometry to calculate the desired angles between the sensors in question. In order to do this, distances between related sensors must be known. This may become an issue because people come in various shapes and sizes. Assuming this barrier is overcome, the next step is storing the angle data into a useable format. The customers desire the C3D format, so that needs to be looked into.

Example Calculations for Storage Requirements

Assume the following:

Storage requirement = (6 sensors) * (3 signals) * (10 bits/signal) * (60 Hz) * 24 hours = 933 Mbits = 120 MBytes

Changing to a 16-bit ADC increases the storage requirements to 190 MB.

Using 12 sensors with 16-bit ADCs increases the storage requirements to 375 MB.

Increase to 24 sensors with 16-bit ADCs -- 750 MB.

Results: A 1-GB memory card should be sufficient. Chances are, the sensors will be sampled slower than 60 Hz. Also, 24 sensors may not be necessary. Most importantly, however, the customer expects the data to be accumulated over a 12-hour period. Certainly, it is best to exceed the customer's expectations, but for the purpose of gathering ball-park figures, it appears as though we do not need to store gigabytes upon gigabytes of data. A standard 1-GB, 2-GB, or 4-GB SD card will suffice. It also gives us an idea of pricing.

Step 4. Explore Systematically

Step 5. Reflect on the Results and the Process

Generate Product Concepts

Home