Can kiwirecorder select the rx channel it uses or can I detect the rx channel in use?

rrobinetrrobinet
in WSPR, wsprdaemon, kiwirecorder
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:

Comments

  • oe9ghvoe9ghv
    I also have interrest in connecting to a specific channel on the kiwi.
    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
  • jksjks
    A Kiwi in 8-channel mode detects when the incoming connection is from a program like kiwirecorder that only wants to use an audio channel. It starts assigning these types of connections to channels 2-7 and only uses channels 0 and 1 when all the others are occupied. I just checked this again and it works fine.

    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.
  • rrobinetrrobinet
    Hi John, On all my 8 channel Kiwi with six kiwirecorder.py client sessions, I frequently find sessions which have restarted on their own and connected to rx0 or rx1. Perhaps my code is attempting to restart a failed session too quickly, but my logs don't report that my code is re-executing kiwirecorder in that way. I can probably write code to recover from this situation if I could know what channel is being used by a session or could obtain a list of active users. Can you suggest how I could do that, or another approach to the problem? thanks
  • rrobinetrrobinet
    Upon further reflection, I think when my script executes a scheduled band change it may need to wait for a few seconds for the Kiwi to detect that the previous kiwirecorder client session has terminated. I will experiment with adding a few seconds of delay and report back
  • rrobinetrrobinet
    Waiting 10 seconds did not fix the problem. However changing 'kill KIWIRECORDER_PID' to 'kill -9 IWIRECORDER_PID' seems to have fixed the problem.
    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 ;=)
  • rrobinetrrobinet
    I spoke too soon. kill -9 did not fix the problem at two test sites.
    So I am still looking for a way to ensure that 6 kiwirecorder sessions all are non-waterfall.
  • WA2ZKDWA2ZKD
    a random thought.... start up 2 kiwirecorder sessions using the --wf option so as to grab 0 and 1. Then, start your 6 wspr sessions. Finally, kill the --wf sessions ??
  • KA7UKA7U
    for pid in $(ps -ef | awk '/python/ {print $2}'); do kill -9 $pid; done

    This should kill all instances of python that you have running.
    Ron
    KA7U
  • rrobinetrrobinet
    I am running 6 kiwirecorder sessions to a Kiwi configured in 8 receiver mode and I want to terminate two of those sessions without disturbing the remaining four sessions.
    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.
  • jksjks
    edited May 2019
    Wait 30 seconds instead of 10.

    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.
  • ka7oeika7oei
    As mentioned a while ago, I had the problem of KiwiSDRs not being able to get GPS sync - if, for example, a software update had occurred - while it was "busy" with Kiwirecorder sessions: The instant those sessions were dropped, the Kiwi would immediately sync with GPS.

    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
  • rrobinetrrobinet
    After a lot of debugging of my code in the process of developing wsprdaemon V2.5, I seem to have eliminated some, if not all, of the zombie kiwirecorder.py session which were forcing new sessions to use rx0/rx1.
    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.
  • rrobinetrrobinet
    Is there a way for WD to test for GPS lock on the Kiwi? Then I could add a test for that to WD and shut down all sessions for a minute.
  • jksjks
    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.
    WA2ZKD
  • rrobinetrrobinet
    thanks I can easily use fixes to detect GPS state
    is there a similar curl call to get a list of users?
  • jksjks
    No.
  • HB9TMCHB9TMC
    You could get it from /admin with phantomJS
  • G3ZILG3ZIL
    I'm trying to use curl for the status page to get position for when "backpack mobile" tracing down local noise sources. But, while all other GPS lines update, the position remains fixed and does not correspond to the position on the admin GPS screen, even though, now, 392 fixes have been obtained. Any hints?

    thanks
    Gwyn G3ZIL
  • G3ZILG3ZIL
    To answer my own question. The status page GPS position is fixed by design, picking it up, apparently, from the position set on the admin page sdr.hu for security reasons.
    Powernumpty
Sign In or Register to comment.