This page is actually a collection of articles – all written by me
– about usage and benefits of telemetry with data logging.
The first article followed from a discussion about a battery's internal
resistance and an unexpected idea how to derive it from telemetry data.
Two other articles have been developed from investigations of incidents
that happened to my Senior Telemaster Plus model airplane.
The dedicated review page has comprehensive information about
its telemetry equipment including setup.
While all of the articles are based on data from this model airplane, they
yet address aspects of more general significance – as indicated by
Internal Resistance Calculated from Telemetry Data
This article has been published in the
January 2018 issue of Ken Myers' Ampeer
Later it has been edited for better readability and clearer reasoning;
a new introduction and an interesting aside have been added. This
is the revised edition:
The significance of knowing a drive battery's actual Internal
Resistance (IR) has been thoroughly discussed in the
September (part 1) and
October (part 2) 2017 issues of Ken Myers'
Ampeer Newsletter. Even better, several methods of measuring
have been tested for their feasibility and usefulness. It turned out
that none of them is easy or even conclusive. After the basic method
of calculating IR had been discussed in part 2, it dawned on me
that I might have an easy way to do it without extra equipment. In
some of my models, battery voltage and amperage are measured and
recorded by telemetry in-flight. Just an abrupt change in power
setting, preferably from idle to full, would be needed to show
the voltage drop caused by IR.
There was an appropriate flight of
my Senior Telemaster Plus, done
to test the WingStabi flight stabilizer in light thermal conditions.
The model is loaded with telemetry and all data are recorded during
the flight so they can be analyzed later. The recorder (writing a .csv
file to a MicroSD card) is even in the airplane for more resolution or
precision, respectively. It could be in the transmitter as well, albeit
with ten times lower time-wise resolution, which might be still sufficient
though. Anyway, in the following diagram, the drive battery's voltage
(magenta), amperage (red), and remaining charge (green) are plotted
over the time since telemetry run-up:
The (red) amperage line shows spikes for take-off at about 5:40
(5 minutes 40 seconds) and initial climb (shortly interrupted),
for a second climb at about 8:20, and a third climb at about 17:10. All
of them have been done with full power setting and you see how much less
power is available from the battery after 13 minutes flight time or
even after 3 minutes.
The green line shows a quite continuous discharge over time, and it's
rather smooth compared to the serrated red amperage line because it's
These are real-life data and you see many fluctuations in them –
what is typical. Of course, amperage varies most with power setting. It
drops still noticeably when the airplane gets faster and hence prop rpm
gets bigger, most typically in turns flown with too little up-elevator.
But the small fluctuations are just "natural" – in flight
as well as in the workshop. They remind us not to be too pedantic when
measuring and interpreting data.
The same holds for the (pink) voltage line even if in a different way.
The sensor's resolution is only 0.1 V and the line runs not continuously
but in 0.1 V steps. It starts at 16.6 V before take-off and goes
down to 14.6 V during the last full-power climb. Average cell voltage
is 3.65 V then, and lowest cell-voltage (for clarity not shown in this
diagram) oscillates between 3.7 and 3.6 V due to sensor resolution,
what is actually 3.65 V as well.
There is still no weak cell showing up in the four-cell battery; after
all even a weak cell's voltage drop would not happen that early (with
so much charge remaining, about 50%).
By the way, the 0.1 V sensor resolution is the reason why I've set
a 3.4 V warning level even though 3.3 V would be the actual
critical voltage but then a too low warning level.
Despite the low voltage-resolution I just tried to derive the IR value;
after all the two climbs during the flight lend themselves as measuring
points: Amperage is increased by a huge amount so voltage drops by more
than only one or two 0.1 V steps, all in a quite short time. Amperage
is not zero before the climb, but it's reasonably continuous, at least
compared to the big peak value.
Fluctuations are evened out by taking an average over a few seconds
before and after power is increased, respectively. Since both points
are full-power measurements and the remaining charge in the battery
is quite different, we can't draw a single line for V over A. But we
can draw two of them and their slopes – that is IR values –
should be very similar. The following screenshot of a simple spreadsheet
shows just that:
The two small tables on the left side enclose the voltage and amperage
values I took from the diagram above, one each during the respective
"cruise" flight immediately before the climb and during the
"climb". The labels "08:20" and "17:10"
stand for the points on the time axis where the data have been taken
The voltage difference ("before/after" setting full power)
is divided by the amperage difference, giving the line slope –
that is the Internal Resistance IR in Ω (Ohm). The diagram on
the right side is just an illustration – the two lines are
So the two cases are quite close to each other: 0.0181 Ω,
or 18.1 mΩ (milliOhm), and 0.0167 Ω
(16.7 mΩ) differ from each other by about 8%. And
17.4 mΩ average (about 4.3 mΩ per cell) seems
to be a quite reasonable estimate for a 4S 5000mAh 30C LiPo battery.
(Follow-up: My new charger says 22 mΩ when charging and
20 mΩ when discharging an equal replacement battery.)
Of course, we have to take into account that the measured voltage and
amperage values are not quite accurate because our telemetry is not
exactly a precision instrument. But precision can be enhanced because
we have a whole diagram of values and can take reasonable averages
from the jaggy lines. (Besides, IR might really vary with discharge
High precision is not really necessary, though. It would be if I
wouldn't have telemetry with cell-voltage sensor and recorder and
could just measure the total battery IR in the workshop. My basic
assumption is that battery cells are not created equal (and not
assorted to equals in a pack), and an increasing IR is an idicator
of their aging. There are "weak" cells in a pack which
will age sooner and hence limit the whole battery's capacity and
service life (kind of the weakest link in a chain). But one weak
cell in a pack will become apparent only by a small increase of
total IR. So it would be easier (preciser, clearer) to measure
the IR of each cell in a pack through the balancer connector.
(I don't know if it would stand the amperage, though.)
Then again, the telemetry voltage sensor just measures lowest cell
voltage under load, which is an alternative to IR (soared IR reduces
amperage and voltage). Directly taking the voltage as an indicator
(instead of the indirectly calculated IR) is even a real-life and
real-time measurement. Amperage pulsed by the ESC in flight might
be more significant than artificial DC load in the workshop.
The 0.1 V resolution steps are not too bad because – as
shown above – averages over a few seconds are taken from
recorded values and two measurements are taken.
Quite generally, a recorder enhances telemetry's usefulness. Only
one recorder is needed, which can be put into different models or
even into the transmitter. Still it's useful only for those who
need or want that much telemetry. The average flyer would well do
without recorder, just with the voltage (and preferably amperage)
sensor. He'd still notice if and when a battery deteriorates what
is evidenced by at least one cell having lower capacity and dropping
voltage earlier than the other ones. (See next article below for
how that works out.)
There is an interesting aside: Knowing Internal Resistance lets
us calculate the heating power in the battery.
Power in W (Watt) is voltage times amperage. Voltage "lost"
by IR is amperage times IR. So heating power is amperage squared times
IR. In the case at hand (4S 5000mAh 30C LiPo, 17.4 mΩ IR),
35 A full-power amperage makes for 21.3 W heating power
in the battery (not even 5% of all losses in the drive). The heat
can't flow out of the compact battery pack really fast, not even
with forced-cooling measures, which act only on the pack's surface.
So the pack's temperature rises, but – in this low-power case
– merely by 11°F in mixed flight (as measured by telemetry).
Battery warming is quite familiar to all of us, but the modern LiPo
batteries don't get really hot so we don't think about it like we
did before with the "good old" NiCd batteries. These got
quite hot when nearly discharged, and they have been discharged
routinely without bad consequences (and even intentionally to avoid
memory effect). Back then we knew that IR and hence temperature rise
at the end of the discharge cycle, and that a battery deteriorates
when it's hotter than before after a normal flight. We could even
touch each cell and feel how hot it gets when the battery was recharged.
That way we found out a weak cell and the battery's degraded capacity,
which let us lower the flight time warning in the transmitter. It was
all more or less experience, but it worked.
Today we don't completely discharge (and even charge) LiPo batteries
so they have a reasonable service life. Their IR and hence their heat
production are low, anyway, so perceived temperature is no clear
indication and we can't feel a single cell's temperature either.
We do want to know the battery's temperature for other reasons,
though: it would "boil" over 140°F and "freeze"
below 32°F. Both limits are tricky to feel by hand, so if drive
power is hot or ambient temperature low, we need some means to
measure it. Of course, telemetry lends itself to that. We need
telemetry all the more – but now for voltage and amperage
– just because temperature is no longer a clear indicator
of the battery's and its cells' health (or age) and we don't have
any indication to adjust the flight time warning (throttle timer).
Electric Drive Telemetry and LiPo Battery Failure
This article has been published in the
December 2018 issue of Ken Myers' Ampeer
Later it has been edited for better readability and clearer reasoning;
another diagram and some discussion of uncertainties have been
inserted in the text. This is the revised edition:
We don't completely discharge – and even charge –
modern LiPo drive batteries in order to give them a reasonable
service life. We can afford that because their specific energy
content (Watt-hours per ounce) is about four times that of the old
NiCd batteries. While the charger reliably limits the charge, we may
feel unsure about the actual discharge during flights, which can be
quite different in their power demand after all.
What helps is a telemetry amperage sensor that is able to add up any
battery drain and subtract it from a preset capacity. This is aptly
called a "fuel gauge for the battery". I for one limit
charge to 4.17 V per cell. That means about 3% less capacity
than fully charged to 4.20 V. Hence I have set 4850 (97%)
instead of 5000 mAh (100%) capacity for the telemetry discharge
counter. The low-charge warning level was initially set to 25% or
1250 mAh to be warned in time to land the model before the safe
20% discharge limit (1000 mAh) is reached.
Now these are all nominal values, not necessarily real ones. It is
not uncommon that even a new battery’s real capacity is lower
than specified. In any case, capacity lessens as the battery gets
older, no matter if it’s used or just stored. And it may lose
capacity by maltreatment like deep discharge. Hence these telemetry
parameters have to be adapted –
after the first flights with a new battery, then regularly, after any
mishap, and towards the end of the battery’s service life.
Incidentally, that could make it difficult to use several batteries
in turn in the same model, but I don’t do that.
Besides, the higher the amperage drawn from the battery is, the lower
is its real capacity. Again, it’s not uncommon that
nominal capacity is specified for only 1C. So a lower real capacity
has to be set in telemetry to count down from, and this value should
be adequate to an average flight’s amperage. Otherwise,
rather the low-charge warning level could be set differently –
higher for flights with high amperage load and lower for more
leisurely flights. My flights are not that different, though.
Beyond discharge count, there is even a fair chance to detect
capacity deterioration or just variation in flight. The battery would
drop voltage prematurely, so we may want a telemetry voltage sensor
in addition. For a new battery with fresh cells, total voltage may be
indicative enough of its health. But because some cells in a pack age
faster than others, such a sensor should ideally (additionally)
find the weakest cell and report its voltage. That seems to be
useful when the battery gets old or worn out, and if there are
substantially different flight regimes.
With telemetry, we try to protect our delicate LiPo batteries and yet
get the most out of them. But how does this work out in practice?
Here’s what I think is a typical example:
In October 2016, total battery voltage, amperage, and charge
sensors (all in the ESC) were
in my Senior Telemaster Plus when I made
a mistake. I won’t discuss the gory details but rather
what telemetry could help (or not) in that situation. The following
diagram shows battery voltage (magenta), amperage (red), and
charge (green), as well as the airplane’s altitude (blue, from
a GPS) over a whole practice flight. The horizontal axis shows
minutes and seconds (separated by a colon) since telemetry run-up.
Unfortunately, decimal point and thousands separator are
interchanged on the vertical axes.
The peaks in the (red) amperage and (blue) altitude lines indicate
traffic patterns. In the 23rd take-off things went awry.
The (magenta) voltage as well as the (red) amperage line show the
battery’s discharge curve quite well, I mean how voltage drops
fast in the beginning, then only slowly, until it drops
progressively in the end. That’s a clear indication of my fault
already since a LiPo battery should never be discharged that deep.
I missed the low-charge warning for 1250 mAh (25%) remaining
charge at about 32:05, just at the end of a climb. Two take-offs
later, the recommended 1000 mAh (20%) discharge limit was
under-run at 33:35. Another two take-offs later, the 4 x 3.4 = 13.6 V
low-voltage warning level was under-run at about 35:10. The
safe 3.3 V cell voltage limit was under-run at 36:00 in
the next take-off, but yet the next landing was done at 36:50 without
reaching the critical 3.2 V cell voltage limit. Remaining
charge was 590 mAh (11.8%) or 410 mAh (8.2%), respectively.
It’s not that I’m just a scatterbrained geezer. I even
managed to set up the telemetry correctly (and it worked correctly)
but I messed up the voice output. The low-charge alarm was mistakenly
set to permanent, meaning it was permanently voiced, and there were
even other announcements interspersed. Hence the voice output was
cluttered beyond recognition and I had to learn the hard way why
restricting announcements to a minimum is a good idea.
An interesting aside is that the (red) amperage line’s
“hump” in this diagram’s center shows three
Its inclined right part results from low-voltage power reduction
to keep voltage up at 12.8 V, as evidenced by the (magenta) voltage
line’s level part over it.
Its steeply – but not vertically – rising left and falling
right edges are due to “soft” motor run-up and
That holds for the other red-line “humps” as well,
especially the one leftmost.
While it’s a full-power “hump”, the next one (to the right)
shows even “softer” run-up and braking, which take just as long
now but to or from only half-power, respectively. That seems to be
a fourth ESC feature
as it’s seen in the rest of the flight as well.
Still there was another safety feature:
the ESC was set to
low-voltage “power reduction”. This is meant to save the
battery and yet avoid a surprising dead-stick in case of deep discharge.
Of course, it set in during the next take-off run (at 36:55) when full
power was set. It reduced power continuously and just enough to keep
voltage up, but that made a proper climb after take-off impossible, not
to mention a go-around. Finally I cut power (the rest of it) when the
model touched a bush top (at 37:04). There was still 335 mAh
(6.7%) charge left.
Obviously, the low-voltage trigger level is pre-set (not adjustable)
to the critical 3.2 V per cell, that is 12.8 V for
the 4S battery. This level was slightly under-run to 12.7 V and
even 12.6 V for a split-second so average (not to mention lowest)
cell voltage was 3.175 V or 3.15 V, respectively – too
low. Without any load (amperage), it recovered to only 3.325 V
(13.3 V total, see diagram) whereas it should have reached
3.75 V (15.0 V total) again, minimum idle voltage of a healthy
battery. Obviously, even the small shortfall in voltage and the associated
deep discharge hurt the battery. It was swollen (puffed-up) thereafter and
had noticeably less capacity.
In September 2018, there was even a cell-voltage sensor
in my Senior Telemaster Plus.
I had raised the low-charge warning level to 1500 mAh (30%)
because the battery had lost even more capacity to age. The following
diagram shows the battery’s final flight. The 4S-battery voltage
(magenta) and cell voltage (blue) axes are scaled 4:1 so both lines
are overlaid. Both sensors have 0.1 V resolution so the
cell-voltage line has four times bigger steps. The two lines
coincide fairly well until about 21:00 when a fatal
incidence occurred: cell failure.
The (green) charge line is still rather high (nearly 30% remaining
nominally) at the time of incidence. Altitude (pink) and amperage
(brown) lines show an initial full-power climb to thermal altitude
(at 2:30). Then, more or less (or even zero) power was set while the
airplane loitered in thermals and downdrafts. Power was cut (at
19:20) after the 1500 mAh (30%) low-charge warning had been
In retrospect (looking at the diagram), there was even a sign of the
coming cell failure: There are two short drops of cell voltage (blue,
at 18:42 and 19:04), but only by 0.1 V to still 3.6 V –
well above the 3.4 V warning level. Battery voltage (magenta)
didn’t even drop and recovered by 0.2 V after power had been
cut while (lowest) cell voltage remained low. Even taking the 0.1 V
sensor resolution and the 4:1 scaling into account, this means one cell
was about to fail, but just the fact that it dropped voltage – not
the amount – hinted at that. Hence it was not perceptible.
It’s possible that I coincidentally reduced power just at the
moment when cell voltage dropped, for instance because I realized
that the airplane had gained good altitude in another thermal. My
recollection is clouded by the following events so a log of the ESC
settings during the flight would be needed to clear that up.
Regardless, the interesting question is whether there could have been
another, perceptible sign of the coming cell failure. To answer it,
let’s just assume that amperage dropped permanently due to
increased internal resistance even after the first short voltage
However, there was still no way for me to notice that. This detail
diagram shows no clear amperage drop from 18:45 on – like the
full diagram above – but just the usual fluctuations at a slightly
lower level. And I had expected that the battery would recuperate while
power was cut, but there was hardly any power when needed to fly over
a row of trees. I rather cut power when the airplane was blown by winds
gusting up to 15 mph or even 20 mph, and then sunk into a tree.
At least that’s what I think I did; I have no clear recollection
because I was so stunned. Anyway, battery voltage remained well above
the ESC’s 12.8 V power-reduction trigger level.
It happened in quite a short time, even seen in the 30 seconds time
frame from 20:40 to 21:10 shown in this detail diagram. When some
amperage was drawn from the battery (at about 20:57), its voltage
dropped from 14.8 V to 14.0 V (by 0.8 V) while the
lowest cell voltage dropped from 3.7 V to 2.8 V –
by 0.9 V. The voltage drops are not equal (mind the 0.1 V
resolution) and not exactly synchronous either.
Oddly enough, battery voltage recovered to 14.9 V and even the
bad cell recovered to 3.7 V what is still close to minimum idle
voltage (3.75 V). But the charge left in the battery (green)
was nominally 1436 mAh (28.7%), substantially more than 1000 mAh
(20%) when the battery was new – it had lost capacity. It had
been used for less than 100 flights yet it was 3½ years old
and had suffered the deep discharge two years ago. The loss of capacity
had been noticeable when re-charging it.
The two flights are quite different in their course but overall
drive usage is still quite similar: For a minor part of the
flight duration, full power is set for climb (to traffic pattern
altitude or to thermal altitude). For the major part, more
or less cruise power is used (for traffic patterns or in search
of thermals). For another minor part, power is low or even off
(approaches, descents, thermalling).
The first flight lasted 29:45 and 4515 mAh were used up; 19:20
and 3415 mAh in the second flight. That were 152 mAh/min
and 177 mAh/min, respectively, so battery drain in the first
flight was 86% of that in the second one. If idle times (4:35 and
2:30, respectively) are excluded (what the throttle timer
does), the battery drains were 179 mAh/min and 203 mAh/min,
respectively. Their ratio is now even 88%.
The first flight’s lower battery drain might be due to the
quite big amount of landing approaches. Then again, the second
flight’s higher battery drain might be due to the quite big
amount of downdrafts. Either way, differences in battery drain seem
to be just random. The 200 mAh/min or 20 minutes flight
time rule-of-thumb gained by experience seems to be on the safe side.
Does telemetry help taking care of the drive battery?
Actually it did help avoiding deep discharge, I just didn’t
properly set up the voice output and didn’t pay attention to it.
Surprisingly, it could not help once the battery was flawed and aged,
and that might be due to a LiPo characteristic.
Is the ESC’s low-voltage power reduction a substitute?
To be one, it would have to set in earlier, at least at 3.3 V
cell voltage, and then it would need voice output to alert me of the
coming power reduction – that’s what telemetry does already.
Otherwise, it enforces power reduction and thereby takes away the
option of sacrificing the battery to save the model. I prefer telemetry
and don’t see it as a complement, either.
Is telemetry worth it?
Well yes, it has its value and it’s not really expensive, but
that seems to be a pointless question nowadays. Likewise, if I’d
be asked if I need my smartphone I’d say actually not –
I just have it.
What if there’s no way to have telemetry in a model for some reason?
The traditional throttle timer seems to be still good enough for all
practical purposes. Battery drain is surprisingly constant with my model,
nearly independent of the course of flight. Just a bit more safety margin
would be needed compared to telemetry, maybe 15% at most.
This exemplary investigation of ill-fated flights was possible because
a recorder in the airplane logged all telemetry data ten times a
second and a GPS’s position data twice a second. That’s
an almost complete “black box” system for models, lacking just
servo movements. Especially the power settings (on the ESC’s
channel) would be badly needed to clear up doubts about what really
Logged GPS 3D Location Data for Incident Investigation
This article has not been published elsewhere. It's just a
supplement to the previous article and is supposed to show that
a GPS is a useful device in a model airplane that carries data logging
telemetry already. To this end, it comprises a lot of pictures and some
diagrams to illustrate what has been expounded in the previous
In the first place, the GPS had been installed
in my Senior Telemaster Plus
to have in-flight data like speed, altitude, and distance. In this
regard, it was soon mostly superseded by a
barometric (pressure) sensor.
Yet it has been left in place because there is a data logger in
the airplane as well. Both devices pair up to constitute an almost
complete “black box” system for models.
That proved to be useful even in an early case of incident (in October
2016), which could be cleared up completely, and later in a second case
of incident (in September 2018), which was elucidated for the most part.
These two cases are investigated here as well as in the previous article
Technically, the GPS 3D location data (in
GGA format) are logged twice a second
during flight, along with all telemetry sensor data, which are logged
even ten times a second. Later, the complete log is imported in the
LogView program, which generates statistical
(time series) data diagrams as shown above and below.
From this program, the 3D location data are exported in
format and imported in the Google Earth software. There, the flight path
(with ground speed or climb/sink rate or both combined as different colors)
can be visualized from any viewing angle, including from pilot's position,
as shown below. Both programs have perpetuated their names in the
following screen shots.
Touched a Bushtop
That's what the airplane did at the end of a climb-turn after
take-off when power was scarce and the climb was feeble.
It was a practice flight to test and adjust complicated mutual
flap-aileron mixings as well as the related flap-elevator mixing.
Maybe that's why I just couldn't stop trying again and again and
ignored all warnings in the telemetry voice-output (which was also
cluttered beyond recognition). Anyway, I carried flying traffic
patterns much too far – to a 23rd take-off when
the battery was finally discharged and the ESC's low-voltage power
reduction set in. After the airplane had touched the bushtop, it
tumbled earthwards and bumped on its main landing gear, which got
crooked – but there was no other damage.
This is most of the flight's path drawn as a colored line showing
slow (green) to medium (yellow) ground speed (GPS).
As can be tracked in the statistical data diagram in the previous
article above (for a large
diagram click here), it was a flight with many traffic
patterns and some halts on the runway to adjust mixers.
Take-off direction was eastwards (right in the picture). The initial
wide turns as well as most of the (round) traffic-pattern base legs
(left in the picture) are clipped here.
The really interesting thing is the last crosswind leg (from the
eastern end of the runway), which was low and tight and ran through
a bushtop. It is the small (radius) semi-circle, which has no
following downwind leg but ends up in the meadow north of the runway.
The bush is visible here and the model's path is drawn exactly
through its top.
The last take-off belonging to this crosswind leg is hidden in
the pathlines of the preceding traffic patterns.
The picture even shows where the model was trailed from the parking
area (south) to the runway's eastern end, but curiously the line ends
there. Likewise, there are gaps between all traffic pattern lines,
that is between a landing and the next take-off.
Then again, all take-offs and landings seem to be correctly depicted,
at least they look reasonable.
All but one, that is, because one take-off seems to arise from the
ditch running north to south at the runway's eastern end.
This picture shows that even better, but there is yet no explanation
for this single "runaway".
All other take-offs look reasonable, including the last one, which is
It's correct that its take-off point is just shy of the ditch behind
the runway. The ESC's low-voltage power reduction had set in even during
the take-off run so I literally had to take the airplane off the runway
in the nick of time.
The following low crosswind turn is well pictured here, including a
crosswind apex and a slightly descending part to the bushtop. Obviously,
power had been reduced too much already to maintain even level flight.
From the bushtop, the flight path runs steeper to the ground because
the model had been retarded by the bush's vertical top twigs and I had
cut power completely.
The "hump" at the end of the flight path might come from me
picking up the model, but that is not clear and not relevant, either.
It is crucial that the last take-off and the incident as such are shown
quite correctly. The "runaway" take-off is petty because it
didn't lead to an incident. And it doesn't matter that coasting down after
landings as well as take-off runs are not shown at all.
Only one thing is questionable: The flight path as shown is running
through the bush while the model actually just brushed the
bushtop. If it would have been lower – as shown here –
it would have stuck in the bush. I don't think the bush is
"overinflated" in Google Earth, though.
There was still no barometric altimeter in the airplane to compare to
GPS altitude shown here, and both altimeters are not that precise, either.
But yet we should have a look at the third statistical data diagram in the
previous article above (and
make it larger). It shows battery voltage (magenta), amperage
(red), and charge (green), as well as the airplane’s altitude (blue).
The altitude line is running noticeably below zero while the airplane is on
the ground, evident during the landing/take-off at the left side and in the
center of the diagram.
That holds also for the second diagram in the article above, which shows the
last seven traffic patterns as well as the incident.
This diagram, which shows two GPS altitudes during the whole flight, depicts
values well below zero for all ground runs. That explains why there is no
flight path line on the ground – it's actually underground and hence
clipped in the picture. That might even explain the "runaway" as
a take-off where GPS altitude was extremely off (negative). It might have
been the take-off at about 20:00 after a pause at the runway (to adjust mixers).
It is -10 meters off while most other take-offs are about -5 meters
off (give or take).
After the incident, altitude is still -4 meters but virtually doesn't
drift for about 55 seconds until telemetry is switched off. When telemetry
was switched on, altitude was exactly zero for about half a minute, probably
while the GPS was searching for satellites. Then it starts drifting mostly
to negative but jumps back to -1 meter when the airplane is trailed
to the runway.
Since there was yet no barometric sensor in the airplane, GPS altitude above
ground level (at telemetry run-up) has been used here instead. Additionally,
the 3D location data include the GPS antenna altitude above mean sea level.
The former has one meter resolution, which is why the blue line is stepped
while the brown line with its nominal millimeter resolution is smooth or
serrated, respectively. Otherwise both lines are the same.
Sunk into a Treetop
That's what the airplane did at the end of an actually successful flight.
When the battery discharge warning was announced I wanted to land the model
straight away and eventually even set full flaps for a fast descent. But I
grossly underestimated the wind and, for a moment, just watched in wonder how
the airplane was making leeway and got behind the notorious line of trees in
the east of the field. When I finally opened up, there was hardly any power
and I saw the airplane get just over a tree and then sink almost vertically
into the near side of its crown – obviously by combined effort of sink
speed and a 15 km/h gust of headwind. As it turned out later, one cell
of the drive battery had gone kaput – as usual at the wrong moment.
As by a miracle, the model stayed completely undamaged – that's why
I call it a tree-landing and don't use the word crash.
This is the whole flight's path, with GPS 3D-speed (ground speed and vertical
speed combined) color-coded from green (slow) to red (fast). As can be tracked
in the statistical data diagram in the previous article above, it was a typical flight in strong thermal conditions.
After a 45 second climb to 150 meters, the airplane loitered at low
cruise power for 2½ minutes – in quest of thermals. A short
downdraft boded a strong thermal, which was used for nearly 5 minutes,
eventually even at idle power. At 260 meters, the flight's highest point,
an accordingly strong downdraft followed, which had to be attenuated by re-setting
cruise power after just 10 seconds. About 4 minutes later, power was
even increased to level off at 75 meters. After loitering there for
3 minutes, another thermal was catched and used for 3 minutes. Now
the battery discharge warning was announced at 170 meters and power
While the loitering parts look rather bewildering, the two thermal climbs
give the impression of being clearly discernible by their spiraling pattern.
There is one important variation, though: their inclination. While the first
spiral is moderately inclined, the second one is virtually blown by the wind.
I see that as an indication that the westerly wind had significantly freshened
between the two thermals – a fact that dawned on me only too late when
the airplane got leeward (eastwards) behind the line of trees (centered in
In a way, the weird tangle on the tree has to do with the wind. It
represents the time when the model was in the tree's twigs (see photo
below) for nearly four hours and was heftily shaken by the gusty wind.
Obviously, the GPS needs standstill or a vectored movement to calculate
an exact position. If it's raggedly tossed about, it can't find a
position to converge to. At least I have no other explanation.
The "triangle" in the foreground is similar. It's where I put
the model on the runway for the checks before take-off. Telemetry was
re-started and there was actually no movement.
Anyway, while the GPS is amazingly precise for most of the flight, there
are moments when it acts up.
In the flight's final part its path seems to be flatter, perhaps
because I unconsciously flattened it. That may be true, but the different
flight speeds (yellow changing to a "slow" green) are mostly due
to the wind. The airplane made an upwind turn into strong wind and that's
why it got slower over ground. Besides, this view from southwest shows
that the final turn ended not upwind (westwards) but just southwestwards,
so there is no way to see the path's slope correctly.
In this view, the turn's final part looks even considerably steeper than
the downwind leg before. That's partly because sink rate is higher in a
turn, especially with flaps down. But that's mostly just what a downwind
and an upwind leg look like – flatter and steeper, respectively.
The upwind leg before the last downwind leg is about as steep as the
"final approach". The kink in the flight path is where I set
full flaps for a fast descent because so far the airplane hadn't lost
altitude even up wind, perhaps due to thermal influence. Despite the strong
wind the airplane got to a good position abeam of the runway's threshold.
Maybe that's why I started a downwind leg then, or by force of habit
– I have no idea.
Actually, the wind should make eastward parts of the flight path faster
over ground and thus more yellow, while the westward parts should be slower
and thus more green. That is not clearly shown in the picture, though, perhaps
because the speed differences are not that big.
Rather the different flight speed colors stem from circles not flown correctly,
that is with too little up-elevator and then too much as reactive response,
or from a really fast downwind dive. Anyway, it seems that the airplane
got slower – for whatever reason – from the point on when I
realized that it was behind the line of trees and too low already.
This diagram is similar to the second statistical data diagram in the
previous article above, especially
in that it shows the last thermal circles, the turn back to the field, the
fast descent, and the tree-landing. It does not show remaining battery charge
but instead air speed, (GPS) ground speed (both in km/h), and the variometer
(climb/sink rate in m/s). The two speeds are most interesting here; the other
values are shown to have the context, and the variometer is just for information.
There are several fluctuations in both speed lines. In the diagram's left
part are two synchronous "waves" (at 18:37 and 18:47, respectively)
where (red) air speed is considerably higher than (blue) ground speed (by
7 km/h or even 15 km/h, respectively). The opposed (pink) altitude
fluctuations indicate that this is an upwind part of the flight that was
flown in waves by me. Even though altitude is overall increasing, this is
not the first part of the path shown in the previous picture, which goes
upwards in downwind direction.
Rather this part corresponds to the following, gradient part of the (pink)
altitude line (from about 18:56 to 19:08) in the diagram. Both speed lines
have two peaks in this part (at 18:56 and 19:06, respectively) but now (blue)
ground speed is considerably higher than (red) air speed (by up to 18 km/h).
So this is a downwind part that has been flown in waves as well. Obviously,
the altitude fluctuations are exaggerated in the diagram because they are
compressed over the time axis. The flight path over ground hardly shows
any altitude fluctuations.
Most of the speed fluctuations are not synchronous but opposed. That indicates
turns or even circles with their upwind (air speed higher than ground speed)
and downwind (air speed lower than ground speed) parts as well as crosswind
points (speeds equal).
For instance, the following two (pink) altitude peaks (at 19:08 and 19:19,
respectively) indicate the two staggered circles shown in the flight path
above. Power (amperage, brown) was cut (at 19:18) right after the first
circle and the fast descent started even in the second circle (at 19:25).
The horizontal part (from 19:36 to 20:03) is actually a wide right turn
from upwind to crosswind, overlaid by altitude or sink rate fluctuations,
respectively. There are always corresponding speed fluctuations and all
these fluctuations continue for the rest of the flight.
The last high (blue) ground speed peak (at 20:41) indicates the last, fast
downwind leg. In the crosswind part of the wide final turn (at about 20:45),
(red) air speed is higher than before and after, and correspondingly sink
rate (green) is higher. Still air speed is rather constant compared to ground
speed, which is much lower in the final upwind leg (from about 20:50 to 21:01),
actually being a diagonal leg to southwest in westerly wind and ending up in
In the last four seconds of the flight, (blue) ground speed virtually drops
to zero while air speed drops to zero even faster but after one second jumps
up again to a sharp 18 km/h peak, just to drop to zero again.
That's not only hard to make out in the diagram, it's also hard to explain.
The last peak in amperage is synchronous so the air speed peak is possibly
an acceleration achieved with the rest of power the battery could yield.
That ground speed didn't peak anymore is perhaps due to the fact that the
airplane got over the tree top and was hit by the strong wind, maybe even
a gust, just in this moment.
This diagram demonstrates how GPS heading can help connecting a time-series
diagram to a Google Earth flight path picture.
At about 18:20 (left) the (blue) heading line starts at 335° (north-northwest),
then it decreases rapidly (left turn), rolls over from 0° to 360° (north),
and goes down to 220° (southwest) at 18:34. That was more than a full circle.
Then a nearly straight flight ends at 18:41 when a right turn starts (increasing
heading) that is shortly interrupted at 18:48 and continued at 18:51. It rolls
over at 18:56 and ends at 19:01 where a straight flight at heading 120°
This part of the flight is not visible in the detail flight path picture above.
The following 120° straight flight is the first visible part and it ends
at 19:05 where a left turn begins. This rolls over at 19:10, comes full-circle
to 120° at 19:17 (after 12 seconds), rolls over again at 19:21, comes
full-circle again at 19:29 (after another 12 seconds), rolls over again at
19:35, and stops at 19:39 (after 10 seconds) at 260° heading, 140°
before coming full-circle again. This are the (about) two and a half visible
circles which are blown eastwards by the wind and which are inclined northwards,
as indicated by the altitude fluctuations and shown in the flight path picture.
Just after coming full-circle for the first time, power had been cut at 19:18
and a steep and fast descent started, shown as yellow and even red line in the
picture above. When the circling stopped, the airplane was leveled off and a
long and wide right turn followed.
At 20:06 and just at northern heading, the turn was reversed to a left turn
into the wind and full flaps were set (the "kink" in the flight path).
That made for a quite steep descent maintained until the airplane landed in the
The initial left turn was interrupted by a quarter right turn and continued
until 20:40 to an easterly heading (75°). The "final approach" right
turn ends at 20:58 in the tree, where the heading line plummets from about
230° to zero, that is it ends here because motion stopped.
The flight's start and end in one picture, looking west into the wind. The
weird "triangle" on the runway is where I put the model down for
the checks before take-off. No take-off run is visible but the point of
take-off, just as in the previous section
(about the first incident). Their positions look correct, like it was in
reality. It just seems that the flight path is too low so the take-off
run is "underground" and hence not visible.
The "final approach" to the tree looks perfectly correct as well
when it comes to the path over ground. Even the tree's shape and its height
look correct, but the airplane's hitting point in the tree's crown is
definitely too low, as evidenced by the photos below. The model just didn't
fly into the tree's lee side but flew a bit over its top,
just to sink into the windward side of its crown. Sounds
crazy but that's what really happened.
In this view, the "final approach" is well visible including
its ending far too low in the tree's crown. Probably, the whole approach
is depicted too low but that's noticeable only in comparison to the tree.
By the way, the shade of the trees looks even correct, that is how it is
in early afternoon. That must be a happenstance, though, since there is
no time information in the location data.
The weird "tangle" at the tree's left side looks even correct
as well. It's obviously caused by the shaking experienced by the model during
the four hours spent in the tree. Perhaps the gusty wind moved it in all
directions, and the quite small movements are grossly exaggerated by the GPS.
Anyway, the center of all these movements seems to be the place in the tree's
crown where the model actually rested. At least all movements are on the tree's
windward side (left in the picture).
This picture shows even better that the tangle's center seems to be high
in the tree's crown where the model actually rested. Only when it was
retrieved, the path of motion got too low again, at about the same height
as the hitting point at the other side. The green line finally goes away
from the tree, horizontally to the left, and then down to the ground where
it ends. Actually, I got the model in my hands, about 1.5 meters
above ground level, but GPS antenna altitude shows it -6 meters
below ground level at this time. Most likely, the "underground"
part of the pathline is just clipped in Google Earth.
The airplane was retrieved from the tree by means of an articulated
boom lift. (Big thanks to the club-mate who did that for me!)
This picture shows especially well that there is a reasonable GPS pathline
as soon as there is some vectored and steady movement; it's just too low.
Once the club mate held the model in his hands he swiveled the boom
lift away from the tree and then down to the ground.
There, he handed the model over to me and I carried it back to the parking
area, where I switched off the receiver with telemetry.
What is shown as a field in this picture was a meadow at the time
of incident (and has been made a field again thereafter).
My driving instructor said (as far back as 50 years ago):
“You can't even think as silly as it comes.” He was right.
I could hardly believe what I saw: an airplane in the windward side of
a tree's crown, pointing outwards into the wind.
Conveniently, it wasn't blown out of the tree so it wasn't in danger of
plunging down, and it wasn't blown further into the tree, either.
The picture has been shot after the model had spent nearly four hours
in the tree, where it had been shaken by the gusty wind all the time.
(Many thanks also to the other club-mate who shot photos with his
Anyway, that shows that I wasn't dreaming when I saw the airplane scarcely
getting over the tree's top (or rather close beside it), then lowering
its nose, and finally sinking into the tree's windward side. After all,
I found out only later that it had lost power and therefore started a
steep descent (due to full flaps), which was made nearly vertical
by the strong headwind.
The tree without foliage is just visual proof of the fact that the airplane
did not fly through it. You can see as well that all twigs in the
crown's upper part are pointing slanted upwards – and are just thin
twigs, not thicker branches.
In the first place, this explains why there was not the slightest damage
on the airplane. In turn, this required that the model – nose first
– slowly sunk into the tree's crown where it was literally rescued
by these resilient twigs.
It rested with its wing's and stab's leading edges (sheeted D-tubes) on
the twigs and didn't even slip further into the crown.
Every attempt to push it out of the crown by means of a long rod (as usual
in such cases) would have made for damage – by the rod and by the
So the only way to retrieve it undamaged was to go up to it with an
articulated boom lift, grasp it under its sheeted wing roots, and heave
it out of the twigs.
After giving evidence of the fact that the airplane did not fly
into or even through the tree's crown, this diagram is an attempt to shed
some light upon the problem of false GPS altitude values. To this end, it
contrasts GPS antenna altitude with barometric (pressure) altitude. The
former is shown in the Google Earth flight path pictures while the latter
had been just displayed and logged during flight. The two respective axes
have been equally scaled and offset so that both lines begin at the same
level, which is – by definition – ground level for the former
and zero for the latter.
The time axis covers the whole logging time, about 4 hours and 11 minutes.
It starts with 1 minute and 40 seconds preparation for take-off till 1:40.
The actual flight lasted 19 minutes and 20 seconds till 21:00 when the
airplane landed in the tree. Then it spent nearly 4 hours in the tree
(3 hours and 45 minutes till about 4:06:00) until it was retrieved
and carried to the parking area (for about 4 minutes and 30 seconds)
where telemetry was switched off (at 4:10:32). So 90% of this time are taken
up by the stay in the tree, which is the most prominent center part in the
The jaggy (brown) GPS antenna altitude line corresponds to the weird
"tangle" on the tree in the Google Earth pictures. It varies
both short-waved and long-waved over time, but in the pictures above
it seems to be fairly correct on average. Still, in the end it seems
to be too low just like at the time of the tree landing. Anyway, when
the airplane is retrieved it goes from about +5 meters to
-6 meters below ground level. And even though it turns
upward during the walk to the parking area it's still -3 meters
in the end. The 8 meters difference between +5 and -3 meters
could be even the correct difference between the level in the tree
and ground level.
The (pink) barometric altitude line is not jaggy but stepped, what is
simply due to the 1 meter sensor resolution. At the time of the
tree landing this altitude is +13 meters, but during the
3 hours and 45 minutes stay in the tree it slopes upwards to
+24 meters, perhaps due to an air pressure drop. When the airplane
is finally retrieved, the line steps down by about 7 meters to
+17 meters above ground level. The step could be even
correct (compare photo above), but final altitude should be actually
close to zero and subtracting the 11 meters drift would still give
+6 meters above ground level. If there was an air pressure
drop even during the flight, though, the barometric altitude could be
actually correct in the end. After all, only 1 hPa drop would mean
even 8 meters more. Anyway, at least the line stays level during
the walk to the parking area.
Since comparing both altitudes over the whole time was not very insightful,
here they are compared over the actual flight including its prelude and
postlude. Most striking is that barometric altitude is lower than GPS
altitude for most of the flight, but it creeps up on it and finally it's
The previous diagram suggests that there was an air pressure drop, which
was more pronounced in the first half of the time and then degressive. At
least that would explain why barometric altitude picks up this much during
the actual flight.
According to the timestamps in the smartphone pictures, the model was
retrieved and switched off at 17:00 (5pm) so it had been switched on
at about 12:50 (ten minutes to 1pm). In this time a nearby
weather station recorded an air pressure drop from
969.1 hPa to 967.8 hPa (see red line in the
This 1.3 hPa drop is equivalent to a 10.4 meters rise of
barometric altitude, what is not even equal to the 11 meters drift
after the flight, and there must have been 6 meters drift
even during the flight.
The air pressure line in the weather chart hasn't the same curve shape
as the barometric altitude line, either.
At least the 10.4 meters drift due to air pressure change are for
sure and amount to even 60% of the 17 meters excess altitude at the
end of the whole time.
There could have been a temperature drift as well; after all there was a
1.7°C rise from 26.6°C to 28.3°C at the weather station (see
blue line in the
Or the sensor could have been warm from sunshine before takeoff and cooled
down during the flight.
Whatever, I have no idea how temperature could affect barometric altitude.
It's even possible that the pressure sensor has some
hysteresis, but again I have no idea.
It seems that 6.6 meters, 40% of the excess altitude, will remain
Still there is another striking aspect: At take-off and "landing",
barometric pressure drops noticeably for a short time.
That is most pronounced during the take-off run when the airplane gets
faster but is still on the ground. After take-off, barometric altitude
rises parallel to GPS altitude but offset by the prior drop.
Before the tree landing, altitude drop is natural but it is shortly halted
when air speed drops to zero. Synchronous to the following short peak of
air speed, altitude drops again but goes finally up immediately thereafter.
It looks like barometric altitude is interrelated with air speed.
The speed-to-altitude interrelation is more easily seen in this detail
diagram showing the flight's final 162 seconds.
There is no single part of both altitude lines where they are level.
Even if altitude is constant on average there are always some fluctuations.
Yet barometric altitude differs from GPS altitude not only by the initial
drop, or shift for that matter.
If air speed is higher the difference is bigger and vice versa.
That is not always true, though. We can't just assume that GPS altitude
is always correct. We already know that it drifts as well and that it
has pronounced fluctuations when the airplane is not in continuous
motion. Now we have to expect some fluctuations in flight as well.
Yet the connection between high airspeed and too low barometric
altitude seems to be obvious, especially during the take-off run.
And then there must be a connection during the rest of the flight
as well, at least to some noticeable extent.
Aberrated from Truth
That's what the GPS obviously does all the time during flight, that is
the calculated altitude is sometimes higher but mostly lower than the
airplane's true altitude. That holds for the "antenna altitude"
(AMSL) as well as the indicated
altitude (AGL), which is set to
zero when telemetry including the GPS is powered up. Immediately after
calibration (when enough satellites are found) it starts drifting.
This is visible in parts of flights where the airplane was close to the
ground or even on the ground like on the runway. Google Earth pictures
make it especially obvious then in that the flight's pathline is actually
running underground and is clipped therefore.
The statistical data diagrams show negative indicated altitudes and
corresponding antenna altitudes lower than the initial position.
But there must be variations and drift also in the other (higher) parts
of a flight. There is no strict evidence for this but comparisons with
barometric altitude suggest it.
The GPS device sends 3D location data records to the telemetry sensor bus
(MSB). They are formatted as
GGA sentences conforming to the
definition. Obviously, it specifies mandatory as well as optional
data fields. In this case, only the basic location data are present
in the messages, which are logged twice a second. Maybe they chose
to keep the record length to a minimum in order to reduce bus load.
However, only minimum data are available for later analysis in the
course of incident investigation:
This is a sample record from the second flight analyzed above.
It starts with the tag ($GPGGA) but omits the time of
position fix (between the following two commas). Northern latitude
(4826.77975,N) and eastern longitude (01091.34132,E)
as well as altitude in meters (679.423,M) are the actual
content of the message. The last field (*0E) is a checksum
and all other fields are void.
Especially the omission of
"geoid separation" could be
significant in our case. The source linked above tells about the
GGA sentence: “If the height of geoid is
missing then the altitude should be suspect.” I couldn't say
it any better since the logged data look really suspect, regardless
of the reason why.
The source also tells: “This is the only sentence that reports
altitude.” So this is the correct and only type of sentence to
have 3D (not only 2D) location data and omitting geoid height is sort
of a "flaw".
The time of position fix is missing as well, and that is another
"flaw". There is no way to literally synchronize Google
Earth flight path pictures and LogView data diagrams. The only
timing information available is the cadence of ten telemetry records
per second, which is used to include a timing field in each data
record (formatted as seconds.hundredths). It is counted as relative
time from zero on and shown on a LogView diagram's horizontal axis.
Hence, fairly connecting a three-dimensional flight path with a
time-linear data diagram is possible only by including GPS heading
(and maybe altitude) data in the diagram, what requires logging it
during flight as well.
Google Earth would need absolute time and date timestamps in the
imported KML records. While LogView calculates horizontal and vertical
speeds for color-coding of the flight path line, it does not even
include the second-count, which is shown on the diagram time-axes,
in the exported KML records. Google Earth could at least show this
timeline on the flight path line. If it had the full date and time
of day, it could (technically) even show correct tree shades according
to daytime and season (but I don't know if it actually could).
By the way, this is all the same with the "new" version 2
GPS by Multiplex. They just gave it better hardware, that is a
multidirectional internal antenna and a new GPS processor. The
displayed values and the logged records are exactly the same as
from version 1.
A barometric sensor for altitude and air speed is not better than
a GPS, either. Rather it has its own problems and aberrations, which
seem to be even bigger than those of a GPS. Drift due to changes in air
pressure and temperature is not one of them under normal conditions,
that is with usual flight times of about 20 minutes.
But somehow static pressure (for altitude) rises as well when dynamic
pressure (for speed) rises. That makes for lower indicated altitudes
than in standstill on the ground and generally for altitudes the lower
the higher air speed is.
Possibly that comes from mounting the sensor's pitot-static tube under
the wing, but there's no better place for it on my Senior Telemaster
And barometric data can't be used to generate location data for Google
Was of Some Help
That's what the GPS was for me when I investigated ill-fated flights,
or incidents for that matter, so here are my conclusions:
Does a GPS help investigating ill-fated flights and incidents?
Sure it does, especially because it allows to show intuitive three-dimensional
flight path pictures from any viewing angle. That's a valuable complement
to more abstract statistical data (time series) diagrams and helps
Is the GPS accurate enough for this purpose?
Accuracy of the flight path over ground is beyond my expectations. Just
flight altitude is not quite as accurate. It fluctuates and drifts by a
few meters but is still good enough to show a flight path that makes
sense if seen with due care.
Would a barometric altimeter be a substitute?
Surely not because it fluctuates and drifts even more, just differently.
Then again, to have both (complementing) wouldn't hurt, either. Sometimes
it's value is better than the GPS's, and then it's the other way around.
Is a GPS really needed to clear up how incidents occured?
Of course I would try to clear up an incident even if I had no logged
GPS data – in a pinch. It would be much harder, though. Then I
would regret to have denied myself a GPS, and that's why I have one.
It would be easier to do without a GPS if there would be a way to log
servo movements. Especially the power settings (on the ESC’s
channel) would be badly needed to clear up doubts about what really
happened, sometimes elevator movements as well. There is just no way.
Of course, I have a GPS only in my big and complex and expensive
models; otherwise it would be overkill.