 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion GroupsSpace ScienceAstronomyAmateur AstronomySpace FlightSpace StationShuttleSpace HistorySpace PolicySETI SpaceKB.com Contact UsLink To UsSearch & Site Map |
Space Forum / Shuttle / September 2006gps etc
I noted when Atlantis came back, they included gps data into the mix, I understand this is going to happen more and more soon.What I have never really grasped about gps is how height information is obtained though. On an alied subject, i see in the news group that they have discovered that GPS receivers tend to lose lock when a large solar flare occurs. I cannot say i'm surprised, as front end saturation probably occurs in the recievers. I'd have thought this problem was an obvious one and was surprised to read that its not been considered before. Brian  SignatureBrian Gaff....Note, this account does not accept Bcc: email. graphics are great, but the blind can't hear them Email: briang1@blueyonder.co.uk ______________________________________________________________________________________________________________ >I noted when Atlantis came back, they included gps data into the mix, I >understand this is going to happen more and more soon.What I have never >really grasped about gps is how height information is obtained though. The same way position is determined - by spherical triangulation. GPS height calculations are however notoriously flawed. The system was originally designed to support SSBN's, and when it was adapted to wider [military] use this was not seen as a flaw. (I.E. no military user particularly cares for precise height.) It wasn't until they started using for weapons and proposing it [civil] aircraft guidance that it became a problem. I don't know offhand how the shuttle copes with this flaw. D. SignatureTouch-twice life. Eat. Drink. Laugh. -Resolved: To be more temperate in my postings. Oct 5th, 2004 JDL > >I noted when Atlantis came back, they included gps data into the mix, I > >understand this is going to happen more and more soon.What I have never [quoted text clipped - 10 lines] > > I don't know offhand how the shuttle copes with this flaw. Aren't they flawed by assuming you're on the WGS-84 spheroid and then trying to figure the deviation from that? I'd think the solution would be to "just don't do that" but that the math becomes a lot more difficult. This isn't as much of a problem with more powerful CPUs available. I do know that more recent GPS units figure height much more quickly and accurately. My latest eTrex has no problem and is usually quite accurate whereas my old Lowrance Eagle unit didn't even try. -gc SignatureWhen failure is not an option, success can be expensive. -- Henry Spencer >> GPS height calculations are however notoriously flawed. The system was >> originally designed to support SSBN's, and when it was adapted to [quoted text clipped - 7 lines] >Aren't they flawed by assuming you're on the WGS-84 spheroid and then >trying to figure the deviation from that? No - it's inherent in the system (AIUI), the height calculation is the most sensitive to the number of birds, their geometry in relation to you, propagation delays, clock drift, etc... etc... Even with regards to WGS-84, your height calculation can be off, sometimes significantly. >I'd think the solution would be to "just don't do that" but that the >math becomes a lot more difficult. This isn't as much of a problem with >more powerful CPUs available. The problem is less one of available CPU power, but rather that it is inherent in the design of the system. That's why we have hacks like DGPS and WAAS to overcome (to some degree) this limitation. Even to get a reliable 1-3 meter degree of precision requires either these hacks or considerable post-processing, or both. >I do know that more recent GPS units figure height much more quickly and >accurately. My latest eTrex has no problem and is usually quite accurate >whereas my old Lowrance Eagle unit didn't even try. The accuracy of your eTrex (and mine) in height is highly dependent on the factors I list above. Also 'quite accurate' with regards to a handheld is 'horribly inaccurate' with regards to an autolanding system. Keep in mind that the accuracy reading on your Etrex applies to vertical position as well as horizontal position - even though your reading may be stable, there is still some amount of inaccuracy. (That's one of the most common errors among newbie geocachers - equating 'stable' with 'accurate'.) In fact, geocachers (probably the largest group of non-professionals interested (obsessed) in their position to highest degree of accuracy) regard the 'GPS accuracy test' [1] as little more than a lottery. [1] A common feature of geocacher gatherings. A surveying GPS is used to survey a point in lat-long, then individual cachers are given the same coordinates and asked to locate it using their handhelds and mark it with a flag. Then the actual point is marked and prizes are awarded from nearest to furthest. Height determination is usually a seperate contest. D. SignatureTouch-twice life. Eat. Drink. Laugh. -Resolved: To be more temperate in my postings. Oct 5th, 2004 JDL Hi all, Some interesting assertions here and I couldn't quite see how the mathematical transformation of three SV x, y and z ECI-centric coordinates to obtain one set of ECEF coordinates would contain any bias towards the z vector. If positional errors mainly arise from atmospheric refraction, ephemeris, or orbital errors, these should apply to latitude, longitude and height equally. As I couldn't work it out, I checked a reference book (Introduction to The Global Positioning System, Ahmed El-Rabbany, Artech House). "The positioning accuracy . . . is 16m for the horizontal component and 23m for the vertical component (95% probability level)." Note that this refers to basic trilateration with three SVs - the key point is the HDOP / VDOP ratio. "Because a GPS user can track only those satellites above the horizon, VDOP will always be larger than HDOP. As a result, the GPS height solution is expected to be less precise than the horizontal solution." This makes sense when you think about it and I should have twigged myself. Look at the $GPGSV NMEA sentence structure. For each satellite in view, elevation is reported to a maximum of 90 degrees (ie 180 viewable) whereas azimuth range is 0 to 359 degrees. This allows latitude and longitude to be corrected, under ideal conditions, literally from all angles. Incidentally, the author discusses solar flares extensively so I don't think their effect on a relatively weak radio signal is an eye opener to the GPS community. For those who think that GPS height is "more accurate these days", I suspect it is more likely a consequence of newer receivers taking the GPS reported height (ie height above the centre of the sphere of reference) and calibrating it against the WGS-84 ellipsoid. Within the standard margin of error, this should align the GPS height with the satellite sub point. You can check the 'Geoid separation' value in the $GPGGA sentence to see if this is done, then if you are truly obsessive, visit an online geoid calculator and triple check. My GPS reports my height as 613 metres while my location's geoid correction is 19.3 metres, according to http://earth-info.nga.mil/GandG/wgs84/gravitymod/wgs84_180/intptW.html. This concurs pretty closely with the height reported by my altimeter. Cheers, Bill Bill, thanks for the nice post. Was working on my thoughts on the problem... If you think of it as strictly a geometry problem, where each GPS satellite give you your position as a sphere, with the radius being your distance from the satellite. The satellites with the best geometry for giving you the best Latitude and Longitude positions would be all the satellites that are along the horizon (assuming good signal). The circle of the horizon. None of these satellites along the horizon will give you any good information about altitude. While the best position for a satellite to give you altitude is straight up or straight down. Satellites that are straight up or straight down would give no useful information about your latitude and longitude. Another way to look at this would be to look at the number of satellites that are "close" to the "best" geometry. Let's say within 45 degrees of the optimal. So the "close" geometry satellites for determining altitude would be a cone around a line straight up or straight down. The "close" geometry satellites for Latitude and Longitude would be everything else above the horizon. An area 2-3 times as large, containing 2-3 times as many satellites to choose from, assuming equal distribution. 2-3 times the number of satellites to choose the ones that have the best geometry, to give the most accurate solution. Also, think about how spheres can intersect each other. Latitude and Longitude have the full spectrum of intersections. From, a sphere within a sphere, the intersection being the sphere itself. To, a sphere touching a sphere, the intersection being a point. And, all the circular intersections in between the two. With altitude, the Earth blocks half the possible intersections. There can never be the point intersection, or anywhere close, of two spheres. So, you can probably see why it's a harder problem to determine altitude. It's the Earth, it's constraining the geometry of the problem for altitude more than it is Latitude and Longitude. SignatureCraig Fink Courtesy E-Mail Welcome @ WeBeGood@GMail.Com -- >If you think of it as strictly a geometry problem, where each GPS >satellite give you your position as a sphere, with the radius being your >distance from the satellite. One important thing to keep in mind is that the length of the radius is just a wee bit indeterminate. The surface of the sphere has a non-zero thickness. >So, you can probably see why it's a harder problem to determine altitude. >It's the Earth, it's constraining the geometry of the problem for altitude >more than it is Latitude and Longitude. And if you look at the overall situation at the time of the specs being set you can see why they didn't worry about altitude; Users on the ground - can look up their altitude on a topo map if they actually care that much. Users at (or under) the sea - "we are at sea level idiot, look out the porthole/periscope". Users airborne at high altitude - precise altitude matters little Users airborne at low altitude - "quit looking at the gadget dammit and help me watch for hills, trees, and powerlines!" D. SignatureTouch-twice life. Eat. Drink. Laugh. -Resolved: To be more temperate in my postings. Oct 5th, 2004 JDL fairwater@gmail.com (Derek Lyons) wrote in news:451a2e55.932635078 @news.supernews.com: >>I noted when Atlantis came back, they included gps data into the mix, I >>understand this is going to happen more and more soon.What I have never [quoted text clipped - 10 lines] > > I don't know offhand how the shuttle copes with this flaw. Mostly by not trying to use it all the way to the ground. Pre-GPS, the shuttle's entry navaids were incorporated in this order: DRAG H, then TACAN, then air data, then MLS. GPS is mainly intended to replace TACAN, since the USAF is retiring it. Since air data provides altitude, it can be used to cross-check the GPS altitude after the probes are deployed. And once MLS locks on, it is automatically incorporated in place of GPS (or anything else). On STS-115, the GPS data looked very good, so the ground never called for the crew to take air data to NAV. They did call for air data to G&C, and continued to monitor the air data residuals to make sure GPS was behaving. SignatureJRF Reply-to address spam-proofed - to reply by E-mail, check "Organization" (I am not assimilated) and think one step ahead of IBM. >Mostly by not trying to use it all the way to the ground. Pre-GPS, the >shuttle's entry navaids were incorporated in this order: DRAG H, then [quoted text clipped - 3 lines] >once MLS locks on, it is automatically incorporated in place of GPS (or >anything else). <ponders> Do you know if the Shuttle GPS also uses WAAS or DGPS? D. SignatureTouch-twice life. Eat. Drink. Laugh. -Resolved: To be more temperate in my postings. Oct 5th, 2004 JDL >>Mostly by not trying to use it all the way to the ground. Pre-GPS, the >>shuttle's entry navaids were incorporated in this order: DRAG H, then [quoted text clipped - 5 lines] > > <ponders> Do you know if the Shuttle GPS also uses WAAS or DGPS? No on both. SignatureJRF Reply-to address spam-proofed - to reply by E-mail, check "Organization" (I am not assimilated) and think one step ahead of IBM. >>>Mostly by not trying to use it all the way to the ground. Pre-GPS, the >>>shuttle's entry navaids were incorporated in this order: DRAG H, then [quoted text clipped - 7 lines] > > No on both. Clarification (now that I've actually read my own post) - I know that shuttle GPS does *not* use either. SignatureJRF Reply-to address spam-proofed - to reply by E-mail, check "Organization" (I am not assimilated) and think one step ahead of IBM. > fairwater@gmail.com (Derek Lyons) wrote in news:451a2e55.932635078 > @news.supernews.com: > > On STS-115, the GPS data looked very good, so the ground never called for > the crew to take air data to NAV. They did call for air data to G&C, and > continued to monitor the air data residuals to make sure GPS was behaving. It has been a while since I tought air data, but if I remember correctly, even with a perfect NAV state, you need air data to G&C because wind causes an error on nav derived air data. Wind can cause a significant error in angle of attack, dynamic pressure, and mach number estimates. Danny Dot www.mobbinggonemad.org >> fairwater@gmail.com (Derek Lyons) wrote in news:451a2e55.932635078 >> @news.supernews.com: [quoted text clipped - 9 lines] > a significant error in angle of attack, dynamic pressure, and mach > number estimates. I agree; that's correct and that's why 115 took air data to G&C but not to NAV. SignatureJRF Reply-to address spam-proofed - to reply by E-mail, check "Organization" (I am not assimilated) and think one step ahead of IBM. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.