jks

A few small changes in today's update:

v1.306  July 18, 2019
    Admin GPS tab improvements:
        Galileo sats in alert are removed from the channel after a few seconds.
        New priority mode for QZSS. It's been pointed out that because there are relatively
            few QZSS sats at present (4 currently) they can be unfairly "locked out" if many
            Navstar and Galileo sats are being received and taking all the channels.
            If the priority checkbox is set the last two free channels are reserved for QZSS sats.
            This number is reduced if sufficient QZSS sats already occupy a channel.
            For example if 3 QZSS sats have a channel only one is reserved to try and capture the 4th.

Thanks to Kiwi forum member @fractional_n for the suggestion about QZSS.

So other sources are reporting that most of the Galileo ephemerides seem to have returned to normal. I have noticed this in my testing and the "TDoA capable" count on kiwisdr.com/public has been > 250 all day.

These same sources also said there was little correlation between sats with the alert flag set and sats with ephemerides "issue of data" (IODE) values indicating invalid navigation data. When I added code to track the age of updates to the IODE I noticed the same thing. So this criteria needs to be added in addition to just looking at the alert flag. This is apparently how professional receivers work.

Unfortunately GLONASS, BeiDou, NAVIC et al. don't transmit signals on the L1 frequency (1575.42 MHz, 2 MHz b/w) used by the GPS front-end chip of the Kiwi.

All right, v1.304 has individual enabling of Navstar/QZSS/Galileo acquisition.

Update: the Kiwi in Kuwait has an excellent, strong signal. The DRM signal itself is supposed to be coming from Kuwait according to http://www.hfcc.org/drm

There is a weak one right now on 11.970 MHz in the 25m broadcast band. This from a Kiwi in The Netherlands. Probably too weak to decode unless you can find a Kiwi with better reception. I agree that finding DRM broadcasts is harder than it should be. All the online schedules seem to be outdated.

All right, v1.304 has individual enabling of Navstar/QZSS/Galileo acquisition.

v1.303 is out with a new switch "Include Galileo?". Also fixed a bug where "Include alerted?" didn't have immediate effect each time you changed it. Also fixes-per-minute is shown as "f/min" at the bottom of the page.

Now I've seen cases where including non-alerting Galileo sats will change solutions ("S") from green to red reliably. So that seems to be an indication that not all sats capable of causing problems are marked alerted. But I've also seen plenty of cases where Galileo sats are providing perfectly fine solutions too.

https://gnssperformancemonitor.com/viewdata.php?constellation=2&timespan=1

Since last Thursday/Friday:

NOTICE ADVISORY TO GALILEO USERS (NAGU) 2019026
DATE GENERATED (UTC): 2019-07-13 20:15

NAGU TYPE: GENERAL
NAGU NUMBER: 2019026
NAGU SUBJECT: SERVICE OUTAGE
NAGU REFERENCED TO: 2019025
START DATE EVENT (UTC): 2019-07-12 01:50
END DATE EVENT (UTC): N/A
SATELLITE AFFECTED: ALL

EVENT DESCRIPTION: UNTIL FURTHER NOTICE, USERS EXPERIENCE A SERVICE OUTAGE. THE SIGNALS ARE NOT TO BE USED.

https://www.gpsworld.com/galileo-down-over-weekend

This may have implications for the Kiwi as the Galileo code does not currently recognize a sat being in an "alarm" state preventing its use in position/timing solutions. For example the alarm state of QZSS sats is correctly detected and an option exists on the GPS tab of the admin page to include alarmed sats or not (Q195 is in alarm as of this writing).

The Galileo code does look for alert pages in the I/NAV messages (page type = 1). But none of these are currently seen. We are looking more closely at the Galileo ICD to see what other bits might be present the code should be checking.

Below is an image where the position solutions differ substantially when Galileo is included in the pool of sats (red markers) versus not (green markers). The green markers are close to the true position.