If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#21
|
|||
|
|||
Position Recorders, Accuracy, and Badge altitude gains
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 |
#22
|
|||
|
|||
Position Recorders, Accuracy, and Badge altitude gains
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 |
#23
|
|||
|
|||
Position Recorders, Accuracy, and Badge altitude gains
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 |
#24
|
|||
|
|||
Position Recorders, Accuracy, and Badge altitude gains
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 | |
#25
|
|||
|
|||
Position Recorders, Accuracy, and Badge altitude gains
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 |
#26
|
|||
|
|||
Position Recorders, Accuracy, and Badge altitude gains
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 |
#27
|
|||
|
|||
Position Recorders, Accuracy, and Badge altitude gains
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 | |
#28
|
|||
|
|||
Position Recorders, Accuracy, and Badge altitude gains
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 |
#29
|
|||
|
|||
Position Recorders, Accuracy, and Badge altitude gains
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 |
#30
|
|||
|
|||
Position Recorders, Accuracy, and Badge altitude gains
"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 |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Position recorders for badges | fredblair | Soaring | 5 | March 1st 12 07:01 PM |
Position Recorders allowed the US for Silver badges? | Bastoune | Soaring | 15 | September 22nd 11 01:45 AM |
Any Badge Claims Using GPS Position Recorder plus Barograph? | Papa3 | Soaring | 6 | September 15th 10 10:19 PM |
WAAS question -- altitude accuracy? | Craig Davidson | Piloting | 10 | September 23rd 03 09:56 PM |
gps altitude accuracy | Martin Gregorie | Soaring | 12 | July 18th 03 08:51 PM |