Wideband IQ streaming mode for local processing? [better late than never!]
Hello John.
In http://www.kiwisdr.com/ks/compare.1.1.pdf you note that "Wide-band output mode suitable for use with traditional, external software under consideration".
In http://www.kiwisdr.com/quickstart/, FAQ-Design you note, that your digital down-conversion architecture only allows for 8 channels and that you only allow 3 20kHz wide audio / IQ channels due to performance reasons.
I love the web based UI for casual listening, while I would love to run a handful of CW skimmers or HDSDR and similar ExtIO supporting applications for low latency.
Do you still consider implementing the wideband IQ mode? What is the bottleneck? Is the FPGA capable of multiple wideband (let's say 48ksamples per second) IQ downconversion to cover CW subbands? How many CW subbands would it cover? I know the Beaglebone is not very powerful, is the Beaglebone a bottleneck?
I have an experience implementing ExtIO for HDSDR https://github.com/bubnikv/ExtIO_Omnia , I may help implementing an ExtIO for Kiwi.
Also I am not sure whether you are aware of https://www.sdrpp.org/ . The SDR client is being implemented by a 20 year old (sic!) student and he aready produced a low latency Android port. He implemented support for SpyServer
https://github.com/AlexandreRouma/SDRPlusPlus/tree/master/source_modules/spyserver_source/src
The SpyServer protocol
seem to work in a similar way to KiwiSDR WebSocket based API: It seems to be able to deliver processed FFT + audio IQ. It seems that implementing streaming support for SDR++ may be worthwile considering the grow of the project, the enthusiasm of the author and the amount of financial support he is getting. I am willing to donate some money to him for Kiwi support if others join me. We should likely donate him a single unit as well.
Thanks for considering and 73,
Vojtech OK1IAK
Comments
Kiwi's IQ feed is limited to 20 or so KHz of audio I/Q. It is a different type of SDR than all the other stuff.
Thanks, I see. I read an extensive explanation in some old post from John. For example, the I2C bus bandwidth one of the bottlenecks.
Still I think the SpyServer like plugin for SDR++ would be cool and very useful.
@ok1iak Well, here we are. Over two years later. I had not forgotten about this. For various reasons I decided now was the time to give it a try.
This is an extremely early result. There are all kinds of problems. Currently, all I can get semi-reliably without too many glitches is a wideband output of 240 kHz. I'm pretty sure more can be done with some optimization. There is no CIC filtering in the FPGA yet, so there is aliasing.
To get SDR++ working as quickly as possible on my Mac the easiest thing to do was write a very quick and dirty SpyServer implementation (partial) from the public spec. That's why below it says "SpyServer", "Int16" and "RTL-SDR". But it really is connected to a Kiwi-2 on the special SpyServer port 5555. I have not tried SDR# yet. This Kiwi is on the other side of the world from me. So it is streaming at 240 kHz over the Internet successfully.
You can't make any Kiwi user connections when the Kiwi is configured for wideband mode. But you can make an admin connection. Lots and lots of work to do before this is ready for any sort of release.
Bump, because this thread wasn't showing since it was moved to the "feature requests" category. Apparently threads which pre-date new category creation are simply not displayed. Forum software bug!
@jks Do you use spyserver, or something spyserver-compatible?
Spyserver had used a lot of CPU on my system. ka9q-radio is using about 5x less, depending on how many clients are connected. About 20% of one core with 10 MHz bandwidth. And it's open source.
There's now a soapy module for ka9q-radio, so it works with multiple sdr programs. sdr++ unfortunately dropped soapy support though.
As mentioned in that post, I quickly implemented the simplest, dirtiest server that followed the minimum SpyServer protocol just to get SDR++ to work (barely). My goal was to see if this concept was even possible. SDR++ was the fastest route to that goal.
I don't know anything about soapy or ka9q-radio or how difficult it might be to write a driver for them.
More importantly, this work was paused until other "pieces of tech" become available to make sending a more significant amount of spectrum possible. Like MHz instead of hundreds of kHz. That work is still ongoing..