jks

Added in v1.222

This has been discussed at length before, but I'll summarize.

The current FPGA logic behind the OV indicator is as pessimistic as it could be and almost certainly wrong. Right now if one single sample overflows the ADC the OV indicator will get lit and persist long enough to be seen. That doesn't really indicate a substantial overload condition that will lead to increased IMD products seen in the waterfall etc. The logic really needs to be a threshold/averaging function of some sort.

The +20 dB amplifier / matching buffer ahead of the ADC is a fixed gain block. So yes, you'd have to have new OV logic trigger a GPIO pin and control an external attenuator (with appropriate hysteresis so it isn't pumping on and off all the time).

Yes, this is an actual bug. I had an email about it earlier today and have a fix that should go out in tomorrow's update.

The area you've identified turns out to be exactly the transparent box that the audio FFT explanation text appears in. I forgot to enable mouse events for the box (HTML div actually) so that's why you get the dead zone.

Any difference between the waterfall carrier of a known reference station and the frequency scale comes down to frequency calibration of the ADC XO clock.

At z14 each waterfall FFT bin is roughly 0.9 Hz. But how this translates into what you see on your browser screen is a little muddled because those 2048 bins are "stretched" and anti-aliased to fit your actual visible screen width. But from experience the one above (not yours I know) looks fine for 5 MHz WWV.

Do you have GPS clock correction working? Without GPS correction XO temperature variation may make the frequency offset at z14 look much worse than what you have. To see the exact ppm and Hz difference use the manual clock correction procedure (see admin page "config" tab). The XO spec is +/- 50 ppm @ 66.67 MHz without GPS correction operating.

The new 8-channel Kiwi configuration mode trades two of the zoom waterfalls for the ability to have an extra 4 audio-only receiver channels. I.e. the original RX4/WF4 mode, where each receiver channel was paired with a waterfall, can be replaced by an 8RX/2WF mode where only the first two channels have a waterfall. The other 6 channels get a “blank” waterfall and spectrum display (see this post: http://forum.kiwisdr.com/discussion/1233)

The v1.221 release now adds an audio FFT in place of the zoom waterfall / spectrum for those channels that were formerly blank. This is possible because all the FFT processing is done in Javascript on the browser. No additional FPGA, Beagle or network bandwidth resources are required.

However, this scheme has its limitations and also a number of known bugs that are being worked on. When I have a little more time I will list them. Until then please give the audio FFT a try.

I've been working on an audio FFT display (as mentioned in the new admin "mode" tab). The problem is clearly visible and the FFT will be a good diagnostic tool. Hopefully this issue will finally get fixed.

I've been working on an audio FFT display (as mentioned in the new admin "mode" tab). The problem is clearly visible and the FFT will be a good diagnostic tool. Hopefully this issue will finally get fixed.

I'm not sure (I don't run sdr.hu and don't know precisely how it works) The worst that will happen is that you will end up with duplicate entries that you cannot delete. Although this is more classically a problem when you change from using an ip address as your Kiwi's URL to using a proper domain name.

I had approached someone about placing a Kiwi at Palmer Station (US base). But the conclusion was that it was unlikely to pass review (Internet access costs serious money down there). This despite the fact that they have an IRLP and lightning detection setup already.

I see the same. Let's go a few more days and then I think we can call this one solved.