jks

A single kiwirecorder command can make connections to multiple Kiwis and record to multiple files simultaneously. This is how it is used for example during the TDoA process. So various parameters like -f and -g can have multiple values that will correspond to multiple Kiwis, e.g.

kiwirecorder.py -s kiwi1,kiwi2 -f 1234,5678

connects to kiwi1 recording on 1234 kHz and kiwi2 on 5678 kHz. But

kiwirecorder.py -s kiwi1,kiwi2 -f 7890

Will record 7890 kHz on both.

There are example uses of kiwirecorder in the file kiwiclient/Makefile.

I had to fix a bug in v1.267. So there is now a v1.268 and I added the time limit exemption password to the list of URL parameters. Use "pwd=..." or "password=..."

Feb 20 has come and gone and I have an email into Seeed asking about the production status (email unanswered so far).

But some indirect news. Mouser has been out of stock for some time. But as of this morning now shows 10 units available. And you can successfully add them to your shopping cart. So I have to believe they exist (Mouser is good about not showing stock unless it's actually orderable). I'm hoping this means there was a Kiwi production run and they are being delivered with distributors getting priority. The Seeed website still shows "no stock" however.

I've added a link on the kiwisdr.com page to Octopart, the distributor search engine.

Login to the Beagle of your Kiwi, either using ssh from Linux/Mac, PuTTY from Windows or from the console tab of the admin page.
Type "scs avahi-daemon". Do you see messages like this that give the impression avahi is running?
(in all the following messages "www" will likely be replaced with "kiwisdr", the default Linux hostname of the Kiwi. My Kiwi happens to be named "www")

Feb 26 18:22:26 www avahi-daemon[679]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.1.103.
Feb 26 18:22:26 www avahi-daemon[679]: New relevant interface eth0.IPv4 for mDNS.
Feb 26 18:22:26 www avahi-daemon[679]: Registering new address record for 192.168.1.103 on eth0.IPv4.

If not, try restarting with "scst avahi-daemon", "scsa avahi-daemon" and another "scs avahi-daemon" and see if you get something like this:

root@www:~# scs avahi-daemon
? avahi-daemon.service - Avahi mDNS/DNS-SD Stack
   Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled)
   Active: active (running) since Wed 2019-02-27 01:46:17 UTC; 8s ago
  Process: 6088 ExecReload=/usr/sbin/avahi-daemon -r (code=exited, status=0/SUCCESS)
 Main PID: 6109 (avahi-daemon)
   Status: "avahi-daemon 0.6.31 starting up."
   CGroup: /system.slice/avahi-daemon.service
           ??6109 avahi-daemon: running [www.local]
           ??6111 avahi-daemon: chroot helper

Feb 27 01:46:17 www avahi-daemon[6109]: Process 679 died: No such process; trying to remove PID file. (/var/run/avahi-daemon//pid)
Feb 27 01:46:17 www avahi-daemon[6109]: Found user 'avahi' (UID 107) and group 'avahi' (GID 112).
Feb 27 01:46:17 www avahi-daemon[6109]: Successfully dropped root privileges.
Feb 27 01:46:17 www avahi-daemon[6109]: avahi-daemon 0.6.31 starting up.
Feb 27 01:46:17 www avahi-daemon[6109]: Successfully called chroot().
Feb 27 01:46:17 www avahi-daemon[6109]: Successfully dropped remaining capabilities.
Feb 27 01:46:17 www avahi-daemon[6109]: No service file found in /etc/avahi/services.
Feb 27 01:46:17 www avahi-daemon[6109]: Joining mDNS multicast group on interface usb0.IPv4 with address 192.168.7.2.
Feb 27 01:46:17 www avahi-daemon[6109]: New relevant interface usb0.IPv4 for mDNS.
Feb 27 01:46:17 www avahi-daemon[6109]: Joining mDNS multicast group on interface eth0.IPv6 with address fe80::9a84:e3ff:fe93:a341.
Feb 27 01:46:17 www avahi-daemon[6109]: New relevant interface eth0.IPv6 for mDNS.
Feb 27 01:46:17 www avahi-daemon[6109]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.1.103.
Feb 27 01:46:17 www avahi-daemon[6109]: New relevant interface eth0.IPv4 for mDNS.
Feb 27 01:46:17 www avahi-daemon[6109]: Network interface enumeration completed.
Feb 27 01:46:17 www avahi-daemon[6109]: Registering new address record for 192.168.7.2 on usb0.IPv4.
Feb 27 01:46:17 www avahi-daemon[6109]: Registering new address record for fe80::9a84:e3ff:fe93:a341 on eth0.*.
Feb 27 01:46:17 www avahi-daemon[6109]: Registering new address record for 192.168.1.103 on eth0.IPv4.
Feb 27 01:46:17 www avahi-daemon[6109]: Registering HINFO record with values 'ARMV7L'/'LINUX'.
Feb 27 01:46:18 www avahi-daemon[6109]: Server startup complete. Host name is www.local. Local service cookie is 3560849908.

If that doesn't work type "which avahi-daemon". Does it answer "/usr/sbin/avahi-daemon" ?

That information is only included in the filename currently.

There is an option for IQ format files (only) to include GPS timestamp information as metadata at periodic intervals in the data portion of the file. The .wav file spec allows for this. But in practice files with this metadata included in the data stream (as opposed to metadata in the header at the beginning of the file) keeps some playback applications from working which is unfortunate. The spec says applications are supposed to ignore metadata chunks they don't recognize.

It's an open question whether adding metadata to the header would also cause problems with some playback applications. It would be a real headache if we were to make such a change only to have people start complaining that newly recorded files won't playback for them.

For IQ files, yes, 2-channel (stereo), data is sent I-first, with I and Q samples interleaved.

An IQ file recorded with kiwirecorder on my Mac. Filename shows 1400.000 kHz CF but no passband. Generally IQ recordings are maximum passband though. Mode for a non-IQ mode file would show in place of "iq" in the filename, e.g. "am", "usb" etc. Sample rate will either be 12000 or 20250 Hz depending on if Kiwi was in 4/8 or 3 channel mode.

>>> afinfo 20190226T183722Z_1440000_iq.wav 
File:           20190226T183722Z_1440000_iq.wav
File type ID:   WAVE
Num Tracks:     1
----
Data format:     2 ch,  20250 Hz, 'lpcm' (0x0000000C) 16-bit little-endian signed integer
                no channel layout.
estimated duration: 24.803556 sec
audio bytes: 2009088
audio packets: 502272
bit rate: 648000 bits per second
packet size upper bound: 4
maximum packet size: 4
audio data file offset: 44
optimized
source bit depth: I16
----

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.

Depends on your definition of "safe". If you're going to do this I would strongly recommend using the "backup" function on the admin page to create a "flasher" sd card containing the complete Beagle distro including Kiwi customizations in the (likely) event you need to restore the Beagle filesystem. Don't use the sd card that came with the Kiwi. Use another one.

Good luck, and please let us know what happens. Be careful you are updating to a kernel that is compatible with the Debian disto you're running.

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.