-
Notifications
You must be signed in to change notification settings - Fork 185
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SoapyMultiSDR #70
Comments
I was thinking about the same thing actually, though not for RTLs only. I'm not a big fan of trying to cram multiple devices into a single wrapper for MIMO reasons because its a pain from the development end. That puts the burden on the API user, which often just means more for loops. But I can see where the existing interface would be nice to just re-use for many devices, so... What if there was a SoapyMulti support driver that worked kind of like the Osmo block top level does now. It would take a bunch of device args to list the internal devices, and then it would summon the underlying SoapySDR device pointers for the internal devices, and reimplement all of the settings calls to distribute them to the correct destination device. Streaming as well, which might get a little hairy with non-homogenous devices and different stream MTUs, but we can memcpy.... Hows that sound? |
That's a more robust plan than what I had in mind -- If I read that correctly it would be simplest (configuration-wise) to only support devices of the same module so there's one configuration proxied to the devices with some sort of management for bandwidth, frequency, etc. between them? Mixing devices would be neat but I'm guessing that would increase the complexity significantly :) |
For the most part I imagine only supporting the same type of device. I think it would pretty much just work with heterogeneous devices, but some stream configurations might be awkward. I think the default args should be simple to reflect using the same type of device, but there could be an advanced mode to support heterogeneous stuff or added later. But basically the settings and streaming are going to look pretty generic, and I think there is a straightforward way to implement them. The constructor The settings* Streaming The readStream call itself calls each internal stream readStream() call sequentially (could be in parallel with threads) on each of the buffers passed in. Even with homogeneous devices, we need to make sure the same amount is read off each channel or do some accounting. Same basic idea with writeStream. Some hand-wavy fixes for the variable read amounts
|
SoapyMultiSDR sounds like a good name. I can go ahead and make the project. It sounds like its going to be more or less on-par with how I maintain SoapyRemote -- which is to add new matching calls when SoapySDR gets additions. Its going to be a bit annoying to go through all the calls, but I think I can plow through it in a weekend once I get some time :-) Also global settings |
Nice, that all sounds good to me; I'll leave it to you to get the project rolling 👍 |
This sounds really cool! I recently pulled in support for synchronized TRX triggers on the bladeRF, allowing N devices to be sample-synchronized (not phase-aligned, but a constant phase-offset). I could help in getting this up and running in SoapyMultiSDR as well. To make this happen, I will need to think about how to integrate the following into Soapy:
@guruofquality - I realize each of these is probably going to require some more thought on my end (and likely separate issue tracker items)... just wanted to chime in so you could delegate some tasks. ;) |
I started the repo, its empty now, but it will be a good place to put any relevant issues: https://github.com/pothosware/SoapyMultiSDR |
Presenting the argument naming convention and inception support, feel free to comment before I do something terrible :-) |
Other than documenting this basic usage on the wiki, SoapyMultiSDR is basically functional from a settings standpoint. The streaming is currently very dumb about heterogeneous stuff happening. So I will have to do something smarter there. But if you wanted to start experimenting with using the driver, I think its in a good place. Here is an example probe:
|
I'm seeing some interesting stuff done using multiple RTL-SDR's combined in the last few months; reviewing liquid's oversampled firpfbch2 and regular firpfbch (polyphase filterbank channelizer) it seems possible to utilize them to combine multiple streams in this manner.
I'm thinking instead of dirtying up the SoapyRTLSDR repo a SoapyMultiRTL repo would be a good one to set up and try.
Thoughts?
The text was updated successfully, but these errors were encountered: