jks

Added in v1.222

Added in v1.222

I found that it almost invites a different use of the radio when listening to Morse as the signal become visible before the audio so it is easier to find and settle on a signal (with arrow keys) than blind the audio overshoot. Not being synchronized to the audio is one of the current problems. But If you actually like this behavior note that you can delay the regular waterfall using the "wfdly" URL parameter (not yet documented). Say something like my_kiwi:8073/?wfdly=1000 to get the waterfall to appear 1 second (1000 milliseconds) before the audio. You can specify negative values also.

Limitations of the audio FFT

So you have to understand the context in which the audio FFT operates. The goal is to perform the FFT entirely within the browser using Javascript based on the audio data stream sent by the Kiwi. In this way zero additional resources are required on the Kiwi side. No additional FPGA cells, Beagle processor cycles or network bandwidth. This is a requirement for Kiwis configured in 8 channel mode where channels 2-6 are unable to display the traditional waterfall. But also for Kiwis in which the owner/admin has disabled the waterfall for all channels to save bandwidth on expensive, metered Internet connections (e.g. 3/4G for Kiwis at remote locations)

Why is the spectrum single-sided? The first thing you will notice is that in every demodulator mode except IQ a single-sided FFT spectrum is presented, i.e. the 0 Hz carrier point is on the left and the 6 kHz (1/2 the 12 kHz audio sample rate) on the right (visibility depends on passband filter settings). Why is this? The zoom waterfall doesn’t do this. Well, by the time audio has gone through demodulation on the Kiwi and transmitted on the network it is no longer an IQ signal. It is now a real-valued signal (think audio mono instead of stereo). This means that an FFT by definition will only give you a one-sided spectrum from 0 to 1/2 the sample rate. By contrast the zoom waterfall on the Kiwi is fully independent of the audio channel and always operates in a high-bandwidth IQ mode.

This situation has some interesting consequences. It means that if your passband setting “goes below” the 0 Hz carrier point then that part of the spectrum (call it negative) will be “folded over” 0 Hz and be merged on top of the positive part of the spectrum. For AM, where the passband is symmetrical around 0 Hz, both spectrum halves are merged. But this is not an issue since traditional AM by definition has equal valued sidebands. USB/CW looks the same as the zoom waterfall. But LSB is folded and is displayed just like USB. The lesser-used DSB/ISB is a problem because each sideband has independent content and merging their display is undesirable.

But here is where IQ mode comes to the rescue. The IQ demodulator by definition does not transmit only real-valued samples over the network. So the audio FFT is able to perform a full IQ (quadrature) FFT and you get a display where the 0 Hz carrier point is in the middle of the display with LSB/USB on either side. Now AM, LSB and DSB/ISB display as they would on the zoom waterfall. But the network bandwidth is up to 8 times larger in IQ mode. A factor of two because two channels instead of one and a factor of 4 because the usual 4:1 audio compression employed can’t be used in IQ mode (it would mess up things using IQ data like DRM etc.) No free lunch.

Why is the entire row of zoom/pan controls below the demod buttons disabled? To get a decent display update rate, and not cause the browser too many problems, a modest sized FFT is used. There is no capability to zoom-in as with the zoom waterfall. You always get a fixed spectrum span of 0 to 1/2 or -1/2 to +1/2 (IQ mode) of the 12 kHz audio sample rate.

Why are the display update speeds different in IQ mode and non-IQ with/without audio compression? This has to do with some different FFT sizes required due to different network data rates in these modes.

Why does the display sometimes show areas of repeated spectrum (same values) sometimes with interrupted audio? This occurs if Javascript running on your browser/computer has problems keeping up with the FFT. Ways of improving this situation are being looked at. Underpowered mobile devices are likely to have more problems than PCs.

There are a bunch of minor problems: display glitches when changing modes, values “stuck” in the upper spectrum display (if enabled), the FFT display is not synchronized with the audio etc.

Added in v1.222