jks

Seeed finally got back to me about the Kiwi production situation. They said they were not able to find ADC chips. I didn't understand this at all as a single click on a bookmark with my mouse showed hundreds of chips in stock at the usual suspects. The only thing I can think of is that Seeed's purchasing department didn't quite understand that Linear Technology had been acquired by Analog Devices back in 2017. And rebranding of the parts may have occurred causing them to think they weren't the same as those called out by the Kiwi Bill-of-Materials. But that's just a guess. Trying to get detailed information out of Seeed is like pulling teeth and seems to be one of the pitfalls of doing business with China.

Anyway, they are supposed to receive 350 parts tomorrow and hopefully production will resume shortly thereafter.

I must mention however that I am extremely grateful for Seeed's involvement with the Kiwi. Their production quality is top notch. And their efforts to develop the distributor network has helped the project tremendously.

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.