Position Recorders, Accuracy, and Badge altitude gains

[Tony[_5_]]

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/gliding/flightinfo.html?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???

[Marc]

On May 27, 1:44*pm, 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/gliding/flightinfo.html?dsId=242...
>
> 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 you first turn on a GPS receiver, it takes somewhere between a
few seconds and minutes for it to figure out where it is and find
sufficient satellites to track for a full 3D fix. During that period,
a flight or position recorder should set the navigation warning flag
in the recorded fixes, indicating the full 3D navigation is not
available. I can't download the IGC file (as I'm not registered on
the OLC site), but I suspect you'll find that the first few B records
have the character "V" in column 24, indicating no GPS data or 2D
fix. In any case, if you submitted such an IGC file to the "Badge
Guy" after October 1, it would be rejected due to lack of an
acceptable altitude baseline prior to takeoff...

Marc

[Darryl Ramm]

On Sunday, May 27, 2012 1:44:25 PM UTC-7, 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/gliding/flightinfo.html?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???

That seems concerning, hopefully folks from FlywithCE, and SSA and IGC will look at this. There is nothing in the IGC file that seems to explain this.. Its just recording apparently normal 3D fixes. Does the IGC file direct from the device/logbook program have anything unusual looking in it?

Darryl

Darryl

On Sunday, May 27, 2012 1:44:25 PM UTC-7, 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/gliding/flightinfo.html?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???

That seems concerning, hopefully folks from FlywithCE, and SSA and IGC will look at this. There is nothing in the IGC file that seems to explain this (Marc - no 2D fix flags I can see). Its just recording apparently normal 3D fixes. Does the IGC file direct from the device/logbook program have anything unusual looking in it?

What is also interesting is my reading of current FAI rules is there is no clear language/simple requirement for the OO and/or pilot to ensure the flight recorder/logger is actually turned on before flight. The OO required to do things like ensure the device is in the glider, attached, not tamperable (I don't read turning on as tampering) and to independently verify the take off an departure time - but so what if the OO knows the take off time, it the recorder was not turned on. Sure you expect the OO to do their job here and note the flight recorder in-fligh start discrepancy. But what then does the NAC examiner/badge person do? If (like I hope there is) there is a requirement for the FR to be on before flight please provide the rule number.

Thanks

Darryl

[Steve Leonard[_2_]]

Want a bit more concern? Look at my flight from May 13.
http://www.onlinecontest.org/olc-2.0/gliding/flightinfo.html?dsId=2355098
Good baseline before takeoff, but it is 400+ meters high. Then, a bit
into the flight, there is a downward vertical correction (19:09:08).
Maybe again the 2D to 3D correction? Then, right after the downward
correction, is a majoor upward correction (19:11:16. There were no 18
knot thermals or even short climbs due to a zoom). Could be that the
inflight corrections were when I move the logger from the panel to the
canopy frame.

Interesting that I have not ever seen any major jumps like that with
the GPS altitude from my Cambridge logger.

Steve Leonard

[Darryl Ramm]

On Sunday, May 27, 2012 9:08:02 PM UTC-7, Steve Leonard wrote:
> Want a bit more concern? Look at my flight from May 13.
> http://www.onlinecontest.org/olc-2.0/gliding/flightinfo.html?dsId=2355098
> Good baseline before takeoff, but it is 400+ meters high. Then, a bit
> into the flight, there is a downward vertical correction (19:09:08).
> Maybe again the 2D to 3D correction? Then, right after the downward
> correction, is a majoor upward correction (19:11:16. There were no 18
> knot thermals or even short climbs due to a zoom). Could be that the
> inflight corrections were when I move the logger from the panel to the
> canopy frame.
>
> Interesting that I have not ever seen any major jumps like that with
> the GPS altitude from my Cambridge logger.
>
> Steve Leonard

Steve

FYI there are no position reports (B records) in that file that indicate a 2D fix.

Do you have a trace from the same flight from your Cambridge flight recorder?

Darryl

[uros]

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.

In second case the altitude is continuous but with big changes.
Changing the position could have effect. Usually GPS antenna for
flight computer is positioned on perfect spot. Better spot for
flyWithCE Flight Recorder will also result in better results.

Best regards

Uros
www.flywithce.com

[Marc]

On May 28, 11:59*am, 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.

Uros, if the GPS was engaged in cold/warm start and recording 2D or
degraded fixes, why wasn't the navigation warning flag set (V in
column 24 of the B records)?

Marc

[Darryl Ramm]

On Monday, May 28, 2012 12:13:57 PM UTC-7, Marc wrote:
> On May 28, 11:59*am, 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.
>
> Uros, if the GPS was engaged in cold/warm start and recording 2D or
> degraded fixes, why wasn't the navigation warning flag set (V in
> column 24 of the B records)?
>
> Marc

And if the fixes were 2D why was the GPS altitude not recorded as zero. At least that's is a requirement of IGC flight recorders--I'll admit to being lost as to what actual hard specs the NACs are supposed to hold position recorder manufacturers too. I hope the SSA is looking at this.

Darryl

[Steve Leonard[_2_]]

On May 28, 1:59*pm, 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.
>
> In second case the altitude is continuous but with big changes.
> Changing the position could have effect. Usually GPS antenna for
> flight computer is positioned on perfect spot. Better spot for
> flyWithCE Flight Recorder will also result in better results.
>
> Best regards
>
> Uros
> www.flywithce.com

I think the issue I had was likely due to positioning near a cable to
my Cambridge GPS Nav display. Next chance I get, I will repeat the
position and change, noting exact time of change to compare with
changes in reported altitude or position. It is odd that it had
position correct, and altitude offset steady while stationary.

I do like the FlywithCE logger and can hopefully prove that mine was
an error created by installation. Something for us all to be aware
of.

Steve Leonard

[Tony[_5_]]

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?

[Grider Pirate[_2_]]

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.

[jjbird]

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).

[Darryl Ramm]

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

[[email protected]]

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/gliding/flightinfo.html?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

[Tony[_5_]]

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.0/gliding/flightinfo.html?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.

[Darryl Ramm]

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.0/gliding/flightinfo.html?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

[uros]

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

[Richard Brisbourne[_2_]]

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.

[Papa3[_2_]]

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

[Darryl Ramm]

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

[Darryl Ramm]

On Tuesday, May 29, 2012 11:52:09 PM UTC-7, 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*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

Uros

Thanks, I'm not ever suggesting that you were not disclosing the chipsets being used or that these were not based on consumer devices, or that is necessarily a problem. All that I was aiming at is that with these advanced modern GPS chipsets is the important of needing to understand the firmqare settings controlling many of the chipset behaviors. Telling us the chipset used just lets people know potentially the many different chipset settings that could be relevant to practical use and approval as a position recorder.

I'm hoping you know those settings used in the devices from whoever you purchase them. I think its is important that the approving agencies are provided with that data as well, and that they understand it. And I think it would help with transparency if that data was in future made public as a part of any approval process. With many GPS chipsets telling us the model chipset used without that extra data is next to useless.

Thanks


Darryl

[PCool]

Dead reckoning is not a problem, the NMEA sentence is showing DR fixes and
the logger can reject them (like LK does).
The problem is only with Sirf Start V and some Sirf Star IV baseband
receivers and their firmware.
These devices cannot be modified in firmware.

The simple solution, for me, would have been: since we have a max error of -
say - 500m distance and 200m altitude, then lets raise for example the 300km
badge distance to .. 302?, and 3000m altitude gain to .. 3300? That's better
than nothing and most people would agree.
After all we all do this for fun.

paolo


"Darryl Ramm" > ha scritto nel messaggio
news:f2be4b99-5050-4592-9b09-
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

[PCool]

It seems to me that the problem is that the software does not undestand the
takeoff altitude, nothing else.
It should have nothing to do with the gps itself. Bug?
"uros" > ha scritto nel messaggio
...
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

[Martin Gregorie[_5_]]

On Wed, 30 May 2012 07:03:43 -0700, Darryl Ramm wrote:

> I'm hoping you know those settings used in the devices from whoever you
> purchase them. I think its is important that the approving agencies are
> provided with that data as well, and that they understand it. And I
> think it would help with transparency if that data was in future made
> public as a part of any approval process. With many GPS chipsets telling
> us the model chipset used without that extra data is next to useless.
>
Daryl,

In my quite limited experience the only GPS I know for certain smoothed
the trace was the Garmin GPS II+ and I know why as well: it only stores a
few points (1024 or 2048 IIRC) and so to hold all of a long trail it has
to condense runs of fixes into a straight line with just the ends
retained. Of course this would have made it utterly useless as a COTS
logger. However, AFAIK it has never messed about with the fixes it
outputs. At least I've never seen any sign of this in the traces dumped
from my EW Model D logger, which is invariably connected to one of my
Garmin GPS II+ units.

On a slightly different topic: GPS altitude. I've always known that all
GPS altitudes are relative to the WG-84 geoid but have never known how
precisely that corresponds sea level, so I finally did some research and
it turns out that its within +/- 1 metre of AMSL.

That is less than the error in a standard GPS receiver's height
measurement. I don't believe I've ever seen an EPE of less than 3 metres.
Just now one of my GPS II+ units said EPE=5m when I took it outside. So,
my guess is that for almost all our purposes its reasonable to take a
valid GPS height as being equivalent to altitude AMSL provided an error
of +/- 20-25 feet is acceptable for the task in hand.


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

[Darryl Ramm]

On Wednesday, May 30, 2012 3:52:41 PM UTC-7, Martin Gregorie wrote:
> On Wed, 30 May 2012 07:03:43 -0700, Darryl Ramm wrote:
>
> > I'm hoping you know those settings used in the devices from whoever you
> > purchase them. I think its is important that the approving agencies are
> > provided with that data as well, and that they understand it. And I
> > think it would help with transparency if that data was in future made
> > public as a part of any approval process. With many GPS chipsets telling
> > us the model chipset used without that extra data is next to useless.
> >
> Daryl,
>
> In my quite limited experience the only GPS I know for certain smoothed
> the trace was the Garmin GPS II+ and I know why as well: it only stores a
> few points (1024 or 2048 IIRC) and so to hold all of a long trail it has
> to condense runs of fixes into a straight line with just the ends
> retained. Of course this would have made it utterly useless as a COTS
> logger. However, AFAIK it has never messed about with the fixes it
> outputs. At least I've never seen any sign of this in the traces dumped
> from my EW Model D logger, which is invariably connected to one of my
> Garmin GPS II+ units.
>
> On a slightly different topic: GPS altitude. I've always known that all
> GPS altitudes are relative to the WG-84 geoid but have never known how
> precisely that corresponds sea level, so I finally did some research and
> it turns out that its within +/- 1 metre of AMSL.
>
> That is less than the error in a standard GPS receiver's height
> measurement. I don't believe I've ever seen an EPE of less than 3 metres.
> Just now one of my GPS II+ units said EPE=5m when I took it outside. So,
> my guess is that for almost all our purposes its reasonable to take a
> valid GPS height as being equivalent to altitude AMSL provided an error
> of +/- 20-25 feet is acceptable for the task in hand.
>
>
> --
> martin@ | Martin Gregorie
> gregorie. | Essex, UK
> org |

Martin that is all nice, but for particular devices here people are observing altitude errors of 1,000' or so (presumably caused by 2D fixes being marked incorrectly as valid 3D fixes). To me that's the issue, not whether GPS altitude in principle is usable. It is, but as I think this is showing the devil is in the details of how devices work/are usable in detail in the field (and consequently what the specifications they are required to meet are and how they are approved for use). Hopefully there are some quick product fixes possible here and some look at improving the specs and/or approval process.

Darryl

[Darryl Ramm]

On Wednesday, May 30, 2012 3:52:41 PM UTC-7, Martin Gregorie wrote:
[snip]
> On a slightly different topic: GPS altitude. I've always known that all
> GPS altitudes are relative to the WG-84 geoid but have never known how
> precisely that corresponds sea level, so I finally did some research and
> it turns out that its within +/- 1 metre of AMSL.

Actually I'm not sure where you get +/- 1m difference between the WSG-84 geoid and AMSL. It's potentially larger than that (but still that does not mean GPS altitude is inherently not usable). e.g. see this article http://www..esri.com/news/arcuser/0703/geoid1of3.html

Darryl

[Martin Gregorie[_5_]]

On Wed, 30 May 2012 16:13:59 -0700, Darryl Ramm wrote:

> Martin that is all nice, but for particular devices here people are
> observing altitude errors of 1,000' or so (presumably caused by 2D fixes
> being marked incorrectly as valid 3D fixes).
>
Point. And, a related one: how come there are all these GPS devices out
there (Garmin, I'm looking at you) whose display real-estate is so
precious that they can't devote any of it to flagging up invalid fixes.
At least neither LK8000 nor XCSoar suffers from this problem.

I've never seen anything like the sort of errors you mention, though if
my EW model D is left running on the ground its trace often hops up and
down a few feet. Do we know if any of those mega-deviations spike down to
exactly zero ft?


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

[Darryl Ramm]

On Wednesday, May 30, 2012 3:28:29 PM UTC-7, PCool wrote:
> Dead reckoning is not a problem, the NMEA sentence is showing DR fixes and
> the logger can reject them (like LK does).

Sorry I'm am completely lost with what you are saying - where is NMEA involved here at all? I have never looked at a FlyWithCE position recorder or poked around inside it but I assume for example that the FlyWithCE FR300 (presumably a Canmore GT-730FL-S OEM unit) would use the SkyTraq Venus binary data log format. I don't have a definitive spec for that format but did have a couple of quick peeks at Skytraq based SDK docs and source code for GPSBabel (which reads that log format). None of that showed obvious things like DR or 2D/3D flags showing up in the data records. That would indeed be kind of a surprise if it was the case and I'm hoping its really there in one of he fields that is simply not in the very basic documentation, and even more basic understanding of this, that I have. If you know more it would be great to have a pointer to some documentation for the Skytraq Venus log format. Anybody want to loan me an FR300? Can't be too hard to dump the raw log file contents...

> The problem is only with Sirf Start V and some Sirf Star IV baseband
> receivers and their firmware.
> These devices cannot be modified in firmware.

I don't think we know enough about what is going on here to say what problem is where. But its not just some chipsets are configurable in firmware or not, if a company shipping an OEM based GPS unit can't get into the firmware and change some of these A-GPS/DR/altitude etc. type config settings or convince the OEM to then its kind of academic whether the chipset would allow that in principle.

> The simple solution, for me, would have been: since we have a max error of -
> say - 500m distance and 200m altitude, then lets raise for example the 300km
> badge distance to .. 302?, and 3000m altitude gain to .. 3300? That's better
> than nothing and most people would agree.
> After all we all do this for fun.

200m? Where did that come from? We have flights (ones mentioned in this thread) with position recorder altitude errors greater than 1,000' - when comparing an position recorder vs. the GPS and pressure altitude in a Cambridge flight recorder.

You cannot just add a distance or altitude (although I know that is what the IGC is thinking) for large scale errors. If the errors were beaten down to what GPS is really capable of then its a very different matter. And simply adding a large course distance or altitude gain fuzz factors do not really address missing or falsely entering an OZ by hundreds of feet or more (as might be possible if A-GPS/DR features are enabled) or grossly busting airspace or appearing to bust airspace when you did not, or as shown in flights reported here apparently invalid (but marked valid in the IGC file) large altitude errors.


Darryl

> paolo
>
>
> "Darryl Ramm" > ha scritto nel messaggio
> news:f2be4b99-5050-4592-9b09-
> 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

[PCool]

You are talking about a log format, which has nothing to do with talking to
the gps baseband and detecting dead reckoning or invalid fixes.



"Darryl Ramm" > ha scritto nel messaggio
...
On Wednesday, May 30, 2012 3:28:29 PM UTC-7, PCool wrote:
> Dead reckoning is not a problem, the NMEA sentence is showing DR fixes and
> the logger can reject them (like LK does).

Sorry I'm am completely lost with what you are saying - where is NMEA
involved here at all? I have never looked at a FlyWithCE position recorder
or poked around inside it but I assume for example that the FlyWithCE FR300
(presumably a Canmore GT-730FL-S OEM unit) would use the SkyTraq Venus
binary data log format. I don't have a definitive spec for that format but
did have a couple of quick peeks at Skytraq based SDK docs and source code
for GPSBabel (which reads that log format). None of that showed obvious
things like DR or 2D/3D flags showing up in the data records. That would
indeed be kind of a surprise if it was the case and I'm hoping its really
there in one of he fields that is simply not in the very basic
documentation, and even more basic understanding of this, that I have. If
you know more it would be great to have a pointer to some documentation for
the Skytraq Venus log format. Anybody want to loan me an FR300? Can't be too
hard to dump the raw log file contents...




> The problem is only with Sirf Start V and some Sirf Star IV baseband
> receivers and their firmware.
> These devices cannot be modified in firmware.

I don't think we know enough about what is going on here to say what problem
is where. But its not just some chipsets are configurable in firmware or
not, if a company shipping an OEM based GPS unit can't get into the firmware
and change some of these A-GPS/DR/altitude etc. type config settings or
convince the OEM to then its kind of academic whether the chipset would
allow that in principle.

> The simple solution, for me, would have been: since we have a max error
> of -
> say - 500m distance and 200m altitude, then lets raise for example the
> 300km
> badge distance to .. 302?, and 3000m altitude gain to .. 3300? That's
> better
> than nothing and most people would agree.
> After all we all do this for fun.

200m? Where did that come from? We have flights (ones mentioned in this
thread) with position recorder altitude errors greater than 1,000' - when
comparing an position recorder vs. the GPS and pressure altitude in a
Cambridge flight recorder.

You cannot just add a distance or altitude (although I know that is what the
IGC is thinking) for large scale errors. If the errors were beaten down to
what GPS is really capable of then its a very different matter. And simply
adding a large course distance or altitude gain fuzz factors do not really
address missing or falsely entering an OZ by hundreds of feet or more (as
might be possible if A-GPS/DR features are enabled) or grossly busting
airspace or appearing to bust airspace when you did not, or as shown in
flights reported here apparently invalid (but marked valid in the IGC file)
large altitude errors.


Darryl

> paolo
>
>
> "Darryl Ramm" > ha scritto nel messaggio
> news:f2be4b99-5050-4592-9b09-
> 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

[Darryl Ramm]

"PCool" > wrote:
> You are talking about a log format, which has nothing to do with talking
> to the gps baseband and detecting dead reckoning or invalid fixes.
>
The problem being discussed in this thread is all about the binary log file
format in these devices.. There is apparently nothing with these devices
that anybody (user, FlyWithCE developer) has any control over that talks
to the GPS baseband or any NMEA stream. The OEM supplied binary log inside
these devices is the only way data gets into the IGC file. If data is not
in that log them it's not possible to get that into an IGC file. Or say if
invalid or DR fixes are in that log and not obviously marked then the
conversion program cannot generate the appropriate flags in the IGC file B
records. There is no other software running on board that can look at NMEA
GPS data so again the points you are raising have no relevance to the
problem being discussed. The chipset being used can certainly generate a
NMEA stream with DR flags etc. but nobody uses these FlyWithCE devices to
do that AFAIK (they require a USB master). Right now the most interesting
question about these devices is just exactly what is or is not in that
internal binary log. The next question is what are the DR/altitude/DOP mask
related firmware settings used in the device to generate the log fixes.

Darryl

>
> "Darryl Ramm" > ha scritto nel messaggio
> ...
> On Wednesday, May 30, 2012 3:28:29 PM UTC-7, PCool wrote:
>> Dead reckoning is not a problem, the NMEA sentence is showing DR fixes and
>> the logger can reject them (like LK does).
>
> Sorry I'm am completely lost with what you are saying - where is NMEA
> involved here at all? I have never looked at a FlyWithCE position
> recorder or poked around inside it but I assume for example that the
> FlyWithCE FR300 (presumably a Canmore GT-730FL-S OEM unit) would use the
> SkyTraq Venus binary data log format. I don't have a definitive spec for
> that format but did have a couple of quick peeks at Skytraq based SDK
> docs and source code for GPSBabel (which reads that log format). None of
> that showed obvious things like DR or 2D/3D flags showing up in the data
> records. That would indeed be kind of a surprise if it was the case and
> I'm hoping its really there in one of he fields that is simply not in the
> very basic documentation, and even more basic understanding of this, that
> I have. If you know more it would be great to have a pointer to some
> documentation for the Skytraq Venus log format. Anybody want to loan me
> an FR300? Can't be too hard to dump the raw log file contents...
>
>
>
>
>> The problem is only with Sirf Start V and some Sirf Star IV baseband
>> receivers and their firmware.
>> These devices cannot be modified in firmware.
>
> I don't think we know enough about what is going on here to say what
> problem is where. But its not just some chipsets are configurable in
> firmware or not, if a company shipping an OEM based GPS unit can't get
> into the firmware and change some of these A-GPS/DR/altitude etc. type
> config settings or convince the OEM to then its kind of academic whether
> the chipset would allow that in principle.
>
>> The simple solution, for me, would have been: since we have a max error > of -
>> say - 500m distance and 200m altitude, then lets raise for example the > 300km
>> badge distance to .. 302?, and 3000m altitude gain to .. 3300? That's > better
>> than nothing and most people would agree.
>> After all we all do this for fun.
>
> 200m? Where did that come from? We have flights (ones mentioned in this
> thread) with position recorder altitude errors greater than 1,000' - when
> comparing an position recorder vs. the GPS and pressure altitude in a
> Cambridge flight recorder.
>
> You cannot just add a distance or altitude (although I know that is what
> the IGC is thinking) for large scale errors. If the errors were beaten
> down to what GPS is really capable of then its a very different matter.
> And simply adding a large course distance or altitude gain fuzz factors
> do not really address missing or falsely entering an OZ by hundreds of
> feet or more (as might be possible if A-GPS/DR features are enabled) or
> grossly busting airspace or appearing to bust airspace when you did not,
> or as shown in flights reported here apparently invalid (but marked valid
> in the IGC file) large altitude errors.
>
>
> Darryl
>
>> paolo
>>
>>
>> "Darryl Ramm" > ha scritto nel messaggio
>> news:f2be4b99-5050-4592-9b09-
>> 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

[PCool]

Ok got it thx, this is a very clear explanation of the problem.
paolo


"Darryl Ramm" > ha scritto nel messaggio
...
"PCool" > wrote:
> You are talking about a log format, which has nothing to do with talking
> to the gps baseband and detecting dead reckoning or invalid fixes.
>
The problem being discussed in this thread is all about the binary log file
format in these devices.. There is apparently nothing with these devices
that anybody (user, FlyWithCE developer) has any control over that talks
to the GPS baseband or any NMEA stream. The OEM supplied binary log inside
these devices is the only way data gets into the IGC file. If data is not
in that log them it's not possible to get that into an IGC file. Or say if
invalid or DR fixes are in that log and not obviously marked then the
conversion program cannot generate the appropriate flags in the IGC file B
records. There is no other software running on board that can look at NMEA
GPS data so again the points you are raising have no relevance to the
problem being discussed. The chipset being used can certainly generate a
NMEA stream with DR flags etc. but nobody uses these FlyWithCE devices to
do that AFAIK (they require a USB master). Right now the most interesting
question about these devices is just exactly what is or is not in that
internal binary log. The next question is what are the DR/altitude/DOP mask
related firmware settings used in the device to generate the log fixes.

Darryl

>
> "Darryl Ramm" > ha scritto nel messaggio
> ...
> On Wednesday, May 30, 2012 3:28:29 PM UTC-7, PCool wrote:
>> Dead reckoning is not a problem, the NMEA sentence is showing DR fixes
>> and
>> the logger can reject them (like LK does).
>
> Sorry I'm am completely lost with what you are saying - where is NMEA
> involved here at all? I have never looked at a FlyWithCE position
> recorder or poked around inside it but I assume for example that the
> FlyWithCE FR300 (presumably a Canmore GT-730FL-S OEM unit) would use the
> SkyTraq Venus binary data log format. I don't have a definitive spec for
> that format but did have a couple of quick peeks at Skytraq based SDK
> docs and source code for GPSBabel (which reads that log format). None of
> that showed obvious things like DR or 2D/3D flags showing up in the data
> records. That would indeed be kind of a surprise if it was the case and
> I'm hoping its really there in one of he fields that is simply not in the
> very basic documentation, and even more basic understanding of this, that
> I have. If you know more it would be great to have a pointer to some
> documentation for the Skytraq Venus log format. Anybody want to loan me
> an FR300? Can't be too hard to dump the raw log file contents...
>
>
>
>
>> The problem is only with Sirf Start V and some Sirf Star IV baseband
>> receivers and their firmware.
>> These devices cannot be modified in firmware.
>
> I don't think we know enough about what is going on here to say what
> problem is where. But its not just some chipsets are configurable in
> firmware or not, if a company shipping an OEM based GPS unit can't get
> into the firmware and change some of these A-GPS/DR/altitude etc. type
> config settings or convince the OEM to then its kind of academic whether
> the chipset would allow that in principle.
>
>> The simple solution, for me, would have been: since we have a max error >
>> of -
>> say - 500m distance and 200m altitude, then lets raise for example the >
>> 300km
>> badge distance to .. 302?, and 3000m altitude gain to .. 3300? That's >
>> better
>> than nothing and most people would agree.
>> After all we all do this for fun.
>
> 200m? Where did that come from? We have flights (ones mentioned in this
> thread) with position recorder altitude errors greater than 1,000' - when
> comparing an position recorder vs. the GPS and pressure altitude in a
> Cambridge flight recorder.
>
> You cannot just add a distance or altitude (although I know that is what
> the IGC is thinking) for large scale errors. If the errors were beaten
> down to what GPS is really capable of then its a very different matter.
> And simply adding a large course distance or altitude gain fuzz factors
> do not really address missing or falsely entering an OZ by hundreds of
> feet or more (as might be possible if A-GPS/DR features are enabled) or
> grossly busting airspace or appearing to bust airspace when you did not,
> or as shown in flights reported here apparently invalid (but marked valid
> in the IGC file) large altitude errors.
>
>
> Darryl
>
>> paolo
>>
>>
>> "Darryl Ramm" > ha scritto nel messaggio
>> news:f2be4b99-5050-4592-9b09-
>> 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

[Martin Gregorie[_5_]]

On Wed, 30 May 2012 16:20:28 -0700, Darryl Ramm wrote:

> On Wednesday, May 30, 2012 3:52:41 PM UTC-7, Martin Gregorie wrote:
> [snip]
>> On a slightly different topic: GPS altitude. I've always known that all
>> GPS altitudes are relative to the WG-84 geoid but have never known how
>> precisely that corresponds sea level, so I finally did some research
>> and it turns out that its within +/- 1 metre of AMSL.
>
> Actually I'm not sure where you get +/- 1m difference between the WSG-84
> geoid and AMSL. It's potentially larger than that (but still that does
> not mean GPS altitude is inherently not usable). e.g. see this article
> http://www.esri.com/news/arcuser/0703/geoid1of3.html
>
Here: "The new World Geodetic System was called WGS 84. It is currently
the reference system being used by the Global Positioning System. It is
geocentric and globally consistent within ±1 m. Current geodetic
realizations of the geocentric reference system family International
Terrestrial Reference System (ITRS) maintained by the IERS are
geocentric, and internally consistent, at the few-cm level, while still
being metre-level consistent with WGS 84." - from:

https://en.wikipedia.org/wiki/World_Geodetic_System

yes, I know its only Wikipedia, but IME it seems to be generally OK for
technical details, but its backed up by this source:

http://kartoweb.itc.nl/geometrics/Reference%20surfaces/body.htm

IOW the 'best fit' geometric elipsoid, which can deviate from AMSL by up
to 105m is adjusted for gravimetric factors (the reference data set seems
to be ITRF96) and the result is the WGS84 geoid. According to the second
reference: "The World Geodetic System of 1984 (WGS84) datum has been
refined on several occasions and is now aligned with the ITRF to within a
few centimetres worldwide." which appears to be referring to the
deviation from AMSL though this is nowhere stated explicitly but appears
to be the meaning in the given context.


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