jks

Three channels at 20 kHz is subject to being reduced to only two depending on experiences with stability. I would have set it at two but I couldn't get the FPGA code to compile using only two channels for reasons I still don't understand. From the CHANGE_LOG file:

v1.250  December 31, 2018
    Add 20 kHz wide audio bandwidth mode.
        A third entry to the list of FPGA configurations. See admin "mode" tab for details.
    
    Add Ethernet 10/100 speed select to admin network tab.
        The speed changes after a few seconds of delay (no Kiwi restart required).
        This allows you to be looking at a waterfall in another window and see if
        the Ethernet spurs (if present at your installation) improve or not.
        Be sure the device (router, switch) your Kiwi connects to supports 10 Mbps Ethernet.
    
    Accept 'k' & 'M' scaling suffixes in frequency and passband parameters.
        Examples: Type "/15k" in frequency box to get a 15 kHz wide passband. Or "/2.7k", "-5k,10k" etc.
        Use a URL of "...?f=7.4M/16.5k" to set a frequency of 7.4 MHz and passband of 16.5 kHz.
        Note uppercase 'M' since 'm' is already keyboard shortcut for mute.
        You can remember this because the 'M' in MHz is always capitalized whereas 'k' in kHz is not.
        Note also 'k' used to be paired with 'j' as the frequency up/down jog shortcut.
        Now use the 'j' and 'i' keys are used (also 'J' and 'I' to jog faster).
        Using the 'i' key is actually more natural because it fits the placement of your
        index and middle fingers better than 'j' and 'k'.
        Finally, 'i' was previously used to select IQ mode. Now use 'q' instead.
        Type 'h' or '?' to see the complete keyboard shortcut help panel.

"Auto add NAT rule" only does so for the Kiwi port -- 8073 or whatever has been configured. It does not do so for port 22 under any circumstances.

The Kiwi uSD "flasher" card is bootable. It can recover a Kiwi with an eMMC in any condition besides an outright hardware failure.

If someone has purposefully configured NAT on their router to forward port 22 to the Kiwi without setting a Debian root password, well, they deserve what they get. I highly doubt there are "many" installations in this condition.

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.

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.

Here's what I do. I have a git clone of the current Kiwi disto on my Mac. I edit there and compile to get the compilation bugs out. The main Makefile detects when you're not compiling on the Kiwi and allows different compile tools/flags to be used that are particular to your development machine.

Then on the target Kiwi I use NFS to mount the Mac sources read-only onto /root/Beagle_SDR_GPS. So I can just ssh into the Kiwi and build/test there without having to be copying all the source files all the time. unix_env/bashrc (that gets installed as /root/.bashrc on the Kiwi) has some hints about setting up NFS on the Kiwi and your development machine (I don't know about Windows though). Because the mount is read-only if the update process is unintentionally started on the Kiwi it won't reverse-write the sources on the Mac and destroy my work-in-progress (super important obviously).

The various Makefiles have manual targets for copying the Verilog source files to whatever environment Xilinx Vivado happens to be running. In my case I run it on Ubuntu on a VirtualBox VM on my Mac. It works surprisingly well despite all the emulation layers (about 10 minutes to build the FPGA image on a three-year-old MacBook Pro).