Open yarda opened 2 years ago
Unfortunately, it seems there is nothing related to this problem (or at least I wasn't able to find it).
My next steps will be extraction of the minimal reproducer from the sdrangel code and with it I will ask on the Ettus USRP forum, but I am new to sdrangel, so it will take some time.
What about the big red text in that page: Please note that this product is now End-of-Life (EOL), and is no longer available for sale through Ettus Research, and is not recommended for use in new designs or in new projects.
and
[WARNING] [MULTI_USRP] Setting IQ imbalance compensation is not possible on this device.
[WARNING] [MULTI_USRP] AGC is not available on this device.
[WARNING] [MULTI_USRP] AGC is not available on this device.
2022-01-27 23:09:17.639 (C) USRPInput::acquireChannel: Failed to lock LO
Pretty obvious isn't it?
What about the big red text in that page: Please note that this product is now End-of-Life (EOL), and is no longer available for sale through Ettus Research, and is not recommended for use in new designs or in new projects.
It's open hardware and it is still fully supported by the UHD driver. Anybody can build it. There is no need to buy it from the Ettus.
and
[WARNING] [MULTI_USRP] Setting IQ imbalance compensation is not possible on this device. 1) This just say that the HW doesn't support IQ imbalance. [WARNING] [MULTI_USRP] AGC is not available on this device. 2) This just say that the HW doesn't support AGC [WARNING] [MULTI_USRP] AGC is not available on this device. 2022-01-27 23:09:17.639 (C) USRPInput::acquireChannel: Failed to lock LO
This error is probably not related, I tried different things during the session, and something on my last try failed, see the previous lines from the log.
ad 1) and 2) if the client find out that the HW doesn't support AGC and IQ balance it shouldn't provide controls in the UI (or the controls should be grayed out).
If it really "Failed to lock LO" it will not lead you very far... In short it was never assumed that the USRP plugin would support all USRPs this is mainly for B200' series.
I do not have a USRP1 so I am unable to improve or correct things for the USRP1. Feel free to do a PR.
It seems the sdrangel works very well with the USRP1, except some minor details. E.g. the useless AGC/balance controls in the UI. Also I had a problem to switch to the secondary daugtherboard (because USRP1 has two daughterboards slots), but it seems this can be workaround with the device user arguments. I created simple ham transceiver with it and successfully made several contacts with it, the performance seems to be much better than I expected.
I think most people use the USRP HW in the full duplex mode so they may not notice such problem which manifests only in the simplex TX/RX modes. My guess is some timing problem during the TX/RX switching which leads to usage of the alternative antenna.
I definitely want to improve the USRP1 support in the sdrangel.
Is there a way how to enable the debug output? I.e. to quickly get the UHD API call sequence before I dive into the code.
If you compile from source I think it enables debug output by default but maybe this has been disabled in the Fedora package (I do not own this part). In the log options you can control the console message level but I think that for debug it should be enabled as a whole at compile time (there is some Qt variable).
Yes, it seems the debug output was disabled in Fedora intentionally not to spam regular users. It can be re-enabled by (this could be similar in other distros):
$ echo -e "[Rules]\n*.debug=true" > ~/.config/QtProject/qtlogging.ini
Regarding the original problem it could be related to the sub devices settings and channel mapping. I will experiment with it.
This issue is going to be closed due to inactivity
Sorry, I didn't know the policy about closing inactive issues. I opened the issue to track the problem and let other users know that such problem exists. I am bit slow with the fix. So feel free to close this issue. I will provide PR once I have something usable. I think I can reference even closed issue in the PR.
If you have a fix that's great and if you need some more time to turn it into a PR please assign the issue to yourself. The no activity bot will skip issues that are assigned. I think you should be able to assign the issue to yourself if not please let us know here. In the meantime I remove the no issue label.
I have project "Contributor" label, but it seems I cannot assign myself to the issue. If you can assign me to the issue, please do it.
The problem doesn't seem to be in the antenna switching, but that the USRP sometimes doesn't stop transmitting. And with the power going to the TX/RX antenna, the rx is routed from the RX2 antenna and the firmware will not switch antennas until the the transmission cease. Which is correct function. Now I am trying to figure out why it sometimes doesn't stop transmitting.
Subject or type of issue
Describe your issue here. I have USRP1 with the SBX and WBX daughterboards, SBX is the primary daughertboard, uhd-4.1.0.5 driver and firmware are used. If I add source and sink both with the antenna set to the TX/RX antenna, sometimes (in more than the 50 % cases) the receiving antenna after the transmit changes to the RX2 (i.e. the second antenna on the daughterboard). It seems it cannot be switched back to the primary TX/RX antenna (in the UI there is still written TX/RX antenna and nothing happens if I try to switch it there). It can be switched back by doing few TX/RX cycles and then it is usually correctly set.
Is this a runtime or compilation issue? Runtime
If compilation, where in the instructions are you stuck?
SDR
Development environment
Actual behavior
Expected behavior
Steps to reproduce
Log Files
Log: