Jump to content

GPSlug

+Premium Members
  • Posts

    388
  • Joined

  • Last visited

Posts posted by GPSlug

  1. Combined GPS+GLONASS will give you some more availability in situations where using GPS on it's own is impossible or has really bad geometry. That's really the only benefit.

     

    Generally, if GPS on it's own is working adequately but not great, adding GLONASS won't improve accuracy. It isn't quite like there being 24 more GPS satellites in orbit. GLONASS isn't as accurate as GPS, so seeing additional satellites from GLONASS won't help as much as if they were GPS satellites. You also won't get EGNOS corrections for GLONASS.

     

    In your valleys you might get a position more often, but it still won't be great. If your problem is more about getting the ephemeris for new satellites (i.e. your satellite page has bars but they won't go solid) because of both the valley walls and big trees, you might get more improvement from an external antenna.

  2. Disclaimer: I am not a signal processing guy. What I know about it is what I've picked up being around GPS over the years. So please bear with me when I don't know where to draw the line between what's obvious to any EE/RF/DSP person and what's specific to the GPS flavor of spread spectrum. I apologize in advance for anything stupid I might say. I'll also limit the discussion to pre-modernized L1.

     

    OK, I may be getting it ... or not. In my world the FCC assigns a range of frequencies called a band. You can use any frequency for a transmission as long as any type of modulation of that frequency does not generate frequencies outside the band. The modulation type can be AM, FM, SSB, spread spectrum and on and on. Are you saying the FCC is proposing overlapping bands or sharing of a band?

     

    EDIT: I may be missing a key point about spread spectrum. My thinking it is just multiple frequencies for one info stream.

    At least as applied to GPS, spread spectrum does the opposite. It allows multiple info streams on one frequency.

     

    The band that GPS uses is centered on L1, and all GPS satellites transmit on L1. The PRN codes modulated on the signal are so high rate (~1 MHz C/A code, ~10 MHz P code), that they really are a lot like modulating noise on the signal, spreading it across a wide bandwidth. But the receiver knows at least the C/A code and can remove it from the signal and use it for accurate ranging. It's also pretty resistant to some kinds of jamming - an in-band spike isn't as bad as it could be because it only takes out a narrow part of the signal.

     

    So, GPS is using this chunk of spectrum with more power in the middle and tailing off at the ends. A basic receiver might only use the middle part, and more advanced receivers will also go out farther into the tails. Compared to other kinds of modulation, the power drop-off for spread spectrum is very gradual by nature. A limited amount of overlap between bands is expected. As long as the other guy's modulated noise isn't too high compared to your modulated noise, it's acceptable.

     

    The adjacent bands to L1 are pretty much limited to satellite services, so you'd never be close to a strong transmitter. Lightsquared's spectrum was originally approved to be mainly on satellites, with the option to use some low power transponders to extend the service to places where you couldn't get the satellites. The waiver that has caused the kerfuffle would allow them to use higher power transponders out in the open.

  3. "bleed over" makes no sense to me as an engineer and a ham operator. What do you mean?. Transmitters can make noise on multiples of the frequency called harmonics. Harmonics don't affect nearby frequencies(the first harmonic is double the frequency). A transmitter can be too strong for a receiver's front end tuner band pass filter, which affects all frequencies, not just nearby ones. That is solved by moving away or fixing the receiver. Many a ham has put better filters on their neighbors TVs, even though hams are not legally required to install filters. I think maybe the front ends of today's modern GPSs are much better than TVs IMHO and they should be fine. I have had GPS problems near high power cell or TV towers. I have pretty much ignored previous threads so this is my first reaction..

    GPS is different because it's spread spectrum. There isn't a strong frequency peak you can just use a narrow filter for. The peak is spread out and barely above the noise, so you need a wide front end to get the signal at all. It's even worse for high accuracy commercial receivers and high sensitivity consumer receivers that need to go wider to get as much signal as possible. They can handle a reasonable amount of raised noise floor, but LightSquared's scheme is far from reasonable - even their "reduced impact" plan. Their spreading overlaps with GPS's spreading too much, and is a lot stronger.

  4. Is there a ribbon cable that could be connected wrong? A jumper?

     

    It may just be dead. QC on serial ports got pretty lax towards the end of the time that they came standard.

     

    Maybe connect a Christmas light LED to TX and GND and see if there's any activity from "copy somefile.txt com1".

  5. You can get Trimble Planning here. It will take the Yuma format files.

     

    The 2001 files here are listed as <DayOfYear>.ALM. Google "day of year" for any number of calculators to compute the day of year from calendar date. Pick the closest file on or before the day in question and rename it to whatever.YUM so Trimble Planning knows what to look for.

     

    Then in Trimble Planning, select Almanac|Clear, then Almanac|Import|YUMA and get the file you downloaded. It should now be using an almanac that would have been received on that date.

  6. I assume this is a serial port from the motherboard, rather than USB-to-serial?

     

    One thing I'd check for is that sometimes Windows can spontaneously decide that your GPS receiver is a serial mouse and sets up the driver for that. If you find a serial mouse installed in the device manager, uninstall it and reboot without the device plugged in.

     

    I'd also check the BIOS settings to see if the COM port setting looks right.

  7. In Sweden we have a discussion about that the normal mode seems to be more accurate then the WAAS/Egnos mode. Do you have any comments about that?

     

    I have done tests with two Garmins (Dakota 20 and Oregon 450) side by side during a day and the normal mode "always" shows better numbers on accuracy (3 meters ->7 meters typically)

    Is this the EPE that is bigger with EGNOS? Or are you measuring the position error directly?

     

    SBAS gives corrections for increased accuracy, but it also (more importantly for Safety of Life applications, like flying) allows the receiver to get a better estimate of its error. This is most significant for the ionospheric corrections. In a strong or quickly changing ionospheric environment, a receiver will have a much better idea of how well it's correcting for the error using SBAS than using the GPS broadcast model. And the ionosphere tends to be more variable in higher latitudes, like Sweden.

     

    Could it be that your accuracy is better, even if the reported EPE is worse?

  8. Ashtech has launched a new web-based (javascript) planning tool. It even lets you put in an obstruction profile.

     

    For dates prior to current, Trimble is either projecting from current orbital information, or isn't "projecting" at all, and is using the true history (which would require some monster tables!).

    You can download historic almanac files from the U.S. Coast Guard. But if I recall correctly, and if Trimble's planner hasn't changed since I last used it, you would need to manually download and open an old almanac file for the time you're interested in.
  9. You raised an interesting question, however. What "plane of reference" does GPS use to report elevation? Never really thought about it myself, since I've never used GPS elevation as sole "altitude" reference when flying, either civilian or in the military. In fact, I don't know anyone who does or if it's even FAR/ICAO legal. I'd think not.
    If you're asking what they're using when they use the satellite data instead of the baro sensor to create the numbers, those in common use will correct the altitude due to earth's somewhat non-spherical nature -- it has a little middle-aged "equatorial bulge" around the waist -- using the WGS84 model. That not only locks in latitude/longitude for all of us as a common datum (instead of dozens of them unique to each country or area), it assumes a specific model of the earth that takes the "bulge" into account, among other things. Local variations throw the ideal of a WGS84 shape for a loop, though, and is why a GPS has to take those into account also. Of some interest, it's WAAS (something some folks here don't think matters much, but I appreciate for the additional accuracy it provides in x and y) that provides the additional information in the z axis. Again, the z axis doesn't interest me much when I'm caching, but it is interesting to know it's there.

     

    What I don't know is which WAAS capable units are actually taking the additional correction information into account when displaying altitude readings derived from satellite data.

     

    As a result, the corrected projection of altitude is actually very close to MSL. I'm sure my Garmin Oregon 450 isn't certified for an IFR approach in the vertical, but I do know that there are some Garmin units that solve for altitude the requisite 5X per second that are. So it can be done, and the results must be pretty darned good.

    Behind the scenes in the receiver, when the latitude, longitude, and height* are generated, the height starts out referenced to the WGS84 ellipsoid. Then for the user interface, a lookup table is used to apply a geoid offset to give MSL. That MSL height is what the barometer is calibrated to.

     

    If you look at the NMEA $GPGGA definition, it gives the MSL height and the geoid separation that was used to calculate it. That way, you can back it out to the more mathematically pure ellipsoidal height and maybe apply a geoid model that works better for you than whatever the receiver is using.

     

    WAAS doesn't really do anything specifically for height. It's just that the ionospheric corrections tend to give more improvement for vertical error than for horizontal.

     

    I am 99% sure that my car SatNav (a cheap Chinese import) reports elevation against the ellipsoid. (Either that, or my car SatNav is using an incorrect geoid specification.) Here in south-east Queensland, it consistently shows elevation around 20 to 30 metres higher than standard topo charts, etc. Elevation above MSL is of no consequence for car navigation purposes, so it really doesn't natter that they don't seem to have programmed the geoid corrections into the unit. However, it means that while the reported elevation gain / loss is reasonably accurate, I can't easily correlate my car SatNav's reported elevation against detailed topo maps, elvation markers, etc.

    Yeah, they probably just didn't bother. But this reminds me of a long time ago, figuring out that we had been applying the geoid separation with the wrong sign. The separation was small enough where we were developing that we hadn't noticed.

     

    *I was joking in my earlier post about elevation being an angle. But seriously, since "elevation" is already being used in GPS receiver software to describe the angle of a satellite, it isn't usually used to describe the height. That would just be confusing. Mostly, GPS people just simply say "height", qualified with "MSL" or "ellipsoidal" (or "orthometric" when they're feeling fancy). I totally agree that jargon can mean something very specific to one user group and something very specifically different to another user group. That's why I just leave that up to people who do market-specific user interfaces. :rolleyes:

  10. The 60 CSx will be significantly better in tree cover than the 60 CS.

     

    Not so much better in a gorge. If you're getting no position with the 60 CS, you might get a really bad one with the 60 CSx. If you're getting a bad position with the 60 CS, you'll probably still get a bad one with 60 CSx. Maybe a little better, possibly worse.

  11. You can try a full reset in case the stored almanac data is corrupted. Let it track continuously for about 15 minutes after the full reset to get a new almanac.

     

    Does it take a long time to even get one satellite? (could be hardware problem)

    Or is it getting some normally and taking longer for others? (more likely corrupted data)

  12. But increasing the number of GPS-capable devices also increases the load on the system of GPS satellites and infrastructure, which is aging quickly and in need of serious overhaul.

     

    What terrible journalism! Did they do no research? GPS receivers put 0 load on the satellites and infrastructure. GPS receivers are just that - receivers. The satellites put out the same signal and are under the same load whether there are 50 million receivers or just one.

    I was trying to give them the benefit of the doubt and assume they meant a political load, i.e. pressure on the GPS Wing to keep a high standard. But given how bad the rest of the article is, that might be too much credit.

  13. I'm looking at the data now. 133(46) isn't showing in the almanac of the existing two GEOs, but it looks usable.

     

    Its own almanac is showing itself as healthy. It's in test mode but, as usual for WAAS, the corrections it's giving are good. So you shouldn't have any problems if your receiver picks it up and starts using it.

     

    But even if your receiver normally uses the WAAS GEOs for ranging off of, it won't be for this one yet. It's still moving around a fair bit while they settle it into its orbit. The ephemeris says it's only good to 3-6 km.

×
×
  • Create New...