v1.221: Audio FFT added

edited September 2018 in KiwiSDR Discussion
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.


  • Another great option thanks.
    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.
    Its not the same as full "click to go there" waterfall use, closer to real radio use.
    I can see a compact interface working well on this mode, E.G. audio spectrum (or small waterfall) and big tuning symbols for phone/tablet use
  • Quite useful addition
    Seems that for the display of centre location of the pass band a position further to the right as now is only the case for the IQ mode would be better so it does not get blanked by a extension control window.
    Never noticed it before but it turns out the FSK window extends beyond 50 pct of the screen width and if resizing is possible that will help with viewing the audio FFT.
  • 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.
  • jksjks
    edited September 2018
    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.
  • One drawback of the present setup is folks using channels 1 and 2 for a couple of hours when they only need audioFFT. Not sure how to improve this - any ideas?
Sign In or Register to comment.