-
Notifications
You must be signed in to change notification settings - Fork 435
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SDRangel restores LimeSDR[0:0] on startup rather than LimeSDR[0:1] #1066
Comments
How comes you get the second Rx ([0:1]) on the first tab R0? This is normally impossible. When you change to LimeSDR in R0 it always get the first Rx ([0,0]) to open the second you need to do it in another tab and as you know SDRangel only restores the first tab (R0) at re-start. |
Just press the select sampling device then select Lime/USRP[0:1] |
Ah yes... each Rx is seen as a different device in the list of devices. On save/restore the current device selection should be saved also. In the case of single channel devices if for example you had a RTL-SDR then it comes back with a RTL-SDR. This should be the same in this case taking into account the device subsystem (first or second channel). |
The Rx (or Tx) number is what is called the However this information is not retained in the
Correction: this part is wrong it is only that the information saved for a device in a preset will not be tied to the sub-device. |
In fact this happens here: https://github.com/f4exb/sdrangel/blob/master/sdrgui/mainwindow.cpp#L233 and then the settings for the device once selected are applied from the working preset. Issue is similar to what happens with presets. The information retained is the device URI e.g The information is saved here: https://github.com/f4exb/sdrangel/blob/master/sdrgui/mainwindow.cpp#L1990 |
SDRangel typically restores the last DeviceSet that was being used when re-started.
One example of where this doesn't quite happen, is for LimeSDR and USRP that have multiple channels. It seems [0:0] is always restored, even if [0:1] was last used.
The text was updated successfully, but these errors were encountered: