gqrx
gqrx copied to clipboard
gqrx-sdr
Sudden device disconnections are not handled gracefully
Lots of SDRs are dongles - that is, the SDR board has a USB plug soldered directly to it, rather than a receptacle for a cable, and plugs directly into the host computer with no cable. This means that the USB port is "load-bearing" and supports the entire weight of the SDR - plus any antenna or cables attached to the far end - at a significant mechanical disadvantage. This seems to be really good at making the USB interface lose connection for a split second whenever the device is wiggled in its socket.
This could just be a minor inconvenience, and cause a short period of lost samples, but GQRX currently amplifies this into a much more annoying problem by requiring a full restart every time it happens. Usually, it's easy to see that it has happened, because all demodulation stops, the spectrogram freezes, and the waterfall starts drawing smooth unbroken vertical lines instead of updated spectrum images. Attempting to stop and restart sample acquisition causes GQRX to crash immediately.
I don't know exactly what this looks like on the backend and how hard it would be to change, but it would be really nice to at least have the ability to detect and start SDR devices that were plugged into the host system after GQRX was started, which at the moment does not seem to be possible at all.
The nicest thing would be for GQRX to be able to detect brief connectivity losses to the sample source, automatically re-initialize it, and resume sample acquisition as before, but I recognize that's probably a lot of trouble to implement. I'd say that any improvement at all over the current situation would be a breath of fresh air, though, even if it requires user interaction to re-select and re-start acquisition. Right now, it feels like GQRX was designed under the assumption that SDRs rarely disconnect intermittently, but this is unfortunately not the case in the world of big heavy RTL-SDR dongles.
Possible duplicate of #1102. I think this has a slightly broader scope than that one does, but it might not matter - I'll defer.
Hello.
Attempting to stop and restart sample acquisition causes GQRX to crash immediately.
This works to me in case of device (RTL dongle) disconnection. Reconnect the device, open input device configuration dialog, clock "OK" without changing options. This should reopen the device and restart the flowgraph.
The nicest thing would be for GQRX to be able to detect brief connectivity losses to the sample source
gr-osmosdr sources do not have any interface (callback, message, etc...) that can be used to get device loss notification. In case of device disconnection the source just stops producing samples...
You may use short USB extension cable (AM-AF) or USB HUB to connect your dongle. This should fix "dongle falling from USB port" problem and moving the dongle and antenna away from your computer should reduce noise levels too.
I can't reproduce the crash in case of RTL dongle disconnection. Which version of gqrx are you using?
As Vlad notes, it's much simpler to solve this problem by using a USB extension cable to remove mechanical stress. Otherwise one is destroying a cheap socket, and an expensive computer, for the sake of a not very expensive cable. An RTL-SDR may be low cost, the computer isn't!
An added benefit of using a cable is that RFI from the computer is physically further away from the RF hardware, and induces less spurious noise in to the receive chain. That's at least two benefits! Also, an unreliable USB socket hastens the day when kit is only good for the skip.
HTH, 73,
Robin, G8DQX
PS: The same idea of using a flexible cable also applies at the RF input end of a dongle, especially if using a heavy (low-loss) not very flexible cable to feed the antenna.
On 10/03/2022 22:05, Fluora wrote:
Lots of SDRs are dongles - that is, the SDR board has a USB plug soldered directly to it, rather than a receptacle for a cable, and plugs directly into the host computer with no cable. This means that the USB port is "load-bearing" and supports the entire weight of the SDR - plus any antenna or cables attached to the far end - at a significant mechanical disadvantage. This seems to be really good at making the USB interface lose connection for a split second whenever the device is wiggled in its socket.
This could just be a minor inconvenience, and cause a short period of lost samples, but GQRX currently amplifies this into a much more annoying problem by requiring a full restart every time it happens. Message ID: @.***>
To be clear, I share the opinion that big heavy USB dongles are a horrible thing, and that the RTL-SDR et al are designed very poorly with that in mind. I already use a USB extension cable, and it almost works to prevent spurious disconnection events. However, that's not what I came here to talk about. Because the most common SDR in existence is a dongle, and because USB extension cables are against spec and not as ubiquitous, it stands to reason that most people out there are plugging it directly into their computer, and those using GQRX are constantly running into this problem.
Are you absolutely sure that there's no way to detect or handle device disconnections without an explicit notification from the backend? This condition is quite easy to see as the user, so why couldn't GQRX detect the fact that samples have stopped coming in and try re-initializing the device?
Alternatively, if you think it would be productive to file a bug with the backend software to add disconnection event notifications, then that seems reasonable to me, but I wouldn't personally know how to do this or if it makes sense to do.
why couldn't GQRX detect the fact that samples have stopped coming in and try re-initializing the device?
Because this is unexpected behavior. SDR++ does the same thing. It freezes and even does not stop processing. And it requires user interaction: press "stop", select new device, press "start" - not much different from Gqrx.
Alternatively, if you think it would be productive to file a bug with the backend software to add disconnection event notifications
We already have "disconnection" event notification in the IQ Tool - end of file event. We can't detect this event because the flowgraph is started with nonblocking tb->start() call instead of blocking tb->run() call, that returns when there are no more samples to process. It is not possible to switch to using blocking call as we have to stop and restart flowgraph in many places: switching demodulators, connecting and disconnecting optional processing blocks, etc... It would not be possible to differentiate between flowgraph stopping on it's own and being stooped due to user action. That's why the end of file in the IQ Tool does not depress the "play" button.