Position Recorders, Accuracy, and Badge altitude gains

On May 29, 6:45*am, Tony wrote:
On Monday, May 28, 2012 1:59:19 PM UTC-5, uros wrote:
I have checked both flights and for the first flight it seems to me
that the flight recorder was turned on too late. Every GPS needs some
time to find correct position and when the GPS is moving this time is
even longer. The correct procedure is to turn on the GPS few minutes
before the flight so that GPS could correctly find first position and
will start recording correctly. These jumps could be easily detected
and the recording would be cut off.

Sure I know that you should turn it on on the ground but I forgot. *And with turning it on in flight of course it will take a little time to "find itself". *However why on earth doesn't it wait until it has found itself to start recording fixes? *And even then, why was it recording fixes over 2000 ft too high if it had found itself?

The bottom line is probably "it shouldn't". That it isn't reporting a
non-valid 3D fix is troublesome...
My GPS knowledge is quite dated, but doesn't it take something like 12
minutes to get an ephemeris (or was it almanac?) download? Fifteen+
years ago, we would not launch a unit until we confirmed a 3D fix, and
that OFTEN took 12 minutes.

On Tuesday, May 29, 2012 10:52:09 AM UTC-4, Grider Pirate wrote:
On May 29, 6:45*am, Tony wrote:
On Monday, May 28, 2012 1:59:19 PM UTC-5, uros wrote:
I have checked both flights and for the first flight it seems to me
that the flight recorder was turned on too late. Every GPS needs some
time to find correct position and when the GPS is moving this time is
even longer. The correct procedure is to turn on the GPS few minutes
before the flight so that GPS could correctly find first position and
will start recording correctly. These jumps could be easily detected
and the recording would be cut off.

Sure I know that you should turn it on on the ground but I forgot. *And with turning it on in flight of course it will take a little time to "find itself". *However why on earth doesn't it wait until it has found itself to start recording fixes? *And even then, why was it recording fixes over 2000 ft too high if it had found itself?

The bottom line is probably "it shouldn't". That it isn't reporting a
non-valid 3D fix is troublesome...
My GPS knowledge is quite dated, but doesn't it take something like 12
minutes to get an ephemeris (or was it almanac?) download? Fifteen+
years ago, we would not launch a unit until we confirmed a 3D fix, and
that OFTEN took 12 minutes.

The almanac takes 12.5 min to transmit, but each satellite will transmit its own full ephemeris and other info every 90 seconds. Most new receivers have flash memory that saves the almanac though so they can usually get a fix in under 30 seconds (as quick as a second or two if they were powered down for only a few minutes). The other big change that allows modern gps get rapid fixes is the number of channels they have - in steady operation having 50 channels does no good, but when booting up multiple channels can be trying to get a fix on a satellite which makes the time to first fix a lot faster.

I'm not sure what gps engine the CE uses (or how it is set up internally), but it would have to check more than one message from the gps to get a full picture of the quality of a fix, the standard NMEA messages have a data valid/invalid flag, but don't appear to distinguish there what type of fix is being delivered, it takes a separate flag in another message to determine that.

That said, I can't quite wrap my head around whether the 2d/3d issue could be causing what Steve saw, a 2d fix should pin the altitude to the geoid (which ought to be pretty close to ground level - it's about 475m at sunflower). If for some reason it didn't have a very good view of the sky overhead then it could be just an issue of only using satellites near the horizon (in which case the gps altitude would be pretty poor quality).

On Tuesday, May 29, 2012 9:16:26 AM UTC-7, jjbird wrote:
On Tuesday, May 29, 2012 10:52:09 AM UTC-4, Grider Pirate wrote:
On May 29, 6:45*am, Tony wrote:
On Monday, May 28, 2012 1:59:19 PM UTC-5, uros wrote:
I have checked both flights and for the first flight it seems to me
that the flight recorder was turned on too late. Every GPS needs some
time to find correct position and when the GPS is moving this time is
even longer. The correct procedure is to turn on the GPS few minutes
before the flight so that GPS could correctly find first position and
will start recording correctly. These jumps could be easily detected
and the recording would be cut off.

Sure I know that you should turn it on on the ground but I forgot. *And with turning it on in flight of course it will take a little time to "find itself". *However why on earth doesn't it wait until it has found itself to start recording fixes? *And even then, why was it recording fixes over 2000 ft too high if it had found itself?

The bottom line is probably "it shouldn't". That it isn't reporting a
non-valid 3D fix is troublesome...
My GPS knowledge is quite dated, but doesn't it take something like 12
minutes to get an ephemeris (or was it almanac?) download? Fifteen+
years ago, we would not launch a unit until we confirmed a 3D fix, and
that OFTEN took 12 minutes.

The almanac takes 12.5 min to transmit, but each satellite will transmit its own full ephemeris and other info every 90 seconds. Most new receivers have flash memory that saves the almanac though so they can usually get a fix in under 30 seconds (as quick as a second or two if they were powered down for only a few minutes). The other big change that allows modern gps get rapid fixes is the number of channels they have - in steady operation having 50 channels does no good, but when booting up multiple channels can be trying to get a fix on a satellite which makes the time to first fix a lot faster.

I'm not sure what gps engine the CE uses (or how it is set up internally), but it would have to check more than one message from the gps to get a full picture of the quality of a fix, the standard NMEA messages have a data valid/invalid flag, but don't appear to distinguish there what type of fix is being delivered, it takes a separate flag in another message to determine that.

That said, I can't quite wrap my head around whether the 2d/3d issue could be causing what Steve saw, a 2d fix should pin the altitude to the geoid (which ought to be pretty close to ground level - it's about 475m at sunflower). If for some reason it didn't have a very good view of the sky overhead then it could be just an issue of only using satellites near the horizon (in which case the gps altitude would be pretty poor quality).

The chipsets used in these devices are more than simple GPS receivers, an for example what altitude a 2D fix provides is often very much up to the chipset. For example the SiFR III chipset used in the FR100 provides settings that will generate 2D fixes with extrapolated or software provided altitude data, varies wether the chipset provides 2D data when 3D is not available, etc. etc. (e.g. look up (altitude hold, altitude source, degraded mode, in the SiRF documentation). I'm not at all familiar with the chipset in the newer FR300. But we've got reports here of strange altitude behavior with both an FR100 and an FR300. I have **no idea** what is going on, but if I was looking at this seriously I would want to know all the chipset firmware settings. Basically I don't see any way a NAC or the IGC could/should ever approve a position recorders without knowing the full chipset firmware settings (and verify them and have a way to verify in future updates/revisions), and possibly for the purposes of transparency/disclosure it make sense to publish those setting in the approval documents in future. Maybe Uros might want to shorten this conversation and just make those firmware settings public.

Again I want to point out I have no idea what is going on here, just these chipsets really need to be understood by the approving bodies. My understanding is for position recorders that is now really the NACs not the IGC itself. I am not sure if the NACs to have the technical resources/skill level to tackle this type of thing--it would be great to be wrong here.

Darryl

On Sunday, May 27, 2012 4:44:25 PM UTC-4, Tony wrote:
Leah and I are down here at Chilhowee for a VSA rally and had an enjoyable flight in the Ka7 today attempting a silver altitude gain for the highly sought after VSA Silver Coin. Unfortunately by the time we were hot, tired, hungry, in pain, and had to pee we hadn't quite made the gain. I found the trace for my FlywithCE interesting though. We released about 2400 MSL and I soon remembered that I hadn't turned on the FlywithCE. So I turned it on at about 3000 I think. Check out the trace: http://www.onlinecontest.org/olc-2.0...l?dsId=2421969

It seems that the FlywithCE was trying to insist that I had started on the ground, then realized that wasn't right, and attempted to correct for it by jumping the altitude up about 3000 feet. If it had just recorded the actual altitude it would've been fine. I would've had a trace starting in mid-air, right where I turned on the recorder.

The IGC decided that position recorders like the FlywithCE will be allowed for Silver and Gold altitude gain after this fall. Would I be able to claim this obviously bogus trace for Silver Altitude? (evil grin). I suspect this is a problem associated with not turning the thing on until mid flight but dang shouldn't it just record what the actual position is???

When your observer goes to fill out the badge application, he or she has to make some statements as to how the flight log was controlled. It would seem reasonable to expect this might include noting that the logger was not only properly installed, but on.
Try again Tony
UH

On Tuesday, May 29, 2012 2:52:24 PM UTC-5, wrote:
On Sunday, May 27, 2012 4:44:25 PM UTC-4, Tony wrote:
Leah and I are down here at Chilhowee for a VSA rally and had an enjoyable flight in the Ka7 today attempting a silver altitude gain for the highly sought after VSA Silver Coin. Unfortunately by the time we were hot, tired, hungry, in pain, and had to pee we hadn't quite made the gain. I found the trace for my FlywithCE interesting though. We released about 2400 MSL and I soon remembered that I hadn't turned on the FlywithCE. So I turned it on at about 3000 I think. Check out the trace: http://www.onlinecontest..org/olc-2....l?dsId=2421969

It seems that the FlywithCE was trying to insist that I had started on the ground, then realized that wasn't right, and attempted to correct for it by jumping the altitude up about 3000 feet. If it had just recorded the actual altitude it would've been fine. I would've had a trace starting in mid-air, right where I turned on the recorder.

The IGC decided that position recorders like the FlywithCE will be allowed for Silver and Gold altitude gain after this fall. Would I be able to claim this obviously bogus trace for Silver Altitude? (evil grin). I suspect this is a problem associated with not turning the thing on until mid flight but dang shouldn't it just record what the actual position is???

When your observer goes to fill out the badge application, he or she has to make some statements as to how the flight log was controlled. It would seem reasonable to expect this might include noting that the logger was not only properly installed, but on.
Try again Tony
UH

Hank,

Not sure if it wasn't clear in the original post but I wasn't attempting an actual badge flight on this flight. Of course on an official badge flight the OO would ensure the logger is turned on before takeoff. And of course any official claim would be denied if the logger wasn't turned on before takeoff. I'm just trying to understand why the logger made this wacky error, and it seems to me that being turned on after takeoff shouldn't be a valid reason for that.

On Tuesday, May 29, 2012 12:52:24 PM UTC-7, wrote:
On Sunday, May 27, 2012 4:44:25 PM UTC-4, Tony wrote:
Leah and I are down here at Chilhowee for a VSA rally and had an enjoyable flight in the Ka7 today attempting a silver altitude gain for the highly sought after VSA Silver Coin. Unfortunately by the time we were hot, tired, hungry, in pain, and had to pee we hadn't quite made the gain. I found the trace for my FlywithCE interesting though. We released about 2400 MSL and I soon remembered that I hadn't turned on the FlywithCE. So I turned it on at about 3000 I think. Check out the trace: http://www.onlinecontest..org/olc-2....l?dsId=2421969

It seems that the FlywithCE was trying to insist that I had started on the ground, then realized that wasn't right, and attempted to correct for it by jumping the altitude up about 3000 feet. If it had just recorded the actual altitude it would've been fine. I would've had a trace starting in mid-air, right where I turned on the recorder.

The IGC decided that position recorders like the FlywithCE will be allowed for Silver and Gold altitude gain after this fall. Would I be able to claim this obviously bogus trace for Silver Altitude? (evil grin). I suspect this is a problem associated with not turning the thing on until mid flight but dang shouldn't it just record what the actual position is???

When your observer goes to fill out the badge application, he or she has to make some statements as to how the flight log was controlled. It would seem reasonable to expect this might include noting that the logger was not only properly installed, but on.
Try again Tony
UH

It might seem reasonable to expect official observes to do lots of things. But there is no requirement AFAIK for the OO to report anything except that they observed the flight, even when required to do things like seal a particular model of flight recorder to the cockpit I suspect many badges have been approved where it is assumed the OO did things that they did not. At least with the current SSA OO worksheet the OO gets to check a box they either sealed the flight recorder to the aircraft or observed the aircraft after landing. Nowhere on that SSA form is there any mention of the flight recorder being powered on or a place for the OO to note that the flight recorder is powered on/operating before flight.

There is no requirement in anything I can recall in the sporting code, pilot & OO guide or any flight recorder or position recorder document that requires (or even suggests) the OO note that the flight recorder is powered on before flight. And in practice from most of the badge and record flights I've seen the turning the device on before the flight has been left to the pilot. And just being on may not be enough. An OO would ideally need to note that the device has acquired a 3D fix or or has been on long enough to be expected to acquire a 3D fix.

Not all of these devices provide the pilot/OO with a way to determine if a 3D fix is being correctly received, and for some devices with a slow cold start (e.g. if the receiver has been powered off a long time and/or moved a long distance while off) and/or poor antenna location this might take significantly longer than folks are expecting. And without that indicator if there was a non-obvious antenna problem the OO might assume things are fine, and if the devices then (as might be the case here) report invalid 3D fixes as if they were valid then there may be no way to work out the data in invalid. This really seems to be a technical issue that deserves investigation, not something that hoping that human (OO) procedures can or should somehow paper over. If I'm missing any relevant rules or guidance here please let me know.

Darryl

On 29 maj, 19:03, Darryl Ramm wrote:
On Tuesday, May 29, 2012 9:16:26 AM UTC-7, jjbird wrote:
On Tuesday, May 29, 2012 10:52:09 AM UTC-4, Grider Pirate wrote:
On May 29, 6:45*am, Tony wrote:
On Monday, May 28, 2012 1:59:19 PM UTC-5, uros wrote:
I have checked both flights and for the first flight it seems to me
that the flight recorder was turned on too late. Every GPS needs some
time to find correct position and when the GPS is moving this time is
even longer. The correct procedure is to turn on the GPS few minutes
before the flight so that GPS could correctly find first position and
will start recording correctly. These jumps could be easily detected
and the recording would be cut off.

Sure I know that you should turn it on on the ground but I forgot. *And with turning it on in flight of course it will take a little time to "find itself". *However why on earth doesn't it wait until it has found itself to start recording fixes? *And even then, why was it recording fixes over 2000 ft too high if it had found itself?

The bottom line is probably "it shouldn't". *That it isn't reporting a
non-valid 3D fix is troublesome...
My GPS knowledge is quite dated, but doesn't it take something like 12
minutes to get an ephemeris (or was it almanac?) download? Fifteen+
years ago, we would not launch a unit until we confirmed a 3D fix, and
that OFTEN took 12 minutes.

The almanac takes 12.5 min to transmit, but each satellite will transmit its own full ephemeris and other info every 90 seconds. Most new receivers have flash memory that saves the almanac though so they can usually get a fix in under 30 seconds (as quick as a second or two if they were powered down for only a few minutes). The other big change that allows modern gps get rapid fixes is the number of channels they have - in steady operation having 50 channels does no good, but when booting up multiple channels can be trying to get a fix on a satellite which makes the time to first fix a lot faster.

I'm not sure what gps engine the CE uses (or how it is set up internally), but it would have to check more than one message from the gps to get a full picture of the quality of a fix, the standard NMEA messages have a data valid/invalid flag, but don't appear to distinguish there what type of fix is being delivered, it takes a separate flag in another message to determine that.

That said, I can't quite wrap my head around whether the 2d/3d issue could be causing what Steve saw, a 2d fix should pin the altitude to the geoid (which ought to be pretty close to ground level - it's about 475m at sunflower). If for some reason it didn't have a very good view of the sky overhead then it could be just an issue of only using satellites near the horizon (in which case the gps altitude would be pretty poor quality).

The chipsets used in these devices are more than simple GPS receivers, an for example what altitude a 2D fix provides is often very much up to the chipset. For example the SiFR III chipset used in the FR100 provides settings that will generate 2D fixes with extrapolated or software provided altitude data, varies wether the chipset provides 2D data when 3D is not available, etc. etc. (e.g. look up (altitude hold, altitude source, degraded mode, in the SiRF documentation). I'm not at all familiar with the chipset in the newer FR300. But we've got reports here of strange altitude behavior with both an FR100 and an FR300. I have **no idea** what is going on, but if I was looking at this seriously I would want to know all the chipset firmware settings. Basically I don't see any way a NAC or the IGC could/should ever approve a position recorders without knowing the full chipset firmware settings (and verify them and have a way to verify in future updates/revisions), and possibly for the purposes of transparency/disclosure it make sense to publish those setting in the approval documents in future. Maybe Uros might want to shorten this conversation and just make those firmware settings public.

Again I want to point out I have no idea what is going on here, just these *chipsets really need to be understood by the approving bodies. My understanding is for position recorders that is now really the NACs not the IGC itself. I am not sure if the NACs to have the technical resources/skill level to tackle this type of thing--it would be great to be wrong here.

Darryl

I do not hide that I am using the consumer electronics device. The
firmware is implemented by the device manufacturer. They only
implemented few changes so that I can implement some of the flight
recorder features. The chipset inside FR300 is SKYTRAQ and which is
listed on my page http://www.flywithce.com/recorder300.html.

All device manufacturers are using standard chipsets (or even more –
standard modules). I have not heard that anyone would implement
changes to position calculation. So even if you would spend few
hundred EUR more there is no guarantee that GPS altitude would have
perfect altitude (bonus there is that you have pressure altitude).

And consumer electronics device is the main reason why the device can
cost 89 EUR instead 500 EUR like any other fully certified (and
purpose built) flight recorder. I believe that this is great device
which is very simple to use and very affordable.

Best regards

Uros
www.flywithce.com

At 06:52 30 May 2012, uros wrote:
On 29 maj, 19:03, Darryl Ramm wrote:
On Tuesday, May 29, 2012 9:16:26 AM UTC-7,
jjbird wrote:
On Tuesday, May 29, 2012 10:52:09 AM UTC-4,
Grider Pirate wrote:
On May 29, 6:45=A0am, Tony wrote:
On Monday, May 28, 2012 1:59:19 PM
UTC-5, uros wrote:
I have checked both flights and for the
first flight it seems to
=
me
that the flight recorder was turned on too
late. Every GPS needs
=
some
time to find correct position and when
the GPS is moving this
tim=
e is
even longer. The correct procedure is to
turn on the GPS few
minu=
tes
before the flight so that GPS could
correctly find first
position=
and
will start recording correctly. These
jumps could be easily
detec=
ted
and the recording would be cut off.

Sure I know that you should turn it on on
the ground but I forgot.
=
=A0And with turning it on in flight of course it will
take a little time
to=
"find itself". =A0However why on earth doesn't it
wait until it has found
=
itself to start recording fixes? =A0And even then,
why was it recording
fix=
es over 2000 ft too high if it had found itself?

The bottom line is probably "it shouldn't".
=A0That it isn't
reportin=
g a
non-valid 3D fix is troublesome...
My GPS knowledge is quite dated, but doesn't
it take something like
1=
2
minutes to get an ephemeris (or was it
almanac?) download? Fifteen+
years ago, we would not launch a unit until
we confirmed a 3D fix,
an=
d
that OFTEN took 12 minutes.

The almanac takes 12.5 min to transmit, but
each satellite will
transmi=
t its own full ephemeris and other info every 90
seconds. Most new
receiver=
s have flash memory that saves the almanac though
so they can usually get
a=
fix in under 30 seconds (as quick as a second or
two if they were powered
=
down for only a few minutes). The other big change
that allows modern gps
g=
et rapid fixes is the number of channels they have -
in steady operation
ha=
ving 50 channels does no good, but when booting up
multiple channels can
be=
trying to get a fix on a satellite which makes the
time to first fix a
lot=
faster.

I'm not sure what gps engine the CE uses (or
how it is set up
internall=
y), but it would have to check more than one
message from the gps to get a
=
full picture of the quality of a fix, the standard NMEA
messages have a
dat=
a valid/invalid flag, but don't appear to distinguish
there what type of
fi=
x is being delivered, it takes a separate flag in
another message to
determ=
ine that.

That said, I can't quite wrap my head around
whether the 2d/3d issue
co=
uld be causing what Steve saw, a 2d fix should pin
the altitude to the
geoi=
d (which ought to be pretty close to ground level -
it's about 475m at
sunf=
lower). If for some reason it didn't have a very
good view of the sky
overh=
ead then it could be just an issue of only using
satellites near the
horizo=
n (in which case the gps altitude would be pretty
poor quality).

The chipsets used in these devices are more than
simple GPS receivers,
an=
for example what altitude a 2D fix provides is often
very much up to the
c=
hipset. For example the SiFR III chipset used in the
FR100 provides
setting=
s that will generate 2D fixes with extrapolated or
software provided
altitu=
de data, varies wether the chipset provides 2D data
when 3D is not
availabl=
e, etc. etc. (e.g. look up (altitude hold, altitude
source, degraded mode,
=
in the SiRF documentation). I'm not at all familiar
with the chipset in
the=
newer FR300. But we've got reports here of strange
altitude behavior with
=
both an FR100 and an FR300. I have **no idea**
what is going on, but if I
w=
as looking at this seriously I would want to know all
the chipset firmware
=
settings. Basically I don't see any way a NAC or the
IGC could/should ever
=
approve a position recorders without knowing the
full chipset firmware
sett=
ings (and verify them and have a way to verify in
future
updates/revisions)=
, and possibly for the purposes of
transparency/disclosure it make sense
to=
publish those setting in the approval documents in
future. Maybe Uros
migh=
t want to shorten this conversation and just make
those firmware settings
p=
ublic.

Again I want to point out I have no idea what is
going on here, just
thes=
e =A0chipsets really need to be understood by the
approving bodies. My
unde=
rstanding is for position recorders that is now really
the NACs not the
IGC=
itself. I am not sure if the NACs to have the
technical resources/skill
le=
vel to tackle this type of thing--it would be great to
be wrong here.

Darryl

I do not hide that I am using the consumer
electronics device. The
firmware is implemented by the device
manufacturer. They only
implemented few changes so that I can implement
some of the flight
recorder features. The chipset inside FR300 is
SKYTRAQ and which is
listed on my page
http://www.flywithce.com/recorder300.html.

All device manufacturers are using standard
chipsets (or even more =96
standard modules). I have not heard that anyone
would implement
changes to position calculation. So even if you
would spend few
hundred EUR more there is no guarantee that GPS
altitude would have
perfect altitude (bonus there is that you have
pressure altitude).

And consumer electronics device is the main reason
why the device can
cost 89 EUR instead 500 EUR like any other fully
certified (and
purpose built) flight recorder. I believe that this is
great device
which is very simple to use and very affordable.

Best regards

Uros
www.flywithce.com

Couple of points worth mentioning here. First, the
SSA approval for flywithce appears only to accept
GPS altitude for verifying flight continuity- a seperate
pressure device is required for height claims.

Second- not all consumer GPS chipsets are equal.
It's interesting that the BGA have withdrawn approval
for the Oudie as a position recorder because the Atlas
V chipset in the new, bright, version, is optimised for
use in motor vehicles, and has track smoothing built
in. This can give significant position errors whenever
you do something (like a tight turn just before an
observation zone) which you couldn't do in a car.

There's been a bit of correspondence about this in the
LK8000 forum, and the expert view there is there's no
way round this.

On Wednesday, May 30, 2012 7:09:30 AM UTC-4, Richard Brisbourne wrote:

Couple of points worth mentioning here. First, the
SSA approval for flywithce appears only to accept
GPS altitude for verifying flight continuity- a seperate
pressure device is required for height claims.

Second- not all consumer GPS chipsets are equal.
It's interesting that the BGA have withdrawn approval
for the Oudie as a position recorder because the Atlas
V chipset in the new, bright, version, is optimised for
use in motor vehicles, and has track smoothing built
in. This can give significant position errors whenever
you do something (like a tight turn just before an
observation zone) which you couldn't do in a car.

There's been a bit of correspondence about this in the
LK8000 forum, and the expert view there is there's no
way round this.

When we were looking at COTS recorders a few years back (now GPS Position Recorders), I played around with a couple of different units. I found that the majority of COTS units (Garmins leap to mind) did some sort of "smoothing" or "projecting" when they lost signal briefly. This was tested by driving a known course at known times and blocking the antenna with a metal shield for a few seconds.

The takeaway was not that these GPS Position Recorders were inherently unusable but that some amount of care would need to be taken in post flight analysis. In the case that Tony mentions, post-flight analysis works given the impossible climb and descent rates that were noted.

Note that fully-compliant IGC FRs are subject to additional requirements including recording fix validity, satellites in use, etc. and undergo significant testing for the above sorts of problems. Given that the SSA and other NACs, as well as the IGC GFAC are pretty much all volunteer organizations, it's tough to ask for a lot more formal testing to be done. Unless, of course, some of the folks writing in this thread are interested in volunteering...

Erik Mann (P3)
SSA FAI Badge and Record Committee

On Wednesday, May 30, 2012 4:09:30 AM UTC-7, Richard Brisbourne wrote:
At 06:52 30 May 2012, uros wrote:
[snip]

I do not hide that I am using the consumer
electronics device. The
firmware is implemented by the device
manufacturer. They only
implemented few changes so that I can implement
some of the flight
recorder features. The chipset inside FR300 is
SKYTRAQ and which is
listed on my page
http://www.flywithce.com/recorder300.html.

All device manufacturers are using standard
chipsets (or even more =96
standard modules). I have not heard that anyone
would implement
changes to position calculation. So even if you
would spend few
hundred EUR more there is no guarantee that GPS
altitude would have
perfect altitude (bonus there is that you have
pressure altitude).

And consumer electronics device is the main reason
why the device can
cost 89 EUR instead 500 EUR like any other fully
certified (and
purpose built) flight recorder. I believe that this is
great device
which is very simple to use and very affordable.

Best regards

Uros
www.flywithce.com

Couple of points worth mentioning here. First, the
SSA approval for flywithce appears only to accept
GPS altitude for verifying flight continuity- a seperate
pressure device is required for height claims.

Second- not all consumer GPS chipsets are equal.
It's interesting that the BGA have withdrawn approval
for the Oudie as a position recorder because the Atlas
V chipset in the new, bright, version, is optimised for
use in motor vehicles, and has track smoothing built
in. This can give significant position errors whenever
you do something (like a tight turn just before an
observation zone) which you couldn't do in a car.

There's been a bit of correspondence about this in the
LK8000 forum, and the expert view there is there's no
way round this.

Many of these chipsets have similar features, and behaviors like smoothing, dead reckoning, altitude filtering/seeding, behaviors on 2D fixes, DOP masks etc. can often be modified in firmware settings, whether the device manufacturers or resellers are able to make changes or have the OEM make changes for them is a separate question.

The reason reported GPS altitudes in position recorder is now more interesting is that they are potentially about to be used for more than proof of continuation of flight following the recent South African IGC meeting. That's the whole point why this thread got started, is interesting, and why the questions raised deserves looking at from the approving NACs and IGC.

Darryl