HDSDR under Linux?

[Adam Nielsen]

Hi all,

I'm just wondering whether anyone has been able to use HDSDR (or similar)
under Linux with the RTL2832. I have been able to get it to run with Wine,
but I can only listen to previous captures since Wine doesn't provide any way
for Windows programs to access USB devices. Using VirtualBox isn't an option
as it can only pass through USB1.1 devices, and USB1.1 can't transfer enough
data for the RTL2832 so while it works, the audio is too choppy to be useful.

Balint's BorIP protocol allows HDSDR to receive data over the network so I
investigated this (thinking I could run a BorIP server to talk to the
hardware, then tell HDSDR to connect to localhost to read the data) but alas
there's no BorIP server for Linux.

The Osmocom rtl-sdr code comes with an rtl_tcp program which appears to send
data over the network and runs under Linux, but of course it's incompatible
with the BorIP protocol so no luck there.

Has anyone managed to get a program like HDSDR working on a Linux machine?

Thanks,
Adam.

[M0GHY]

I've found the same on Linux Mint 12, HDSDR installs perfectly fine under wine but lacks the usb subsystem.

I've not tried this, but http://wiki.spench.net/wiki/Gr-baz lists a BORIP source grc for gnu radio, perhaps it would be possible to get HDSDR to latch onto that either remotely or on the same machine with EXTIO/BORIP.

I look forward to not having to fire windows up :)

M0GHY.

[Adam Nielsen]

> I've not tried this, but http://wiki.spench.net/wiki/Gr-baz lists a BORIP
> source grc for gnu radio, perhaps it would be possible to get HDSDR to latch
> onto that either remotely or on the same machine with EXTIO/BORIP.

Unfortunately the BorIP source just means it listens to packets received from
elsewhere. HDSDR with the ExtIO plugin can already do this. The problem is
creating the BorIP packets in the first place. If there was a BorIP *sink*
for GNURadio then that could be connected to HDSDR but alas it seems the only
way to create BorIP packets is under Windows. Or by rewriting the BorIP
server so it works under Linux.

Cheers,
Adam.

[M0GHY]

Actually the BorIP protocol (http://wiki.spench.net/wiki/BorIP) looks relatively trivial to implement, I'm tempted to have a go at it if I find time. I suppose the hard part would be linking back the sink to the rtl2832 source block, but can't say that I've had a look at the code for it.

I envision that it could come in pretty useful for people wanting a headless linux back end (even masthead) and then using windows/linux front end desktop/notebook. The back end system shouldn't even need to be that powerful (I'm thinking Raspberry Pi) as the real grunt is done in HDSDR/WinRAD.

M0GHY

[Adam Nielsen]

> Actually the BorIP protocol (http://wiki.spench.net/wiki/BorIP) looks
> relatively trivial to implement, I'm tempted to have a go at it if I find
> time.

I was thinking the same, but I only have an RTL2832 so I couldn't test support
for all the other devices. I've also been thinking about creating libsdr
which can talk to a bunch of different SDR devices, then a BorIP server which
just sits on libsdr (the idea being other software can also use libsdr, so
they don't all have to include their own "drivers" for each SDR device.)

> I suppose the hard part would be linking back the sink to the rtl2832
> source block, but can't say that I've had a look at the code for it.

It'd probably be easiest to ignore GNURadio entirely, and (like the Windows
BorIP server) just talk to the hardware directly and then broadcast the
packets over the network. Then the existing BorIP sources (for GNURadio,
ExtIO/HDSDR, etc.) would just work on the client side.

> I envision that it could come in pretty useful for people wanting a headless
> linux back end (even masthead) and then using windows/linux front end
> desktop/notebook. The back end system shouldn't even need to be that powerful
> (I'm thinking Raspberry Pi) as the real grunt is done in HDSDR/WinRAD.

Definitely. I'm still waiting for my Pi so I don't know how successful it
would be, but I imagine it would all hinge on how well the I/O performance is.
If it can receive lots of USB packets and transmit them over Ethernet
without much CPU usage then it should be fine.

Cheers,
Adam.

[Balint Seeber]

I've got Linux (and therefore Mac) BorIP server using patched GNU Radio UDP Sink block on the to-do list, which will enable HDSDR/etc to use real hardware on those platforms. Hope to get around to it soon. By all means, a server unhooked from GNU Radio is also certainly possible - but to begin with using it is probably a good starting point, as any existing supported device could be used off-the-bat (instead of implementing hardware access separately in the server).

Pi will definitely be cool - just remember Ethernet is only 10/100 and actually operates via USB, so might cause bus contention if relaying high-rate baseband. Very interested to hear how people will go with this!

[Adam Nielsen]

> I've got Linux (and therefore Mac) BorIP server using patched GNU Radio UDP
> Sink block on the to-do list, which will enable HDSDR/etc to use real hardware
> on those platforms. Hope to get around to it soon. By all means, a server
> unhooked from GNU Radio is also certainly possible - but to begin with using
> it is probably a good starting point, as any existing supported device could
> be used off-the-bat (instead of implementing hardware access separately in the
> server).

If you did it this way (a BorIP sink for GNU Radio), would it still be
possible to change frequency remotely, as you're e.g. browsing the spectrum in
HDSDR? I have been assuming you would have to modify the flow graph every
time you wanted to tune to a different frequency.

Unless you can do away with grc, and code the .py file manually? Maybe then
you could allow the BorIP sink to call back into the hardware source to adjust
the frequency.

Cheers,
Adam.