support for Omnia SDR

[bubnikv]

Dear Martin.

I wonder whether you would kindly implement a support for the Omnia SDR transceiver into your rtlsdr driver.

The Omnia SDR www.omnia-sdr.com

is a short wave HAM radio SDR transceiver, implementing an USB hub, USB audio class device and a libusb low speed communication port for controlling an internal VFO, band pass filters etc. The Omnia firmware could be changed to let the USB audio class device identify itself as something different than an USB audio device as to avoid the stock Linux USB driver to open it, so I suppose it should be then possible to implement an audio like driver using the libusb interface by porting a Linux USB audio kernel driver to libusb in a similar way it has been done for the rtlsdr.

Once there is a driver for the Omnia, I suppose one would be able to use your stock sdrtouch Android application for receive. A transmit function would be cool as well :-)

Thanks for consideration, Vojtech

[martinmarinov]

Hey Vojtech,

Unfortunately there are not current plans to support this hardware.

I would need a good framework that works well on Android + an actual hardware device to test on during development. Both of which I believe do not exist at the moment for this hardware.

Martin

[bubnikv]

I have found that there is a commercial implementation of a libusb audio driver for Android: http://superpowered.com/ I asked them, whether they would provide a free driver for open source, or how much would be the licensing cost for a low profile application, but I did not get an answer.

The device also needs a low speed libusb control, but that should be trivial to implement.

Would you be interested to play with the device? I think the authors would give you one for free.

[bubnikv]

Actually it seems that to implement audio-in for a fixed USB ID and a fixed audio protocol on Android using libusb-1.0 is quite simple: https://github.com/shenki/usbaudio-android-demo

I will try to sketch up a proof of concept with the Omnia.

[bubnikv]

Hello Martin.

It has been nearly three years since I opened this request. I did some experiments since then.

First I got it compile, see https://github.com/bubnikv/rtl_tcp_andro-/commit/83d12334153f28b55934c8a5835efb38e00d7e82 https://github.com/bubnikv/rtl_tcp_andro-/commit/4559e0ff1ca74428afa9f59ce4e2d5e468dee1c1

I tested accessing the sound card of the Omnia hardware using libusb-1.0 on Windows and I got it working. I had to deregister the Windows sound card driver from the USB device and register the system libusub.sys using the https://zadig.akeo.ie/ tool. Then I was able to write a working http://www.hdsdr.de/ plugin for the Omnia hardware talking to the Omnia's sound card directly using libusb-1.0 isochronous transfer. It was not difficult at all using the following sketch, as the Omnia sound card emulation supports just a single isochronous mode and no sound card control interface.

https://github.com/shenki/usbaudio-android-demo

Now comes the interesting stuff. How to integrate it with your rtl_tcp driver?

It seems to me relatively straightforward to clone RtlSdrDevice.java & RtlSdrDeviceProvider.java to an OmniaDevice.java & OmniaDeviceProvider.java, then to clone rtlsdrdevice.c & sdrtcp.c,h to my omniadevice.c, omniatcp.c,h and implement the libusb communication there. Using your infrastructure it should be relatively straightforward to pipe the data from the TCP channel to libusb and vice versa. So far so good.

I have following difficulties:

1) How does the 16 bit sampling protocol work? How does the master (the application) ask for the 16 bit sampling? How does the TCP protocol between the application and the driver change with 16 bit sampling? You stated explicitly in the documentation of your driver that the driver does not support it.

2) Your sdrtouch application supports sampling rates 0.256msps, 1.024 msps and 2.048 msps. I understand these are suited to the rtl chip. Could you please extend sdrtouch to support 0.192msps for the sound card based device like the Omnia?

3) Could you please extend the protocol to send the center of the receive frequency to the driver, at least in the CW mode? The reason for that is, I have a firmware for the Omnia, which supports CW transmit by the Omnia directly without master support as long as the Omnia knows where to transmit. This would allow us HAMs to use your SDRTouch with Omnia as a standalone RX/TX solution at least for CW and it is a very low latency solution indeed.

4) I am waiting for some cheap rtlsdr device to evaluate your SDRTouch from the user perspective of morse code operator, however it already seems to me that the frequency scale would benefit from showing denser legend when zooming in for very narrow modes as CW. Indeed, the usual CW filter bandwidth used is around 500Hz wide.

For fun, this is the documentation to my firmware extensions to support standalone CW transmit. https://github.com/bubnikv/omniasdrbasicfirmware

Tony Parks of http://fivedash.com/ sold thousands of SoftRock receivers and rxtx combos. While the SoftRock receivers are slowly being replaced by the crop of AirSpy+ and SdrPlay devices (they are still a bit more expensive than the SoftRock RX Ensamble kit + a reasonable sound card and the soft rocks likely perform better on HF), there is enough of SoftRocks around to consider supporting them. Implementing a full fledged USB audio driver over libusb as offered by https://superpowered.com/ is quite job in itself. There is https://github.com/Themaister/libmaru which looks interesting, but frozen years ago. It is a pity google does not provide these drivers, iOS devices support multiple USB sound cards with no issue. Still it may be a viable alternative to implement a subset of the isochronous USB sound card protocol, as I expect that the cheaper USB sound cards will implement just the isochronous protocol, being phase locked to the USB bus frequency.

Thanks for your work. Being now full time on an open source project https://github.com/prusa3d/prusaslicer it makes me appreciate other's open source endeavors and the twork load and communication traffic it generates.

Vojtech

[bubnikv]

When we are at it, it would be nice to run a SoftRock based server on Raspberry PI Zero or similar. Again, writing a rtlsdr server to sample from an USB sound card and passing it to a TCP channel is trivial, but it would require the SDR Touch to offer configuration of the sampling frequency and sampling depth. Piping my SDR to the sunny garden bench would be smashing.

Also integrating some mode decoders into the application would be cool. I ported a multi-mode digital modes Linux application gmfsk to PocketPC years ago https://sourceforge.net/projects/pocketdigi/ so I have some experience with that, though my free time to dive into larger projects is limited. I would like to have a morse decoder in my pocket again though, so I can help with that. If the driver knew where the CW center frequency is, the morse code decoding may be performed at the driver side and the decoded text piped to the UI application somehow (though multiplexing the SDR audio with decoded text over the TCP connection seems like a ugly solution).