-
Notifications
You must be signed in to change notification settings - Fork 14
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
Implement open by serial #26
Comments
Honestly, something is probably wrong with the Airspy find and open functions. The device ID just some "internal" index that changes as soon as you open the first device. Although it could be fixed, in my opinion, this device ID stuff has to go. It should use the open by serial convention. Since you have two airspy devices, I would greatly appreciate a PR that cleans up this stuff. Just as an example, airspyhf does this:
A plea in SDRPlay for open by serial: pothosware/SoapySDRPlay3#23 (and its almost ready for merge) |
Thanks Josh, That makes sense. I'll have a look at the airspyHF code and see what I can do! What I still don't understand is how I can open two CubicSDR windows and successfully read simultaneously from two Airspys, if the issue is fundamentally with SoapyAirspy. |
I have just reviewed the code since this has come up on our mailing list. To me, it seems like everything is in place and this should work already. I have given this a quick test on a site that has one Airspy R2 and one Airspy mini (they are easy to distinguish thanks to their different sample rates) and a current "master" build of this repo. Result looks good to me:
Device selection by serial seems to work as expected in OpenWebRX as well. Any other tests I could perform? |
In my challenge to get two AirSpy models active on a system running two SatNOGS client I experience something similar.
I find it strange to see a colon in the serial value and the option to use I would prefer that this would work similar to the rtlsdr driver. This would look something like this |
@janvgils can you help debug this, soapy airspy code was recently updated to open by serial but there still may be some minor bugs. The colon in the serial number looks like some unexpected formatting or local issue: Serial number to string And back to 64-bit number And basically its not converting back nicely to the same 64-bit integer. The string formed by |
I will try and see if I can successfully build the latest code with the proposed change |
Here an update on this issue: I am testing this on a Debian buster x86_64 distribution.
So this looks promising and to make sure the serial is used I also tried a dummy serial to see what happens.
The final test will be done by me reconnecting all the AirSpy devices and check if the client also works. |
I connected the second AirSpy and this also looks good.
If others have the same experience I hope this will be make it to stable a release a.s.a.p. Thanks for the support. |
I'm happy the fix worked. Can you share the |
Hi, The only thing I did, as descripted in my previous posts, is a git clone, nothing else.
|
Sorry, completely missed that. The code is fine, it just needs a release. I'm closing the issue, since this actually got resolved a while ago. And I will tag the repo |
Hello,
I'm working on an application where I need to connect multiple SDRs of the same type (AirSpy R2). Each one has a different antenna so I need to be able to distinguish between them.
We can display connected devices with:
With two AirSpys connected this gives:
As in the C++ API, I want to be able to connect to a specific device i with:
sdr = SoapySDR.Device(device_list[i])
This works for the first SDR with device_id=0. However, the next device crashes! As per:
I believe this is a bug in the Python binding. Something to do with the device_id being a string, but somewhere it is being checked again an int range?
Any advice on workarounds would be appreciated, or I'm happy to work together to fix the bug.
Thanks,
Bill
(For more info, I've had a brief discussion on the forum: https://groups.google.com/g/pothos-users/c/-l1P1NFdfgQ)
The text was updated successfully, but these errors were encountered: