jks

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.

Thanks. Will be fixed in the next release (v1.811)

So I would guess this is an issue with Windows and Chrome/Edge not being able to deliver the Javascript realtime requirements for the resampler. The fact that you're not getting any Kiwi under/overruns and the Qlen is stable kind of confirms that.

This entire project is built on the idea that browsers live up to their promise of providing stable, well documented platforms for delivering content/media. And over the years I've been constantly disappointed in the delivery on that promise. I guess I shouldn't be surprised.

rx.kiwisdr.com (aka kiwisdr.com/public) is now subject to a simple click/tap captcha to help evade recent DDoS attacks on kiwisdr.com.

Apologies, but this is the sorry state of the world we live in..

Fixed in v1.809. The timestamp menu setting, including any custom value, and URL/local menu setting will be saved in browser storage.

Also, the complete list of URL parameters is here: http://kiwisdr.com/info/#id-user-tune

Thinking about this some more (because I can't help myself). Higher frequency time stations are more useful because there is more relative frequency offset to visualize. At least when doing a manual calibration and you need to "eyeball" the offset in the waterfall (zoomed all the way in).

But HF time signals are more prone to having junk carriers close to the time station carrier (I've seen this) compared to LF time signals. But the later are not always present depending on antenna and Kiwi location. Hence the good SNR requirement mentioned by @nitroengine.

One thing we do have I remember now is the audio PLL associated with the SAM mode. So if SAM is able to achIeve a lock the exact offset can be determined rather than derived from, say, the number of waterfall bins which at z14 is only 1.76 Hz/bin (1.8 kHz span / 1024 bins). This is why the manual calibration instructions say to use the IQ extension for the ultimate fine tuning of the calibration.

Also needed is probably the more difficult part: Analysis of several different time signals at different frequencies and some sort of voting logic before there can be confidence in a solution.

There's absolutely no need for individual Kiwi's to be downloading from there when it needs to be compiled into a compact binary form as part of a release. The list is huge and fetching it off the filesystem of the Kiwi would break the Kiwi realtime restrictions (i.e. audio failures).

I improved my own Makefile so there's less manual work to update the list.

SDR protection circuit

SDR MW filter

Well, the complexity is a result of people asking for features over the years. That's the trade-off. I try and limit it as much as I can. It's a thankless task, as some people are always unhappy..