jks

When you mentioned "external decoders" I assumed you were interested in I/Q obtained from the L/R channels of the browser audio output, e.g. so the browser could be used to control the Kiwi. It is indeed possible to connect over the network (via web sockets) to the Kiwi server and issue the same API commands as the browser UI does to set frequency etc.

An example written in Python that works on Linux/OS X is called kiwiclient/kiwirecorder available here: https://github.com/jks-prv/kiwiclient/tree/jks-v0.1 It is capable of recording to .wav files but there is no reason you couldn't stream to another application. I think Christoph was working on (or has working) an interface to GNUradio this way. The I/Q mode bandwidth is of course limited to the audio channel bandwidth (currently 12 kHz).

I see those occasionally and don't quite understand them. But I also haven't spent any time trying to track them down. My guess would be some buffering problem where a configuration save command from a prior admin session is leftover someplace and gets flushed out to the Kiwi during the next connection (the arrival from China in this case). I don't believe anything malicious is going on here.

October 7/8: Massdrop is active again for 7 days. $80 discount on the Kiwi kit ($219 vs $299). Free (but slow) shipping to the USA. Best deal out there. Limited quantities available and over 70 people were on the notification list. So don't delay.

@Kevin Not a problem at all. What led me straight to the bug was the report in the other thread: click the "kick" button on a WSPR auto-run connection and the server crashes.

Okay, I see the bug. It was actually introduced in v1.235 but doesn't get triggered until a restart (like when updating to v1.236)

I'll fix it in today's update. But the issue now is that you'll either have to temporarily turn off WSPR auto-run or go through the manual update procedure one more time to get past this problem.