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
Created attachment 1781826 [details] Airspy patch adding multiple sources support
Created attachment 1781827 [details] gr-osmosdr spec file diff
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.
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. :/
Maybe jskarvad or someone else who is more skilled in C than I am could fix the patch? :)
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle. Changing version to 35.
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.
Created attachment 1832161 [details] Proposed fix Even more simplified version of the hack.
Unfortunately, I cannot check it myself, because I don't have the airspy HW.
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.
(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.
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".
(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.
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.
Created attachment 1832251 [details] Proposed fix Updated version of the patch, that should address the problem with no serial number given.
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)?
By the way, my gcc version is 11.2.1 20210728 on latest Fedora 35 Workstation beta for x86_64.
(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.
FEDORA-2021-3fffc46710 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2021-3fffc46710
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.