Successful rtl_sdr return code 5 not handled, RTLSDR not found

[mluckham54]

While installing from source in WSL Ubuntu on Windows 10, RTLSDRs are not found by radiosonde_auto_rx. In fact the dongle is found but the call to rtl_sdr returns an unexpected return code.

As a result both the source code as-is, and the Docker image, do not work.

The issue can be fixed in autorx/utils.py by handling the unexpected return code.

except subprocess.CalledProcessError as e:
  # This exception means the subprocess has returned an error code of one.
  # This indicates either the RTLSDR doesn't exist, or
  
  if e.returncode == 1:
    pass

  # rtl_sdr on wsl/Ubuntu returns 5
  return true

[darksidelemm]

Any idea what this return code means and why it's returning it instead of a return code of 0?

I'm not sure your solution here is the best approach, that will result in the function returning True even if the return code is 1. We want to be extremely specific about what return codes we consider to be 'OK'.

[mluckham54]

I agree, perhaps e.returncode == 5 should be the test to return True, and keep the default pass for all other cases.

I noticed the return value when debug logging was enabled, and I had some extra logging to display the code.

I've started to look at the rtl_sdr repo to see if I can find why. When running on the command line, rtl_sdr always outputs "User cancelled" so I suspect it is related to that

[darksidelemm]

That makes me wonder if the timeout command (5 second timeout) is killing the rtl_sdr process before it connects to the sdr and outputs the requested 200000 samples. That would probably account for the "User cancelled" message, as timeout would be sending a SIGTERM to rtl_sdr.

Maybe rtl_sdr is just taking longer to setup/connect to the RTLSDR under WSL for some reason?

[mluckham54]

I tried with a reduced quantity of samples and I recall it still returned 5. I'll do some tests shortly with different values of the # of samples.

It could indeed be slower, or at least different. I'm using usbipd/usbip to transfer the USB device from Windows to the ubuntu environment.

User cancelled is just a text output, there doesn't seem to be an exit code associated with it at first glance.

[mluckham54]

It doesn't matter how many samples, if I just run rtl_sdr on the command line. The code is always 5. I tried different sample rates too.

[mluckham54]

rtl_test also returns 5

[mluckham54]

Nothing in rtl-sdr source calls anything other than exit(1) ... but main() can return a value 'r' in both rtl_test and rtl_sdr, the value in r is a return value from a libusb library call (eg: libusb_cancel_transfer. I'll look at trying to increase logging for rtl_sdr to see what value is return in 'r'

[mluckham54]

Confirmed that this is how 5 (-5) could be returned by rtl_sdr. So now to figure out why

[darksidelemm]

Yep, definitely need to figure out if a return code of 5 could mean something else that might imply the RTLSDR is not available, before adding in code that assumes it means the RTLSDR is ok...

[mluckham54]

In the rtl-sdr project, librtlsdr.c is code that cancels transfer for each outstanding buffer. The first time libusb_cancel_transfer is called it returns 0, after that for each remaining buffer it returns -5. Setting -5 to 0 after the cancel loop ends allows the exit code of rtl_test, rtl_sdr, etc to return 0 - so that appears to be the source of the '5' error code that radiosonde_auto_rx sees.

Looking at libusb.h, the error is LIBUSB_ERROR_NOT_FOUND. The man page I found that describes libusb_cancel_transfer is not specific as to which possible error codes could be returned (https://nxmnpg.lemoda.net/3/libusb_cancel_transfer).

My assumption is that it's the wsl and usbipd/usbip combination that is the root cause of rtl_sdr working this way. I don't have an rPi system set up to test that hypothesis.

If I remove the usbipd device mapping such that lsusb does not report any SDR devices, and run rtl_test or rtl_sdr again, the error return value is 1 (LIBUSB_ERROR_IO).

[mluckham54]

I created an issue on the usbipd-win project for their comment dorssel/usbipd-win#572

I couldn't find a way to report the issue on the rtl-sdr project

[mluckham54]

I reported this issue to the rtl-sdr project:

https://osmocom.org/issues/6005

[darksidelemm]

From prior experience, any changes will take a long time to propagate through to package repositories.

If i can confirm that a return code of 5 will never be associated with a missing RTLSDR, then I could probably accept that error code, but it looks like that might not be the case?

[mluckham54]

Thanks again for replying so quickly. As I mentioned above with no rtlsdr present the exit code from rtl-sdr was 1. In the case of rtl-sdr and the device present, the requested data buffer is output properly, it's just the exit code that's unexpected. Do you have a list of test cases? Mike

…

On Mon, Apr 17, 2023, 05:17 Mark Jessop ***@***.***> wrote: From prior experience, any changes will take a long time to propagate through to package repositories. If i can confirm that a return code of 5 will never be associated with a missing RTLSDR, then I could probably accept that error code, but it looks like that might not be the case? — Reply to this email directly, view it on GitHub <#765 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABFWP5AC55DCLQLQTY5FM33XBUDB3ANCNFSM6AAAAAAWPIUKA4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[mluckham54]

The dorrsel response describes the root cause, in case you didn't read it yet. Mike

…

On Mon, Apr 17, 2023, 10:19 Mike Luckham ***@***.***> wrote: Thanks again for replying so quickly. As I mentioned above with no rtlsdr present the exit code from rtl-sdr was 1. In the case of rtl-sdr and the device present, the requested data buffer is output properly, it's just the exit code that's unexpected. Do you have a list of test cases? Mike On Mon, Apr 17, 2023, 05:17 Mark Jessop ***@***.***> wrote: > From prior experience, any changes will take a long time to propagate > through to package repositories. > > If i can confirm that a return code of 5 will never be associated with a > missing RTLSDR, then I could probably accept that error code, but it looks > like that might not be the case? > > — > Reply to this email directly, view it on GitHub > <#765 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABFWP5AC55DCLQLQTY5FM33XBUDB3ANCNFSM6AAAAAAWPIUKA4> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >