jks

December 3, 2025: Our kiwisdr.nz store is temporarily sold out. More units available December 15. Distributors have plenty: DX Engineering (US), ML&S (UK), WiMo (DE).

As always thanks for your support. Enjoy the holidays.

@XPloRR Sorry, this is a very bad time of year for me. Dozens of big problems stacked up ahead of you. People waiting..

You need to detect an impending inactivity or 24hr timeout. And then react to it in some manner, which may not be in the same way the Kiwi UI does.

When the inactivity time remaining drops below 1 minute you might show a panel like the kiwi does. And if that panel is ack'd send a "SET inactivity_ack" message on the SND socket. That will reset the inactivity timer (this is an alternative to actually making a change, e.g. frequency change, which also resets the timer). If the user doesn't ack and the connection closes then you can show something that says to reload. In your case pressing the 1/0 button I guess. The Kiwi doesn't give an opportunity to enter an exemption password after an inactivity timeout. Because the password can be given in the URL ahead of time. But you might want to (as described below).

When the 24hr time expires, and the connection closes, you can present a panel asking for an exemption password. If given then reopen connection giving ipl=(exemption pwd) as you show.

How to tell of an impending inactivity or 24hr timeout. This is a little tricky because it was done in the easiest possible way for the Kiwi UI. Not in the easiest way for a general API.

Figure out what rx channel number you're connected to (N) by looking for a msg on the WF socket early on of the form "MSG kiwi_up=1 rx_chan=N". This should probably also be sent on SND socket, but it isn't (historical reasons).

Then every 3 seconds on the SND socket you will see a msg like:

The user_cb value is JSON giving info on all the rx channels. In this case all 4 channels of a Kiwi in 4-channel mode. Since you determined earlier that N=0 you want the first array element of user_cb where i=0. Now look at the object values rt, rn & rs. rt means "remaining type". 0 = no time limits in effect. 1 = inactivity timer will expire soonest. 2 = 24hr timer will expire soonest. rn is the number of seconds until expiration. rs is the h:mm:ss string representation of rn.

So when rn < 60 an expiration will occur within one minute.

Trying to connect when the 24hr limit has been exceeded will cause this msg on the SND socket: "MSG ip_limit=ttt%2cxxx.yyy.zzz.www" where ttt is the 24hr limit in minutes, %2c is the hex encoding for the "," character and xxx.yyy.zzz.www is the source ip address the incoming connection. Receiving this msg is what triggers the display of the exemption password panel in the Kiwi UI.

From the CHANGE_LOG file:

After updating to v1.826 (or later) Kiwi with serial numbers 210xx (i.e. 21000 - 21099) will switch to running on the secondary proxy server. You still connect to these Kiwi in the usual way, e.g. 21033.proxy.kiwisdr.com or 21033.proxy.kiwisdr.com:8073 But the browser address bar will now say 21033.proxy2.kiwisdr.com:8073 (note "proxy2")

Okay, thank you for the changes.

I see as of this morning Eike has made an official B25 release on eibispace.de. So I will get that into the next software release.

And there went half my day. This is from the forum server. Goddamn Chinese AI companies. OpenAI.com too (although they were slightly better behaved). I had to beef up the IP filtering on the forum server to match what the proxy/web server (kiwisdr.com) has.

So I was wrong about the "too_busy=N" message (I can't remember how this stuff works anymore without looking at the code). "N" in this case is a count of the number of available channels. But N is context dependent.

In the case of a non-Kiwi app connecting @studentkra is correct that this will be count of the non-Kiwi UI channels the admin has configured. Which may be different from the actual number of free channels available to regular connections using the Kiwi UI. A lot of people clamp down on non-Kiwi apps due to the number of bot connections they see. Either allowing zero non-Kiwi channels or only a small number. Note there is bot identification/filtering on top of this restriction.

So the question of how to flag QiwiQ as a valid connection, compared to the bots, is reasonable. I don't have a good answer currently. Probably some sort of public key identification scheme is needed. But can you imagine the hassle in implementing that. I don't have the time and a large part of the community doesn't stay updated to the latest release anyway, so wouldn't get any potential fix.

Hi Ron. I think you must have checked "acquire if busy" because I now see "GPS acq yes" in the user control panel "Stat" tab with 3 users connected.

One better way to assess frequency cal / drift than simply using zoom level 14 is to use the WSPR extension since it has an FFT display that has very good resolution. In the screenshot below I have set it to run on 30m. But tuned to a dial frequency of 14999.25 so that the time station carrier is in the middle of the display (200 Hz offset). Notice that it looks pretty good. Maybe just a tiny bit low. What's important is how stable that carrier is in the WSPR display over time with the GPS "good" sat count being a relatively large value (say larger than 4).

Also, the backslash '\' key toggles which label database is being displayed. The name of which is shown in small white lettering in the top left corner of the frequency scale. Type 'h' to see a list of all shortcus keys.

You are correct that on a mobile client there is no real use for an IQ mode button. However the SAM, SAU, SAL, SAS and QAM modes should be considered. Perhaps just SAM since the others are less frequently used. There is a real advantage to using synchronous AM decoding for weak AM signals.

Just my opinion, but I think using red to outline active buttons has too little contrast. Maybe something like yellow would be better?