Analysis

Theory says that an individual magnetic sensor pointing in direction $\hat n = ( n_x, n_y, n_z )$ and observing a magnetic source of strength $m$ oriented in the direction $(m_x, m_y, m_z )$ at a distance $r = (r_x,r_y,r_z)$ will observe a magnetic field $B$

$$B = { \mu_0 \over 4 \pi \vert r\vert^5 } \left( 3 (m \cdot r ) ( r \cdot n ) - (r \cdot r ) ( m \cdot n ) \right)$$ (1)

An array of $S$ sensors, numbered $s = 0 \ldots S-1$, usually has all the directions $n_s$ known and fixed. The sensors are not all in the same location, so their distances $r_s$ to the magnetic source will not be equal. These distances are the difference $r_s=p-o_s$ of the sensor positions relative to the center of the array $o_s$ and the magnetic source position relative to that center $p$. Thus,

$$m \cdot r = (p_x-o_x)m_x + (p_y-o_y)m_y + (p_z-o_z)m_z$$ (2)

We can write equation 1 for each of the magnetic sensors. We have $S$ equations that relate $S$ known values of $B_s$ with $6S$ known constants $n_s, o_s$ and $6$ unknown values $p=(p_x,p_y,p_z)$ and $m=(m_x,m_y,m_z)$. Providing we have $s \geq 6$, a solution is possible. The computation is not merely non-linear due to the dot-products such as equation 2, but especially due to the term $\vert r\vert^5$ which expands to

$${ 1 \over \vert r\vert^5 } = \left( r \cdot r \right) ^ {-2.5}$$ (3)

This can be solved using an iterative descent by brute force, but this has an unpredictable execution time and is thus inappropriate for a system seeking a predictable performance.

A popular method involves separating both $p$ and $m$ into their unit vectors $\hat p,\hat m$ and magnitudes $\vert p\vert,\vert m\vert$ and rewriting the equations. Assuming we place our sensors in an array pattern that makes tracking possible, we can compute an intermediate result called the magnetic field tensor gradient. This result is nine linear combinations of the $B_s$ values (the actual combinations are dependent on the array pattern) which can be used to deduce $\hat p$ and $\hat m$ using some nasty calculations[2]. Although nasty, the execution time can be predicted and so this calculation is preferred for a real time system. Once those values are known, a separate computation step uses all the original $B_s$ to compute the $m$ and $p$.

This entire calculation sequence was prototyped in MATLAB to analyze recorded data files, working from Tucson AZ. The data was usually acquired by personnel in San Diego CA, since someone needed to move the desired target object past the sensor array in a predictable path. For certain kinds of testing, the object could be hung over the array as a pendulum. This could be left swinging for remote algorithm developers to collect additional data whenever they needed it.

Once the algorithm was demonstrably tracking objects, it was translated directly into C and installed on a Linux computer. After verifying that it generated the same tracking results as the MATLAB version, lab staff could stream data from any of the hardware systems to the algorithm development computer over the network (and/or VPN). The track results were delivered to a nearby computer with a 3D graphics and perspective capable display for inspection.

Now that the algorithm is stabilized and reliable, it may be installed locally on all computers that are easily fast enough to perform the floating point math. In general, therefore, Pentium-class and above have the tracking algorithm, while 386 and 486 do not.