jks

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.

Alright, I got lucky with some TDoA results and have a new theory. What I thought was the receive site described above is actually the transmitter site (marked "OTHR/CYP2" on the TDoA map below). If you look at that Google map it shows three long element arrays each at roughly 30 degrees to each other (individual array elements are small white dots if you zoom in far enough). This structure is very similar to the JORN arrays seen at three locations in Australia.

To me this makes some sense as this OTHR is very often heard transmitting on multiple frequencies simultaneously. If the beam steering of an individual array has limits then multiple arrays at different angles might be needed to cover the areas of interest.

The Akrotiri site (marked as reference "OTHR/CYP1" on the TDoA map) is full of dozens of Yagis and other TX/RX capable antennas. Probably not the place you want a multi-megawatt ERP service co-located.

I have updated the documentation at http://kiwisdr.com/quickstart/index.html#id-sdr_hu-dup to be more clear about this problem.

One final (for now) update. I tried to give a Kiwi demo on the built-in browser of my "smart TV". Didn't work of course (no audio). This update fixes it.

You get a number of GPS status indications in the output from a /status query of a Kiwi. Instantaneous GPS "lock" isn't one of them, but you can derive it by looking for the "fixes" counter to increment between several queries spaced a few seconds apart. For example curl kiwisdr.jks.com:8073/status produces:

status=active
offline=no
name=0-30 MHz SDR, ZL/KF6VO | Tauranga, New Zealand
sdr_hw=KiwiSDR v1.292 ? ? GPS ? ? ANT-SWITCH ?
op_email=...
bands=0-30000000
users=0
users_max=4
avatar_ctime=1560738755
gps=(-37.631016, 176.172019)
gps_good=6
fixes=39613
fixes_min=30
fixes_hour=1792
tdoa_id=ZL/KF6VO
tdoa_ch=2
asl=30
loc=Tauranga, New Zealand
sw_version=KiwiSDR_v1.292
antenna=Marginal sensitivity
uptime=79688

The fixes_{min,hour} counters are for the benefit of TDoA and have a much coarser update rate. Too long to be used as a lock indicator I think. gps_good being >= 4 used to be a necessary-but-not-sufficient condition for lock. But no longer due to Christoph's Kalman filter.