From: Andy on
On Feb 15, 3:00 pm, Paul Keinanen <keina...(a)sci.fi> wrote:
>
> Take a look what happens to the elevation display, when you walk below
> a bridge, that obscures at least some of the satellites.

Walking under a bridge selectively also blocks out satelites at higher
angles above the horizon, which as stated earlier, increases the error
in the elevation calculation.

Andy
From: rickman on
On Feb 16, 3:16 pm, Paul Keinanen <keina...(a)sci.fi> wrote:
> On Tue, 16 Feb 2010 13:52:30 +0100, "Boudewijn Dijkstra"
>
>
>
> <sp4mtr4p.boudew...(a)indes.com> wrote:
> >Op Mon, 15 Feb 2010 19:22:25 +0100 schreef Paul Keinanen <keina...(a)sci.fi>:
> >> On Mon, 15 Feb 2010 04:13:09 -0800 (PST), Surinder Singh
> >> <gogreenmi...(a)gmail.com> wrote:
>
> >>> What would be best technology (GPS,IR,Radio/freq,ultrasonic etc) for
> >>> doing distance measurements upto 10km with accuracy of 1 meter?
>
> >> So the accuracy requirement is 100 ppm.
>
> >> Is this measurement in vacuum or in the atmosphere and if so, what is
> >> the refractive index during the measurement. Any mirages ?
>
> >> Even when using lasers or some microwave measuring devices, the
> >> propagation in typical atmospheric conditions will bend the beam
> >> slightly downwards, thus forming an arc and thus the reading would
> >> also be slightly too big.
>
> >Unless you would compensate for this predictable effect.
>
> >> The speed of light is about 300 ppm lower at sea level than in vacuum,
> >> so also the elevation and hence air density will affect the speed of
> >> light and this may also cause errors.
>
> >Unless you would compensate for this predictable effect.
>
> Perfectly true, if you do temperature and humidity measurements along
> the path to determine the refractive coefficient.
>
> Unfortunately, in practice, this is the hard part.

The total effect from vacuum to sea level air is 300 ppm you say. So
how much is it going to vary at sea level. I think the OP required
100 ppm accuracy, no? I wouldn't expect the 300 ppm effect to vary
more than 10, 20, maybe 30 ppm. Do you disagree?

Rick
From: rickman on
On Feb 16, 3:34 pm, Paul Keinanen <keina...(a)sci.fi> wrote:
> On Tue, 16 Feb 2010 12:13:54 -0600, Vladimir Vassilevsky
>
> <nos...(a)nowhere.com> wrote:
>
> >linnix wrote:
>
> >> On Feb 15, 7:27 pm, rickman <gnu...(a)gmail.com> wrote:
>
> >> Just convolutions and trigonometry.  Nothing heavy.  10 to 20MIPS
> >> should work.
>
> >The initial solution of the GPS system of equations starting from zero
> >knowledge requires a lot of number crunching. It could take several
> >minutes on the 10 MIPS machine without FPU.
>
> While I understand that in the old days, in the worst case, it takes
> quite a long time (several minutes) for a single channel GPS receiver
> to try out all the 32 PRN sequences in order to lock into at least
> _one_ GPS satellite and then wait until the whole GPS satellite
> constellation _almanac_ has been downloaded and after that, lock into
> at least 4 satellites to get the fix.
>
> However, these days, with a multichannel receivers, each "receiver"
> can search for a specific satellite PRN sequence in parallel and
> perform the required navigational calculations, without waiting for
> the satellite almanac.

Can you do the calculations without the almanac? Why would the older
systems require the downloading of the almanac if it isn't required?

Rick
From: linnix on
On Feb 16, 5:19 pm, rickman <gnu...(a)gmail.com> wrote:
> On Feb 16, 3:34 pm, Paul Keinanen <keina...(a)sci.fi> wrote:
>
>
>
> > On Tue, 16 Feb 2010 12:13:54 -0600, Vladimir Vassilevsky
>
> > <nos...(a)nowhere.com> wrote:
>
> > >linnix wrote:
>
> > >> On Feb 15, 7:27 pm, rickman <gnu...(a)gmail.com> wrote:
>
> > >> Just convolutions and trigonometry.  Nothing heavy.  10 to 20MIPS
> > >> should work.
>
> > >The initial solution of the GPS system of equations starting from zero
> > >knowledge requires a lot of number crunching. It could take several
> > >minutes on the 10 MIPS machine without FPU.
>
> > While I understand that in the old days, in the worst case, it takes
> > quite a long time (several minutes) for a single channel GPS receiver
> > to try out all the 32 PRN sequences in order to lock into at least
> > _one_ GPS satellite and then wait until the whole GPS satellite
> > constellation _almanac_ has been downloaded and after that, lock into
> > at least 4 satellites to get the fix.
>
> > However, these days, with a multichannel receivers, each "receiver"
> > can search for a specific satellite PRN sequence in parallel and
> > perform the required navigational calculations, without waiting for
> > the satellite almanac.
>
> Can you do the calculations without the almanac?  Why would the older
> systems require the downloading of the almanac if it isn't required?
>
> Rick

You can start the calculation without the almanac, but you need it for
fine tuning of the position. Newer devices might estimate the almanac
before downloading it from the satellite.
From: Paul Keinanen on
On Tue, 16 Feb 2010 17:19:57 -0800 (PST), rickman <gnuarm(a)gmail.com>
wrote:

>On Feb 16, 3:34�pm, Paul Keinanen <keina...(a)sci.fi> wrote:

>> While I understand that in the old days, in the worst case, it takes
>> quite a long time (several minutes) for a single channel GPS receiver
>> to try out all the 32 PRN sequences in order to lock into at least
>> _one_ GPS satellite and then wait until the whole GPS satellite
>> constellation _almanac_ has been downloaded and after that, lock into
>> at least 4 satellites to get the fix.
>>
>> However, these days, with a multichannel receivers, each "receiver"
>> can search for a specific satellite PRN sequence in parallel and
>> perform the required navigational calculations, without waiting for
>> the satellite almanac.
>
>Can you do the calculations without the almanac? Why would the older
>systems require the downloading of the almanac if it isn't required?

The almanac contains coarse keplerians for all satellites,
sufficiently accurate for determining if a particular satellite is
high enough above the horizon, so it is worth trying to lock into it.

Once you know which satellites look promising, you also know which
their PRN sequence and it is easier to search for those sequences
only.

In old single channel receivers, you had to try out all the 1023
"phase shifted" versions of a specific PRN sequence before lock, which
may take some time. With the almanac, you can narrow the test to those
interesting (above horizon) PRN sequences (satellites), which will
speed up the startup on old receivers.

The message from an individual message will contain the exact
keplerians for that particular satellite, so the orbit and hence
position of that satellite can be determined exactly for navigation
purposes.

A modern multichannel receiver will search for all possible PRN
sequences (satellites) in parallel and once four satellite positions
(with sufficiently geometry between each other and sufficiently high
above horizon), the receiver position can be determined exactly.

The satellite almanac is intended to help old single channel receivers
(dominant when the system was designed) performing a reasonable fast
cold start.