GPSlug

Start putting the nails in LightSquared's coffin: NTIA and FCC Agree: No Practical Way to Fix LightSquared’s GPS Interference Problem

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.

This (pdf) is probably the best technical overview. There's tons of other stuff on saveourgps.org.

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. 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.

The most common typo is probably transposed numbers. See if switching a couple makes sense. Yeah, that's wrong. Must have meant NAD83.

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.

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".

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.

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.

It's all WGS84. Pretty much the whole impetus behind WGS84 and its predecessors was to have a consistent world-wide datum for all the U.S. military maps.

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?

Ashtech has launched a new web-based (javascript) planning tool. It even lets you put in an obstruction profile. 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.

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. 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.

No, you're wrong. Elevation is an architectural drawing of a vertical part of a building. Sheesh!

You're all wrong. Elevation is the angle something else is above your local horizontal.

The almanac I have says it's unhealthy. I haven't tracked it yet, so I don't know what it's putting in it's ephemeris.

Hmm. Do you use custom waypoint symbols?

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.

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)

You need to set the waypoint symbol that you use for unfound caches to be the geocache symbol. Hit menu-menu-"Setup"-"Geocache" to select the symbol.

Same datum. It's just that it would be UTM coordinates instead of lat/long.

A serious answer: No. A few cm per year is well under the accuracy used in geocaching.

Here's a simulation someone made of how much it will drift. Apparently it will still be broadcasting into July and the new one may be out of test mode as soon as October.

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.

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.