Why is the data transfer for IQ 8 times as high
MaPePeR opened this issue · 6 comments
I noticed, that IQ mode uses 8 times as much internet bandwidth in comparison to the normal am demodulation. Why is that?
I'd expect double the data rate because of the 2 channels, but not 8 times more.
I assume that the reason is, that for IQ mode the sample rate is 48000Hz instead of the default 12000Hz? But then I don't understand, why that data then seems to be downsampled to 12000Hz in JavaScript?
There is no 4:1 compression in IQ mode. For non-IQ modes compression is the default, but it is also selectable ("comp" button on the audio tab).
Also, the Kiwi Javascript code re-samples to the host audio rate. This is almost always 44.1 or 48 kHz although other slower rates are sometimes required depending on the host.
Is there a specific reason one cannot enable compression for IQ mode?
Also, the estimates in the FAQ are slightly off, then: How much Internet upload bandwidth is used?
Short answer: 40k bytes/second (320k bits/sec), all 4 channels active.
The compressed audio takes 4.8k bytes/sec and compressed waterfall 12k at the current maximum frame rate (about 23 Hz). For 4 channels you might expect the total to be 68k (total multiplied by four) but it is only 40k bytes/sec because the waterfall slows down under the load of four simultaneous users.
I measured audio for a single IQ channel to be at around ~48kB/s. So 60kB/s for a single channel with fast waterfall and IQ mode enabled? With 4 channels that could go up even more?
The answer to the What's the worst case daily and monthly bandwidth consumed? is also wrong then, i guess.
Most users of IQ mode are digital demodulators (e.g. DRM) where adding compression to the IQ stream just makes the noise margin worse. Something digital demods struggle with on shortwave anyway. Also, I don't think you could simply apply the current compression algorithm (ADPCM) to each I & Q channel independently. I think bad things would happen if you did that (e.g. IQ unbalance). You'd really need an IQ-specific compression algorithm.
Those bandwidth estimates were written a long time ago when the max channel bandwidth was 8.25 kHz instead of today's 12 kHz (and the optional 20.25 kHz in 3-channel mode).
Trying to use the websocket extension permessage-deflate would be one option that would not mess with the data itself.
Another option would be to try lossless compression with libflac.js.
That should bring down the data rate by a lot. At least in comparison to the uncompressed raw pcm samples - at the cost of some CPU/FPGA cycles, of course, or what do you think?
CPU cycles on the Beagle are already at a premium, especially for the common case of 8 IQ connections via kiwirecorder for offline WSPR processing (Rob's wsprdaemon script). So I'm not sure this is a good trade-off. But it might be an interesting experiment.
There is an FPGA implementation for flac encoding, so if there is a any space on the fpga left that might be a better option, then: https://github.com/xavieran/fLaCPGA
Don't know how good/complete that implementation is, though.