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.

So we got this working with the two Kiwis on ports 8073 and 8074 respectively, behind the 4G router and the proxy enabled for both.

Also, the Kiwi network scanner (kiwisdr.com/scan) has been updated to version 1.5 and allows you to specify the port number instead of always using the 8073 default. Handy in the case of a Kiwi with port number other than 8073 with a local ip set by DHCP, and the ip has moved and you don't know what the new one is.

An ip:port combination must uniquely identify a single network connection. So there is no conflict with having two port 8073 devices on your local network, the 10:8073 and 103:8073 devices. Each can be reached separately and simultaneously. The problem comes when trying to reach them from the Internet via your modem/router.

On the Internet-side of the router there are only addresses of the form public-ip:port So a particular public port can only map to a single device on the local side e.g. pub:8073 => 10:8073 Assuming you have access to the NAT configuration of your router, which you may not for a 4G modem/router, you could also have, say, pub:8074 => 103:8073 Or if you have configured the "103" Kiwi to use port 8074 successfully (you had an issue doing this?) then pub:8074 => 103:8074

In your particular case the issue is slightly different because you're using the Kiwi proxy due to not having configuration access to the router. The proxy is mapping name1.proxy.kiwisdr.com:8073 => 10:8073 The proxy always has to use port 8073 with proxy.kiwisdr.com With v1.290 it is now possible to simultaneously map name2.proxy.kiwisdr.com:8073 => 10:8074 (note "name2" and "8074"). On the public side the use of "name1" and "name2" will differentiate the two Kiwis.

But on the local side you must use two different port numbers because of how the proxy works. It is not able to configure any NAT in your router that might otherwise allow using the same port number on the two Kiwis on the local side.