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 

"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.