jks

Nice article on rtl-sdr.com about the topic: https://www.rtl-sdr.com/locating-various-hf-transmitters-and-number-stations-with-kiwisdrs

wsprd handles the problem of strong signals "covering up" weak ones in an interesting way. After a first pass of decoding signals they are coherently subtracted from the spectrum and the entire decoding pass is run a second time to, hopefully, pickup the remaining weaker signals.

The Kiwi version doesn't do the subtraction and second pass because of how it implements the wsprd algorithm. To more efficiently use the limited processing power of the Beagle, and to help meet the realtime constraints, the per-symbol FFTs are spread out over the entire sampling time. As opposed to wsprd which does everything at once (at the end) when presented with all the samples together in a file. So when the two minutes of sampling are done the Kiwi only has to run the decoding process on the previously computed FFTs of the symbols during the subsequent two minute interval (i.e. overlapped with the next sampling period). But to do the subtraction and a second pass would require all that processing to be done again during the two minute window and there just wouldn't be time for it in most cases.

We have to remember what the Kiwi extensions are. They are meant to be a very convenient, browser-based, built-in subset of fancier decoders that normally require separate programs with their associated hassles of virtual-audio-cables etc. They will never match the features or performance of existing decoders that have had much more effort put into them (and are closed-source and fee-based in many cases).

Yes, I do everything myself in user space. At various times during development I tried C-threads, Linux realtime scheduling etc. and I had nothing but trouble.

I would suggest just sticking with processing the existing audio IQ stream you can currently get over the net. You have the Python kiwiclient example showing how to do it. Many other languages have web socket libraries if you don't want to deal with Python.

As for why the Kiwi timing isn't disrupted by uploads to wsprnet.org: it's because the upload happens from javascript in the user's browser, not from C-code running on the Kiwi side. This is an example of the advantage of being able to split your extension code into C and javascript parts.

Hi,

The Kiwi is not really suitable for transferring ADC samples directly to a PC compared to most other SDRs. This is by design. Most other SDRs transmit as large a bandwidth as possible of baseband IQ samples directly to a PC over the simplest interface possible (usually USB).

The Kiwi is designed to be a standalone device connected directly to a local network and optionally to the Internet. It provides multiple, independent narrow-bandwidth channels for direct use by a browser. To do that the Kiwi requires the BeagleBone. The Ethernet interface is on the Beagle, not the Kiwi board. The Kiwi only uses an SPI interface between its FPGA and the Beagle.

Fortunately we are at a point in time where there are lots of SDR designs available, with different features and different price points. You should have no trouble finding exactly the device you need. Something like the HackRF, SDRPlay, AirSpy, LimeSDR, PlutoSDR etc. See https://www.rtl-sdr.com for reviews.

It's OTHR:
http://www.iarums-r1.org/iarums/radar-2013.pdf
https://en.wikipedia.org/wiki/Over-the-horizon_radar

Looking for a Kiwi not currently listed on sdr.hu? Try http://kiwisdr.com/public and http://rx.linkfanel.net

I edited the post for you..

Compression is always disabled when in IQ mode. Another way of looking at it is to observe the network transfer rates for the audio data:
6 kB/s regular mode (4:1 ADPCM compressed, non-IQ, mono)
24 kB/s compression off
48 kB/s IQ (no compression, stereo)

Yep. An unfortunate bug that was introduced but then masked by some other unrelated debug settings that were removed later on. So it passed all the testing. Fix coming in today's update.

v1.191 fixes this problem. Reboot to get the update right away.