[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: |
Tue, 16 Jul 2019 15:36:13 -0700 |
Yo Michael!
On Tue, 16 Jul 2019 23:14:02 +0100
"Michael J. Tubby B.Sc. MIET" <address@hidden> wrote:
> > Yes, because the receiver failed to check the health status in the
> > ephmeris.
>
> No, the SV said it was 'healthy' but was wrong ... they fixed it by
> marking it bad in the system almanac, at least that's what the NavCen
> NANU said.
Got a citation?
Check out IS-GPS-200K.pdf
Section 20.3.3.5.1.2 Almanac Data.
Table 20-VI. Almanac Parameters
Then note the Almanac has no "health' flag.
Since the Almanac has to last a long time it has no short term parameters,
like health.
> > Before you can use a sat for a fix you need to get lock, then
> > download the ephemeris. If the receiver forgets to check the
> > health bit in the ephermeis then you bought a crappy receiver.
>
> Sure, but there's the issue of does the SV police itself and the
> answer is "not always". SVN23 went rogue but said it was good, hence
> it got trusted in position solutions which is why the ground station
> had to mark it bad in the Almanac.
See above. No health flag in the Almanac.
There is a health data in other parts of thhe subframe, just not
in the Almanac. So you are sorta correct, for the wrong reasons.
But, does this really matter to gpsd? I would hope that the receiver
looks at all thhe many health flags available to it before using a
satellite in a fix computation.
If the receiver is reporting bad fixes thhen gpsd is hosed no matter
what.
> > Spoofing is a much more complex issue. To handle that you need a
> > really new receiver that knows how to check for that. If you look
> > at the u-blox AED doc they are very clear to say their spoofing
> > detection is not to be trusted.
>
> Sure, it doesn't guarantee to be right, i.e. it may not detect all
> spoofing - from our testing:
>
> a) when presented with a constellation which has a mixture of mainly
> genuine SVs plus one or two 'bad actors' it usually gets it right
>
> b) when completely hidden from the real constellation [Faraday cage]
> and presented with signals from HackRF+Linux+GPSSIM it is easily
> fooled *if* your RefClock (into HackRF) is of good quality
The issue is not really if the receiver detects the spoofing, but if
the fix is marked valid with known spoofing.
RGDS
GARY
---------------------------------------------------------------------------
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
pgpnEhUrBxM_k.pgp
Description: OpenPGP digital signature
- Re: [gpsd-dev] gpsd - AT command control on modems, (continued)
- Re: [gpsd-dev] gpsd - AT command control on modems, Gary E. Miller, 2019/07/13
- Re: [gpsd-dev] gpsd - AT command control on modems, Paul Fertser, 2019/07/14
- Re: [gpsd-dev] gpsd - AT command control on modems, Gary E. Miller, 2019/07/14
- Re: [gpsd-dev] gpsd - AT command control on modems, Paul Fertser, 2019/07/14
- Re: [gpsd-dev] gpsd - AT command control on modems, Gary E. Miller, 2019/07/14
- Re: [gpsd-dev] gpsd - AT command control on modems, Hal Murray, 2019/07/15
- Re: [gpsd-dev] gpsd - AT command control on modems, Gary E. Miller, 2019/07/15
- Re: [gpsd-dev] gpsd - AT command control on modems, Michael J. Tubby B.Sc. MIET, 2019/07/16
- Re: [gpsd-dev] gpsd - AT command control on modems, Gary E. Miller, 2019/07/16
- Re: [gpsd-dev] gpsd - AT command control on modems, Michael J. Tubby B.Sc. MIET, 2019/07/16
- Re: [gpsd-dev] gpsd - AT command control on modems,
Gary E. Miller <=