On Sun, 31 May 2015 16:18:10 +0200, pcool wrote:

Very interesting view, Andy!
But, can a Flarm cpu do this? My doubts come from the fact that the
calculation engine in my flight software takes about 25ms every second
on a 400mhz ARM cpu. For flight path estimation, some of those
calculations would be necessary too. A very conservative estimation
would be 20% of 25ms, needed by flarm too. So let's say 5ms, but on 8mhz
(50 times slower). That means 250ms.
The available time slot is 1000ms but it cannot be used entirely,
because the data must be transmitted and received within the timeslot
itself.
So using the same thumb rule, I would say 250ms out of 750ms are used
for calc, leaving 500ms for the rest.
The "rest" being dealing with the gps, receiving data from the radio,
processing data and compare for each data the collisions. outputting
NMEA to serial port if needed, recording the flight, managing the leds
etc.
And we must consider that the ATmel 128 cpu has no floating point, no
math, and even a sin() and cos() function are made from scratch in C
language by the cross compiler.
This is why, although "thumb ruled", I cannot thing that a cone like
yours is in use, but something much more simpler.
Because there is no time to do things like you say, I believe.
What do you think?

"Andy Blackburn" wrote in message
...

I don't know exactly how the Flarm guys do their math to project a
flight path, but I think of it as a cone with it's point at the glider
and it's wide end 15 seconds ahead of the glider. The cone can be
straight or curved and the cone's centerline defines the overall
curvature, which can be defined by a number of factors, but for
simplicity's sake lets say that it is a circle based on the last three
datapoints (it could be any kind of mathematical curve). If the glider
is flying straight, the circle has an infinite radius (a straight line).
If the glider is thermaling the circle has a radius of a few hundred
feet.

Now imagine the pilot of the glider has decided that instead of
thermalling to the left he wants to thermal to the right because he
thinks the core is not at the center of the left hand turn but rather at
the center of the new right hand turn he wants to establish.. He puts
the stick over to the right and the glider starts to roll. The bank
shallows, passes through wings level and eventually settles in a steady
right hand turn. From start to finish it takes around 10 seconds. What
happens to the projection of his future flight path? As his circle
widens the projection widens until it is straight out in front of him
and then starts curving to the right until it is a cone curved to the
right in a circular arc with a radius of several hundred feet (whatever
his turn radius is.

It is true that because no instrument can read the pilot's mind you
cannot predict that the point 15 second ahead of the glider will flip
from being on a left hand circular arc to a right hand circular arc, but
that projected point and any given moment is the BEST ESTIMATE of where
the glider is headed and as the wide end of the cone arcs through
straight ahead the edge of the cone will intersect any paths on that new
circle. It won't be a 15 second warning, more like 7-10 seconds
depending on how much the cone widens. There is no algorithm or system
that will read the mind of the pilot before he even knows his mind, but
the Flarm approach certain warns you of a glider heading your way as
soon as it is in fact heading your way - that's what we want it to do.

You can be more conservative and set the warning to alert for any glider
that is close enough to hit you based on the maximum possible closure
rate -
assuming both pilots turn aggressively to go exactly head to head. This
would require a warning for any glider within a mile to a mile and a
half (assuming 300 knot closure rate). Also assume the other glider is
in a 25 knot thermal or 25 knots of sink and you are in the opposite to
take a worst case scenario. Anyone plus or minus about 1200 feet and
within a mile to a mile and a half distance should generate a warning.
That is the warning volume to be 99.9999% sure that no matter what you
do or the other pilot does you will be warned at least 15 seconds from
possible impact. Oh, except if the higher glider has speed brakes out,
then you need more like a +/- 2500 foot warning height band.

Without some assumption on projected path, collision warning turns into
a traffic alert system if you want 100% certain that no matter what
either pilot does you will be warned at least 15 seconds ahead of time.
Getting continuous warnings on dozens of glider all the time defeat the
purpose I'd like to see served in a collision warning system - that it
only warns you when a collision is a real possibility, not a 0.0001%
chance that I would get warned about a few seconds later anyway if the
worst case circumstances in terms of pilot maneuvering actually came to
pass.

If that's what this has been about, it is kind of silly and academic.
You should only give warning on things that are pretty likely to happen
- or like the boy who cried wolf, people will stop listening to you.

I see what you're getting at, but I know what I've done using a Parallax
BS2 STAMP that was running a 'compiled', i.e. probably P-coded, integer
BASIC to do some simple time-critical calculations while driving an RC
servo and scanning a pair of switches.

I also remember just what we managed to get a smallish mainframe to do
back in the early 70s with its 1.5 uS (666 Khz) cycle time.

I don't know the Atmel at all, but if it can use interrupts for i/o
handling rather than dimly waiting for each byte to dribble in from its
serial ports then the position might look a bit better than you seem to
think it is.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |