USRP: Don't call get_tx/rx methods if tx/rx channels is 0, as may result in KeyError exception #1288
Conversation
…ult in KeyError exception
|
sdrangel-7.3.2-2-g032b36ce7-win64.exe 2022-06-13 09:43:34.423 (D) USRPInput::openDevice: open device here I'll just see whether I can find sensible values for master_clock_rate and dboard_clk_rate |
|
200 MHz for these parameters seems sensible after reading this: https://files.ettus.com/manual/page_twinrx.html log now reads: 2022-06-13 11:00:50.806 (D) USRPInput::openDevice: open device here |
|
The radio doesn't have AGC and there seems to be a bit of trouble setting the gain value. However, it looks like this can be overcome by configuring 'Gain - Man' BEFORE starting the RX. Trying to change it after previously starting the radio in 'Gain - Auto' doesn't often work. When I say the gain can be set, I can see the spectrum moving up and down with the gain setting. I'm a bit concerned that when I tune to where a strong signal should be in the FM band, it isn't there. I'll investigate this a bit more. I also see a few of these issues in the logs: 2022-06-13 11:14:40.720 (D) USRPInput::applySettings: exception: RuntimeError: NotImplementedError: set_rx_agc() is not supported on this radio! when the radio is in manual gain mode and the it has already been determined in the same session that the radio doesn't have any TX channels. |
|
When I change the sample rate as the radio is operating the axes on the displayed spectrum don't change, they are set correctly for the startup sample rate. The appearance of the data in the display changes (making me think that the sample rate is actually changing) but the axes don't update. The axes do update if I stop the capture, set the sample rate and restart. |
|
I set the master_clock_rate parameter in the 'Devices - User arguments' field as I had done successfully on an Ettus E320. With that device, the manually configured master clock rate was displayed in the sampling device configuration pane - next to the selected sample rate. With this X310 the master clock rate parameter is not displayed next to the sample rate. With the X310, for a selected sample rate of the 2MS/s, the display reads '- 2000k' |
|
When I select the receiver [0:0] and start a capture, the LED under the RF A, RX2 port illuminates, so that's where I connected my antenna. Turns out it was receiving on the non-illuminated RF A, TX/RX port. I will check the internal wiring of the radio, as I understand a number of different rx daughterboards can be used with this device. -- AFTER FURTHER INVESTIGATION -- Looks like this is due to UHD driver mismatch between the uhd.dll bundled with SDRangel and my radio (with UHD ver 4.2). When I replace the bundled uhd.dll with one that matches my radio the correct LED's light up. |
|
With regard to sample rates, it looks like there might be a similar issue to the E320. I set 2 MS/s sample rate and center on a prominent FM signal, say 93MHz. If I change the center frequency to 92MHz the prominent signal is indicated to be at 92.95 MHz (at the right hand side of the spectrum). If I tune to 94MHz, the prominent signal is indicated to be at 93.05 MHz (at the left hand side of the spectrum). Looks like the radio is sampling faster than indicated. Just tried to repeat this, and it looks like the sample rate might be different for a a new restart. Tune to 92MHz, prominent signal is now indicated at 92.7MHz, tune to 94MHz prominent signal is 93.3MHz (as before, when tuned to 93MHz the signal is in the dead center) |
|
There is a DDC block in the X310 consisting of CIC and half band filters. Obviously not all requested sample rates are available (and some that are available don't give great performance, due CIC passband roll off). If I use the Ettus supplied utility to capture data from radio to disk I can read the warning messages when a bad choice of decimation rate is selected. As well as the requested sample rate and the actual sample rate achieved. So for this command: rx_samples_to_file --file c:temp\usrp_samples.dat --rate 3000000 --freq 93000000 I get this response: Creating the usrp device with: ... Setting RX Rate: 3.000000 Msps... Setting RX Freq: 93.000000 MHz... Waiting for "lo_locked": +++++++++ locked. Press Ctrl + C to stop streaming... Done! It looks as though SDRangel is trying to set a sample rate that cannot be achieved. The radio is saying that it can't be achieved and reporting what the best is that it can do and that SDRangel isn't acting on that information? |
|
In #1278 (comment) - you say that SDRangel does correct to the nearest valid sample rate - so not sure what the difference is here. Note that SDRangel doesn't understand/use any of the text that the UHD driver prints to the log file - it calls set_rx_rate, then get_rx_rate/get_master_clock_rate to get what was actually set. What do youy get for the following log messages: |
|
Just to clarify wrt to selection of the nearest valid sample rate the code appears to be working correctly for the E320 radio but not for the X310. In the development of your previous solution for the E320 there was a period when the GUI reported that the radio was sampling at a particular rate and the evidence showed otherwise. That is the type of behaviour I'm seeing with the X310 and this code version sdrangel-7.3.2-2-g032b36ce7-win64.exe |
|
Extract from the log shows this: 2022-06-15 20:21:25.968 (D) DSPDeviceSourceEngine::gotoRunning: USRPInput started There is no reference to "actual sample rate" in the log. The only reference to "master_clock_rate" is near to the top of the log: 2022-06-15 20:20:13.544 (D) USRPInput::openDevice: open device here |
|
Just to mention the positives, I am able to get samples from the radio, look at the spectrum and waterfall and apply a variety of demod plugins. I've been able to use the Noise Figure Plugin to sweep gain settings at a particular frequency and plot the Noise Figure so SDRangel is proving very handy. I just need to be a bit wary about sample rate setting at the moment! |
|
I'd guess the exception that is being raised (due to no AGC) means the settings for the radio are only partially set - so need to handle that case better. Try setting to manual - then changing the frequency. |
|
#1293 may help get to the next problem. |
|
I have understood your request 'Try setting to manual - then changing the frequency.' to be, set the Gain drop down box to be 'Man' (as opposed to 'Auto') and then make a change in sampling frequency, is that right? In this case I would expect that the sampling rate would 'snap' to the nearest valid sample rate. This isn't what happens. This is what I observe, when in Gain - Man mode:
extract from log, when incrementing sample rate: 2022-06-23 11:35:17.708 (D) USRPInputGUI::updateHardware |
|
Is that log with the latest build? I would have expected a different error message. If it is that latest, it suggests the exception isn't being caught properly. |
|
Sorry, I've just seen your comment from here re: new version: #1293 (comment) This log was from this version: sdrangel-7.3.2-2-g032b36ce7 I'll redo tests shortly |
|
Now using version: sdrangel-7.3.2-33-gee2043770-win64 extract from log, when incrementing sample rate: 2022-06-23 12:34:20.393 (D) DSPDeviceSourceEngine::gotoRunning: USRPInput started |
|
I don't know why you are still getting that exception. However, can you not just make sure you have Gain set to Man in the GUI before you start acquisition? That way it shouldn't occur. |
|
I have set the Gain to Man before starting the acquisition and I still get the exception. I'm still using sdrangel-7.3.2-33-gee2043770-win64 Here's an extract from the log, where I set to Man before starting an acquisition, changed the sample rate and changed the gain setting: 2022-06-27 19:03:54.803 (D) DSPDeviceSourceEngine::initAcquisition |
|
Just tried this with the sdrangel-7.4.0-win64 release, with the same results. 2022-06-27 19:19:36.973 (D) USRPInputGUI::updateHardware |
|
Are you using the version of UHD that is included with sdrangel or another? |
|
@f4exb - Could you please merge f4exb/sdrangel-windows-libraries#14 in to your sdrangel-windows-libraries? |
|
Here's a build with UHD 4.2.0 included - https://github.com/f4exb/sdrangel/suites/7123330160/artifacts/282663595 Please give that a try without changing the UHD DLL. There may be a binary incompatibility if you change it. |
I was using the uhd.dll from UHD 4.2.0 that I had copied into the SDRangel directory. The included uhd.dll seemed to illuminate the incorrect receive port on my radio. This was corrected when I used the more up to date file. |
Just tried this and it seems to work as I expected.
|
|
Just been reading some UHD documentation re: set_rx_agc() An attempt to call set_rx_agc() on a radio without AGC will result in an exception. set_rx_agc() is called in both the if and the else clause, lines 828 and 838 respectively. Presumably this is why I'm getting an exception? sdrangel/plugins/samplesource/usrpinput/usrpinput.cpp Lines 824 to 841 in 280de90 |
|
. |
|
Hang on - there's another path! I'll fix it. |
First attempt to fix #1284