jks

So the problem here is that FT8 has a much greater time synchronization requirement (i.e. "wall clock" time) than WSPR does. The timing of the audio hitting FT8 must match what time the FT8 program is getting from the host operating system within a second or two at most.

The Kiwi produces a delay in the audio stream because it has some buffering. Buffering is required because it is the only defense against latency/interruption issues in the network, particularly when the audio is being delivered by the Internet over long distances with lots of potential points of interruption. So you are already being disadvantaged by the time delay of this buffering to begin with. Any additional cumulative delay by other software behaving badly (e.g. sample rate compensation by the VAC) may push the total timing over the FT8 limit.

One thing you could try is reducing the Kiwi buffer size to reduce the fixed delay. The penalty for doing this is that you will have much less immunity to short-term network interruptions. That means it's important to make sure there are no highly variable latency devices in the path between the Kiwi and computer running the browser, like a WiFi router or a cheap Ethernet switch that might behave badly with heavy traffic on the other ports.

Add "abuf=n.nn" to the URL where n.nn is a number in seconds of the minimum audio buffer size. Start with 0.5 and experiment with a range from 0.3 to 0.8

It would also be interesting to know on the control panel "Stats" tab what the value of the Audio "Qlen" (queue length) is when you are having problems versus what the value is when starting (this value will vary when the abuf= value is changed)

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.

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
----

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.