Bug 1958557 - Support multiple Airspy devices
Summary: Support multiple Airspy devices
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gr-osmosdr
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Jaroslav Škarvada
QA Contact: Fedora Extras Quality Assurance
URL: https://osmocom.org/issues/5144
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-05-08 19:22 UTC by Daniel Rusek
Modified: 2021-10-12 21:28 UTC (History)
3 users (show)

Fixed In Version: gr-osmosdr-0.2.3-13.20210217gita100eb02.fc36
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-10-12 21:28:22 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Airspy patch adding multiple sources support (2.04 KB, patch)
2021-05-10 22:20 UTC, Daniel Rusek
no flags Details | Diff
gr-osmosdr spec file diff (1.31 KB, patch)
2021-05-10 22:22 UTC, Daniel Rusek
no flags Details | Diff
Proposed fix (2.06 KB, patch)
2021-10-12 10:33 UTC, Jaroslav Škarvada
no flags Details | Diff
Proposed fix (2.05 KB, patch)
2021-10-12 10:37 UTC, Jaroslav Škarvada
no flags Details | Diff
Proposed fix (2.04 KB, patch)
2021-10-12 14:53 UTC, Jaroslav Škarvada
no flags Details | Diff

Description Daniel Rusek 2021-05-08 19:22:22 UTC
Description of problem:
Please, consider supporting multiple Airspy devices in gr-osmosdr. Currently, this is not possible and only one of my connected Airspy R2 devices is available in GNU Radio companion and Gqrx.

There was a patch adding this support (by being able to specify the device serial number as a value for the "airspy" argument in Airspy Source) already posted in 2016: https://lists.osmocom.org/pipermail/osmocom-sdr/2016-April/001446.html

The patch still seems to work fine on latest gr-osmosdr and adds exactly the functionality needed to make multiple Airspy devices available. Please, consider adding this patch in Fedora gr-osmosdr.

Version-Release number of selected component (if applicable):
gr-osmosdr-0.2.3-4.20210217gita100eb02.fc35

How reproducible:
Every time.

Steps to Reproduce:
1. Connect two or more Airspy devices.
2. Try using both of them in GRC or Gqrx.

Actual results:
Only one of the Airspy devices is available because the Airspy Source does not support multiple devices.

Expected results:
All connected Airspy devices (displayed by an "airspy_info" command) are available.

Additional info:
Here is an upstream ticket: https://osmocom.org/issues/5144

Comment 1 Daniel Rusek 2021-05-10 22:20:44 UTC
Created attachment 1781826 [details]
Airspy patch adding multiple sources support

Comment 2 Daniel Rusek 2021-05-10 22:22:35 UTC
Created attachment 1781827 [details]
gr-osmosdr spec file diff

Comment 3 Daniel Rusek 2021-05-10 22:36:08 UTC
I have found out that even though the patch works fine, it has one behavior change that could be considered as an regression. :( When this patch is applied, the Airspy Source does not find any devices when an "airspy" argument is specified without any value (just "airspy"). It works fine when specifying it as "airspy=0" (which is what Gqrx does by default). I have found no other issues besides this and both my Airspy R2 SDRs work fine now after specifying them by their serial numbers.

Comment 4 Daniel Rusek 2021-05-10 23:04:55 UTC
According to this comment from the source code patch, it should work: "if no device arguments are given or s/n=0, the first found airspy device will be used" - So yeah, it is an regression, unfortunately. :/

Comment 5 Daniel Rusek 2021-05-10 23:10:22 UTC
Maybe jskarvad or someone else who is more skilled in C than I am could fix the patch? :)

Comment 6 Ben Cotton 2021-08-10 13:40:53 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle.
Changing version to 35.

Comment 7 Jaroslav Škarvada 2021-10-12 10:33:05 UTC
Created attachment 1832160 [details]
Proposed fix

No problem to add the patch downstream, it seems useful, but better to get it to upstream.

Please try the following hack whether it resolves your problem. If yes, it seems like some gcc regression and I will open gcc bug.

Comment 8 Jaroslav Škarvada 2021-10-12 10:37:06 UTC
Created attachment 1832161 [details]
Proposed fix

Even more simplified version of the hack.

Comment 9 Jaroslav Škarvada 2021-10-12 10:39:13 UTC
Unfortunately, I cannot check it myself, because I don't have the airspy HW.

Comment 10 Daniel Rusek 2021-10-12 12:44:19 UTC
I unfortunately also do not have any Airspy hw here at the moment. :-/

But when I was using two Airspy R2 dongles, they worked fine when using the original patch that I posted in #c1, however that patch caused a regression as mentioned in #c3.

Comment 11 Jaroslav Škarvada 2021-10-12 12:48:25 UTC
(In reply to Daniel Rusek from comment #10)
> I unfortunately also do not have any Airspy hw here at the moment. :-/
> 
> But when I was using two Airspy R2 dongles, they worked fine when using the
> original patch that I posted in #c1, however that patch caused a regression
> as mentioned in #c3.

Updated patch I posted should target the regression.

Comment 12 Daniel Rusek 2021-10-12 13:54:24 UTC
I have actually managed to find some AirSpy R2s here that I thought were somewhere else. :-) So, I was able to test your patch from #c8, sadly it still does the same thing: When I use the "airspy" argument without any value, it does not find any actual devices. It works fine when I use "airspy=0".

Comment 13 Jaroslav Škarvada 2021-10-12 14:34:16 UTC
(In reply to Daniel Rusek from comment #12)
> I have actually managed to find some AirSpy R2s here that I thought were
> somewhere else. :-) So, I was able to test your patch from #c8, sadly it
> still does the same thing: When I use the "airspy" argument without any
> value, it does not find any actual devices. It works fine when I use
> "airspy=0".

Could you post your gcc version and architecture?
Also what it writes to the stderr?
"Attempting to open airspy by s/n=...."

I think I can rewrite the patch to be more robust, but at first I would like to understand what's going there. I will probably open gcc bug, maybe it's just undefined behavior and not a bug.

Comment 14 Jaroslav Škarvada 2021-10-12 14:47:37 UTC
I probably got it. It seems there was an gcc bug in the gcc-10, but it seem they fixed in the gcc-11. My hack was targeted to the gcc-10. I will provide new version of the patch.

Comment 15 Jaroslav Škarvada 2021-10-12 14:53:30 UTC
Created attachment 1832251 [details]
Proposed fix

Updated version of the patch, that should address the problem with no serial number given.

Comment 16 Daniel Rusek 2021-10-12 17:24:54 UTC
Thanks Jaroslav, the last patch (from #c15) seems to work fine and does not seem to contain the regression anymore. :-)

Any chance you could also submit this patch upstream (probably as an attachment here: https://osmocom.org/issues/5144)?

Comment 17 Daniel Rusek 2021-10-12 17:34:08 UTC
By the way, my gcc version is 11.2.1 20210728 on latest Fedora 35 Workstation beta for x86_64.

Comment 18 Jaroslav Škarvada 2021-10-12 20:57:03 UTC
(In reply to Daniel Rusek from comment #16)
> Thanks Jaroslav, the last patch (from #c15) seems to work fine and does not
> seem to contain the regression anymore. :-)
> 
> Any chance you could also submit this patch upstream (probably as an
> attachment here: https://osmocom.org/issues/5144)?

I added comment to the upstream tracker.

Comment 19 Fedora Update System 2021-10-12 21:27:39 UTC
FEDORA-2021-3fffc46710 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2021-3fffc46710

Comment 20 Fedora Update System 2021-10-12 21:28:22 UTC
FEDORA-2021-3fffc46710 has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.