The KiwiSDR 2 online store is open for orders! Please visit kiwisdr.nz
Can kiwirecorder select the rx channel it uses or can I detect the rx channel in use?
We would like to use wsprdaemon with the 6 audio-only channels of an 8 channel Kiwi.
While kiwirecorder most often prefers to use one of the audio-only sessions, frequently I find a kiwiwrecorder session on one of the the 2 waterfall rx channels of a private kiwi with no other listeners than wsprdaemon.
I suppose that I could find a way for a script to get a list of currently active rx channels, but I would prefer to address the root cause of this behavior.
Here is an example from KPH:
RX0: "wsprdaemon_v2.3" (10.14.70.84, unknown location) 14097.10 kHz usb z0 161:35:22
RX1:
RX2: "wsprdaemon_v2.3" (10.14.70.84, unknown location) 24926.10 kHz usb z0 161:35:21
RX3: "wsprdaemon_v2.3" (10.14.70.84, unknown location) 10140.20 kHz usb z0 161:35:21
RX4: "wsprdaemon_v2.3" (10.14.70.84, unknown location) 18106.10 kHz usb z0 161:35:21
RX5: "wsprdaemon_v2.3" (10.14.70.84, unknown location) 28126.10 kHz usb z0 161:35:21
RX6: "wsprdaemon_v2.3" (10.14.70.84, unknown location) 21096.10 kHz usb z0 161:35:21
RX7:
While kiwirecorder most often prefers to use one of the audio-only sessions, frequently I find a kiwiwrecorder session on one of the the 2 waterfall rx channels of a private kiwi with no other listeners than wsprdaemon.
I suppose that I could find a way for a script to get a list of currently active rx channels, but I would prefer to address the root cause of this behavior.
Here is an example from KPH:
RX0: "wsprdaemon_v2.3" (10.14.70.84, unknown location) 14097.10 kHz usb z0 161:35:22
RX1:
RX2: "wsprdaemon_v2.3" (10.14.70.84, unknown location) 24926.10 kHz usb z0 161:35:21
RX3: "wsprdaemon_v2.3" (10.14.70.84, unknown location) 10140.20 kHz usb z0 161:35:21
RX4: "wsprdaemon_v2.3" (10.14.70.84, unknown location) 18106.10 kHz usb z0 161:35:21
RX5: "wsprdaemon_v2.3" (10.14.70.84, unknown location) 28126.10 kHz usb z0 161:35:21
RX6: "wsprdaemon_v2.3" (10.14.70.84, unknown location) 21096.10 kHz usb z0 161:35:21
RX7:
Comments
We have 2 kiwis on RadioHill and are decoding wspr with wisprdaemon.sh. At the moment 4 channels (kiwi1) for public users,
and 8 channels (kiwi2) wspr.
If i could select a channel, i could configure both kiwis to 8 channels and use 12 channels for wspr and still have 4 channels
for public with waterfall. But the first connection receives always channel 0 with waterfall but it should connect to
2 to 7.
Would be a great enhancement!
vy 73 de Holger, OE9GHV
So there is no need for an option to connect to a specific channel. And this has problems anyway. What if the specific channel you want is busy? What happens then? What if the Kiwi you're connecting to is no longer in 8-channel mode and you are requesting a channel outside the range of available channels?
The example Rob cites above could only occur if ch7 happened to be busy when the kiwirecorder (via wsprdaemon) connection was made and was assigned ch0. The connection to ch7 then disconnected before that snapshot of the channels was taken.
I infer that the signal sent by a simple 'kill' did not fully terminate the kiwirecorder process, so when I started the new kiwirecorder session on another band the Kiwi assigned it to rx0 or rx1.
So I have a fix.
However I would still like to be able to get a list of active user sessions ;=)
So I am still looking for a way to ensure that 6 kiwirecorder sessions all are non-waterfall.
This should kill all instances of python that you have running.
Ron
KA7U
I record the PID of each kiwirecorder session and execute 'kill -9' on those PIDs I want to terminate, wait 10 seconds and then start a new kiwirecorder session on a new frequency.
However those new sessions are assigned to rx0 and rx1, not to the rx2...rx7 I want, so it appears that the Kiwi thinks the old sessions are still active for more than 10 seconds after I have killed them.
So far I have not found a way to detect and/or work around this problem which affects many of the sites running wsprdaemon.
I did some more testing and noticed something. If you fire up 6 connections to channels 2-7, and then kill all of them, sometimes not all of them disconnect immediately. And when there is a delay it seems to take 25 seconds or so before they finally disconnect. This behavior doesn't happen all the time. Usually all 6 disconnect immediately which is what's supposed to happen.
30 seconds is a strange interval. The code has a 60 second watchdog in which it actively trades a sequence number with the client (browser or kiwiclient) to catch the case of the client code having gone away but the network connection hanging open. Christoph made some changes to both the server and kiwiclient code a while back to more reliably detect client network connection closure. I have this extremely vague memory that TCP has a 30 second timer someplace. But it's probably been 25 years since I last looked at TCP/IP stack code.
Having had no suggestions on how to deal with this (other than the extremely useful "Mine doesn't do that!") I simply modified the schedule to provide a 2 minute gap in coverage in the (local) middle of the night where each of the three receivers, over the course of 2 minutes, would be scheduled for no reception. This would allow the opportunity for software updates to occur and reduce the likelihood that I'd ever go more than 24 hours without a GPS lock.
I was expecting to see "hung" kiwirecorder sessions occasionally with one of the intended user slots (1 or 2 of 8) being occupied by a Kiwirecorder - something that had happened once in a while (e.g. exactly a Kiwirecorder session on RX0 or RX1 of 8 receivers) - but this hasn't ever happened, as far as I can tell: This had occasionally happened when I was running it 24/7, but i've not observe this with them running 24/7-120seconds...
I was also expecting the see no GPS lock after a software update as had happened before - but I've not seen that happen, either...
Go figure.
Clint
So I think I can close this thread by confirming the problem was in my code.
However it is very difficult to debug these sessions with no way to determine what users are currently logged in to the Kiwi.
is there a similar curl call to get a list of users?
thanks
Gwyn G3ZIL