[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] gpsd - AT command control on modems

From: Gary E. Miller
Subject: Re: [gpsd-dev] gpsd - AT command control on modems
Date: Sun, 14 Jul 2019 12:35:23 -0700

Yo Paul!

On Sun, 14 Jul 2019 22:05:30 +0300
Paul Fertser <address@hidden> wrote:

> Hey Gary,
> On Sun, Jul 14, 2019 at 11:24:08AM -0700, Gary E. Miller wrote:
> > That is not the policy of this list.  Or any other list I am on.
> > Reply All has long been discouraged here.  Last time we stopped
> > it was because of the echo storms it caused.  
> I am using "group reply" on this list and nobody complained so far :)

Hmm, I thought I did?  And it caused problems with another user just this

> So we must be talking about different things here; I'm talking about
> the feature of a MUA.

Or talking past each other...

> > > > No modern GPS needs assistance data.  That just speeds up the
> > > > start, which for a new GPS should still be under 2 minutes.    
> > > 
> > > I would speculate assistance data can help a lot when the
> > > reception conditions are too poor (EMI, physical obstacles) for
> > > reliable reception of ephemeris from the sats but good enough to
> > > be getting time signal from them. Am I wrong here?  
> > 
> > Here we prefer data and experience to speculation.
> > 
> > A modern GPS will just listen to all GPS at once on startup.  If
> > there is a strong enough signal then the ephemeris for that sat is
> > downloaded in 90 seconds.  
> If we are talking about legacy GPS it should be 30s IIRC.

Implementation dependant.  30 seconds after the subframe data is
streaming in, but other stuff needs to happen first.  The data carrier
needs to be synced to.  Then the GPS usually waits for the start of
the next subframe.

But 30s or 90s, not worth getting the assistance data.  The assistance
data will be closer to the almanac data so the ephemeris still needs to
be downloaded.

> > If the signal is not strong enough, then the ephemeris is useless.  
> I thought the signal requirements for the C/A code to be used for
> ranging are a bit lower than they're for demodulating LNAV from
> it.

Yes, but then would you really want to use that in a fix?

> And with L2C this should be even more evident with the CL
> code. This is just a speculation on my part, indeed.

A big part of L2C is making the data easier to decode.  But since L2C is
not yet ready for prime time, it is indeed just speculation.

> I think I've heard about receivers being able "to keep the fix" in
> conditions where it was impossible to acquire it from a fresh
> state. However, I'm not able to provide any real data indeed.

All guesses until we have hard data.

> > So only GPS with only a few receive channels, mostly older ones,
> > benefit from assistance data.  
> Yes, the number of correlators. Also they were benefiting from
> remembering almanac and the last known date and position so they would
> try decoding signals from sats that were supposed to be visible in
> that particular moment and place. Good ol' times eh ;)

There is no benefit to keeping the almanac when you have a 72 channel
receiver.  You just listen to all sats all the time.

> > This is why the more modern GPS no longer even support assistance
> > data.  
> I remember ublox (ANTARIS 4) being able to get a fix within few
> seconds when current ephemeris were known. It might have been
> meaningful from power saving point of view. Not sure what exactly
> changed since then (there already were enough correlators to
> concurrently decode signal from all the birds flying).

If you are worried about saving the tiny power that turning off the GPS
saves you then the last thing you want to do is turn on a power hungry
ethernet or wifi to download assistance data.

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin

Attachment: pgpyF_GlrRp0z.pgp
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]