jks

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.

All I got out of that thread was "82 year old codger" and "AI hallucinations", both of which I can relate to (lol).

Actually I think I know what the problem is (amplitude imbalance). But I can't test until tomorrow.

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.

In the next release I am changing the default of "acquire if busy" to be checked (enabled). This change will only affect new software installations, i.e. not change an existing configuration in case someone has explicitly set the value.

Okay, I think I have this fixed. Will be in the next release.

It a corner case: When two bands abut each other, and you're tuned to the exact frequency in common with the bands (e.g. 7200 as mentioned here), the - - - buttons should use the lower band's tuning step. And the + + + buttons should use the upper band's tuning step.

The story is slightly more complicated for overlapping bands. Which right now occurs for ITU R3 (Asia/Pacific) with the 40m amateur and 41m broadcast bands. Basically 41m has priority because it's first in the admin DX tab "band bars" list (unless you've changed it).

He mentioned in his email to me (but not in the post above) that it was set in continuous mode.

Okay, I see what's wrong. It's because I'm an idiot.

Will be fixed in the next release..

The EXT socket you used to open DRM can be used to open any of the extensions. You just change ext_switch_to_client=X where X is the name of the extension as it appears in the extension menu on the Kiwi UI. As mentioned before, you can very easily use the browser debug window "network" tab to see exactly what socket command are being sent by the Kiwi Javascript client code -- commands that you will have to send yourself. This is much easier than reading the code to see what it's doing. Select the EXT socket and HTTP response tab.

A lot extensions can run without any parameters needing to be set. E.g. the cw_decoder, cw_skimmer and FT8 extensions because their default parameters will just work. All you have to do is somehow display their decoding output. In the case of the cw decoders that means processing the cw_chars=... message. And ignoring messages like cw_plot and bar_pct if test mode is active. For FT8 just process the chars=... message.

Send a close or stop and blur messages when done (varies by extension for historical reasons).

You can use the test mode message to debug with to get a strong pre-recorded CW signal that will decode 100%. Similarly for FT8 mode. No tuning to an active CW/FT8 frequency required.