jks

See the recent announced post for a solution to this problem.

I started work on that feature a while back. It's unfortunately difficult to implement. So I put it aside for now. Too much else of greater importance going on.

Oh wait -- I see now why /bin/nc is not getting installed by the Makefile. Fixed now for the next release. We hadn't noticed this previously since there are so few users of the KMtronic-UDP.

Thanks for pointing this out!

You can try it. But you need to be prepared to ssh into the Kiwi and restore the binary file (or rebuild from source) if installing the binary manually happens to leave the Kiwi server bricked due to some incompatibility. This is essentially what I'm going to do next to start exploring what those issues are.

So from the admin console tab you can do:

And then use the restart button on the control tab.

You can use your own ref clock. But it needs to be a frequency that's compatible with the Kiwi's ADC clock, e.g. 66.6xxx MHz. Not a 10 MHz house reference.

Lots of people program a 66.672 MHz output from a Bodnar GPSDO to feed the EXT CLK input. That gives a precise 12 kHz audio sample rate which some people require. Settings for external clock setup are on the admin page, config tab. Including the setting where you disable the Kiwi's GPS clock correction (which makes no sense to enable for almost all external clock situations).

With Kiwi-2 the self test output function is just an additional feature for that connector.

Try putting the new address on the front of the local list (not the end).

There is this issue that if you have overlapping IP space in the list then the list processing stops at the point of the overlap (e.g. the same IP address duplicated or overlapping subnets). There was a post some time ago that discussed this. The fix is a bit complicated and I don't have time right now.

Use the "ips" command in the admin console to see if your new address makes it into the ipset table.

Either notation can be used (with or without a /32 subnet for a single IP address).

There is a software bug (v1.665 and earlier) that has been observed by a number of people now. The attenuator becomes set to about 26 dB of attenuation even though the slider on the user RF tab and admin page config tab all say zero. Worse, the problem persists across restarts.

I have reviewed the code and can't see an obvious issue. So the next release, v1.666, has a bunch of debugging added to log the problem so I can fix it. You can clear this problem by simply changing to attenuator to a non-zero value and then back to zero on the user RF tab slider (changing the admin slider won't fix the problem). If your Kiwi is public you might want to consider making the RF attenuator adjustable by "everyone" for this reason. Setting on the admin page, config tab. My apologies for this very annoying bug.

+++

About SMA connector torque: Many of you will know more about this than me. But I'll tell you what I know.

You have to be careful with SMA connectors. Because the fittings are brass they have to be torqued tight enough to make a good ground connection on the outer threads. But you don't want to use a wrench that supplies too much torque because that will deform the soft brass and then the connector will be ruined.

So if you think signal levels from your antenna are down try finger tightening the threads a little bit more. But don't use a tool unless you're extremely careful. You can use the self-test function of the signal generator extension with the SMA-to-SMA cable that was supplied with the Kiwi to verify the Kiwi's RF front end is working properly. Procedure described here: http://kiwisdr.com/quickstart/#id-self-test

Hewlett-Packard used to ship a special SMA/SMB connector torquing tool as part of the service kits for their test equipment just for this reason. But it was very expensive if purchased separately. Hundreds of dollars! Anyone remember that?

It's on the list. But low priority. Because I have to go through Beagle device-tree hell to make it work.

I've already fixed one aspect of this issue (will be included in the next software release).

After a page reload all is well. Adjusting the passband edge works when the cursor is dragged anywhere in the grey frequency scale area. When the cursor enters the waterfall area below the scale the edge dragging stops and reverts to passband tuning.

Here's the bug: As soon as you drag the waterfall just once then passband edge dragging in the lower half of the frequency scale breaks. It now behaves the same as a passband edge drag entering the waterfall area. Namely that the edge dragging stops and reverts to passband tuning.

So that problem has been fixed. What I'm working on now is trying to make edge dragging persist no matter where the cursor wanders to. But this is much more difficult.