Re: GPS for mountain walking

Adrian Godwin wrote:

You first want to acquire data about signal strengths in forests
at various times of the year, then find or build a facility that
provides similar signal strengths (and multipath etc.)

Like I said, it's not just a question of signal strength, there's also the
issue of picking up signals from different directions, and maintaining lock.

What I was also going to mention was that when geocaching in a forest, you
are moving, therefore signals are being gained and lost constantly. The
unit's ability to maintain lock whilst individual signals come and go is a
critical factor in geoching, as it is in simply walking through a forest, so
whatever else the test may have been useful for, it doesn't give much
information on how well a moving GPS in a forest will perform. As I said,
my 60CS is very good at keeping lock once it's got it.

in a
repeatable way that doesn't depend on the season or weather.

Much fuss is made about weather, but I've never noticed reception being any
worse in bad weather, and that includes heavy rain and fog. I once recorded
an excellent track through a forest in torrential rain.

In fact, the worst reception I can remember was on a clear mountain top on a
fine sunny day (not hot or hazy). For most of that day I only picked up 5-6
satellites, so I think that the satellite constellation is far more
significant than the weather.

Actually, though, he doesn't try to justify it this way : he
admits it's a flawed test and states that he intends to improve it
later. Whether that makes it completely useless is arguable -

It may be useful for something, but not really for measuring the usefulness
of a unit when moving through a forest.

That's more information than I had before I read
the article even if I don't know how they'll all behave in
more realistic conditions.

I will point out two things which will be obvious to some, but perhaps not
everyone.

1. Don't use battery save mode in a forest, that's just asking for
problems.

2. When reception is potentially bad, such as in a forest, you can get
better reception by holding the unit out in front of you, higher up and away
from your body (and vertical in the case of the 60CS). Just removing your
own body as a cause of blocked signals can make the difference between
keeping lock and losing it.

There are certain places in the Ystradfellte valleys where the sides are
particularly steep and I usually tend to lose lock, Farewell Rock is one,
Sgwd Gwladus is another. I usually find that the 60CS keeps lock all the
way to Sgwd Gwladus, and can keep it if I'm careful, but once I lose lock
there, I can't get it back. Most of the time I can't be bothered to go to
the extra effort to keep a good signal, it tends to interfere with the walk
and the photography too much, but if you really need to maintain a good
lock, you can improve your odds by holding it up high away from your body.

Paul's better experience of the 60cs
in his conditions is also interesting, but unfortunately he
hasn't got a 60csx to do comparisons with.

Nope. I do remember someone sending me a track of a walk around the
Ystradfellte Falls area with a SporTrak and I think it kept lock all the way
around! I've never managed that with my Garmins, but my 60CS is better than
my 12 was.

The conclusion that I think I'd draw is that if were in the
market for one of these, I'd seriously consider paying a bit
more for the csx,

That's what bothered me about the test, it gives the impression that the
60CS is a bit naff. It's not. So it's not very good at getting a lock
inside a building! So what? I don't need a GPS to navigate to the kitchen
to make a cup of tea! In the real world, I have no complaints with it. The
kinds of places that I tend to lose lock are the kinds of places that any
GPS would lose lock. It doesn't matter how good the receiver is, signals
can't travel through solid rock (so scrambling up a rock face with rock in
front and your body behind is bound to cause problems for any receiver).
Forests are rarely a problem, unless they're in a deep valley, and you're
hardly likely to get lost walking along a valley, are you?

Paul


.

Relevant Pages

  • Re: GPS for mountain walking
    ... For a start, in a building, you can only pick up signals from one direction, ... whereas in a forest you'll be picking up signals from ... trees don't form a solid blockage in any direction (except in a particularly ... and this will help the GPS to maintain lock. ...
    (uk.rec.walking)
  • [PATCH] signal handling race condition causing reboot hangs
    ... But the "sighand" lock is dropped in several cases before the task's ... If a process running on another cpu posts a SIGCONT or SIGKILL just after ... has blocked all other signals will result in an unkillable process. ... running with kill(-1, SIGSTOP) and killcalls to temporarily ...
    (Linux-Kernel)
  • Re: Xilinx DCM Reset
    ... is present in order for it to lock. ... the sdram clock is output to ... then fed back into the FPGA and finally to the DCM. ... CLKIN and either the CLK0 or CLK2X signals to be present and stable ...
    (comp.arch.fpga)
  • Re: semantics of pthread locks
    ... then signals a waiting thread when it detects that the condition ... redundant testing for the condition. ... : lock. ...
    (comp.os.linux.development.system)
  • Re: Digital PLL acquisition problem
    ... I want to lock on a 22170 Hz sine signal in 10 ms lock time ... So I put a window at the ouput of my filter to only sweep in a 2600 Hz ... If you sample the data first, then implement your PLL, a pure-logic state machine frequency/phase detector will have an uncertainty around the edges of +/- 1/2 sample, which quite broad for many purposes. ... Assuming that the tone is strong enough you can get the same effect by estimating the incoming signal's phase and counting rotations -- this works very well in practice, with much noisier signals than you can hope to use a frequency/phase detector on, and doesn't have the edge uncertainty. ...
    (comp.dsp)