A friend recently asked my advice following an experience with an MRT call-out in the mountains.
The team members are equipped with radios that add a GPS fix to each transmission, allowing the users to be tracked. In the event in question, the radio wasn't used until the team member arrived at the casualty. The fix placed the incident on one side of a mountain ridge, and a helicopter was called in to this location.
As it happens, the GPS fix was wrong, and the incident was actually on the other side of the ridge.
Since I'd discussed the effect of multipath and reflections on a UKC thread, the question to me was "was this a multipath incident?" And my conclusion, looking at the traces of the incident, was that it almost certainly was (strictly, it was a shadowing & reflection problem). Quite where the reflections were coming from that fooled the GPS receivers is hard to determine, but the incident occurred in a gully that gave at least 270 degree blockage, and in some parts, formed an almost complete bowl.
The problem is associated with canyons, and occurs in mountainous and urban environments, where the direct path between satellite and receiver is blocked (or 'shadowed'), but a signal is received from a reflecting surface, such as a cliff face or tower block. These reflections add additional path lengths to the measured pseudoranges, and so fool the triangulation calculations, pulling the fix away from the actual position. The problem is exacerbated by the increasing sensitivity of modern receiver chipsets, which can lock onto, and track the (generally) weaker reflected signals. As the satellite constellation moves about, the reflections come and go, so a static user can appear to jump about. If a satellite moves into direct view, this will often cause the position fix to jump back to the 'real position'.
The next obvious question was: "how can we tell when this effect is happening?"
Sadly, the answer to that is "tricky..." Here are a few things that should start to ring alarm bells, and let you consider the possibility that the fix may be in error:
You're in a gulley, or a steep-sided valley. There are slab-sided rock faces around you (although even more rounded or broken-up surfaces will cause problems).
If you're tracking users, and have regular updates*, then look out for sudden, large changes of position, which will look like long, straight track sections (you need to consider the time interval between fixes, too, as lack of intermediate position updates will also look like this). Also watch out for zig-zagging paths, since these are often caused by changing reflections. Of course, they can also be caused by zig-zagging up a steep face... It might be possible to provide a graphical indication of large jumps, by colour-coding the traces with apparent velocity, so that jumps are highlighted in red, for instance, and 'normal progress' in green.
* that might be another recommendation: make sure users report their positions regularly, and don't simply wait until they're 'in position'; that way, you can track their progress, and probably detect large position jumps. If you're using radios that prepend a GNSS fix to all voice transmissions, instigate a regular 'comms check' procedure (this might simply be a pressel/PTT, rather than an actual voice message), or, if the radio supports it, enable a regular, autonomous position transmission. You'd need to consider the effect on battery life, of course.
Keep an eye on the receiver's accuracy estimate, since the receiver computation should be able to determine that the signals "don't add up"; the longer reflected path length is likely to cause a large error circle (cf a conventional 2D resection on a map; think about the size of the 'cocked hat' if you deliberately include a bearing error). A poor accuracy estimate should warn you that something may be amiss.
If you can display the satellite constellation and C/No values for the receiver, you might be able to see if the geomorphology is blocking a number of satellites. If your control station is fairly close to the incident (say 50km), then, if it has a clear view of the sky, you should be able to know what satellites should be visible, and compare them to the satellites received by a team member. Since the satellite orbits are known to the system by almanac and ephemeris, it ought to be possible to display the predicted satellites (although I cannot tell you a system that will do this; GPS Test, perhaps?).
For a receiver equipped with mapping of some sort, and a user who can navigate without GPS, it should be obvious that the receiver is giving an incorrect fix (e.g. in this case, obviously on the wrong side of the ridge), and this might be reported to control. Assuming voice comms is available...
Oh, and SBAS (WAAS/EGNOS etc) won't help, since it corrects (mostly) for clock and ionospheric errors, and knows nothing about the local multipath & reflection environment, so cannot correct these errors.
For the future, one might envisage a system that used ephemeris and a terrain map to predict possible reflection hot-spots, and provide a warning to users and control that GNSS fixes might be being distorted, either in real time (using a constellation model), or statically (using only the terrain map). There is quite a lot of work going on at the moment addressing this problem of shadowing and reflections in urban environments (since urban users now dominate GNSS use). There are a couple of interesting figures in the following paper that illustrate the sort of problems that occur, and the kind of traces that result from reflections distorting position fixes:
http://www.cs.bgu.ac.il/~eranfrie/gnss_signals_in_urban_canyons.pdfThe yellow trace is the actual path, and the red trace is the GNSS computed path.
My understanding is that SARLOC retrieves more data from the receiver than a simple position fix, and that data might usefully be displayed to a control operator to help identify possible reflection issues (estimated error radius, visible constellation, C/No). The coloured trace & error radius ideas would be applicable to MRMap. If any of the MRT/SAR types on here have contacts with SARLOC or MRMap developers, feel free to pass the suggestions on. I'm also more than happy to hear feedback on the discussion above; it was pointed out that my naďve, laboratory-based suggestion of a way to reduce reflection effects might be the last thing on the mind of an MRT member on a steep, wet, scree slope...
