jks

Ha ha, okay. Not to worry. See our documentation here: http://kiwisdr.com/info/#id-user-marker-masked

Probably in the admin "DX" tab you used the red buttons import JSON or import CSV on the downloaded files mentioned in the document.

I guess I'm going to have to add a file in that document that will put everything back the way it was, lol.

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..

From the CHANGE_LOG file:

From the CHANGE_LOG file:

From the CHANGE_LOG file: