jks

It's the middle of the night now in the EU, but here's a quick fix until a software update in a few hours.

If your Kiwi receives no signals because the IQ balance has ended up with huge offset values simply do this:
Open the IQ extension.
Set the PLL mode to OFF (very important).
IQ balance as normal (AM mode, antenna disconnected, no signals or spurs within passband when zoomed in).

Everything should now be back to normal.

The update will improve the IQ balancing user interface and fix a bug related to 20 kHz mode (the above fix works for both 12 and 20 kHz mode).

Okay, v1.266 is out with some fixes.

So the problem is that you can't be doing an IQ balance with the PLL turned on. This fact is now documented with the IQ balance instructions in v1.266. What's happening is that the PLL is trying to find something to lock onto and as a result is pulling the I and Q values around causing the sampling for IQ balance to be, well, unbalanced. That's why repeatedly doing a balance with the PLL on was causing the I offset value to start moving significantly away from zero until the offset itself was overwhelming the desired I signal component. This has the of effect drowning out the received signals causing the volume to go down, large S-meter reading, etc. that you observed.

Each IQ balance you make is cumulative since the prior IQ balance is in effect each time you make a new balance. That's why it's so important that there is no signal or spur within the passband while you balance -- so the I & Q offset numbers measured are not skewed by any signals being received (only influenced by the uniform noise level).

There is a new button in the balance popup that allows the offsets to be restored to their default values. And also fields for manual entry on the admin config tab. So in the future you shouldn't get stuck if somehow a bad balance occurs (e.g. there was something other than uniform noise in the passband).

Interestingly, I discovered that the default IQ offset value for 12 kHz mode (4 and 8-channel mode), -0.02, is not the correct one to use for 20 kHz mode. It seems to scale with channel bandwidth. The correct value is -0.02 * 20.25/12.0 (kHz) = ~ -0.034 So I had to add some code to use the correct default depending on mode.

There is really no reason to ever be rebalancing the IQ. The Kiwi is not like those analog sampling SDRs (e.g. SoftRocks) that need to be individually tuned. The default values have been shown to be correct for all Kiwis with their modern differential input ADC and ADC preamp. The only thing that is currently unknown is why the required Kiwi IQ offset values are not zero. The fact that the same value is required for all Kiwis (either -0.02 or -0.034 as mentioned earlier) seems to indicate there is a software/firmware reason someplace. Today's finding that this offset value is channel-bandwidth dependent is an important clue. But this is not really a problem, it's just an open question.

One of the best ways to understand the effects of IQ offset is to try the following. Find a moderately weak carrier such as an Ethernet spur with the antenna disconnected. In AM mode set the tuning so the carrier is in the low frequency part of the passband, like 300 Hz or so. Narrow the passband to 1 kHz by typing '/1k' in the frequency entry box. If you're in AM mode you should not hear a 300 Hz tone if the IQ is balanced properly. Now open another browser tab and connect to the admin config tab. Change the I balance offset to -1.0 You should hear a 300 Hz tone in the now unbalanced condition. When you change the value back the tone should stop. This is how I discovered the default balance value was wrong in 20 kHz mode. You get tone when using the 12 kHz mode balance value.

Calm down, it's just a bug with 20 kHz mode. I'm looking at it now.

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.

Okay, I think kiwirecorder resampling works now. Update from https://github.com/jks-prv/kiwiclient.git (master or jks-v0.1 branch) and use the new "-r N" or "--resample N" option where N is the new sample rate in Hz. Works with regular and IQ-mode recordings. See the "resample" and "resample_iq" example targets in the Makefile.