USRP E320 - Overflows when adding channel #1278
Comments
|
Tried to capture a log file, but in this instance the radio didn't appear to drop samples, just the audio device: 2022-06-05 14:58:03.420 (D) DSPDeviceSourceEngine::initAcquisition |
|
I think there is an issue with the setting of the sample rate. I select 1MS/s and tune to a prominent signal in the Broadcast FM band. I then increase the frequency in small steps and track by eye the prominent signal. I would expect to be able to tune close to 0.5MHz high before the prominent signal disappears off the left hand side of the spectrum. However, I can still see the signal when tuned 1.9 MHz higher. This is of course symettrical, so I can still see the signal when I'm tuned 1.9 MHz low. If I reduce the sample rate, using the thumbwheel digits next to the 'SR' label to 250,000 S/s , then my prominent signal is at the edges of the spectrum when the center frequency is +/- 0.5 MHz. From what I've seen, it looks like the radio is sampling 4x faster than it is asked to. |
|
I set sample rate in the GUI at 1MS/s and here are the log entries: 2022-06-06 11:48:08.661 (D) USRPInput::applySettings: clock set to "internal" |
|
With the b210, I get a different master_clock_rate: 2022-06-06 11:59:11.879 (D) USRPInput::applySettings: set sample rate set to 1000000 But the "actual sample rate" is what the UHD driver thinks it has been set too, which looks correct. |
|
I think the problem is related to your master_clock_rate being 61440000. According to https://kb.ettus.com/E320_Getting_Started_Guide, this should be an integer multiple of the sample rate (which that isn't). |
|
Was just looking at the same doc. It does say that the default master clock for E320 is 16 MHz, but it can go up to 61.44 MHz. In https://files.ettus.com/manual/page_general.html#general_sampleratenotes It does say that if the master_clock_rate is not specified, then the UHD driver (3.8.5 and newer) will automatically select a clock rate that will work with the requested sample rate. Looks like this might be the better solution for B2XX and E3XX radios. Could I set a command line argument to set the master clock rate or does this parameter get overwritten every time a capture is started? I'll have a play. |
|
SDRangel doesn't set the master clock, I believe - that's just displaying what UHD has set. You can try adding master_clock_rate=xx after ip_addr parameter, separated by , E.g. something like ip_addr=192.168.0.1,master_clock_rate=16000000 |
|
I've tried adding the 'master_clock_rate' parameter as a 'Device user argument' but as yet have not had any success. I'll keep trying. Incidentally, I used to code in the ip_addr as a user parameter but have found that I don't need it. I deleted all 'Device user arguments' for my USRP device and now I can select the RF A or RF B channel on the E320 by selecting either sampling device 'ni-e320-XXXXXXX[0:0]' or 'ni-e320-XXXXXXX[0:1]' I wonder whether knowledge of the ip address has persisted - maybe an uninstall and reinstall would test this? |
|
If I use the Ettus supplied command line utility to capture samples, with the parameters I've mentioned above I get warnings saying the sample rate can't be achieved. eg stipulating master clock rate with this: rx_samples_to_file --args "master_clock_rate = 61440000" --file c:\temp\usrp_samples.dat --rate 1000000 --freq 93000000 I get this: Setting RX Rate: 1.000000 Msps... If I don't stipulate the master_clock_rate ie I use this: rx_samples_to_file --file c:\temp\usrp_samples.dat --rate 1000000 --freq 93000000 I get this: Setting RX Rate: 1.000000 Msps... Setting RX Freq: 93.000000 MHz... Waiting for "lo_locked": ++++++ locked. SDRangel seems to be reporting that it is using a master_clock_rate and sample rate which are not possible? |
Yes - as I said, the master clock needs to be an integer multiple of the sample rate. I suspect the problem is that at startup, to work out range of supported sample rates, SDRangel sets master clock to min and max values. It then tries to reset it to automatic, with: I'm guessing that this isn't the way to do it on the E320, as it appears you have the max clock rate still set (61440000). Perhaps the property name is different. Can you send me the output of: This will list all the properties for your device. |
|
Here's 'uhd_usrp_probe --tree' without the stuff at the top / |
|
From the log below, it looks like the correct sample rate is achieved using the auto setting of the master_clock_rate via UHD (at 16:53:13.671), and then the master_clock_rate is manually configured, which scuppers it? The actual sample rate isn't reported after the master_clock_rate is set, I wonder if it changes? 2022-06-06 16:53:13.519 (D) USRPInput::applySettings: clock set to "internal" |
|
According to the USRP mailing list, E320 doesn't support automatic master clock (despite what it says in the docs). So the above patch skips the min/max sample rate calculation, that is now just for B2xx. The master clock is just left as the default. You may be able to adjust it with the device arg, if needed. Can you give this build a try? https://github.com/f4exb/sdrangel/suites/6821039503/artifacts/262569799 |
|
Just given this a quick go. master_clock_rate appears to be set to 16 MHz as indicated in the sampling device pane. setting sample rate to 1MS/s looks like it works correctly, the LO can be swung +/- 0.5MHz and a known signal stays in the spectrum view. Broadcast FM demodulator works well, where it previously struggled (dropping audio). ADSB is picking up some aircraft. all looks good, will play around with it a bit more, but thought i'd just give you a bit of brief feedback. Excellent work and thank you |
|
Extract from log with sample rate set to 2MS/s: 2022-06-07 17:51:21.090 (D) USRPInput::applySettings: clock set to "internal" |
|
Good to hear. What happens if you try to set a sample rate that isn't an integer factor of the master clock? Does it go wrong or just correct to the nearest valid value? |
|
Looks like it corrects to the nearest one. I haven't tried to set a custom master_clock_rate via the device arguments to get a bespoke sampling rate. I haven't had a lot of luck with setting device arguments, but will try later. I had to replace the bundled uhd.dll with the UHD 4.2 version for it to talk to my radio, but then I didn't need to play with device arguments. It just picks up the 2 receive channels of the radio as separate sampling devices. I did expect to be able to tune the 2 channels independently, which I can't. But I will see whether this is a limitation of the hardware. |
|
Good, thanks. The master rate arg wouldn't have worked properly before, but hopefully it does now. |
|
One thing I have noticed is that when I occasionally get a 'timeout' I cannot clear the error / restart the sampling device by clicking on the stop and then start button. I need to 'Reload device'. Having said that I've just had an occurrence when I can't clear the timeout error via a reload ..... or deleting and re adding the sampling device in fact I had to close SDRangel and restart it. The timeout normally happens when I set too high a sample rate. |
|
Just had some success setting the master_clock_rate via the device arguments. Need to 'Reload Device' for changes to take effect but then new sample rates that were previously unavailable now are (presumably within the limitations of the E320 interpolators/decimators). setting in excess of 61.44MHz results in 'could not start sample source' error, as expected. |
|
Fixed in 7.3.2. |
Forgot to mention I'm on Windows 10, with SDRangel 7.3.1
I'm greatly appreciating the capability to use an ethernet based USRP with SDRAngel but I've encountered a few issues, the first was that I needed to replace the uhd.dll in the SDRAngel folder with a newer version. (Upgraded from UHD 4.0 to UHD 4.2).
The main problem I'm encountering now is that when I add an SDRAngel 'channel' (Broadcast FM Demod) to process the received data, I invariably get overflows (signified in the log and with the red O indicator), this is for low data rates eg 1MS/s. From memory I'm sure I've had success with an RTL-SDR under similar conditions. The demod audio is very slow and distorted.
Without a 'channel' attached I can view the spectrum and waterfall of a channel sampled at a reported 5.333 333 MS/s without issue.
The text was updated successfully, but these errors were encountered: