Problem with device list
129 views
Skip to first unread message
Wolfgang Fritz
Mar 30, 2016, 3:09:14 AM3/30/16
to gq...@googlegroups.com
Hi,
I am looking into the issue why the SDRPlay is sometimes displayed in
the device list and sometimes not.
It seems (I'm not familiar enough yet with this stuff, so I'm not sure)
that some osmosdr drivers do not probe a for a device but always say the
device is present. Otherwise I wouldn't see devices in the device list I
have not connected, would I?
The SDRPlay driver is different. It tries to initialize the SDRplay
hardware, and if that is successful, it says the device is present.
This has some major issues:
1. If the device is already initialized, the drive delivers the error
"already initialized" and osmosdr interprets this a a failure, result:
device not present. And that's the reason why the sdrplay disappears
from the device list.
2. The sdrplay probing leaves the device uninitialized, so gqrx stops
working if you open the device list a second time.
I can think of two approaches to solve this problem:
1. Probe devices only on program start and keep the list of detected
devices for later use. Disadvantage: Devices connected after program
start are not found.
2. Stop the active device when the device list is opened, then probe
devices as now. After probing, restore device state and restart it.
Advantage: devices connected after program start are detected.
Disadvantage: Receiver is stopped while the device list is open.
What do you think?
Wolf, DK7OB
I am looking into the issue why the SDRPlay is sometimes displayed in
the device list and sometimes not.
It seems (I'm not familiar enough yet with this stuff, so I'm not sure)
that some osmosdr drivers do not probe a for a device but always say the
device is present. Otherwise I wouldn't see devices in the device list I
have not connected, would I?
The SDRPlay driver is different. It tries to initialize the SDRplay
hardware, and if that is successful, it says the device is present.
This has some major issues:
1. If the device is already initialized, the drive delivers the error
"already initialized" and osmosdr interprets this a a failure, result:
device not present. And that's the reason why the sdrplay disappears
from the device list.
2. The sdrplay probing leaves the device uninitialized, so gqrx stops
working if you open the device list a second time.
I can think of two approaches to solve this problem:
1. Probe devices only on program start and keep the list of detected
devices for later use. Disadvantage: Devices connected after program
start are not found.
2. Stop the active device when the device list is opened, then probe
devices as now. After probing, restore device state and restart it.
Advantage: devices connected after program start are detected.
Disadvantage: Receiver is stopped while the device list is open.
What do you think?
Wolf, DK7OB
Alexandru Csete
Mar 30, 2016, 5:26:08 PM3/30/16
to gq...@googlegroups.com
On Wed, Mar 30, 2016 at 9:09 AM, Wolfgang Fritz <wolfgan...@gmx.net> wrote:
> Hi,
>
> I am looking into the issue why the SDRPlay is sometimes displayed in the
> device list and sometimes not.
>
> It seems (I'm not familiar enough yet with this stuff, so I'm not sure) that
> some osmosdr drivers do not probe a for a device but always say the device
> is present. Otherwise I wouldn't see devices in the device list I have not
> connected, would I?
Some devices do not support autodetection, or gr-osmosdr does not have
> Hi,
>
> I am looking into the issue why the SDRPlay is sometimes displayed in the
> device list and sometimes not.
>
> It seems (I'm not familiar enough yet with this stuff, so I'm not sure) that
> some osmosdr drivers do not probe a for a device but always say the device
> is present. Otherwise I wouldn't see devices in the device list I have not
> connected, would I?
it implemented, so these devices will always be listed to indicate
that they are supported.
> The SDRPlay driver is different. It tries to initialize the SDRplay
> hardware, and if that is successful, it says the device is present.
>
> This has some major issues:
>
> 1. If the device is already initialized, the drive delivers the error
> "already initialized" and osmosdr interprets this a a failure, result:
> device not present. And that's the reason why the sdrplay disappears from
> the device list.
then probing will fail because the device is already in use.
>
> 2. The sdrplay probing leaves the device uninitialized, so gqrx stops
> working if you open the device list a second time.
> I can think of two approaches to solve this problem:
>
> 1. Probe devices only on program start and keep the list of detected
> devices for later use. Disadvantage: Devices connected after program start
> are not found.
>
> 2. Stop the active device when the device list is opened, then probe devices
> as now. After probing, restore device state and restart it. Advantage:
> devices connected after program start are detected. Disadvantage: Receiver
> is stopped while the device list is open.
doubt is that I'm not sure we have full control over stopping and
closing devices.
Alex
wofritzyt
Mar 31, 2016, 3:53:57 AM3/31/16
to Gqrx SDR
On Wednesday, March 30, 2016 at 11:26:08 PM UTC+2, Alexandru Csete wrote:
On Wed, Mar 30, 2016 at 9:09 AM, Wolfgang Fritz <wolfgan...@gmx.net> wrote:
> Hi,
>
> I am looking into the issue why the SDRPlay is sometimes displayed in the
> device list and sometimes not.
>
> It seems (I'm not familiar enough yet with this stuff, so I'm not sure) that
> some osmosdr drivers do not probe a for a device but always say the device
> is present. Otherwise I wouldn't see devices in the device list I have not
> connected, would I?
Some devices do not support autodetection, or gr-osmosdr does not have
it implemented, so these devices will always be listed to indicate
that they are supported.
> The SDRPlay driver is different. It tries to initialize the SDRplay
> hardware, and if that is successful, it says the device is present.
>
> This has some major issues:
>
> 1. If the device is already initialized, the drive delivers the error
> "already initialized" and osmosdr interprets this a a failure, result:
> device not present. And that's the reason why the sdrplay disappears from
> the device list.
That's the case for all devices. If gqrx is already using a device,
then probing will fail because the device is already in use.
>
> 2. The sdrplay probing leaves the device uninitialized, so gqrx stops
> working if you open the device list a second time.
I'm not sure I understand this, but it doesn't really matter.
When probing the SDRPlay, the driver tries to initialize it. After that, it uninitializes it again. (the SDR API has a method for this, don't know about other drivers). If the device is already initialized, it is uninitialized anyway. So after probing you always have an uninitialized device, which is fatal if the probing is done when gqrx is already running.
> I can think of two approaches to solve this problem:
>
> 1. Probe devices only on program start and keep the list of detected
> devices for later use. Disadvantage: Devices connected after program start
> are not found.
I guess I'm OK with this approach, since the present implementation is broken.
I have a first version, but It needs more testing.
The main issue is that the device detection has to be done very early in the startup, before the configuration is restored, since this already initializes the configured device.
>
> 2. Stop the active device when the device list is opened, then probe devices
> as now. After probing, restore device state and restart it. Advantage:
> devices connected after program start are detected. Disadvantage: Receiver
> is stopped while the device list is open.
I'm not sure this will work but you are welcome to try. The reason I
doubt is that I'm not sure we have full control over stopping and
closing devices.
Yes, I saw that problem too.
I've checked cubicsdr, which uses soapysdr directly without osmosdr. At start up it probes devices and displays the device list, and you have to select the one you want to use. I don't like that because you have to select the device every time you start the program. If you open the device selection tab while the program is running, it displays the known devices. There is a button for refreshing the list, in this case the device is stopped. I did not look into the code because their solution won't help anyway since they are not using osmosdr.
I send you a patch for review when I've finished my tests.
Wolf
Alex
wofritzyt
Mar 31, 2016, 12:33:08 PM3/31/16
to Gqrx SDR
On Thursday, March 31, 2016 at 9:53:57 AM UTC+2, wofritzyt wrote:
<......>
I have a first version, but It needs more testing.
The main issue is that the device detection has to be done very early in the startup, before the configuration is restored, since this already initializes the configured device.>
> 2. Stop the active device when the device list is opened, then probe devices
> as now. After probing, restore device state and restart it. Advantage:
> devices connected after program start are detected. Disadvantage: Receiver
> is stopped while the device list is open.
I'm not sure this will work but you are welcome to try. The reason I
doubt is that I'm not sure we have full control over stopping and
closing devices.
Yes, I saw that problem too.
I've checked cubicsdr, which uses soapysdr directly without osmosdr. At start up it probes devices and displays the device list, and you have to select the one you want to use. I don't like that because you have to select the device every time you start the program. If you open the device selection tab while the program is running, it displays the known devices. There is a button for refreshing the list, in this case the device is stopped. I did not look into the code because their solution won't help anyway since they are not using osmosdr.
I send you a patch for review when I've finished my tests.
OK, here is my patch for review. The devices are only probed at program startup. The device list is not updated if a device is connected after program start. This has effect only for devices whch drivers really check for the presence of the device, like SDRPlay. Later the cached device list is used in the input configuration.
WolfAlex
dbl...@gmail.com
Mar 31, 2016, 2:50:37 PM3/31/16
to Gqrx SDR
Alex:
Just upgraded my mac to OS X 10.11.4 and GQRX no longer works with my Funcube Dongle Pro+.
Very disappointed as it was working so well before, except that the indicated frequency above the window showed 1 MHZ lower than actual. I hope these problems will be addressed as GQRX is the one I recommend to all my friends as the best!
Thank you for all your hard work to make such an excellent program.
W Kies
Alexandru Csete
Apr 2, 2016, 7:46:33 PM4/2/16
to gq...@googlegroups.com
On Thu, Mar 31, 2016 at 6:33 PM, wofritzyt <wolfgan...@gmx.net> wrote:
>
> OK, here is my patch for review. The devices are only probed at program
> startup. The device list is not updated if a device is connected after
> program start. This has effect only for devices whch drivers really check
> for the presence of the device, like SDRPlay. Later the cached device list
> is used in the input configuration.
>
Hi Wolf,
>
> OK, here is my patch for review. The devices are only probed at program
> startup. The device list is not updated if a device is connected after
> program start. This has effect only for devices whch drivers really check
> for the presence of the device, like SDRPlay. Later the cached device list
> is used in the input configuration.
>
I'm quiet tired and may not properly undserstand what is going on, but
would it be possible to move the code somewhere else than
mainwindow.cpp? Mainwindow is already a huge file and we should avoid
adding new code if we can - in particular if the code is not directly
related to mainwindow functionality.
Perhaps move into a separate header file, or have it as a static
member of CIoConfig? THe data structure itself could still be a member
of MainWindow, if required.
Some other comments:
> + else if (this_dev.find("FUNcube Dongle V2.0") != string::npos)
> + {
> + devstr = "fcd,type=2,device='FUNcube Dongle V2.0'";
> + devList.insert (std::pair<QString, QVariant>(QString("FUNcube Dongle V1.0"), QVariant(devstr)));
Should be V2.0
> + while (it != dev.end())
> + {
> + std::cout << (*it).first << ":" << (*it).second << std::endl;
> + ++it;
> + }
> + std::cout << "=========================================" << std::endl;
Is this output necessary once the code is working? If yes, can we use
qDebug()? Perhaps keep it in the CIoConfig constructor.
> devList.insert (std::pair<QString, QVariant>(devlabel, devstr));
As I said before, no spaces between function name and ().
Alexandru Csete
Apr 2, 2016, 8:00:22 PM4/2/16
to gq...@googlegroups.com
On Thu, Mar 31, 2016 at 8:50 PM, <dbl...@gmail.com> wrote:
> Alex:
> Just upgraded my mac to OS X 10.11.4 and GQRX no longer works with my
> Funcube Dongle Pro+.
> Very disappointed as it was working so well before, except that the
> indicated frequency above the window showed 1 MHZ lower than actual. I hope
> these problems will be addressed as GQRX is the one I recommend to all my
> friends as the best!
> Thank you for all your hard work to make such an excellent program.
Well, it looks like Apple decided to change the sound card naming so
> Alex:
> Just upgraded my mac to OS X 10.11.4 and GQRX no longer works with my
> Funcube Dongle Pro+.
> Very disappointed as it was working so well before, except that the
> indicated frequency above the window showed 1 MHZ lower than actual. I hope
> these problems will be addressed as GQRX is the one I recommend to all my
> friends as the best!
> Thank you for all your hard work to make such an excellent program.
that the audio device is no longer called "FUNcube Dongle V2.0" but
"FUNcube Dongle V2_0", so gqrx can no longer detect the device. I'm
sure there was a very important reason for making this change...
The good news is that it has an easy fix in gqrx.
The bad news is that I have practically 0 time to work on gqrx now and
for many months ahead, so I really have no idea when I will have the
time required to make a new OS X build, sorry.
Alex
Wolfgang Fritz
Apr 3, 2016, 7:02:04 AM4/3/16
to gq...@googlegroups.com
Am 03.04.2016 um 01:46 schrieb Alexandru Csete:
> On Thu, Mar 31, 2016 at 6:33 PM, wofritzyt <wolfgan...@gmx.net> wrote:
>>
>> OK, here is my patch for review. The devices are only probed at program
>> startup. The device list is not updated if a device is connected after
>> program start. This has effect only for devices whch drivers really check
>> for the presence of the device, like SDRPlay. Later the cached device list
>> is used in the input configuration.
>>
>
> Hi Wolf,
>
> I'm quiet tired and may not properly undserstand what is going on, but
> would it be possible to move the code somewhere else than
> mainwindow.cpp? Mainwindow is already a huge file and we should avoid
> adding new code if we can - in particular if the code is not directly
> related to mainwindow functionality.
>
> Perhaps move into a separate header file, or have it as a static
> member of CIoConfig? THe data structure itself could still be a member
> of MainWindow, if required.
>
I'll look into this. There is another issue I found, the us of a
> On Thu, Mar 31, 2016 at 6:33 PM, wofritzyt <wolfgan...@gmx.net> wrote:
>>
>> OK, here is my patch for review. The devices are only probed at program
>> startup. The device list is not updated if a device is connected after
>> program start. This has effect only for devices whch drivers really check
>> for the presence of the device, like SDRPlay. Later the cached device list
>> is used in the input configuration.
>>
>
> Hi Wolf,
>
> I'm quiet tired and may not properly undserstand what is going on, but
> would it be possible to move the code somewhere else than
> mainwindow.cpp? Mainwindow is already a huge file and we should avoid
> adding new code if we can - in particular if the code is not directly
> related to mainwindow functionality.
>
> Perhaps move into a separate header file, or have it as a static
> member of CIoConfig? THe data structure itself could still be a member
> of MainWindow, if required.
>
std::map for the device list orders the list alphabetically, which is
different from the original ordering.
> Some other comments:
>
>> + else if (this_dev.find("FUNcube Dongle V2.0") != string::npos)
>> + {
>> + devstr = "fcd,type=2,device='FUNcube Dongle V2.0'";
>> + devList.insert (std::pair<QString, QVariant>(QString("FUNcube Dongle V1.0"), QVariant(devstr)));
>
> Should be V2.0
>
>
>> + while (it != dev.end())
>> + {
>> + std::cout << (*it).first << ":" << (*it).second << std::endl;
>> + ++it;
>> + }
>> + std::cout << "=========================================" << std::endl;
>
> Is this output necessary once the code is working? If yes, can we use
> qDebug()? Perhaps keep it in the CIoConfig constructor.
>
or less for me to understand what's going on. I missed this one.
>> devList.insert (std::pair<QString, QVariant>(devlabel, devstr));
>
> As I said before, no spaces between function name and ().
>
BTW Alex, I really appreciate your responses, knowing your very limited
time. I contacted the driver developers but got no responses so far...
Wolf, DK7OB
Alexandru Csete
Apr 4, 2016, 3:41:05 PM4/4/16
to gq...@googlegroups.com
Hi Wolf,
Thanks for the update. It worked well during my tests so I have pushed
it. It is also faster to user the cached device list so I think
overall this change was good.
Thanks
Alex
> --
> You received this message because you are subscribed to the Google Groups
> "Gqrx SDR" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to gqrx+uns...@googlegroups.com.
> To post to this group, send email to gq...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/gqrx/57025326.3090207%40gmx.net.
>
> For more options, visit https://groups.google.com/d/optout.
Thanks for the update. It worked well during my tests so I have pushed
it. It is also faster to user the cached device list so I think
overall this change was good.
Thanks
Alex
> You received this message because you are subscribed to the Google Groups
> "Gqrx SDR" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to gqrx+uns...@googlegroups.com.
> To post to this group, send email to gq...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/gqrx/57025326.3090207%40gmx.net.
>
> For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages