More Garmin woes

"I thought this was likely due to a bug in the GPSr software so I contacted Garmin, but they said that the time comes from the satelites and so there must have been a glitch in this signal."

I admire the Garmin person for trying hard to give you an answer to shut you up, but what was told was pure hokum. There was no problem with the downlink signal. If the time of the downlink transmission was as much as a nanosecond off, it would have been serious. That is why the various USAF monitoring stations watch these things very closely, and if one satellite makes errors or starts to drift too much, then it is taken offline and into maintenance mode.

Some people have tried to accuse sunspots for doing this, but I doubt it. Sunspots will very temporarily wipe out the downlink from one satellite.

It is rare, but something might have happened inside your Garmin receiver. Also, there could be something odd with the sorting algorithm of your analysis software. The software probably resides in a computer, and there could have been a power transient that flew through some computer bus.

Now, on rare occasions, there have been other problems with GPS, but these are mostly of an interference problem, and these get reported to a group at the US Department of Transportation. I've reported problems there, and they seem to react in some fashion. If some rogue terrestrial transmitter interferes with the downlink signal (1.57GHz), then it wipes out the entire downlink signal, and it does not just produce a one-minute mistake. The DOT group will react even if the reporter is from a country allied to the US.

–B.G.–

Bob, you appear to know a bit too much about all this GPS downlink stuff.

Do you by chance work for "No Such Agency"?

Are you monitoring our GPS use unbeknownst to us?

How about our SPOT signals?

And our Sat phone calls?

Bob, I like you and your tech knowledge but, and don't take this the wrong way, but do you wear a black suit to work?

I gave up on GPS years ago, after a brief trial, when I figured out that some terrestrial form in North Twentynine Palms was playing with the signal.

I decided it would be much more difficult for the form to screw up the earth's magnetic field.

1. No, I don't work for No Such Agency and I don't wear a black suit at all.
2. I have dealt with people from No Such Agency, but they would never admit to the exact organization that they did work for.
3. I started working in the telecom and GPS industry in 1994, and I've participated in industry meetings on GPS, so I am not a complete fool on the subject. I've helped many technical people figure out why their $50K system had a GPS failure and then suddenly cleared. This is over maybe twelve or fourteen countries.
4. I've helped customers install other big GPS rigs in their federal buildings, and those organizations were very closely aligned with No Such Agency.
5. Yes, I have spent a large amount of my time monitoring various GPS systems, but never anything to do directly with Spot or sat phone calls.
6. Currently I am trying to decide whether to be a taxpayer or not.

Nick, yes, they used to periodically run jamming tests at Twentynine Palms, China Lake, and most similar spots like that. Nearly always they would make a public announcement of each test in advance. That is because the civilian GPS downlink frequency can be jammed by a determined adversary. The military frequency is much harder to jam, so they had to run tests to see what got hit and what didn't. They don't do those very often now, which is why we are more dependent on GPS for lots of stuff.

–B.G.–

Stuart, my take is the unit restarted &/or the satellite ephemerides data or table updated… I have never looked at my individual track points that closely, but the next time I see an anomaly, I will…

"satellite ephemerides data"

How would the satellite ephemerides data cause a time offset this large?

–B.G.–

Several decades of experience fixing crappy programming (much of it my own) has taught me that most of these types of issues are the result of poor programming. It sounds like you are using your own code to interpret the tracks and if that is the case, you may have processed the track points incorrectly. You have to remember that the track points that a GPS captures are not necessarily sequential on the mapping plane. Poor reception might place one point 5 miles ahead of your current location, so if you process by coordinate sequence (positional relationship), the point with the poor coordinates will seem out of place chronologically.

I would next be suspicious of Garmin's programming. One of the most difficult things to handle in real time systems is latency. If the GPS gets bad reception and creates what we call (in the digital mapping world) a zinger… which is a set of coordinates that actually fall off the mapping plain, it may take a while (milliseconds) to process the point and if not handled correctly, a "good" point (or many) could actually be stored before the bad point has been saved.

I was an early adopter of the Garmin Foretrex series when it was released and Garmin made a huge screw-up in recording their track point dates. They were all stamped with the same date (06/01/2007) which was weird since it was released in 2010. They also had a real issue with their high sensitivity receivers when they were released. The track distances never agreed with the trip data. That took them ages to fix that one.

I complained to Spot about a problem I had with their device… after losing reception for about 20 minutes it placed the missed track points at my last know location (piled them all up on top of each other about a mile from where I was). The track points indicated that I was a mile farther back than I actually was and since the time was changing, it suggested I was sitting and resting when I was actually walking… could have been a problem in an emergency. The times were correct but the coordinates were all the same. They basically told me this wasn't wrong it was a "feature", they didn't want the track points to be lost. All of these issues are related to some form of poor programming.

Have a look at the track around this time. If the track has a small backtrack in it then it would seem to be an issue with the relative position of the readings in the file. I assume the file has been written in time sequential order and not been sorted by time. If the track is consistent (no back track) then most probably an ephemeris update or other glitch.

Bob should have posted more as a ? than a statement… as you point out it can not be the satellites and I don't think it is the unit; so what about the info sent… not sure how long the track was and how long the unit was on…

"Bob should have posted more as a ? than a statement"

However, my last post was a question and not a statement.

The ephemeris data isn't going to give you a one minute error.

I tend to agree with Mark about the way the data file is being written.

For example, if you were heading north and your latitude numbers keep increasing, then that is normal. If you suddenly got hit with some multipath interference, it might suddenly make your apparent position a half-mile behind you to the south. If the file is written a certain way, then the outlier point will appear to be out of the expected time order.

It is for reasons such as this why I always tried to look at a figure of merit of each data point. If you had eight satellites visible, then that normally leads to a smaller EPE (estimated position error), and if you had only three or four satellites visible, then the EPE might increase a lot. That simply makes the user look for problems in the reception environment and try to eliminate them.

It's really hard to say when we don't know what the analysis software was supposed to be doing.

It's even more fun if you get inside the GPS receiver and dink around with the Kalman filtering parameters. That will dictate how the outliers are filtered out.

–B.G.–

Ha! My day job is writing software and I've seen plenty crappy code too. However if I had to choose between software for a mil spec satelite and a consumer grade gadget that was probably outsourced to India or China, it wouldn't be hard to decide which was most likely to be reliable.

Let me be clear: my own software just flagged up the problem, by displaying a negative speed. I then went back to the original GPX file of the track recorded by the Garmin. GPX files are encoded in XML so are fairly human readable in a simple text editor. I could see the jump back in time right there in the original file. Looking at the shape of the track at this time would lead me to conclude that I was probably stationary at this time – the track wonders in a gently figure of 8 with no sudden jumps (my software is designed specifically to detect this type of false wonder and remove these extraneous points) and I know what effect multipath interference has on tracks having had direct experience of this before.

My gut feel is that this is a bug in the Garmin software and I'm a bit nonplussed that Garmin are not prepared to admit that this is even a possibility, it's not as if they don't have frequent software updates already. I've sent them a futher enquiry but no response yet.

Stuart,
I know very little about programing. But I can say that I noticed long ago when I call up any of the vendors in the tech industry, their first, second, and last explanation involves blaming the problem on either my computer or some other vendor… but always someone other than their company. It really irritates me.

Billy