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