jks

Hi Larry. If you're talking about the kiwirecorder and/or kiwi_nc (netcat) Python programs as we discussed in email then the situation is a bit different from the browser interface on the Kiwi itself (Ron's answer is excellent).

When you use the "--wf" option with kiwiclient (i.e. as used by the "wf:" target in the Makefile) what happens is the Kiwi sends waterfall data at zoom level zero (0 - 30 MHz) at a 1 Hz update rate by default. The data is 1024 bins wide which is the size of the waterfall FFT and also how many bins are seen on the browser interface. So at zoom=0 each bin represents roughly 30 kHz of spectrum (30 MHz / 1024 bins ~= 30 kHz).

I recall you said your analysis application wanted 512 bins of input data. So one thing you could do is simply throw away the first 512 bytes of output data on each update. Then you'd be left with 512 bins of data for 15 - 30 MHz. Now there is a --zoom option in kiwiclient as well but it turns out it isn't implemented quite correctly at the moment. It would be easy to fix however and then together with the -f option to set the center frequency you could set whatever power-of-two zoom sub-multiple of 30 MHz you wanted. For example as Ron said set the frequency to 22.5 MHz (the middle of the 15-30 MHz segment) and zoom=1. Then you'd get 1024 bins beginning at 15 MHz each with about 15 kHz of resolution.

That is a sure sign of the power supply not meeting the 50 millisecond "ramp up" requirement of the Beagle. That is, if you were to look at the time it takes the 5V waveform to go from 0V to 5V it would be too slow. This can happen if it is taking too long to charge the power supply output capacitor which will will look like a dead short for a period of time (especially if it is a large cap).

But when you plug the power supply into the Kiwi the cap is already charged and the waveform appears to ramp up quickly.

I will improve the input parsing for this field to prevent the problem in the future.

For those of you who struggle like me to get regular expressions working this is the greatest thing since sliced bread: https://regex101.com

I assume you mean 20 kHz. The default b/w for the "AM" mode button is 10 kHz now (+/- 5 kHz either side of carrier) and 5 kHz for "AMN" (+/- 2.5 kHz). There has been a suggestion that rather than adding a third button (e.g. "AMW", for which there is no room) a single AM button toggle between 3 or 4 b/w choices (20, 15, 10, 5 kHz?).

Adding an initial b/w field to the admin "config" tab to go along with the initial mode selection is certainly possible.

The WSPR extension decoding process (not the sampling during the two minute sampling interval) is hugely compute intensive. And if you are in an area where lots of WSPR signals are being received on multiple bands simultaneously, causing heavy decoder load, and you have other regular connections on an 8-channel system then it is possible the realtime scheduling requirements cannot be met leading to audio underruns.

This behavior is a bug, but also difficult to fix. So it probably won't be anytime soon given everything else that is being worked on.