Position Recorders, Accuracy, and Badge altitude gains

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

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

He "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/Re...faces/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 |