[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: Michael J. Tubby B.Sc. MIET
Subject: Re: [gpsd-dev] gpsd - AT command control on modems
Date: Tue, 16 Jul 2019 23:14:02 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

On 16/07/2019 19:17, Gary E. Miller wrote:
Yo Michael!

On Tue, 16 Jul 2019 08:53:49 +0100
"Michael J. Tubby B.Sc. MIET" <address@hidden> wrote:

While it is true that several GPS receivers work without needing the 
system Almanac, you have to be careful as strange things can happen 
since the Almanac contains the SV Operational Health for each of the 
Yes, there are a few tidbits in the almanac not present elsewhere.
Sat health is not one of them as each sat broadcasts that in its

Remember that SVN23/PRN23 had a failure of its onboard atomic clock
back in Feb 2016 and that any GPS receiver using it in its navigation 
solution was off by around 13.7uS ... this threw out GPS receivers
using it in the position solution by a mile or two.  We had hundreds
of emergency services vehicles in the south-west of England in the
wrong location for several hours until SVN23 was marked bad.
Yes, because the receiver failed to check the health status in the

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.

While starting up without the system almanac is common place these
days it is optimistic since it assumes that every SVN that you
acquire lock to is behaving and there is a chance that one or more is
not - there's also increased chance of trusting a spoofed signal... I
know, I tried ... its amazing what you can do with a HackRF-One,
Rubidium frequency standard borrowed from a friend and Linux GPSSIM
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.

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

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


Michael J Tubby B.Sc. (Hons) MIET / Technical Director
Email: address@hidden
Direct: +44 (0)1905 752892
Mobile: +44 (0)7973 225144

Thorcom Systems Limited
Phone: +44 (0)1905 756 700
Address: Unit 4, 96B Blackpole Trading Estate West, Worcester, WR3 8TJ, England, UK
Company registered in England & Wales No. 02704696 / VAT Number GB487925681 / EORI GB487925681000

This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed.
Any views or opinions expressed are solely those of the author and do not necessarily represent those of Thorcom Systems Limited.
If you are not the intended recipient of this email, you must not take any action based upon its contents or disclose it to any third-party.
Please contact the sender if you believe you have received this email in error.

reply via email to

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