jks

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.

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.