jks

One of my tests of the new 20 kHz bandwidth mode was to run my Kiwi with 3 simultaneous connections, each using the WSPR extension, to put some load on the system. My active antenna coupler has been broken for months now as evidenced by the "flatline" waterfall/spectrum I have (save the Ethernet spurs). I think there is a broken wire, component etc. someplace such that I essentially have an air gap in the connection (AM BCB signals are 45 dB down from where they should be). So I didn't expect the WSPR decoder itself to be running for long after the two minute capture window.

Well, you can guess what comes next. I take a look 30 minutes later and all 3 bands (40m/30m/20m) are filled with WSPR decodes. Including a guy 400 km away running 10 mW on 30m. This was in the middle of the day. SMH. From the upload to wsprnet.org:

26 spots:
 Timestamp           Call        MHz         SNR Drift   Grid        Pwr     Reporter    RGrid       km      az
 2018-12-31 01:34    ZL1TIU      7.040105    -26     0   RF73je      0.2     ZL/KF6VO    RF82ci      156     127 
 2018-12-31 01:32    ZL2MWS      10.140160   -22     2   RE78mv      0.01    ZL/KF6VO    RF82ci      397     15 
 2018-12-31 01:28    ZL2MWS      10.140246   -21     2   RE78mv      0.01    ZL/KF6VO    RF82ci      397     15 
 2018-12-31 01:25    ZL1TIU      10.140203   -15     0   RF73je      0.2     ZL/KF6VO    RF82ci      156     127 
 2018-12-31 01:25    ZL2IK       10.140241   -6      0   RF74ci      1       ZL/KF6VO    RF82ci      285     142 
 2018-12-31 01:25    ZL1VCC      14.097009   -6      0   RF81cu      5       ZL/KF6VO    RF82ci      56      0 
 2018-12-31 01:20    ZL1ER       14.097151   -15     0   RF81du      0.05    ZL/KF6VO    RF82ci      56      352 
 2018-12-31 01:20    ZL2MWS      10.140130   -17     1   RE78mv      0.01    ZL/KF6VO    RF82ci      397     15 
 2018-12-31 01:18    ZL1TIU      14.097104   -25     0   RF73je      0.2     ZL/KF6VO    RF82ci      156     127 
 2018-12-31 01:16    ZL2IK       10.140243   -5      0   RF74ci      1       ZL/KF6VO    RF82ci      285     142 
 2018-12-31 01:16    ZL1TIU      10.140203   -16     0   RF73je      0.2     ZL/KF6VO    RF82ci      156     127 
 2018-12-31 01:14    ZL1VCC      14.097008   -9      -1  RF81cu      5       ZL/KF6VO    RF82ci      56      0 
 2018-12-31 01:14    ZL1TIU      7.040105    -22     0   RF73je      0.2     ZL/KF6VO    RF82ci      156     127 
 2018-12-31 01:12    ZL2MWS      10.140145   -20     0   RE78mv      0.01    ZL/KF6VO    RF82ci      397     15 
 2018-12-31 01:08    ZL1ER       14.097151   -21     0   RF81du      0.05    ZL/KF6VO    RF82ci      56      352 
 2018-12-31 01:08    ZL2MWS      10.140150   -21     0   RE78mv      0.01    ZL/KF6VO    RF82ci      397     15 
 2018-12-31 01:06    ZL2IK       10.140243   -5      0   RF74ci      1       ZL/KF6VO    RF82ci      285     142 
 2018-12-31 01:06    ZL1TIU      10.140203   -15     0   RF73je      0.2     ZL/KF6VO    RF82ci      156     127 
 2018-12-31 01:04    ZL2MWS      10.140137   -21     1   RE78mv      0.01    ZL/KF6VO    RF82ci      397     15 
 2018-12-31 01:04    ZL1TIU      7.040105    -24     -1  RF73je      0.2     ZL/KF6VO    RF82ci      156     127 
 2018-12-31 01:02    ZL1VCC      14.097009   -25     -1  RF81cu      5       ZL/KF6VO    RF82ci      56      0 
 2018-12-31 00:56    ZL2MWS      10.140183   -25     2   RE78mv      0.01    ZL/KF6VO    RF82ci      397     15 
 2018-12-31 00:56    ZL2IK       10.140242   -8      0   RF74ci      1       ZL/KF6VO    RF82ci      285     142 
 2018-12-31 00:56    ZL1TIU      10.140203   -7      0   RF73je      0.2     ZL/KF6VO    RF82ci      156     127 
 2018-12-31 00:54    ZL1TIU      7.040105    -21     0   RF73je      0.2     ZL/KF6VO    RF82ci      156     127 
 2018-12-31 00:52    ZL2MWS      10.140144   -22     0   RE78mv      0.01    ZL/KF6VO    RF82ci      397     15 

One of my tests of the new 20 kHz bandwidth mode was to run my Kiwi with 3 simultaneous connections, each using the WSPR extension, to put some load on the system. My active antenna coupler has been broken for months now as evidenced by the "flatline" waterfall/spectrum I have (save the Ethernet spurs). I think there is a broken wire, component etc. someplace such that I essentially have an air gap in the connection (AM BCB signals are 45 dB down from where they should be). So I didn't expect the WSPR decoder itself to be running for long after the two minute capture window.

Well, you can guess what comes next. I take a look 30 minutes later and all 3 bands (40m/30m/20m) are filled with WSPR decodes. Including a guy 400 km away running 10 mW on 30m. This was in the middle of the day. SMH. From the upload to wsprnet.org:

26 spots:
 Timestamp           Call        MHz         SNR Drift   Grid        Pwr     Reporter    RGrid       km      az
 2018-12-31 01:34    ZL1TIU      7.040105    -26     0   RF73je      0.2     ZL/KF6VO    RF82ci      156     127 
 2018-12-31 01:32    ZL2MWS      10.140160   -22     2   RE78mv      0.01    ZL/KF6VO    RF82ci      397     15 
 2018-12-31 01:28    ZL2MWS      10.140246   -21     2   RE78mv      0.01    ZL/KF6VO    RF82ci      397     15 
 2018-12-31 01:25    ZL1TIU      10.140203   -15     0   RF73je      0.2     ZL/KF6VO    RF82ci      156     127 
 2018-12-31 01:25    ZL2IK       10.140241   -6      0   RF74ci      1       ZL/KF6VO    RF82ci      285     142 
 2018-12-31 01:25    ZL1VCC      14.097009   -6      0   RF81cu      5       ZL/KF6VO    RF82ci      56      0 
 2018-12-31 01:20    ZL1ER       14.097151   -15     0   RF81du      0.05    ZL/KF6VO    RF82ci      56      352 
 2018-12-31 01:20    ZL2MWS      10.140130   -17     1   RE78mv      0.01    ZL/KF6VO    RF82ci      397     15 
 2018-12-31 01:18    ZL1TIU      14.097104   -25     0   RF73je      0.2     ZL/KF6VO    RF82ci      156     127 
 2018-12-31 01:16    ZL2IK       10.140243   -5      0   RF74ci      1       ZL/KF6VO    RF82ci      285     142 
 2018-12-31 01:16    ZL1TIU      10.140203   -16     0   RF73je      0.2     ZL/KF6VO    RF82ci      156     127 
 2018-12-31 01:14    ZL1VCC      14.097008   -9      -1  RF81cu      5       ZL/KF6VO    RF82ci      56      0 
 2018-12-31 01:14    ZL1TIU      7.040105    -22     0   RF73je      0.2     ZL/KF6VO    RF82ci      156     127 
 2018-12-31 01:12    ZL2MWS      10.140145   -20     0   RE78mv      0.01    ZL/KF6VO    RF82ci      397     15 
 2018-12-31 01:08    ZL1ER       14.097151   -21     0   RF81du      0.05    ZL/KF6VO    RF82ci      56      352 
 2018-12-31 01:08    ZL2MWS      10.140150   -21     0   RE78mv      0.01    ZL/KF6VO    RF82ci      397     15 
 2018-12-31 01:06    ZL2IK       10.140243   -5      0   RF74ci      1       ZL/KF6VO    RF82ci      285     142 
 2018-12-31 01:06    ZL1TIU      10.140203   -15     0   RF73je      0.2     ZL/KF6VO    RF82ci      156     127 
 2018-12-31 01:04    ZL2MWS      10.140137   -21     1   RE78mv      0.01    ZL/KF6VO    RF82ci      397     15 
 2018-12-31 01:04    ZL1TIU      7.040105    -24     -1  RF73je      0.2     ZL/KF6VO    RF82ci      156     127 
 2018-12-31 01:02    ZL1VCC      14.097009   -25     -1  RF81cu      5       ZL/KF6VO    RF82ci      56      0 
 2018-12-31 00:56    ZL2MWS      10.140183   -25     2   RE78mv      0.01    ZL/KF6VO    RF82ci      397     15 
 2018-12-31 00:56    ZL2IK       10.140242   -8      0   RF74ci      1       ZL/KF6VO    RF82ci      285     142 
 2018-12-31 00:56    ZL1TIU      10.140203   -7      0   RF73je      0.2     ZL/KF6VO    RF82ci      156     127 
 2018-12-31 00:54    ZL1TIU      7.040105    -21     0   RF73je      0.2     ZL/KF6VO    RF82ci      156     127 
 2018-12-31 00:52    ZL2MWS      10.140144   -22     0   RE78mv      0.01    ZL/KF6VO    RF82ci      397     15 

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.