Camera Tracking of Aircraft Control Positions

The standard method of tracking the aircraft’s control positions as the pilot moves the controls for flight test instrumentation (FTI) purposes is to attach string potentiometers (string pots) to the control cables/rods. As the control cable/rod moves based on the pilot’s inputs a spring loaded thin steel wire is reeled in or out of the string pot. The mechanical movement of the reel changes the electrical resistance resulting in a change in voltage output which is then measured and recorded by the FTI system.

In some cases though it would be ideal if you could track the aircraft control positions without having to physically attach a wire to the control cable/rod. So I developed a system to track the control positions using a web camera to track a target consisting of a piece of thin black card with two white circles.

In the following example in a Beechcraft King Air we’ve mounted the web camera on the instrument panel looking back at the yoke. The software detects the two white circles and tracks their position within the camera’s field of view.

To track the rotation angle of the yoke, i.e. to track the aileron deflection we can work out the angle between the centers of the two white circles. To track the elevator deflection we track the movement of the yoke in and out of the instrument panel by tracking the change in diameter of the circles, or the distance between the two circles. As the yoke is pushed forward the circles appear larger and vice-versa as the yoke is pulled back.

In this particular calibration screenshot the aileron deflection is displayed as 47.81%, i.e. there is a slight rotation, 50% would indicate no rotation of the yoke. The elevator position is listed as 82.65% where 50% would indicate the yoke is centered in terms of fore and aft movement and 100% would indicate the yoke has been pulled back fully.

This is the USB web camera that we used. You can get a feel for it’s physical size by comparing it to the size of the USB plug. What was very useful was the replaceable lens which meant we could use different lenses based on their field of view depending on the particular aircraft type in terms of the physical spacing between the camera and the target.

One of the initial issues we ran into was the jello effect in the video stream from a combination of the vibration that the camera experiences and it’s use of a rolling shutter. So we mounted the cameras in a housing we made up in which we included anti vibration foam, the black foam material you can see in the photo below.

For aircraft that don’t have a yoke but have a joystick instead we mount the cardboard target on a control cable/rod and then mount a camera to track the linear movement of the target as the control cable/rod moves. We typically have to also do this for the rudder in aircraft with a yoke as well.

The following photo shows the cardboard tracking targets mounted in an Extra-300 aircraft, with one on a control rod for the elevator and one on the rudder control cable. You can just make out the camera mounted to track the rudder control cable movement in the top right of the photo.

The software to perform the circle detection from the 1080p USB web camera ran on an ODROID single board computer. It would process each frame to detect the location of the circles and then using the calibration data for the particular target it would then output the control position data to the FTI system where it would be recorded and displayed in real-time.

The ODROID in it’s enclosure mounted in the Extra-300.

The biggest issue we faced with the camera tracking system was due to lighting conditions. In particular for the installations mounted in the cockpit tracking a yoke we ran into issues where the camera’s automatic gain control couldn’t deal with large and quickly changing lighting conditions based on the sun shining into the cockpit as the aircraft maneuvered.

In the example screenshot below the system can still detect and track the two white circles. However as the sun moves further down the white circles will disappear. In most of these sorts of installations we built a small cardboard shroud to prevent direct sunlight hitting the target area. However the ideal would be to use a camera with a high or at least very wide dynamic range.

For installations where the target was mounted on a control cable/rod and away from direct sunlight we never ran into issues with losing the target for brief moments. In general in these installations we installed some LED lighting to give us a fairly constant lighting condition. In the photo above of the camera mounted with anti vibration foam you can see a short strip of 3 LEDs to provide lighting from the camera aimed at the target.

For an example of the data collected using this system take a look at the Extra-300 Spin article.

So far we’ve installed and used this system in the following aircraft – Cessna 172, Extra-300, Learjet, King Air, and AirTractor.

Extra-300 Spin

This is an example of the data collected by my Homebrew FTI (Flight Test Instrumentation) system during a spin in an Extra-300.

The control positions were tracked using a camera based tracking system that I developed and the output from the camera tracking units were fed into the FTI unit.

Here are a couple of graphs showing the FTI captured during the spin.

This first graph shows the control positions for the rudder and elevator and the roll angle during the spin. The spin is entered with full back stick and full right rudder. To stop the spin full opposite rudder is applied briefly and then then the rudder and stick are returned to neutral.

The second graph displays the indicated airspeed (IAS) as Vi and the ground speed from the GPS as GS in addition to the pitch and roll angles.

The third graph shows the angular rates for all three axes.

And lastly a graph showing the accelerations experienced in all three axes in m/s^2.

We also had a GoPro camera mounted in the cockpit which we synchronized with the FTI data.

The FTI data and synchronized video in my FTI Playback software.

 

Homebrew FTI (Flight Test Instrumentation)

I first got involved in designing FTI equipment in 2008 when TFASA (Test Flying Academy of South Africa) asked me to design some FTI equipment to be used in a Hawker Hunter jet that they were using for a course they were running. I did a write-up on this work in – Geeks and Fast Jets.

Subsequent to that work I developed a couple of follow up FTI units that TFASA have used over the years on various types of aircraft when running test pilot training courses.

The first FTI unit in the Hawker Hunter used a ruggedized PC as the FTI unit to collect data and log it from various sensors and to provide a real display in the cockpit.

For the follow-up unit which needed to be installed on much smaller aircraft where space, weight and power requirements were smaller I switched to a simple SBC (Single Board Computer) called the Fez Rhino. The Fez Rhino ran a small embedded version of the .Net (Common Language Runtime – CLR) runtime.

Sensors were connected via a combination of serial inputs and analog inputs. For a later iteration I switched to the Fez Hydra which was similar in terms of running an embedded version of .Net just with a slightly more powerful CPU and a different physical connector setup.

Here is a photo of one of the Fez Hydra based FTI units with a test harness to test the 16 analog inputs, 6 digital inputs and 3 serial ports.

The one serial port was always connected to a Rockwell-Collins ADAHRS unit as shown below. The unit provided air data in terms of airspeed and pressure altitude plus attitude and heading (AHRS) information from a set of 3-axis gyros, accelerometers and magnetometers and in addition GPS information.

Data was logged to an SD card for downloading after the flight and in-flight one of the serial ports could be connected to a Windows CE device called the Oudie to display real-time data and graphs to the test pilot instructor and student.

For the third and current iteration of the FTI package we wanted a more portable system that didn’t need as much wiring to the ADAHRS+GPS sensor and not having to get power from the aircraft. This enables us to quickly install and remove the system from different aircraft.

Instead of using an off-the-shelf SBC like the Fez Hydra I contracted the design of a custom SBC from John Baxter who I knew via mutual work colleagues. He designed a custom PCB with an Amtel micro-CPU plus a battery charging circuit and a WiFi module.

The unit includes the Rockwell-Collins ADAHRS+GPS unit mounted inside our case on top of a lead plate plus rechargeable batteries and the custom SBC.

The portable FTI unit mounted in a Cessna C-172.

The updated in-cockpit application now running on an Android based tablet receives the data via the WiFi connection to display the real-time data including graphs and to record the data for processing and playback after landing on a PC.

Some screenshots of the FTI app running on a tablet.

 

Landing – Ground effect, flare – JSBSim

Taking a look at the ground effect and the flare on landing performance using JSBSim to see it’s effect on the final sink rate and the change in airspeed.

For this test I’m using the Boeing 737 model included with JSBSim. The aircraft is setup and trimmed at 150ft AGL with a speed of 140kt IAS and on a 3 degree flight path with the flaps and gear down.

This is the Cl versus AoA for the B-737 model.

The coefficient of induced drag versus AoA. It increases as the square of the AoA.

The ground effect kicks in when the aircraft is roughly within 1 wingspan above the ground. For the B-737 this means the ground effect starts at just under 100ft AGL since it has a wingspan of 93ft.

There are two main changes in aircraft performance when in ground effect, namely the coefficient of lift (Cl) increases for a given angle of attack and the induced drag coefficient decreases for a given angle of attack. Both effects increase the closer the aircraft gets to the ground, expressed as the ratio b/h (wingspan / AGL).

The following graph shows the increase in Cl versus b/h as a factor increase over the normal Cl versus AoA used for this B-737 model.

So at an AGL of 50ft there is a roughly 2% increase in the coefficient of lift which rises to roughly 6% at 25ft AGL.

The following graph shows the decrease in the induced drag coefficient Cdi versus b/h.

At an AGL of 50ft there is roughly a 7% decrease in induced drag and when we get down to 25ft AGL there is roughly a 24% decrease.

So left unchecked during the landing the ground effect will result in a slight ‘float’ down the runway in terms of the extra lift being generated and with lower induced drag and the increased lift will lower the sink rate.

Three landing tests were performed, all with the same starting conditions, i.e. trimmed at 140kt IAS at 150ft AGL with a flight path angle of 3 degrees resulting in a descent rate of 12.5ft/s or 750fpm.

In the 1st landing test the ground effects were removed from the aircraft model and no control inputs to the elevator or throttles were made, i.e. the aircraft continued descending at 140kts and at 750fpm until it hit the runway very hard.

In the 2nd landing test the ground effects were enabled but again no control inputs were made. In other words no pilot inputs after the control positions were set during the initial trim, but the aircraft was influenced by the ground effect as it descended below 100ft AGL.

In the 3rd landing test the ground effect model was enabled and the throttles were retarded at 50ft AGL and then the aircraft was rotated slowly in pitch in order to flare the aircraft.

First the background: Airbus gives 3 landing distance tables, “manual/manual”, “manual/autobrake” (FCOM 2.03) and “autoland/autobrake”.

“Manual/manual” is the minimum landing distance based on certification flight tests. You arrive over the “screen” (50ft) with Vref (Vls), retard the thrust and rotate the aircraft along a constant flight path resulting in a touchdown speed of Vls minus 7-8 kts and a relatively high pitch attitude. Derotation is positive and max brakes are applied without reverse.

The following graph shows the flight path for the 3 landings.

And a zoomed in view from 50ft AGL onwards.

The landing with no ground effect and no pilot inputs followed the 3 degree flight path onto the runway, landing 850m on from the 150ft AGL start. The landing with the ground effect enabled but with no pilot inputs ballooned above the initial 3 degree flight path and landed 992m from the start. The 3rd landing with pilot inputs to retard the engines to idle thrust and to initiate a flare landed 988m from the start.

The following graph shows the throttle and elevator inputs that were applied plus the resulting pitch rate.

You can see a nose pitch down rate as the engines are retarded to idle thrust just before the elevator input is applied.

As expected for the no ground effect and no pilot input landing the pitch, alpha (AoA) and gamma (flight path angle) all remain constant from their initial trim angles all the way onto the ground.

For the ground effect landing with no pilot inputs the pitch attitude remains pretty constant around 2.4 degrees nose up, but as the ground effect comes into play the AoA and flight path angle decrease together as a result of the increased lift.

And lastly for the landing with pilot inputs. The flare maneuver is obvious with the increasing alpha from the trim value around 5.2 degrees to a peak of around 6.2 degrees which then decays back down to roughly 5 degrees on touch down. The pitch attitude increases from 2.25 degrees to 4.75 degrees and then is held at this angle for approximately 1.5 seconds until touch down.

The flare also decreases the flight path angle from the initial 3 degrees to about 0.3 degrees on landing.

In terms of the airspeed in the no ground effect with no pilot input case the IAS remained pretty constant around the initial trim value of 139.5kt. In the case of the landing with ground effect and no pilot inputs the IAS increased by roughly 1kt in the last 4.5 seconds.

The combination of retarding the thrust to idle and increasing alpha during the flare means we bled off approximately 7.5kts from the initial approach speed.

And lastly in terms of the descent rate during the approach and the final sink rate as the aircraft lands. In the landing with ground effect and no pilot inputs the ground effect decreases the final sink rate from 750fpm down to 175fpm.

In the landing with pilot inputs to decrease the thrust and to flare the aircraft the final sink rate is reduced to only 75fpm, quite a greaser!

One effect that hasn’t been modeled is the change in pitch moment due to ground effect. When coming into ground effect the downwash angle from the wing over the tailplane is reduced which in turn reduces the amount of lift from the tailplane resulting in a nose down pitching moment.

Here is an example of some wind tunnel data and flight test data for the Comet airliner with a wingspan of 107ft and the change in pitching moment when in ground effect.

If this change in pitching moment had been modelled then for the test flight with ground effect but no pilot input we would’ve seen the pitch attitude decreasing as the aircraft came into ground effect instead of the constant pitch attitude. This would also have changed the AoA experienced etc. For the test flight with pilot input we would need to apply a greater elevator deflection during the flare to counteract the nose down pitching moment if we wanted to achieve the same pitch attitude and AoA.

 

 

Pitch Rate Damping – JSBSim Test

When an aircraft pitches up or down the tailplane rotates around the cg of the aircraft and this motion causes a change in the tailplane’s angle of attack, which generates a change in lift at the tailplane. This change in lift at the tailplane in conjunction with the tailplane’s arm from the cg generates an opposing, or damping, pitching moment.

The pitch rate damping moment is proportional to the length of the tail arm and the change in lift. The change in lift is proportional to the change in the angle of attack which is proportional to the pitch rate and inversely proportional to the true airspeed.

The moment due to pitch rate is:

Unlike some of the other longitudinal moments, like the moment due to alpha which relates to static stability, the pitch rate moment in addition to being proportional to the dynamic pressure is also inversely proportional to the TAS.

As the TAS increases the change in the tailplane’s angle of attack for the same pitch rate is smaller.

This means that flying at the same IAS (same dynamic pressure) at different altitudes results in a different pitch rate damping, i.e. for the same IAS at a higher altitude the pilot will experience less pitch rate damping.

I’m going to test this out in JSBSim with the Boeing 737 model. Here is the relevant snippet from the 737’s aerodynamics section for specifying the aerodynamic moments. In this case Cm-q has a value of -27.

The aircraft is trimmed at an IAS of 250kt at 3,000ft and then an elevator step input is applied. The same test is then performed at 30,000ft.

Altitude    IAS      TAS      Mq (lb.ft per 1 degree/s pitch rate)
3,000ft     250kt    261kt    -20,016
30,000ft    250kt    393kt    -12,369

So the pitch rate damping moment at 30,000ft is approximately 62% of the pitch rate damping motion at 3,000ft.

Now for some graphs comparing the response of the aircraft to the same elevator step input at 3,000ft and at 30,000ft.

With lower pitch rate damping moment the aircraft’s pitch rate increases more rapidly at 30,000ft and achieves a higher maximum pitch rate.

The pitch angle also increases more rapidly at 30,000ft.

The lower pitch rate damping at 30,000ft also means that the angle of attack increases at a faster rate at 30,000ft compared to at 3,000ft.

The higher alpha will result in a greater Cm-alpha restoring moment diminishing the lower pitch rate damping moment to some degree.

An illustration of the various pitching moments for the aircraft at 30,000ft.

The reason the net moment isn’t exactly 0 while the aircraft is in trim up until the elevator step input at time 1.0 is because the aerodynamic reference point (AeroRP) for the aerodynamic forces and moments isn’t coincident with the cg, in addition to other pitching moments from the engines for example.

Max Q – Maximum Dynamic Pressure

During a rocket launch the commentator will often call out “Max Q” at a specific point in time during the launch. This is the point at which the dynamic pressure acting on the rocket will be at it’s maximum.

The dynamic pressure or Q is the product of the air-density and the velocity squared of the object travelling through the air.

The SI unit for pressure is the pascal. One pascal is the pressure exerted by a force of magnitude of one newton perpendicularly upon an area of one square meter.

SpaceX provide a webcast of their launches which includes a simple telemetry display showing the rocket’s current speed and altitude.

Using the International Standard Atmosphere model to lookup the density at each altitude reported in the telemetry and using the reported velocity at that point we can calculate the dynamic pressure for each telemetry point. Plotting the dynamic pressure for the telemetry points we’ll be able to see at which point in terms of altitude and velocity the rocket experiences it’s maximum dynamic pressure.

Here is a graph based on telemetry data from SpaceX’s JCSAT-14 launch.

The maximum dynamic pressure (Max-Q) experienced is roughly 30 kPa at an altitude of roughly 11.5 km while travelling at a speed of 1500 km/h.

As a comparison here is a graph for the Space Shuttle launch STS-124. The telemetry supplied also includes the throttle position, and you’ll notice that the main engines of the Space Shuttle are actually throttled back significantly to 72% for a couple of seconds.

This is done to limit the maximum dynamic pressure that the Space Shuttle will need to handle during a launch.

The maximum dynamic pressure experienced by the Space Shuttle is roughly 35 kPa at an altitude of roughly 10.8 km and travelling at a speed of roughly 1550 km/h. So in the same ballpark in terms of altitude and speed and dynamic pressure as the SpaceX rocket.

You’ll notice a kink in the velocity squared line at around about the 40 km mark even though the main engine throttle percentage doesn’t change. This is due to the separation of the two solid rocket boosters.

I thought it would be interesting to compare the maximum dynamic pressure experienced by an airliner. So I used some data from the Flightradar24 website that tracks ADS-B broadcast by airliners broadcasting their altitude, ground speed etc.

So assuming there isn’t any significant wind I’m assuming that the ground speed matches the true airspeed. Then again using the International Standard Atmosphere (ISA) we can lookup the density for the specific altitude and use that to calculate the dynamic pressure.

So it looks like the maximum dynamic pressure is experienced at cruising altitude and cruising speed and roughly peaks around 25 kPa. In other words an airliner’s maximum dynamic pressure that it experiences is roughly in the same ball park as experienced by a SpaceX rocket and the Space Shuttle and the airliner experiences it at roughly the same altitude.

To get a feel for how much pressure 25 – 35 kPa is remember it’s the equivalent to 25,000 – 35,000 N/m². Which is roughly 2,500 – 3,500 kg sitting on a 1 square meter surface.

Now the palm of your hand is roughly 10 x 10 cm, i.e. 0.01 m², so it’s the equivalent of holding 25 – 35 kg in the palm of your hand.

Modelica – Simple Rocket Test

In the mid 1980s while I was in high school my father bought me an Apple II, well actually a clone of an Apple II from Hong Kong. He had been a helicopter pilot in the air force and had then become an airline pilot, hence the Hong Kong connection.

I had always had an interest in aircraft and so one of the first programs I wrote for the Apple II was a very basic aircraft simulator based on formulas in Mechanics of Flight and some basic high school trigonometry.

Recently I came across a talk given by Michael Tiller titled – Modelica: Component-Oriented Modeling of Physical Systems which describes the Modelica language and tools which allow you to describe a physical system by listing the equations involved. As long as the number of variables involved equals the number of equations then Modelica can simulate the model. He also has a free online book describing Modelica – Modelica by Example.

So I downloaded the free open source version of Modelica – OpenModelica to test it out. For an initial basic test I decided to model a simple rocket launch. Three forces are modeled, namely the thrust from the rocket engine which is constant while it has fuel, aerodynamic drag both on the way up and on the way down and the gravitational force on the rocket which varies since the fuel mass decreases as it’s burnt by the engine.

In terms of the aerodynamic drag the assumption is made that as the rocket reaches it’s maximum trajectory it flips over 180 degrees to come down nose first so that the coefficient of drag used is the same for the ascent and the descent. I also assume that the rocket won’t be flying very high so we can assume a constant air density.

Forces acting on the rocket.

Here is the Modelica code to model the rocket system, the heart of which are the seven equations describing the forces and calculating the rocket’s mass based on the fuel consumption.

Here is a graph showing most of the variables (forces, velocity and height) over the course of the simulation run. Click on the graph for a full size version.

Here is an annotated version of the graph with some sanity checks. Click on the graph for a full size version.

1. Engine cut-off. The model starts with 100kg of fuel and a fuel burn rate of 10kg/s so we expect engine cut-off at exactly 10 seconds. At 10s we see the net force flips from being positive, i.e. the engine force is greater than the gravitational force and drag force to being negative since the engine has cut out. Leaving only drag and gravity acting on the rocket.
2. Gravitational force. Note how the gravitational force decreases from time 0s when the rocket is full of fuel to time 10s when the fuel is all used up.
3. Maximum net force. Is a trade-off between the rocket motor force which is constant and the gravitational force which decreases as fuel is burnt versus the increasing drag force which increases with the square of the velocity. After this point the drag force starts to dominate.
4. Maximum velocity. Reached as the rocket motor shuts off. Also maximum drag force at the same time.
5. Apogee. Reached as the velocity goes to 0, drag also goes to 0 at this instant and the net force is gravity only.

By simply changing some of the parameters of the model, e.g. the fuel burn rate or the initial amount of fuel etc. you can quickly see what effect that has by re-running the simulation.

MH-370 Forward Tracking

The last reported location for MH-370 from Malaysian military radar is N6.6381 E96.408 at 18:22UTC. If we assume some maximum ground speed for the next 78 minutes until the 19:40UTC satellite ping then the intersection of the maximum aircraft range from the time of the last radar contact until the 19:40UTC satellite ping will define the northernmost and southernmost points on the 19:40UTC ping ring that the aircraft could have reached. Effectively turning the 19:40UTC ping ring into an arc.

The following plot shows the possible positions for the aircraft at 19:40UTC as blue dots on the ping ring based on a maximum ground speed of 520kts from the time of the last radar contact. The blue dots in this plot along the ping ring are spaced 1 degree apart in bearing from the satellite sub-point at 19:40UTC.

The subsequent 4 satellite pings at 20:40UTC, 21:40UTC, 22:40UTC and 00:11UTC show the aircraft being further away from the satellite at each ping.

What I’ve done is to write a simple Python program that takes an assumed constant ground speed as input and then starting with each starting point indicated by the blue dots on the 19:40UTC ping arc tries to fit a projected ground track at that speed to all the subsequent ping rings.

It does that simply by for each starting point iterating over all possible ground tracks from 0-359 degrees in 1 degree increments and working out the resulting ground position at the time of each of the subsequent satellite pings. If there is a match to within a user defined error range, at the moment set at 4% then it plots that ground track.

I’ve plotted the resulting possible ground tracks for 3 different ground speeds from 19:40UTC onwards, 350kt, 400kt and 450kt.

You can see why the initial ‘red arcs’ that Inmarsat released based on the 00:11UTC ping had a gap between them.

In addition to the being able to determine a range to the satellite for each ping Inmarsat also recorded the frequency change due to the Doppler effect at the time of each ping. The Doppler shift data in effect allows you to work out what the LOS (Line Of Sight) speed was between the aircraft’s position and velocity and the satellite’s position and velocity.

The authorities released a graph showing the BFO (Burst Frequency Offset) recorded for each satellite ping. Mike Exner with the help of Duncan Steele have converted these into LOS speeds for each ping.

So my idea was to then filter out the possible ground tracks shown in the plots above by only including those that also matched the Doppler data for each ping.

Given the satellite’s 3D position (SPx, SPy, SPz) and velocity (SVx, SVy, SVz) and the aircraft’s position (APx, APy, APz) and velocity (AVx, AVy, AVz) then the LOS speed between them can be calculated as follows.

The following plots show the result of including the Doppler data to filter out ground tracks that don’t match both the satellite ping rings and the LOS speed derived from the Doppler data.

However unfortunately in order for any tracks to match based on the Doppler data I had to increase the error margin for the Doppler data to 50-95% compared to the 4% used for the ping ring positions.

The Doppler error margin used for each of the plots is included in the plot title, 50% for 350kt, 70% for 400kt and 95% for 450kt.

All three of the plots above only show southern routes matching both the ping rings and the Doppler data. However if I drop the ground speed to 300kt and use a Doppler error margin of 70% then some of the northern routes also match.

Given the need to use such large error margins for the Doppler data filtering I see 3 main possibilities.

– I’ve made a mistake in some of the calculations in my program. Feel free to look at the source code and point any errors out.

– I’ve made a typing error when entering some of the data into the program, e.g. the satellite co-ordinates, velocities etc. Again take a look at the source code and let me know if you spot any such errors.

– The data I’m relying on isn’t accurate.

In terms of the data I’m relying on most of it has been derived by others rather than coming directly from the authorities. In terms of the ping ring ranges the authorities have only released the elevation angle of 40 degrees for the last ping at 00:11UTC. All the other ping ring ranges have been calculated by someone digitizing a plot that the authorities released showing a possible 450kt and 400kt route that the aircraft could’ve taken. The assumption being that the two possible ground tracks matched the ping ring range data that Inmarsat had.

The authorities haven’t released the LOS speeds based on the Doppler data for each of the pings. Instead they’ve only released a graph showing the Burst Frequency Offsets (BFO) recorded and others in particular Mike Exner have then tried to work backwards to calculate the LOS speed. However there is a lot of debate regarding the accuracy of this process mainly based on the assumptions used.

I’ve sourced all my data from Duncan Steele’s blog at www.duncansteel.com

In particular the satellite position and velocity data can be found at – http://www.duncansteel.com/archives/397

Time	Ping Ring Range	LOS Speed
19:40UTC	1762nm	-53.74kt
20:40UTC	1805nm	-70.87kt
21:40UTC	1962nm	-84.20kt
22:40UTC	2199nm	-97.14kt
00:11UTC	2642nm	-111.18kt

The source code for my program, only about 100 lines of Python can be found at – Python source code

MH-370 Back Tracking

For each ping between the aircraft and the Inmarsat satellite we have the range/elevation angle between the satellite at that time (satellite is moving) and the aircraft and we have the Burst Frequency Offset (BFO) Doppler data.

So the LOS speed between the satellite and the aircraft along the LOS vector is as follows:

LOS – Line Of Sight
EA – Elevation Angle between the aircraft and the satellite Vs – Satellite’s velocity vector
Va – Aircraft’s velocity vector
α – Bearing angle from the satellite to the aircraft’s position
β – Angle between the aircraft’s velocity vector and the LOS vector

If we assume a particular position for the aircraft on the ping ring and a particular ground speed for the aircraft then given we have the LOS speed from the BFO Doppler data we can solve for β.

Couple of assumptions/simplifications.

– Assuming that Vx and Vy are 0 for the satellite and only using the Vz component.
– Assuming that Vx is 0 for the aircraft

At 00:11UTC at the time of the last ping the satellite’s velocity components were:

Vz = -82.1m/s Vx = 1.5m/s Vy = -1.5m/s

Using the following data from Duncan Steel – duncansteel.com.

Time (UTC)	Elevation Angle	Ping Radius (nm)	LOS Speed DS (kt)	LOS Speed POL (kt)	Satellite Z (nm)	Satellite Vz (kt)
18:29	53.53	1880	39.77	76.24	623.87	49.12
19:40	55.80	1760	39.14	4.97	651.30	-3.22
20:40	54.98	1806	65.80	57.02	625.88	-47.42
21:40	52.01	1965	79.85	118.34	557.62	-88.38
22:40	47.54	2206	100.64	175.49	451.20	-123.31
00:11	39.33	2652	125.35	250.43	233.91	-159.58

– DS – Duncan Steel & Mike Exner BFO analysis
– POL – Polynomial fit of BFO data – BFO = 0.3673 * ABS(LOS vel in km/hr) + 94.975

I’ve written a Python script that uses the formula above and the data above to iterate over a number of sample aircraft positions along the 00:11UTC ping ring by iterating over α from 1 degree to 89 degrees. An assumed aircraft ground speed is entered as a parameter and for each sample position along the ping arc the script calculates β and derives 2 possible ground tracks for the aircraft at the sample position to match the known LOS speed from the BFO Doppler data.

Given the ground tracks calculated and the supplied aircraft ground speed and the time between this ping and the previous ping the script calculates the aircraft’s position at the time of the previous ping assuming a constant ground speed and constant ground track.

If the computed aircraft position at time of the previous ping is within 2% of the previous ping ring then the aircraft’s position on the current ping ring and it’s calculated position on the previous ping ring are plotted with a line joining them.

The script then continues recursively using the points that are within 2% of the previous ping ring to compute β for each of them based on the LOS speed for this ping ring and working backwards to the previous ping ring.

For a given aircraft ground speed the resulting plot shows the range of possible aircraft positions on the 00:11UTC ping ring and ground track that match the BFO LOS speed and which track back to intersecting the previous ping ring at the correct time.

The idea was to get a feel for the range of possible locations on the 00:11UTC ping ring for a given aircraft ground speed that also matches the BFO LOS speed data at that time and to see how many of those tracks track back to the 19:40UTC ping ring.

The plots also include the last known location for the aircraft at 18:22UTC from the Malaysian military radar, indicated as a yellow diamond. I’ve then assumed a maximum ground speed of 500kts from this time and location for 78 minutes until the 19:40UTC ping and rendered the maximum range that could be covered (650nm) in this time as the yellow circle.

The intersection of this circle with the 19:40UTC ping ring places a maximum northern and southern limit to where the aircraft could be at 19:40UTC along this arc.

When I initially started thinking about writing this program I was only aware of the BFO LOS speeds that Duncan Steele and Mike Exner had calculated. However none of Duncan’s routes that he tried in STK could match the LOS speeds that had been calculated from the BFO data. The routes did match the relevant ping ring times but there was no match for the BFO Doppler data.

Subsequently I became aware from a comment on Duncan Steele’s blog posting for an alternative set of BFO derived LOS speeds. I’ve listed both in the table of data that I’m using above and the Python script takes the LOS speed for the ping ring as an input parameter.

In running the script however there are no matches for any airspeeds tested between 350kts and 500kts that produce any matches using Duncan Steele and Mike Exner’s BFO derived LOS speeds, so in all the plots below I’ve only used the BFO derived LOS speeds from the polynomial fit approach.

Source code for the Python program – MH370Backtrack.py

Plots for 350kt, 400kt, 450kt, 480kt and 500kt.

Live Photo Gallery People Tags

I’ve used the tagging feature in the original Windows Vista Photo Gallery and the Windows Live Photo Gallery versions for tagging people in photos and the location of the photo.

The latest version of Windows Live Photo Gallery now includes a specific ‘People’ category separate from the generic tags category for identifying people in photos. In addition it includes a feature to automatically identify faces in photos and to associate the ‘People’ tags with specific faces in the photo.

The sample below taken from the Windows Live Photo blog shows the new face tagging features. You can also manually draw a rectangle over a face and tag it if the Photo Gallery doesn’t automatically detect the face.

One issue I’ve noticed is that the new people tags aren’t indexed by Windows Search. I often use Windows Search to search for photos based on my people and location tags and the new people tags aren’t found. So at the moment you have to search or filter photos based on the new people tags in Live Photo Gallery itself.

I took a look at the XMP meta-data that is stored by the new people tagging feature in the associated photos.

In the snippet below you can see how the rectangular region for the relevant face is stored if there is one plus the PersonDisplayName. There are APIs in WIC plus associated .Net wrappers in the .Net Framework that allow you to read this meta-data so you could make use of the rectangular regions in your own application that may want to display photos and show the tagged faces etc.

<rdf:Description xmlns:prefix0="http://ns.microsoft.com/photo/1.2/">
  <prefix0:RegionInfo>
    <rdf:Description xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
      <prefix1:Regions xmlns:prefix1="http://ns.microsoft.com/photo/1.2/t/RegionInfo#">
        <rdf:Bag xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
          <rdf:li>
            <rdf:Description xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
              <prefix2:Rectangle xmlns:prefix2="http://ns.microsoft.com/photo/1.2/t/Region#">0.209985, 0.526367, 0.167401, 0.111328</prefix2:Rectangle>
              <prefix3:PersonDisplayName xmlns:prefix3="http://ns.microsoft.com/photo/1.2/t/Region#">Sarah McLeod</prefix3:PersonDisplayName>
            </rdf:Description>
          </rdf:li>
          <rdf:li>
            <rdf:Description xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
              <prefix4:Rectangle xmlns:prefix4="http://ns.microsoft.com/photo/1.2/t/Region#">0.430250, 0.148438, 0.284875, 0.189453</prefix4:Rectangle>
              <prefix5:PersonDisplayName xmlns:prefix5="http://ns.microsoft.com/photo/1.2/t/Region#">Gwen De Roubaix</prefix5:PersonDisplayName>
            </rdf:Description>
          </rdf:li>
          <rdf:li>
            <rdf:Description xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
              <prefix6:PersonDisplayName xmlns:prefix6="http://ns.microsoft.com/photo/1.2/t/Region#">Marcelle De Roubaix</prefix6:PersonDisplayName>
            </rdf:Description>
          </rdf:li>
        </rdf:Bag>
      </prefix1:Regions>
    </rdf:Description>
  </prefix0:RegionInfo>
</rdf:Description>

The following snippet shows the XMP meta-data that is stored if you tag one of your Messenger contacts as a People tag.

<rdf:Description rdf:about="uuid:faf5bdd5-ba3d-11da-ad31-d33d75182f1b" xmlns:prefix0="http://ns.microsoft.com/photo/1.2/">
  <prefix0:RegionInfo>
    <rdf:Description xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
      <prefix1:Regions xmlns:prefix1="http://ns.microsoft.com/photo/1.2/t/RegionInfo#">
        <rdf:Bag xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
          <rdf:li>
            <rdf:Description xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
              <prefix2:PersonDisplayName xmlns:prefix2="http://ns.microsoft.com/photo/1.2/t/Region#">gerhard</prefix2:PersonDisplayName>
              <prefix3:PersonEmailDigest xmlns:prefix3="http://ns.microsoft.com/photo/1.2/t/Region#">89C386678731AB3D7DEE0E14E11E633387FBDBCD</prefix3:PersonEmailDigest>
              <prefix4:PersonLiveIdCID xmlns:prefix4="http://ns.microsoft.com/photo/1.2/t/Region#">8765613456339678115</prefix4:PersonLiveIdCID>
            </rdf:Description>
          </rdf:li>
        </rdf:Bag>
      </prefix1:Regions>
    </rdf:Description>
  </prefix0:RegionInfo>
</rdf:Description>

And lastly a snippet showing how the regular tags which are indexed by Windows Search are stored, basically in a <dc:subject> element and in a <MicrosoftPhoto:LastKeywordXMP> element.

<rdf:Description xmlns:dc="http://purl.org/dc/elements/1.1/">
  <dc:subject>
    <rdf:Bag xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
      <rdf:li>Party</rdf:li>
      <rdf:li>People/Sarah McLeod</rdf:li>
    </rdf:Bag>
  </dc:subject>
</rdf:Description>
<rdf:Description xmlns:MicrosoftPhoto="http://ns.microsoft.com/photo/1.0">
  <MicrosoftPhoto:LastKeywordXMP>
    <rdf:Bag xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
      <rdf:li>Party</rdf:li>
      <rdf:li>People/Sarah McLeod</rdf:li>
    </rdf:Bag>
  </MicrosoftPhoto:LastKeywordXMP>
</rdf:Description>