[time-nuts] Re: GPS Elevation Mask Values.

Tue Nov 23 03:29:31 UTC 2021

Hi Keelan,

I agree with your statements here. This is how the GPS az/el data should 
be generated. I might disagree that point is being overlooked. The whole 
point of plotting this az/el data (even if az/el values are calculated) 
is to see what the antenna sees and where. This could guide antenna site 
choice, elevation mask values, reveal antenna problems, etc.
(Give bragging rights to the person with the best sky view! :) )

Given how this should work, we still have a plot of az/el that doesn't 
match what should happen.

So, why is that?

The last few days a lot of time was spent trying to answer that 
question. It's turning into a saga that might not be over yet.

The first step was to plot the az/el from four different receivers 
(plots posted earlier). Turns out that two have errors in the north (A 
Ublox timing module and Ublox F9P module) and two did not (Venus and 
MediaTek). This is on two different PC's. At this point another test was 
started at an offsite location 15 miles away. This Ublox module also 
indicated the same issue. Huh?

Does this indicate a module problem? Several models of modules, at two 
sites, on three PC's. Ublox is pretty reputable and they've been doing 
this for a while. Seems odd Ublox would have a problem. If so, why now?

For the next run NMEA data was saved with screen shots. NMEA az/el data 
was plotted with other programs. U-Center was used, and some nifty 
utilities Tom Van Baak has were used to make a plot in excel. See plots 
UbloxTiming-LH.jpg, UbloxTiming-UC.jpg, and UbloxTiming-XL.jpg.

The u-center and Excel plots don't show the anomaly! More questions than 
answers. Why only LH when looking at only Ublox modules?

So, A couple USB to serial cables were then crossed over to send the 
NMEA data back to LH. The first test (a Sanity check) played the whole 
85Mb log back to LH (UbloxTiming-LHReplay.jpg) which matches the original.

The log was then cut up and played back in consecutively smaller pieces 
(A painful process!) until some offending data was found. Finally, a set 
of sentences that create point in the sky where it shouldn't be!

$GPGSV,5,1,17,02,26,108,43,05,67,054,49,07,05,037,,11,16,102,42*7F
$GPGSV,5,2,17,13,45,124,48,15,40,170,47,16,05,334,,18,37,294,46*73
$GPGSV,5,3,17,20,36,063,45,23,15,242,39,25,01,217,29,26,13,299,39*76
$GPGSV,5,4,17,28,,,26,29,66,215,50,30,06,066,,46,23,229,42*41
$GPGSV,5,5,17,51,33,204,44*4D

At this point Tom grabbed the ball and did some sleuthing. (It was late, 
he's a couple of time zones over...)

It turns out (Summarizing a lot here!), that while null characters are 
allowed in NMEA, null az and el values with good SNR are odd. Scanning 
the whole log for instances of null az/el data shows this only happens 
for PRN 28. The significance of this, is better stated in Tom's words:

----------------------------------------------------------------------
"...And what's special about that? Well, it's the newest GPS III (3) 
satellite and still undergoing tests. There are 32 GPS sats up there and 
31 are operating normally. PRN 28 is the only odd man out. The previous 
PRN 28, a block II (2) vintage, was deactivated a few months ago. See:

https://www.navcen.uscg.gov/?Do=gpsShowNanu&num=2021035

Also PRN 28 is not yet in the online almanac. See:

https://www.navcen.uscg.gov/?Do=gpsArchives&path=ALMANACS/YUMA&year=2021&exten=txt

and

https://www.navcen.uscg.gov/?Do=gpsArchives&path=almanacs&year=2021&file=34434&type=almanacContent--almanacId--YUMA&name=323.txt

In 323.txt look at the entries and find PRN 01 to 32, except for 28."
--------------------------------------------------------------------

OK, wow!

It appears there is a bird up there sending out who knows what. My 
official guess as to what it's sending is: "I have no idea!" :)

So now we have a sat flying around sending maybe odd data, and ublox 
receivers are reporting that bird in a quirky way, and LH gets all 
messed up trying to display that quirky data. Talk about a perfect storm!

Just a bit more digging. Tom made a few tweaks to his utilities, and a 
few copies of the NMEA log were created. The first removed svn 
28completely, and the other just removed the "28,,," values. Playing 
these big logs back to LH resulted in a the plot we expect to see, with 
nothing above the north pole. In my mind this at least verifies the 
source of the quirk is the "28,,," strings.

To be Continued...

Dan

P.S. A few quick additional notes:

The Venus in the LTE-LITE reports svn28 (I think with only valid az/el, 
but still checking).

The MediaTek on the Adafruit board doesn't even bother trying to report 
it. It's playing it safe!

On 11/22/2021 3:30 AM, time-nuts-request at lists.febo.com wrote:
> Date: Thu, 18 Nov 2021 12:01:28 -0800
> From: Keelan Lightfoot<keelanlightfoot at gmail.com>
> Subject: [time-nuts] Re: GPS Elevation Mask Values.
> To: Discussion of precise time and frequency measurement
> 	<time-nuts at lists.febo.com>
> Message-ID:
> 	<CAOp=Ki8ZfDF1GHeo1PCfcG6FSA8xLTEO0e3tCdKzz4_R1aibgQ at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
> 
> I still feel like an important point is being overlooked here: The receiver
> can not directly tell where in the sky the satellite is. It's impossible to
> determine that from a single point of observation. All the receiver can
> discern is the distance to the satellite. The sky plot is a prediction, not
> an observation.The sky plot is calculated from the almanac data received
> from the GPS constellation as a digital payload.  No combination of
> antenna, cable, or receiving conditions will affect the data contained
> within the almanac message. There are no satellites over the north pole,
> the receiver is just drawing a picture that shows it over the north pole
> based on the almanac data and a bunch of math used to calculate the
> predicted azimuth and elevation for the satellite. All of the satellites
> could be clustered over the north pole and just artificially delaying their
> signals (oh dear I've just made a flat earth argument), but as long as the
> almanac data showed them on their appropriate orbits, the sky plot would
> look perfectly normal because it's just a parallel construction.
> 
> That means that either:
> 
> 1. The GPS constellation is transmitting bad data in the almanac. Very
> unlikely.
> 2. Certain receiver firmwares have a bug in the formulas used to calculate
> the azimuth and elevations of satellites. Very likely. The fact that the
> plot noodles towards the north pole tells me that some equation is being
> pushed past a limit, and it's producing bogus data.
> 
> If you turn on the $GPGSV NMEA-0183 message, you can see the azimuths and
> elevations the receiver is calculating. I'll belabour the point that these
> are just calculations based on the almanac, and your current position and
> the current time. The only actual observed value contained in the $GPGSV
> message is the SNR value. So if the receiver reports that a satellite is
> flying over the north pole, or that it is somehow observable when it's in
> the southern hemisphere, it's because of bad math, not bad observations.
> 
> - Keelan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: UbloxTiming-LH.jpg
Type: image/jpeg
Size: 126361 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20211122/4de12e03/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: UbloxTiming-UC.jpg
Type: image/jpeg
Size: 164575 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20211122/4de12e03/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: UbloxTiming-XL.jpg
Type: image/jpeg
Size: 159047 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20211122/4de12e03/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: UbloxTiming-LHReplay.jpg
Type: image/jpeg
Size: 121165 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20211122/4de12e03/attachment-0003.jpg>