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.

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?

We're also adding a washer to one of the case screws and recommend that you add a ground wire to the case if your antenna connection does not provide a good ground. It is important to provide a ground path for any static charge dissipation.

Well.. There needs to be a more detailed discussion here as there may be some misconceptions about what the KiwiSDR is and what its capabilities are.

The timing repeatability of the measurement you want are a little difficult to achieve given the "best effort" nature of some of the Kiwi functions. This is due to the Kiwi design. Remember that the Kiwi goal is to provide a total solution in a single box, including what is usually the "PC" side of most SDRs that consist of an SDR "IQ-generator" device plus PC with SDR software running on it. And the PC has vastly superior processing power to the Kiwi's single board computer (BeagleBone Green). BUT at the dollar cost of the PC (which most people incorrectly discount) and the often terrible burden of software installation problems (you see this even now in the support forums of the IQ-generator products -- very sad).

So with its design the Kiwi has to give highest priority to processing the audio and guarantee no audio drops (except when the network connection is poor -- something the Kiwi cannot control). Everything else has lower priority, especially waterfall processing. And there are lots of other things going on simultaneously: GPS, user interface, possibly processing to support an open extension etc.

Consider the case of the wsprdaemon group (https://groups.io/g/wsprdaemon/topics). For a long time they asked for custom modification to the Kiwi. And I provided them, best I could. And they bought a number of Kiwi. Fair enough. But in the end their ever-growing requirements forced them to switch to a more traditional IQ-based SDR with a standard PC for the increased processing power.

Some technical points we should discuss. The audio and waterfall output each use two completely independent, tunable, digital downconverters (DDCs). The S-meter values are derived from the audio channel and influenced by the passband. It is not derived from passband-limited waterfall bins. Not many people understand or use this feature but it is entirely possible to tune the waterfall far away from where the audio channel is listening. The audio could be listening to 7020 cw and enter "#28200" in the frequency field to check for 10m beacon activity -- without disturbing the 80m audio (enter "#" to re-align the waterfall to the audio).

Now to your questions:

No. See above. It's just a

No, the passband is not fixed based on mode. The initial passband values are set based on mode. But you can change them to be whatever you want afterwards. And those new values will persist when you return to that mode (I'm talking about the Kiwi user interface here).

Are you talking about the S-meter extension? (graph at the top of the display when active). You must be. Did you really count display pixels between the vertical marker lines to determine this?

I can't remember. That extension was written many years ago. Probably because there was no buffering of the S-meter values. Remember that the S-meter extension runs on a best-effort basis. And also involves a Javascript component that runs in the browser. So yet another source of timing uncertainty. The actual S-meter values are prepended to each audio packet sent from the Kiwi. So occur at a regular rate. But there can be many reasons why they are not processed at a regular rate.

Yes.

Yes. 30 MHz divided by power of two: 15, 7.5 MHz etc. The user control panel "stat" tab shows the spectrum span value.

This varies considerably due to the low priority of the waterfall task. And also the "acquisition time" determined on the zoom factor. And there is a "WF Rate" control on the WF tab that sets relative update time as well. Just like a real spectrum analyzer, high zoom factors take considerable time for the DDC to accumulate all the necessary samples. At z0 it happens in a flash. At z14 it takes forever.

No. See above.

Yes for the S-meter, no for the waterfall (but it would be relatively easy to add and is maybe the easiest solution to your measurement problem). The various URL-based queries that can also be used via curl are listed here: http://kiwisdr.com/info/#id-urls

See #9 answer. I'm more likely to add another query URL to return a sample of waterfall data. Most of the code to do so has already been written for the SNR measurement function since it is based on averaged waterfall bin data.

I'm in the middle of working on new products and upgrades and don't have much time for anything else. I'm having trouble keeping up with my emails as it is..

@F5LFE This is really interesting to me because it seems to be an admin connection attack. I'll bet each of those is trying with a different password.

Here's something you can do to verify that. With the admin console type cdk; touch opt.debug. And then click the restart button on the admin control tab. This will print more messages in the log when someone connects including the attempted password. See if it changes each time.

Look for log entries of the form:

PWD admin admin RESULT: allow=0 pwd_s=<actual admin pwd> pwd_m=<attempted pwd> cant_determine=0 is_local=0 is_local_e=0 [IP address]

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.

I think there was a discussion about this a long time ago. There are indeed industrial drying machines, amongst others as @studentkra mentions, running huge RF power that cycle on & off to dry wood and other materials. Since they're built as cheaply as possible frequency stability is probably not high on the agenda. They're not supposed to leak RF either, but you know how that goes..

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.