jks

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.

Okay, but now G4SDG has faded up to -18 dB according to WSJT-X. And the Kiwi WSPR autorun decode count went from 12 to 13 during that time slot. So it worked at that signal strength. I think this confirms what's going on.

I should also mention, re your earlier query about VHF/UHF Kiwi, that a reason to detect and respond to dynamic changes in the offset is because it is possible for this to be set in the antenna switch configuration. So that a user connection could select an antenna that also switches a downconverter in/out-of-line. On the Kiwi UI this causes a page reload to correct the frequency scale and all the other places the new offset needs to be taken into account.

But in practice I don't think many Kiwi are setup this way. VHF/UHF operation seems to be a static setup rather than associated with an antenna configuration.

First of all I did not write the squelch code, so I can't say exactly how it works. But it was originally designed for the NBFM modes. So using it outside that context is perhaps a bit problematic. I think it tries to compare energy at and above typical voice frequencies and use that as a basis for squelching. So it probably isn't going to work at all on AM BCB signals where there are very few periods of silence.

It works well however on things like the digital bursts in the UK on e.g. 4037.5 kHz. In either USB or AM modes.

The first one you mention is not a true Kiwi, but a clone that runs very old software (v1.690). So it probably has API compatibility issues. I do not provide support for clones. And, sadly, they don't seem to either (the clone forums are full of people who can't get support).

The VHF/UHF ones require detecting the offset via API and adjusting the frequency scale. But the API will still be baseband referenced, i.e. 0 - 30/32 MHz. It's a bit complicated. I will have to go through the code and identify all the places you need to consider applying the offset.

All of these air band signals will be AM mode. The Switzerland one worked for me, but has a huge number of spurious signals. Look for intermittent signals representing the short AM transmissions. The Russian one is another clone running v1.690 so probably won't work for that reason. You can identify these by connecting using the Kiwi web interface and checking the v1.xxx version number of the user control panel "Stat" tab.