jks

It's not so simple though. There are lots of problems. If you listen long enough you'll realize how many glitches there are. Not only the usual audio underruns but full data pump update failures because the FPGA audio buffers are overflowing when the Beagle can't meet the buffer servicing requirements (interrupt latency essentially). This is really bad because it has subtle and very annoying effects. Example: it will cause the fax extension image to tear/shift. And it will probably cause WSPR decoding to fail.

If I release this as a replacement for the 12 kHz bandwidth of 4rx/4wf mode you can imagine the howls of protest. So, as you suggest, it should probably be a third FPGA mode. But more experimentation is needed to see if a less stressful configuration might stop the glitching. Perhaps a 2rx/2wf mode @ 20 kHz that is more designed for private listening by the Kiwi owner rather than multi-channel public access Kiwis (although that would still be available).

Other things to note: Because the waterfall is deliberately the lowest priority process due to its large resource requirements you'll note that it becomes painfully slow much sooner with two or more connections in 20 kHz mode. Also unknown until I check is how many places the 12 kHz bandwidth number is hardwired into code. I tried not to do this, but it may have snuck into some extension code and maybe even the kiwiclient/kiwirecorder code. This will all have to be fixed.

It's not so simple though. There are lots of problems. If you listen long enough you'll realize how many glitches there are. Not only the usual audio underruns but full data pump update failures because the FPGA audio buffers are overflowing when the Beagle can't meet the buffer servicing requirements (interrupt latency essentially). This is really bad because it has subtle and very annoying effects. Example: it will cause the fax extension image to tear/shift. And it will probably cause WSPR decoding to fail.

If I release this as a replacement for the 12 kHz bandwidth of 4rx/4wf mode you can imagine the howls of protest. So, as you suggest, it should probably be a third FPGA mode. But more experimentation is needed to see if a less stressful configuration might stop the glitching. Perhaps a 2rx/2wf mode @ 20 kHz that is more designed for private listening by the Kiwi owner rather than multi-channel public access Kiwis (although that would still be available).

Other things to note: Because the waterfall is deliberately the lowest priority process due to its large resource requirements you'll note that it becomes painfully slow much sooner with two or more connections in 20 kHz mode. Also unknown until I check is how many places the 12 kHz bandwidth number is hardwired into code. I tried not to do this, but it may have snuck into some extension code and maybe even the kiwiclient/kiwirecorder code. This will all have to be fixed.

It's not so simple though. There are lots of problems. If you listen long enough you'll realize how many glitches there are. Not only the usual audio underruns but full data pump update failures because the FPGA audio buffers are overflowing when the Beagle can't meet the buffer servicing requirements (interrupt latency essentially). This is really bad because it has subtle and very annoying effects. Example: it will cause the fax extension image to tear/shift. And it will probably cause WSPR decoding to fail.

If I release this as a replacement for the 12 kHz bandwidth of 4rx/4wf mode you can imagine the howls of protest. So, as you suggest, it should probably be a third FPGA mode. But more experimentation is needed to see if a less stressful configuration might stop the glitching. Perhaps a 2rx/2wf mode @ 20 kHz that is more designed for private listening by the Kiwi owner rather than multi-channel public access Kiwis (although that would still be available).

Other things to note: Because the waterfall is deliberately the lowest priority process due to its large resource requirements you'll note that it becomes painfully slow much sooner with two or more connections in 20 kHz mode. Also unknown until I check is how many places the 12 kHz bandwidth number is hardwired into code. I tried not to do this, but it may have snuck into some extension code and maybe even the kiwiclient/kiwirecorder code. This will all have to be fixed.

You may not know the full history. The current SND_RATE 12k was originally developed for the 4snd/4wf configuration (it used to be less: 8.25k). It was only found through trial-and-error that 8snd/2wf was possible. And that required a new FPGA sound buffer geometry and other careful tuning to get working. I originally thought only 6snd/2wf would be possible, which was much less interesting. 8snd/2wf was motivated by trying to get more WSPR decoders running in parallel and greater worldwide channels for TDoA. WSPR ultimately failed because of insufficient Beagle cpu cycles with 8 WSPR decoders running simultaneously. But the situation was saved with Rob's kiwirecorder script using the stock WSPR decoder running on non-Kiwi hardware.

Getting greater than 12k from 4snd/4wf is a separate problem requiring a different architecture from trying to get the maximum IQ bandwidth possible from a single channel (i.e. making the Kiwi act like all other USB-based SDRs out there that use external PC-based control software).

The problem with this sort of development is that you are pushing all the soft boundaries to their absolute limit. And because there are so many competing processes for resources (e.g. GPS, extensions) you just don't know what's going to give out first. Are you going to run out of SPI bandwidth to handle the audio without dropouts with all possible loading from the GPS? What about running out of cycles on the little eCPU on the FPGA? There are a dozen considerations like this. So you are reduced to incremental development, testing and measurement (there are some built-in realtime measurement tools to help answer some of these questions). Overall this means the total architecture has a very steep learning curve and you're unlikely to make a major change like this easily.

Why is the Kiwi like this? Is this poor engineering? No. It's because the Kiwi was designed to sell for $299/$199 yet have its unique feature set that is different from every other SDR out there. This required a huge effort in optimized/compromise engineering.

Well, it works. Sort of. Try the Beta test Kiwi in Kansas:

http://64.136.200.36:8073/?f=1160.00/12000amz9
vs
http://64.136.200.36:8073/?f=1160.00/16000amz9

Remember that you can change the passband width by typing / into the frequency box (e.g. /20000 for 20 kHz). Or using the 'p' and 'P' keys.

There are some problems as expected. I used a SND_RATE of 20250 so that SND_RATE/54 = 375 so the WSPR will still work (it does). There are some audio underruns of course. But I was able to make two regular connections and a WSPR extension connection and it seemed to work okay. The GPS seemed to run fine.

I think it sounds not quite right with a bandwidth greater than about 16 kHz. That might be a problem with the re-sampler that runs in Javascript on the browser. Measurement for passband flatness is obviously needed. There seems to be some high-frequency artifacts with the compression turned off which doesn't quite make sense.