RTL-SDR not recognized by glrpt

[JoshuaKimsey]

So I am using an RTL-SDR V.3 dongle and had no issues with other software thus far. However, in glrpt, my RTL-SDR dongle is never recognized and it always defaults to the standard "Audio" setting. Even when I forcifully enable the rtlsdr driver in the config for the M2 satellite, it still throws an error and says: Searching for SDR Device "rtlsdr" | No Device: "rtlsdr" Index: 0 found | Failed to Initialize SoapySDR. The weird thing is Soapy itself does recognize it just fine. If I do SoapySDRUtil --probe="driver=rtlsdr" then it recognizes it and prints out the correct information accordingly. However, it should be noted if I just call the Soapy probe without specifying the driver it defaults to the Audio driver. Whether this is intended behavior or not is unknown to me, but I thought it was worth mentioning in case. I should also mention I have tried this on both a version I compiled and on a precompiled version in the Skywave Live Linux distro, with both failing in the same manner. So I do not believe it is a compilation error on either my part or on the author of Skywave. I'd try and mess around with the code to see what's wrong, but I'm simply not well-versed in C++ to be able to do so effectively. I'd definitely like to figure this out, as there really is no other easy way to capture images from the Meteor M2 Satellites on Linux.

Let me know if there's any other info you need from me to help solve this issue! I'll be happy to provide whatever information you need and also to test other situations or solutions as well.

[dvdesolve]

Thank you for detailed report. You should try to specify correct device index while using explicit rtlsdr driver. I'm absolutely sure that there were similar messages and the key was to manually set driver and index options to correct values

Also please tell me your SoapySDR version. It seems like few distros provide newer (but yet not stable) 0.8 version which provides incompatible API changes while the last known working version is 0.7.2. There are plans to add support for 0.8 as soon as stable version will be out

[JoshuaKimsey]

Hmm, ok how do I set the explicit device index when setting the driver option? Edit: I found where in the config file to set the index, but how do I know which index to set it to? SoapySDr --prove="Driver=rtlsdr" doesn't seem to obviously say which index it is.

My version of SopaySDR is 7.2.1, not the beta version. I checked that in case there was an issue. I imagine it's the Arch distros that ship Beta .8 out to people.

[dvdesolve]

You should take a look at the device section of config file, option name is index (there are some examples in share directory in the source root). Try to experiment with different values for it. I remember that some German user was able to use his dongle only with index = 2. I'm not sure why this is the case, may be it's related to the way how SoapySDR enumerates USB devices on a bus.

Interesting enough, there is 0.7.2 version in Arch Linux and 0.8 beta in Debian :)

[JoshuaKimsey]

Ok, I'll try that and see what I can do! May I make a suggestion that for a future update, you have it run through the index numbers through a reasonable amount, maybe 1-25, and see if a specific device is found? Also, the ability to manually select a device from the right click menu in the program would be even better! :)

Interesting enough, there is 0.7.2 version in Arch Linux and 0.8 beta in Debian :) LOL! Well, I can say with honest certainty the Ubuntu repos still have .7.2!

[dvdesolve]

On Debian 10 it's true, at least (see #7).

Yes, improved device selection is on the list of future works. However, the top one is to separate code from glrpt/mlrpt into standalone library and I'm working on it right now. After that I'll be able to work on GUI for glrpt and some nice TUI for mlrpt.

[JoshuaKimsey]

Ok, I can confirm it was the index issue! Setting it to index = 2 solved the issue! Maybe add that to the documentation in the config file that an RTL-SDR device may perform best with that index? Or just have it automatically scan through the first few indexes and see if it finds anything!

And that's cool you're separating it out into different projects. What will the difference be between glrpt and mlrpt?

[dvdesolve]

I want to keep this open just to be sure that nothing will be forgotten and users will be able to find this quickly too. Because behavior isn't consistent between different platforms/distros and related to the SoapySDR library I think we can't do too much in this case, only to rewrite device detection/initialization code which will be definitely done.

As for now the source code for glrpt and mlrpt is the same up to the 96%. Main differences are there just because of GTK wrappers inside glrpt. mlrpt is for users who love to work in console while glrpt is for convenient GUI experience. mlrpt can't show live images for obvious reasons but it should be able to work autonomously by schedule and/or cron timetable (at least I want to do it so).

[JoshuaKimsey]

Sure! And I must admit I just finished watching the tutorial video you linked. If I'd literally watched 30 seconds more I'd have seen him say you have to use index = 2 to make it work... >.> (Hey though, I think you can directly link YouTube videos on your GitHub front pages now! It's a great tutorial to follow, so might be a good idea to do that for newbies coming here :) )

That's actually really cool what you have planned! In theory you could make it so the terminal version could be used by other programs for live decoding. For example, have it so as the program operates on a schedule or integrated with something like Gpredict, it outputs the live images to a webpage or web server. Or it could be integrated in to an all in one solution for pulling both NOAA APT and Meteor M2 images. That's really awesome! I like the direction this is heading! I'll say this much, it is, by far, the easiest all in one solution for Linux. Cause otherwise I'd either have to work with very old Python scripts that break current python formatting etiquette or work with Wine, neither of which are fun...

[JoshuaKimsey]

Oh also, a QoL improvement might be to remove the other two M2 satellite options for now, given that one was DOA and the other is now seemingly out of commission forever. Really only the main M2 config file is needed. Or at least have that be the default opening file, instead of the M2 N-2.

[dvdesolve]

There are 3 configs for 2 satellites: Meteor-M2 and Meteor-M2-2. The only reason for them is just to provide examples for users. I want to save DOQPSK/IDOQPSK configs for future missions (Meteor-M2-3 is planned for launch at 2021) because according to the Roscosmos they will hold the same equipment as Meteor-M2-2.

The user is encouraged to create its own config in XDG config home directory so any possible changes will be very easy and could be performed without root privileges. Also in future version of glrpt I plan to add more UI controls so each setting from config file will be accessible withing GUI.

Yep, having separate universal library will open many ways to use it in different projects including C++ and Python apps, CGI scripts, automation systems (many love Raspberry Pi, e. g.) and so on. So this is the primary goal for now