jks

Okay, if you update to the latest kiwiclient / kiwirecorder then when in S-meter mode:

"--dt-sec=sec" will average (as fast as possible) for that many seconds and then print a measurement result. This is different from "--s-meter=value_greater_than_zero" which averages for a specific number of averages. Naturally it is a conflict to use both --dt-sec > 0 and --s-meter > 0. If you are using --dt_sec you want --s-meter=0.

"--ts", "--tstamp" or "--timestamp" will prefix the output with a timestamp. "--stats" works as before showing you the actual number of averages/sec obtained.

Sample output. See the Makefile for command line examples.

python kiwirecorder.py -s kiwi -p 8074 --s-meter=0 --ts --dt-sec=2 --tlimit=10 --stats
26-Oct-2019 19:24:32 UTC RSSI: -111.2 3.0 meas/sec
26-Oct-2019 19:24:34 UTC RSSI: -111.2 6.0 meas/sec
26-Oct-2019 19:24:36 UTC RSSI: -111.2 6.0 meas/sec
26-Oct-2019 19:24:38 UTC RSSI: -111.2 5.0 meas/sec
26-Oct-2019 19:24:40 UTC RSSI: -110.9 6.0 meas/sec
5.9 meas/sec

Okay, today's v1.336 release now applies the ip blacklist to incoming connections made via the proxy. Because the filtering in done in the Kiwi server instead of iptables a Kiwi log entry is made when the blacklist filter hits. iptables is still used for non-proxy connections for performance reasons.

The "ipt" shell alias now automatically includes the "-v" argument so you can see the packet counter for the iptable filtering rules. I.e. an incrementing packet count means the blacklist filter has been hit. Use "iptz" or "iptc" to clear the counters. These aliases can be used on the admin page console tab.

You're using the proxy? Yeah, I realize now that none of the blacklist stuff will work if you're using the proxy.

This is something I'll have to fix. The reason I used iptables is that it's very efficient at filtering. I can't do nearly as well in the Kiwi code and I didn't want to impose a penalty on everyone since there is currently one default blacklist rule on every single Kiwi.

But when the proxy is in use from the Kiwi's perspective all the connection attempts appear to be coming from the single proxy ip (by definition). The reason you still see the actual user's ip in the log messages is that there is an extra step to uncover the true ip address when the proxy is in use. But this step is not visible to iptables. So for the proxy case I'm going to have to find an efficient way to filter in the Kiwi code..

I am currently using a couple of those stacking headers with the extra-long 8.5mm tails. The trick is to insert the pins only partially into the AI headers. This is not difficult because the insertion force is so great. The problem is to get all 46 pins aligned and moving together without bending any. The Kiwi board can go flush onto the new headers as usual. It gives you about 12mm more spacing between the two boards.

Not the best photo, but you can sort of get the idea. Also note the PMIC heatsink. It wasn't exactly what I wanted but is better than nothing. The random wires is a hack for the console serial port so I didn't have to wait on shipping for the special adapter cable from DigiKey. On the left going out of frame is the USB connection for the fan power.

Below shows progress with an experiment to get a 14-channel configuration working using a BeagleBone AI. The challenge is to move as much processing to the second cpu core of the AI as possible so as not to impact the realtime requirements of serving the 14 audio channels (plus the usual 12-channel GPS etc.) It seems to work. A 14 audio DDC + 1 waterfall DDC configuration (rx14_wf1) was made to fit in the FPGA (LUTs now 97% full) by reducing the amount of CIC filtering logic slightly.

Note below that the processor temperature and clock speed are displayed. The cores are currently running at rate automatically adjusted based on temperature between 1.0 - 1.5 GHz due to the reduced cooling configuration I'm testing.



The Kiwi's internal WSPR extension is running on all 14 channels as a worst-case test since WSPR decoding is so cpu intensive. The fact that this works does not change the fact that Rob's wsprdaemon is the superior solution for anything but casual WSPR monitoring. In fact 14 channels was chosen in support of getting a single Kiwi to work in an all-band wsprdaemon setup.

Below is output from the Linux "ht" command. It shows how certain components of the software have been moved to new Linux processes separate from the main Kiwi process and "locked" to the second core of the processor. "kiwid" is the main process and is locked to cpu0 as seen in the "cpu" column. The other "kiwi.xxx" processes are locked to cpu1. Of interest here is the "kiwi.wsp" process which runs the collective WSPR decoding of all 14 channels.



This is just a progress report. There is a long list of work to do.