Galileo down [alert flag added in v1.302]
Since last Thursday/Friday:
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.
Attachments:
https://forum.kiwisdr.com/uploads/Uploader/26/c9594facd659cddcda1c4b584dbabd.png
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.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.
Attachments:
https://forum.kiwisdr.com/uploads/Uploader/26/c9594facd659cddcda1c4b584dbabd.png
Comments
I wonder if this intentional disruption.
Sorry I meant to say "Nothing to see here, everything is normal, move along"
--for info--
I did turn on "always aquire" just before the screen shot, wanted to see if it recovers, other Kiwi just booted up to much more sensible locations
Mine was not appearing even though I had 29 fixes/min, although it just appeared now on the TDoA map. Still not as many receivers as usual.
It's probably a ransomware attack at the EU control, someone got an email with subject "Glonass wants to be your friend, click here to confirm".
Joking apart I fully expect the BBC to hang it on the Russians tomorrow.
Just checked, I have two GPS antennas, one on a pole at about 8ft and one close to a wall at about 6ft, the higher one is fine, the lower now thousands of miles out.
If you have had the admin page open for a while refresh it, check "always aquire" is enabled (unless the Beagle is heavily loaded) and check GPS connections are tight as mine was very marginal with the normal GPS antenna (not very high or in the clear).
I found the map freezes on mine if I leave the admin page open too long while there are good few channels in use.
The RSSI figures are not great, on my kit antenna they are all above 500 and 6 of the 8 "good" ones over 1100.
Please be sure you have "Include alerted?" set to off and try restarting. When non-alerted Galileo sats are present I'm now seeing the red and green position markers on the map back in close agreement as before. This in NZ and the USA. I'd be interested in other reports.
worked out to roughly 21, 24, 13, 20.
Did look like bad data was getting through, quite possible as there is little fault information from the Galileo squad (other than "don't use").
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.
We probably need individual selection of which sat systems (Navstar, QZSS, Galileo) to include/ignore during sat acquisition.
The problem is, due to mountains I have limited coverage of the sky. Sometimes I have only two Navstar SVs visible.
Didn't the kiwi had GLONASS support once?
Anyone else seeing this?
If this works okay then add Galileo back and try with and without the "Include Galileo?" switch set.
The bug is that sometimes when Galileo is enabled and not giving solutions the code appears to get "stuck" and you never get any good solutions again without a restart. Even after setting "Include Galileo?" to off which normally works as expected.
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.
I have all the checkboxes on the GPS settings tab checked.
EDIT: OK... now all of the sudden it is working (better anyway). 6 sats, 4 good and I am finally getting frequency corrections. This is very strange.
One question - I seem to recall GPS operation is somewhat related to the channel load on the KiwiSDR? Mine is fairly heavily used, although I am not sure how much use there is in the wee hours. It had 3 or 4 users when I first checked earlier this morning it had few sats. Now it had just one user. Oh, and now 8 sats and 5 good. And sats are appearing on the Az/El map. Weird.
I have device with a commercial GPS timing receiver. After powering it up it runs a discovery mode where it is determining the location. Once this is done, it is assumed that the position is stationary. Apparently this helps to get better timing precision.