Native Rust async driver for RTL2832U+R82XX

[jgraef]

Is seify/future-sdr interested in a from-scratch async rust implementation for RTL2832U?

I'm writing one for my SDR framework, but by default it works on its own. The driver was written from scratch, trying not to copy librtlsdr too much, or at least trying to understand what's going on. I found a few bugs, and lots of features that librtlsdr doesn't expose, and that I will definitely experiment with in the future.

Code. It's unpublished - I just got it to work this week.

You can run a test program that runs a rtl_tcp server:

cargo run --release --bin mrrp-rtl-sdr-test -- tcp -l 127.0.0.1:1234

(compilation might take a while since there's a lot of other stuff in the workspace, but the driver crate itself is pretty lightweight)

And usage as a library is also pretty straight-forward:

use mrrp_rtl_sdr::{
    OpenOptions,
    open_any,
};
use tokio::io::AsyncReadExt;

let mut device = open_any(OpenOptions::default()).await?;

// Set sample rate to 2.4 MSa/s
device.set_sample_rate(2_400_000.0).await?;

// Set center frequency to 7 MHz
device.set_center_frequency(7_000_000.0).await?;

// Start sampling and acquire a Reader
let mut reader = device.reader(Default::default()).await?;

// read samples. these are interleaved IQ as pairs of u8, with the equilibrium at 128.
loop {
    let i = reader.read_u8().await?;
    let q = reader.read_u8().await?;
    println!("i=0x{i:02x} q=0x{q:02x}");
}

Noteworthy here is that the Reader is completely separate from the Device. Reader is pretty much just a wrapper around nusb::io::EndpointRead. There's some interaction with the Device, but only when the reader is being closed. Otherwise they don't interact and don't need to synchronize with each other.

Only R82xx tuners are supported right now, and I only tested with R828D, because I only have a RTL-SDR Blog v4.

[bastibl]

Hi, that's awesome! I also wanted to try pure rust drivers. I think that's great direction.

I'd be happy to add this to Seify. I think we should try to join forces in Rust SDR domain. Also, for example, to create a common runtime-independent DSP library (similar to liquiddsp), SDR GUI widgets, etc. At the moment, everything seems rather scattered.

Regarding this driver: At the moment, Seify only has a sync API. My understanding is that nusb can also be driven in sync mode. So maybe this would be an option.

Ideally Seify should also have an async API. Basically the DeviceTrait but with async functions, but I didn't get around implementing that yet.

FYI: there is also https://github.com/ccostes/rtl-sdr-rs, which uses rusb (i.e. Rust wrappers for libusb). But nusb (or even cross_usb?) is nicer.

[jgraef]

I'd be happy to find others to work on SDR/DSP stuff together. I usually end up writing my own code, because existing crates don't fit my needs 100%, and it's also super good for learning. But we could definitely arrange things to be inter-operable and shared where possible. I guess it's better to discuss this in a chat, so I'll join the FutureSDR Discord later.

nusb itself can be driven sync, but my driver was not written for this at all. The issue I see with offering both sync and async, is that it make a lot of stuff more complicated. But maybe there's an elegant way to support both? At the very least the register definitions, and most of the tuner code can be shared, since they're not async. To be frank, I'm not a fan of offering a sync interface, but I'm open to discussing this further.

I'm aware of rtl-sdr-rs and checked it out a bit. At first I wanted to make it work for me, because I can work around it not being async. I think other things popped up that finally made me write my own. Their R828D tuner driver also didn't work correctly for me. And looking into their code, it seems to be mostly a Rust port of librtlsdr. So it would have been pretty hard to fix any issues, since the code is not easy to understand. And having read a lot of librtlsdr code, I'm glad I went for a complete rewrite, not a port.

[kevinmehall]

If you have an async API, you can use block_on from futures_lite or pollster to use it synchronously.

cross_usb hasn't been updated to use nusb v0.2. If you're interested in wasm support, nusb is about to land its own WebUSB backend. WebUSB is async-only because you can't block the JS event loop.

[jgraef]

If you have an async API, you can use block_on from futures_lite or pollster to use it synchronously.

That's a good point. Is there a good reason why nusb offers this as a built-in feature? Otherwise I would consider keeping the API fully async and that if someone wants to use this synchronously, they should do block_on on their end.

nusb is about to land its own WebUSB backend.

Uuuuh, that's good to know! I checked earlier and briefly considered if I could write a backend for it.

[kevinmehall]

Transfers are natively async, so the implementation of ep.wait_next_complete() is roughly equivalent to block_on(ep.next_complete()). EndpointRead is implemented on top of those so the same applies.

Where there is a difference is in the ancillary APIs like open(), claim_interface(), etc where the underlying syscall is blocking. .wait() on these directly calls the blocking syscall, while using them as a Future spawns them on the blocking or tokio blocking threadpool so as to not block the current thread. If you aren't otherwise using async, you don't need those dependencies and the overhead of sending the task to another thread.

[bastibl]

I just played around with a HydraSDR driver with nusb. This seems to work pretty well. Really looking forward to the WebUSB backend. Having nusb-based drivers for native and the web would be really great! Just need an async API for seify, now :-)