jks

Should be better if you restart to get v1.815

Technically it violates the entire spirit of the Kiwi ethos. Why would you spend money on a Kiwi as an IQ generator to drive SDR software on a PC when there are better alternatives for that kind of setup?

But having the option is another point of flexibility/experimentation with the Kiwi I suppose. Anyway, it will all make a lot more sense here within the next 6-12 months or so. Maybe sooner.

And now SDR++Brown has Kiwi support. Audio bandwidth only of course (for now). Nice Kiwi map integration.

I'm still working on "advanced tech" that will make the bandwidth increases mentioned in the posts above more easily obtained. Which would directly translate to increased bandwidth with SDR++Brown.

https://sdrpp-brown.san.systems/#kiwisdr-support

Kiwirecorder v1.5 contains two new features:

* Continuous scanning. Leaving out the "threshold" parameter from the scan.yaml will cause scanning and file recording to be continuous. That is, no squelch will be applied. See the file SCANNING for detailed information.

* Camp mode. Instead of creating a new connection to the Kiwi when kiwirecorder is run it can now "camp" onto an existing connection and record whatever audio the camped user is listening to. Very similar to the camp capability that is presented via the camp/queue panel that appears when you try and connect to a Kiwi when all its channels are full. See the option --camp=CAMP_CHAN where CAMP_CHAN is the Kiwi channel number to camp on (e.g. 0..4 for rx0..rx4).

Note that a 2-channel (stereo) file or netcat stream is always produced because you can't predict what the camped user will do. They may switch from a mono mode (e.g. USB) to a stereo mode (e.g. IQ) at any time. For mono modes the single channel audio is duplicated in both channels. Things also work when the camped user switches compression mode on and off.

Camp mode also works with the --netcat option. For an example see the Makefile "camp" target.

About the "Custom band" fields:

SNR measurement uses the waterfall, although it's easier if you visualize it as using the spectrum. All those spectrum "bins", which originally start in frequency order, are re-sorted by signal strength. Then the 50% bin is taken as the noise floor. The 95% bin is taken as the highest level signal (the remaining 5% ignored to remove super strong outliers). The difference is the SNR. An approximation for sure. But that's what we have.

Now when you measure a custom sub-band you need it to occupy a large part of the spectrum so lots of bins are visible and available for the SNR computation. Just as you would if you were trying to view it in the user interface. And that requires a zoom level appropriate to the start/stop sub-band frequencies you want to use. If you left the zoom at zero (0-30 MHz), and you wanted to measure the 30m ham band, you'd only have a few bins available that covered that frequency range. Not much for the SNR computation to work with.

So, to figure out the correct zoom level to enter do this: With a regular Kiwi connection enter the center frequency of your custom band as the current frequency. Zoom all the way in. Now zoom out one step at a time until both the lo and hi values of your custom band just fit in the waterfall/spectrum. Use the zoom value "n" from the WFn button on the user control panel.

Results from custom band measurements, as well as from the "Also measure ham bands and AM BCB" checkbox setting, are only available from the URL query: my_kiwi:8073/snr (adjust actual Kiwi name/port as necessary). They are not currently displayed in any Kiwi admin or user web interface.

---

Your image happens to fit the definition of a relatively large SNR value due to so many high valued bins plus many bins that are very low valued at the higher frequencies (very bad VDSL RFI in that image). Even though there are practically no useful signals outside of the AM BCB. That's just the limitation of the SNR algorithm.