GPSlug

I checked just now and 133(46) is transmitting now, but it's only sending out message type 0 full of zeros. So, not even close to usable.

The oscillator could be drifting out of spec with age. That would make it take longer to get its first batch of satellites because it wouldn't be looking in the right frequency window before it solved for its own clock drift. Another option is that the real-time clock is giving out, and it doesn't know the right time when its first turned on. Is the set of satellites you eventually get more or less the same as it first started looking for? Either way, there's probably not much you can do about it for a reasonable cost.

It's a matter of semantics, but I would say that if there is any conversion necessary, no matter how trivial, the units have changed. If you are recording distances in a list, and they are all the same unit, you can specify that unit at the top of the column. You can't do that if some are in m and some in km. If you need to specify it, it's a different unit. But if you are driving and need to glance at the display to know how far the next turn is, you may not want to need to squint at the units identifier. They can be annoying, but they keep you on your toes. You always need to be rigorous about your units. You can't just get lazy because it's all "metric". If you're told a vehicle is going "35", you'd better know whether that's in km/h or m/s. It's not that big of a leap from there to imperial units.

The ionosphere can become more active and cause both ranging errors and, in extreme cases, tracking problems. These are more frequent around solar max, but they can happen anywhere in the 11-year cycle. NOAA has a space weather site that predicts and monitors these storms. I don't see that anything significant happened this last weekend. WAAS helps a lot to correct for iono errors, and gives an indication of the amount of remaining error that your receiver can use to bump up its EPE if things are bad.

Heck, not even that. It's still running in "test mode" (transmitting message type 0 = not usable for safety-of-live/aviation), so the signal hasn't changed at all. As far as I can tell, the only thing this announcement meant is that someone was able to check off a milestone. The timing of it probably has to do with there being a European space conference this week. Use for safety of life is supposed to happen later this year.

I believe on the Trip Computer screen, you can set the two large fields to "Location Current" and "Location Selected" (or something like that) to do what you want.

Have you tried all the software "repairs" yet? (i.e. new location, hard reset, reload the firmware) Did it suffer a fall and just stop working suddenly? Or has it been getting slower start-ups over time until it stopped altogether?

My 60Cx was slowing down more and more. Between the accumulated gpx track files and the different map sets I had on it for quick swapping, I figured the micro-SD was getting fragmented. So I pulled all the files off of it, re-formatted, and put just one map file back on it. It loads a heck of a lot faster now using the same map set I was before. That set isn't really large, but it isn't tiny (~300 MB between CNNA-NT, Ibycus Topo, Calgary Trail Maps, and Florida Topo).

MENU - MENU - Setup - System: The first item, "GPS", can be set to "Battery Saver" or "Normal" (or "GPS Off" or "Demo", which you obviously don't want).

Ok, I checked it again. The format I'm looking for has 6 digits after degrees, not 5. That's just an extra decimal place. It's the same as Degrees, Minutes and Seconds DDD° MM' SS.SS" N 32° 18' 23.10" W 122° 36' 52.50"

There's no inherent bias between a WAAS-corrected position and an uncorrected position. So you don't need to worry about that. It's important to keep in mind that over the last several years, users become experienced with how their units behave during solar minimum. Now that we are slowly moving into a period of higher solar activity and increased ionospheric errors, people might find that WAAS becomes more important for them. But even that will be sometimes no big improvement, and sometimes a lot.

It's probably just the SAASM chip that's the sticking point. This could conceivably be a demo/integration unit without the SAASM.

Well it did say "air force" officials. "Typical" could mean "as present in the existing system", which could include the P(Y) signal. I think it's "typical" for "when it leaves the satellite". I.e. not including atmospheric errors and multipath. The article doesn't explain it very well, but this is one of the existing batch of satellites (block IIR-M) that was modified to add on the L5 signal for test purposes. It was a little rushed compared to the rigorous testing that a satellite design normally goes through. Apparently there's a problem with the signal combiner that's throwing off the other frequencies in a way they may not be able to compensate for because it seems to vary with angle. The satellites with L5 designed in (block IIF) wouldn't have the same problem, but they aren't ready yet.

There are some very interesting numbers in there. I have a theory, but I'd like to see more information first. Does anyone have a link to the older threads? I'm having a hard time finding them. Was it always a constant east/west offset?

Here's the full report and subcommittee hearing. This is largely about delays and budget overruns from the contractors making the next generation of satellites. It's gotten to where they'll be cutting it a little close to get them up as the older ones wind down. In some ways, the satellite deployment has been a victim of it's own success. Historically, the satellites have operated much longer and much more reliably than they were designed for. This has always meant that their budget gets cut and the launch schedules stretched out. So there could be a gap where the constellation isn't full. I don't think there's much risk of the system not meeting its specs. But there's some chance it could take a hit on how much it's been outperforming those specs.

It started transmitting L5 on April 10. I don't have an L5 antenna feed at my desk, but I am tracking L1 & L2 on it right now. Since it's unhealthy, I have to force the receiver to do so.

Mar 24: Launched Mar 28: L1 & L2 Transmitters activated It's still set to unhealthy in the almanac, so your receiver won't be using it yet. mattalbr: If TerraPOS uses precise orbits like those generated by IGS, PRN01 might be included already in those products.

A key question here is: Is it always off in the same direction?

This is just speculation, but given the wide area, it sounds like they are picking up some data they can't handle. Once in a great while, satellites that are set "unhealthy" can put out some funky nav data. It shouldn't be anything the receiver can't ignore, but it can expose bugs; like buffer overruns. There is a new prn 01 that isn't set healthy yet, but started transmitting on the 28th. I'll try to capture some data to see if there's anything noticeably weird. But it might be too late now.

I agree, I had a solid lock on 51 with 3.90, but no "D"'s. Does that mean the unit was using the corrections, but just not displaying the "D''s? I am not expert enough to answer that question, just wondering if anyone knows. If you have a serial cable, you can look at the $GPGGA messages coming out. If the quality field is '2' or higher, it should be correcting.

Definitely not anything that needs to be calibrated. It's basically impossible for a consistent position error to be caused by a hardware problem.

They were originally defined to be essentially the same. But as time has gone on, the actual measurement of WGS84 or NAD83 has been done by different entities with different priorities (e.g. more global consistency vs. better alignment with existing benchmarks), and they aren't quite the same any more. For a handheld, it doesn't really matter and the old NGA table that says the difference is basically zero. When you really need an absolute position within the accuracy where it matters, you need to be more specific than just "WGS84" or "NAD83" and specify which realization (which time the big set of measurements was done to define it) is relevant.

So then is it 2 GYPSIES WITH NO MOSS BETWEEN OUR TOES?

Like EraSeek said, as long as you are inside the iono grid, the distance to the nearest station doesn't really matter. Local affects get washed out in the network. It's zero, zero, and zero. Errors are not a part of the DOP calculation. I think the difference from older models is that the error correction algorithm went from being done in software to being done on the tracking chip. FEC is a CPU hog.

Assuming you mean #6 in number of finds, it's BPCachers at 3413. Luckily I already had a link to cacherstats.com.