When to Use HM USRP B Series？
How to Select a USRP Device
USRP (Universal Software Radio Peripheral) devices are flexible, high-performance software-defined radio (SDR) platforms widely used in applications like wireless communication, research, signal processing, and prototyping. Selecting the right USRP device for your needs involves understanding several factors, such as the device's frequency range, bandwidth, sample rate, and processing capabilities. This guide will walk you through the key considerations to help you select a USRP device that meets your project’s specifications and requirements.
Highmesh Product Page
Understanding Your Application Needs
The first step in selecting a USRP device is understanding the specific requirements of your application. Different applications, such as LTE testing, satellite communication, academic research, and public safety communications, have unique needs. Consider the following questions:
Frequency Range: What frequency range does your application operate in? Different USRP models support different frequency ranges, from HF and VHF bands to high-frequency millimeter waves.
Bandwidth: What bandwidth is required for your signals? High-bandwidth applications require USRP models with wider instantaneous bandwidth to capture and process signals accurately.
Performance: Does your application require real-time processing? If so, you may need a model with a higher sampling rate, onboard FPGA processing, or MIMO capability.
By identifying these requirements early on, you can narrow down your options to USRP models specifically suited for your project’s demands.
Frequency Range and Tuning Capabilities
USRP devices are available in a variety of frequency ranges. Each model has a base range, with some offering tunable options. Consider the following:
Low-Frequency Applications: If you need frequencies in the HF, VHF, or UHF bands (3 kHz - 3 GHz), consider models like the USRP B200 or B210, which provide coverage in these ranges and are ideal for general SDR projects.
Mid- to High-Frequency Applications: For applications above 3 GHz, such as 5G or radar testing, look into models like the USRP X310 or the USRP N310, which support higher frequency ranges and more advanced processing capabilities.
Millimeter-Wave Applications: For frequencies up to 6 GHz and above, devices like the USRP N320 or N321 are recommended. These models offer high-frequency tunability and additional processing power.
It’s essential to select a model with a frequency range that fully encompasses the spectrum required by your application.
Bandwidth and Sampling Rate
Another critical factor to consider is the device’s bandwidth and sampling rate:
Instantaneous Bandwidth: The bandwidth of a USRP device determines the range of frequencies it can process at once. If your application requires high-bandwidth signals, such as wideband communication or spectrum monitoring, look for models like the USRP X410, which offers wide instantaneous bandwidths up to 200 MHz.
Sampling Rate: A high sampling rate is essential for capturing and processing fast-moving signals. The USRP N-series and X-series models generally offer higher sampling rates, suitable for real-time applications where accurate signal representation is needed.
Choosing a USRP model with the right bandwidth and sampling rate ensures accurate signal processing without missing any critical data.
Processing Power and FPGA Capabilities
Some applications require advanced processing capabilities, especially those involving real-time analysis or complex signal algorithms. Many USRP models come with FPGA (Field Programmable Gate Array) support, which enables high-speed processing directly on the device. Consider the following:
FPGA-Enabled Models: Models like the USRP N310 and X310 feature onboard FPGAs, which allow for accelerated processing of data, ideal for MIMO systems, real-time SDR applications, and situations requiring low-latency feedback.
Expandable Processing: For high-performance applications, the USRP X410 offers enhanced FPGA processing capabilities, which can handle complex DSP tasks without relying on external computing resources.
Additional resources:
When to Use calcium carbide stone？Are you interested in learning more about Universal Software Radio Peripheral USRP? Contact us today to secure an expert consultation!
What Are the Advantages of Optical Cable Tractor？
If your application requires custom DSP algorithms or heavy data processing, selecting a USRP model with robust FPGA support can significantly improve performance.
Portability and Connectivity Options
Portability and connectivity are essential considerations, especially for fieldwork or remote applications:
Portable Models: For portable or low-power applications, the USRP B200 series is lightweight and USB-powered, making it ideal for mobile or field-based projects.
Networked Models: Networked USRP devices, such as the N310 and N320, offer Ethernet connectivity and allow remote operation over a network, making them ideal for distributed systems and multi-device setups.
Depending on your application, selecting a device with the appropriate connectivity options and portability features can enhance usability and ease of deployment.
Cost and Budget Considerations
USRP devices vary widely in cost, so it’s important to balance performance needs with budget limitations:
Entry-Level Models: If you are new to SDR or have a limited budget, the USRP B200 or B210 offers a good balance of performance and affordability, making it suitable for most research and educational projects.
Advanced Models: For professional or high-performance needs, consider investing in models like the USRP X310 or X410, which come with more powerful FPGAs and broader bandwidth, ideal for commercial and complex applications.
While advanced models offer more features, entry-level USRP devices can often meet the needs of smaller or simpler projects effectively.
FAQs About Selecting a USRP Device
Q: Can I upgrade the frequency range of my USRP device?
A: Some USRP models allow for expansion or modules to extend the frequency range. Check the specifications of each model to see if it supports modular add-ons.
Q: Are all USRP devices compatible with GNU Radio?
A: Yes, most USRP devices are compatible with GNU Radio, a popular open-source software for SDR applications. NI also offers LabVIEW compatibility for many models.
Q: Do I need FPGA programming knowledge for USRP devices with FPGA?
A: While FPGA programming can enhance the device's performance, it is optional for many applications. Standard USRP software tools allow for operation without custom FPGA code.
Q: Can I use multiple USRP devices for MIMO applications?
A: Yes, many USRP models support MIMO configurations by synchronizing multiple devices. Models like the USRP X310 are particularly suited for MIMO setups.
Conclusion
Selecting the right USRP device depends on your specific application needs, including frequency range, bandwidth, processing requirements, and budget. Understanding these factors and how they relate to your project goals can help you choose a USRP model that maximizes performance and efficiency. With careful consideration of your requirements, a well-chosen USRP device can serve as a valuable tool for research, prototyping, and wireless communication development.
For more information about our Highmesh USRP devices, contact our expert team for more details or request a quote.
USRP-users Digest, Vol 77, Issue 10 - The Mail Archive
Send USRP-users mailing list submissions to
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via , send a message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: Bandwidth vs Sampling rate ()
2. Re: Bandwidth vs Sampling rate ()
3. Re: Bandwidth vs Sampling rate ()
4. Port 0 is already connected on start/stop/start of top_block.
(Eric Johnson)
5. RFNoC DmaFifo -> 2x DUC -> AddSub -> Radio, sanity check
(Eric Schneider)
6. Re: RFNoC DmaFifo -> 2x DUC -> AddSub -> Radio, sanity check
(Martin Braun)
7. Re: 3.10.1 issue (Martin Braun)
8. Re: Cannot debug this ... (Martin Braun)
9. Re: Customising B210 software/firmware (Martin Braun)
10. 3.10.1.1 Release Candidate 1 Announcement (Derek Kozel)
11. Re: E312 - ssh connection from USRP to PC (do ber)
12. Re: USRP recv timeout, then returns zero samples
(Rom?n Rodr?guez P?rez)
13. Re: Multiple DSP DDC chains on RF-NoC X310 (Andre Puschmann)
14. Re: RFNoC DmaFifo -> 2x DUC -> AddSub -> Radio, sanity check
(Eric Schneider)
15. Re: Bandwidth vs Sampling rate (Julian Arnold)
16. Re: Multiple DSP DDC chains on RF-NoC X310 (Michael West)
----------------------------------------------------------------------
Message: 1
Date: Thu, 12 Jan 17:39:39 + (UTC)
From:
To: "Marcus D. Leech" <>
Cc: usrp-users <>
Subject: Re: [USRP-users] Bandwidth vs Sampling rate
Message-ID:
<>
Content-Type: text/plain; charset="utf-8"
Awesome, thanks so much for the info :)
----- Original Message -----
From: "Marcus D. Leech via USRP-users" <>
To: "usrp-users" <>
Sent: Thursday, January 12, 11:18:37 AM
Subject: Re: [USRP-users] Bandwidth vs Sampling rate
On 01/12/ 11:14 AM, tilla--- via USRP-users wrote:
DOH,
WBX-120
Yup. Not configurable.
Further, the out-of-band attenuation depth is not infinite, so even with
settable bandwidth, I'd expect that strong adjacent signals would
still be easily detectable. The point of being able to set bandwidth is to
reduce the amplitude of strong adjacent signals that may
otherwise cause a loss of dynamic range.
----- Original Message -----
From: "Marcus M?ller via USRP-users" <>
To: "usrp-users" <>
Sent: Thursday, January 12, 10:46:48 AM
Subject: Re: [USRP-users] Bandwidth vs Sampling rate
Hi,
not all devices even support the analog bandwidth setting. Which
USRP/daughterboard (if applicable) are we talking about?
Best regards,
Marcus
On 12.01. 16:39, tilla--- via USRP-users wrote:
Peeps,
I was running an experiment and I stumbled onto something that did not make
sense to me, but I am far from an expert.
My input signal is a tone from a signal generator playing out on 1 MHz
boundaries over a 10 MHz span dwelling for 1 second.
So, at t=0 tone is at 900 MHz, t=1 901 MHz, t=2 902 MHz, etc.
I perform captures using rx samples to file app.
one capture is center freq = 905, bandwidth = 2 MHz, sample rate = 2MSA/sec
This data set looks exactly as expected, I only see tones at 904,905, and
906... Nothing fishy there...
My next capture is at center freq = 905, bandwidth = 2 MHz, sample rate = 10
MSA/sec.
I see ALL tones over the course of 10 seconds...
I thought the bandwidth parameter was at the analog input, so my thought was I
should still only see 904, 905, and 906 and I should not see anything outside
of the center freq / bandwidth range.
Am I missing something?
Thanks,
_______________________________________________
USRP-users mailing list
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
------------------------------
Message: 2
Date: Thu, 12 Jan 18:20:04 + (UTC)
From:
To:
Cc: "Marcus D. Leech" <>, usrp-users
<>
Subject: Re: [USRP-users] Bandwidth vs Sampling rate
Message-ID:
<>
Content-Type: text/plain; charset="utf-8"
Quick followups:
Which cards support analog bandwidth specification?
Is there something on the hardware I can query to determine if a card supports
analog bandwidth specification so i could take other actions if not present?
When a card doesnt support analog bandwidth parameter, is bandwidth effectively
sample rate or something close to that?
Thanks,
----- Original Message -----
From: "tilla--- via USRP-users" <>
To: "Marcus D. Leech" <>
Cc: "usrp-users" <>
Sent: Thursday, January 12, 12:39:39 PM
Subject: Re: [USRP-users] Bandwidth vs Sampling rate
Awesome, thanks so much for the info :)
----- Original Message -----
From: "Marcus D. Leech via USRP-users" <>
To: "usrp-users" <>
Sent: Thursday, January 12, 11:18:37 AM
Subject: Re: [USRP-users] Bandwidth vs Sampling rate
On 01/12/ 11:14 AM, tilla--- via USRP-users wrote:
DOH,
WBX-120
Yup. Not configurable.
Further, the out-of-band attenuation depth is not infinite, so even with
settable bandwidth, I'd expect that strong adjacent signals would
still be easily detectable. The point of being able to set bandwidth is to
reduce the amplitude of strong adjacent signals that may
otherwise cause a loss of dynamic range.
----- Original Message -----
From: "Marcus M?ller via USRP-users" <>
To: "usrp-users" <>
Sent: Thursday, January 12, 10:46:48 AM
Subject: Re: [USRP-users] Bandwidth vs Sampling rate
Hi,
not all devices even support the analog bandwidth setting. Which
USRP/daughterboard (if applicable) are we talking about?
Best regards,
Marcus
On 12.01. 16:39, tilla--- via USRP-users wrote:
Peeps,
I was running an experiment and I stumbled onto something that did not make
sense to me, but I am far from an expert.
My input signal is a tone from a signal generator playing out on 1 MHz
boundaries over a 10 MHz span dwelling for 1 second.
So, at t=0 tone is at 900 MHz, t=1 901 MHz, t=2 902 MHz, etc.
I perform captures using rx samples to file app.
one capture is center freq = 905, bandwidth = 2 MHz, sample rate = 2MSA/sec
This data set looks exactly as expected, I only see tones at 904,905, and
906... Nothing fishy there...
My next capture is at center freq = 905, bandwidth = 2 MHz, sample rate = 10
MSA/sec.
I see ALL tones over the course of 10 seconds...
I thought the bandwidth parameter was at the analog input, so my thought was I
should still only see 904, 905, and 906 and I should not see anything outside
of the center freq / bandwidth range.
Am I missing something?
Thanks,
_______________________________________________
USRP-users mailing list
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
------------------------------
Message: 3
Date: Thu, 12 Jan 13:42:37 -
From:
To:
Cc: usrp-users <>
Subject: Re: [USRP-users] Bandwidth vs Sampling rate
Message-ID: <>
Content-Type: text/plain; charset="utf-8"
Off the top of my head, TVRX2 and DBS_RX2.
There'd be an item in the property tree for the card, but I don't have
access to the code right this minute.
On -01-12 13:20, wrote:
> Quick followups:
>
> Which cards support analog bandwidth specification?
>
> Is there something on the hardware I can query to determine if a card
> supports analog bandwidth specification so i could take other actions if not
> present?
>
> When a card doesnt support analog bandwidth parameter, is bandwidth
> effectively sample rate or something close to that?
>
> Thanks,
>
> -------------------------
>
> FROM: "tilla--- via USRP-users" <>
> TO: "Marcus D. Leech" <>
> CC: "usrp-users" <>
> SENT: Thursday, January 12, 12:39:39 PM
> SUBJECT: Re: [USRP-users] Bandwidth vs Sampling rate
>
> Awesome, thanks so much for the info :)
>
> -------------------------
>
> FROM: "Marcus D. Leech via USRP-users" <>
> TO: "usrp-users" <>
> SENT: Thursday, January 12, 11:18:37 AM
> SUBJECT: Re: [USRP-users] Bandwidth vs Sampling rate
>
> On 01/12/ 11:14 AM, tilla--- via USRP-users wrote:
>
>> DOH,
>>
>> WBX-120
> Yup. Not configurable.
>
> Further, the out-of-band attenuation depth is not infinite, so even with
> settable bandwidth, I'd expect that strong adjacent signals would
> still be easily detectable. The point of being able to set bandwidth is to
> reduce the amplitude of strong adjacent signals that may
> otherwise cause a loss of dynamic range.
>
> -------------------------
>
> FROM: "Marcus M?ller via USRP-users" <>
> TO: "usrp-users" <>
> SENT: Thursday, January 12, 10:46:48 AM
> SUBJECT: Re: [USRP-users] Bandwidth vs Sampling rate
>
> Hi,
>
> not all devices even support the analog bandwidth setting. Which
> USRP/daughterboard (if applicable) are we talking about? Best regards,
> Marcus
>
> On 12.01. 16:39, tilla--- via USRP-users wrote:
>
> Peeps,
>
> I was running an experiment and I stumbled onto something that did not make
> sense to me, but I am far from an expert.
>
> My input signal is a tone from a signal generator playing out on 1 MHz
> boundaries over a 10 MHz span dwelling for 1 second.
>
> So, at t=0 tone is at 900 MHz, t=1 901 MHz, t=2 902 MHz, etc.
>
> I perform captures using rx samples to file app.
>
> one capture is center freq = 905, bandwidth = 2 MHz, sample rate = 2MSA/sec
>
> This data set looks exactly as expected, I only see tones at 904,905, and
> 906... Nothing fishy there...
>
> My next capture is at center freq = 905, bandwidth = 2 MHz, sample rate = 10
> MSA/sec.
>
> I see ALL tones over the course of 10 seconds...
>
> I thought the bandwidth parameter was at the analog input, so my thought was
> I should still only see 904, 905, and 906 and I should not see anything
> outside of the center freq / bandwidth range.
>
> Am I missing something?
>
> Thanks,
>
> _______________________________________________
> USRP-users mailing list
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> _______________________________________________
> USRP-users mailing list
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> _______________________________________________
> USRP-users mailing list
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
------------------------------
Message: 4
Date: Thu, 12 Jan 13:49:22 -
From: Eric Johnson <>
To:
Subject: [USRP-users] Port 0 is already connected on start/stop/start
of top_block.
Message-ID:
Content-Type: text/plain; charset="utf-8"
I am seeing an issue with stopping and starting a gnuradio top block from
python using the start(), stop(), wait() inside my top block.
The start, stop, and wait work the first time. When executing the second
start I receive the following error message.
thread[thread-per-block[1]: ]: RuntimeError:
On node 0/DmaFIFO_0, input port 0 is already connected.
This error traces to uhd/host/lib/rfnoc/sink_node_ctrl.cpp:84 inside
sink_node_ctrl::_register_upstream_node().
The flowgraph is a simple sin source -> uhd sink and uhd source ->
magnitude squared.
Has anyone seen anything similar?
USRP: X310,FW Version: 5.0,FPGA Version: 33.0,RFNoC capable: Yes
UHD: linux; GNU C++ version 4.8.4; Boost_; UHD_3.11.0.git-96-ga0c5ed6a
gnuradio: v3.7.10.1-190-g3f14e437
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
------------------------------
Message: 5
Date: Thu, 12 Jan 13:49:37 -
From: Eric Schneider <>
To: "" <>
Subject: [USRP-users] RFNoC DmaFifo -> 2x DUC -> AddSub -> Radio,
sanity check
Message-ID: <>
Content-Type: text/plain; charset=utf-8
I am attempting to create a multiple channel transmitter RFNoC graph
configuration. But when run, I get flooded with under-runs. So a few
questions...
1) Should I expect this to work (conceptually)?
2) Do I need to do any special setup (e.g. flow-control settings) on the
blocks/graph?
3) Does the DmaFifo block require any setup to use two ports instead of one?
I am using the UHD API directly (e.g. get_block_ctrl, create_graph,
connect, get_tx_stream, ...), along with a bitstream containing the
required blocks.
The connection is:
streamer/block_id0 -> fifo_blk:0 -> duc0_blk:0 -> addsub:0 -> radio:0
streamer/block_id1 -> fifo_blk:1 -> duc1_blk:0 -> addsub:1
A single channel DmaFifo -> DUC -> Radio graph works fine.
Using: UHD_004.000.000.rfnoc-devel-0-gfb2c
TIA!
Eric
------------------------------
Message: 6
Date: Thu, 12 Jan 17:03:00 -
From: Martin Braun <>
To:
Subject: Re: [USRP-users] RFNoC DmaFifo -> 2x DUC -> AddSub -> Radio,
sanity check
Message-ID: <>
Content-Type: text/plain; charset=windows-
On 01/12/ 12:49 PM, Eric Schneider via USRP-users wrote:
> I am attempting to create a multiple channel transmitter RFNoC graph
> configuration. But when run, I get flooded with under-runs. So a few
> questions...
>
> 1) Should I expect this to work (conceptually)?
Yes, unless you're exceeding some bandwidth limits.
> 2) Do I need to do any special setup (e.g. flow-control settings) on the
> blocks/graph?
No.
>
> 3) Does the DmaFifo block require any setup to use two ports instead of one?
No.
>
> I am using the UHD API directly (e.g. get_block_ctrl, create_graph,
> connect, get_tx_stream, ...), along with a bitstream containing the
> required blocks.
>
> The connection is:
> streamer/block_id0 -> fifo_blk:0 -> duc0_blk:0 -> addsub:0 -> radio:0
> streamer/block_id1 -> fifo_blk:1 -> duc1_blk:0 -> addsub:1
The problem here is that the output of each DUC is 200 Msps, and they're
both going to the AddSub. If you move the AddSub *before* the DUC, you
should be good. If you're not engaging the CORDIC (or have both set to
the same value), that'll even give you the same signal thanks to the
linear property of the filters and additions involved.
-- M
>
> A single channel DmaFifo -> DUC -> Radio graph works fine.
>
> Using: UHD_004.000.000.rfnoc-devel-0-gfb2c
>
>
> TIA!
>
> Eric
>
>
> _______________________________________________
> USRP-users mailing list
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 7
Date: Thu, 12 Jan 17:44:53 -
From: Martin Braun <>
To:
Subject: Re: [USRP-users] 3.10.1 issue
Message-ID: <>
Content-Type: text/plain; charset=windows-
Can you please download the latest maint, then load the FPGA images, and
try again?
Thanks,
Martin
On 01/11/ 07:50 AM, tilla--- via USRP-users wrote:
> Sorry, not trying to bombard the list, but another common error is:
>
> Error: RuntimeError: x300_dac_ctrl: timeout waiting for DAC PLL to lock
>
> :(
>
> ------------------------------------------------------------------------
> *From: *"tilla--- via USRP-users" <>
> *To: *"usrp-users" <>
> *Sent: *Wednesday, January 11, 10:34:38 AM
> *Subject: *[USRP-users] 3.10.1 issue
>
> Hello,
>
> Looking to upgrade from 3.9.2 to 3.10.1 on win 7 64 bit / Visual Studio
> .
>
> Driver install and firmware push are all happy.
>
> When running the Rx IQ imbalance cal script, I get the following error:
>
> x300_dac_ctrl: front end sync failed. unexpected FIFO depth [0xff]
>
> Any known issues around this or parameter tweak?
>
> Thanks,
>
> _______________________________________________
> USRP-users mailing list
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 8
Date: Thu, 12 Jan 17:46:30 -
From: Martin Braun <>
To: "''" <>
Subject: Re: [USRP-users] Cannot debug this ...
Message-ID: <>
Content-Type: text/plain; charset=windows-
Looks like benchmark_rate is doing fine. I would suggest profiling
whatever app you're using.
Cheers,
Martin
On 01/11/ 03:05 AM, Joan Olmos wrote:
> Thanks for your reply.
>
> I've tested the benchmark (with --tx_rate 1.9e6, since I'm transmitting
> on that PC) and it seems OK.
>
> But you are right: it could be anything. Perhaps it's not worth to dig
> too much into it since the PC only has 2 cores and using "top -H" I can
> see up to 6 threads stemming from my program..
>
> Creating the usrp device with: ...
> -- Detected Device: B210
> -- Operating over USB 2.
> -- Detecting internal GPSDO.... Found an internal GPSDO: GPSTCXO ,
> Firmware Rev 0.929a
> -- Initialize CODEC control...
> -- Initialize Radio control...
> -- Performing register loopback test... pass
> -- Performing register loopback test... pass
> -- Performing CODEC loopback test... pass
> -- Performing CODEC loopback test... pass
> -- Asking for clock rate 16. MHz...
> -- Actually got clock rate 16. MHz.
> -- Performing timer loopback test... pass
> -- Performing timer loopback test... pass
> -- Setting master clock rate selection to 'automatic'.
> Using Device: Single USRP:
> Device: B-Series Device
> Mboard 0: B210
> RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: FE-RX2
> RX Channel: 1
> RX DSP: 1
> RX Dboard: A
> RX Subdev: FE-RX1
> TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: FE-TX2
> TX Channel: 1
> TX DSP: 1
> TX Dboard: A
> TX Subdev: FE-TX1
>
> Setting device timestamp to 0...
> -- 1) catch time transition at pps edge
> -- 2) set times next pps (synchronously)
> -- Asking for clock rate 60. MHz...
> -- Actually got clock rate 60. MHz.
> -- Performing timer loopback test... pass
> -- Performing timer loopback test... pass
> -- Asking for clock rate 60. MHz... OK
> -- Asking for clock rate 30. MHz...
> -- Actually got clock rate 30. MHz.
> -- Performing timer loopback test... pass
> -- Performing timer loopback test... pass
> -- Asking for clock rate 30. MHz... OK
> -- Asking for clock rate 30. MHz... OK
> Testing transmit rate 1. Msps on 2 channels
>
> Benchmark rate summary:
> Num received samples: 0
> Num dropped samples: 0
> Num overflows detected: 0
> Num transmitted samples:
> Num sequence errors: 0
> Num underflows detected: 0
> Num late commands: 0
> Num timeouts: 0
>
>
> Done!
>
>
> El 10/01/17 a las 22:25, Martin Braun via USRP-users escribi?:
>> Can you try running benchmark_rate --rx_rate 1.9e6 --channels 0,1 to see
>> if this also happens outside of your application?
>>
>> There could be all sorts of issues ranging from the specific USB
>> controller used to a software bug. Without eliminating options, it'll be
>> hard to pinpoint the root cause.
>>
>> Cheers,
>> Martin
>>
>> On 01/09/ 11:58 AM, Joan Olmos via USRP-users wrote:
>>> Hi,
>>>
>>> I have written a program that implements a SISO/MIMO (configurable)
>>> modem using two B210.
>>>
>>> In the SISO scheme (single channel mode) I have no problems with a USRP
>>> sampling rate of 3.872 MS/s (log attached in blue).
>>>
>>> For the MIMO mode I set a dual channel configuration and a USRP sampling
>>> rate of 1.92 MS/s (half of the rate of the SISO setup). In this case I
>>> get underflows even if I reduce the sampling rate to a very minimum !
>>> (log attached in red).
>>>
>>> I must say that if I run it in a faster computer everything works OK,
>>> but what I can't understand is why the dual channel can't work despite
>>> using a low sampling rate and low CPU load.
>>>
>>> I've also thought about a possible USB data rate limitation (I'm using
>>> USB 2.0) but the USB rate needed for the dual channel setup at half the
>>> sampling rate should be approx. the same as with the single channel.
>>>
>>> Can anybody shed some light on this?
>>>
>>> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>
>>> Creating USRP with args "type=b200, num_recv_frames=512,
>>> num_send_frames=512"...
>>> -- Detected Device: B210
>>> -- Operating over USB 2.
>>> -- Detecting internal GPSDO.... Found an internal GPSDO: GPSTCXO ,
>>> Firmware Rev 0.929a
>>> -- Initialize CODEC control...
>>> -- Initialize Radio control...
>>> -- Performing register loopback test... pass
>>> -- Performing register loopback test... pass
>>> -- Performing CODEC loopback test... pass
>>> -- Performing CODEC loopback test... pass
>>> -- Asking for clock rate 16. MHz...
>>> -- Actually got clock rate 16. MHz.
>>> -- Performing timer loopback test... pass
>>> -- Performing timer loopback test... pass
>>> -- Setting master clock rate selection to 'automatic'.
>>> num. Rx channels reported by usrp: 2
>>> num. Tx channels reported by usrp: 2
>>> Subdevice Specification:
>>> Channel 0: Daughterboard A, Subdevice A
>>> Channel 1: Daughterboard A, Subdevice B
>>>
>>> Subdevice Specification:
>>> Channel 0: Daughterboard A, Subdevice A
>>> Channel 1: Daughterboard A, Subdevice B
>>>
>>> Device name: wicomtec-1 (30CD3EC)
>>> Clock source reported by usrp: internal
>>> -- 1) catch time transition at pps edge
>>> -- 2) set times next pps (synchronously)
>>> Corrected PC clock mismatch of: + milliseconds
>>> Current Time reported by USRP: 1. seconds
>>> Current Time reported by PC: 1. seconds
>>> Normalized_rx_gain for channel 0 = 0.
>>> Normalized_rx_gain for channel 1 = 0.
>>> -- Asking for clock rate 30. MHz...
>>> -- Actually got clock rate 30. MHz.
>>> -- Performing timer loopback test... pass
>>> -- Performing timer loopback test... pass
>>>
>>>
>>> Master clock rate: .
>>>
>>> Setting Rate: ....
>>> Actual Rate Tx(0): ....
>>> usbsize: , k: 20
>>> Setting frequencies: Rx: ., Tx: . MHz...
>>> Actual frequency Tx(0): . MHz...
>>> Setting TX Gain: 80. dB...
>>> Antenna reported by usrp for TX channel 0: TX/RX
>>> Actual TX Gain: 80....
>>> Tx: stream_args.cpu_format = fc32
>>> Tx: stream_args.otw_format = sc16
>>> Tx: stream_args.args = spp=
>>> Tx: stream_args.channel_list = 0, 1
>>> Tx: stream_args.n_channels = 1
>>> max_samps_per_usb_packet =
>>> Available sensors:
>>> temp
>>> lo_locked
>>> Checking TX: LO: locked ...
>>> Tx buffer size in samples:
>>> configusrp: Success
>>> USRP rate: ., baud rate =
>>> Corrected PC clock mismatch of: +288 milliseconds
>>>
>>> ===> DDS: table size = , frequency resolution = 0.923 [Hz]
>>>
>>> ===> Linear interpolation upsampling: upsampling factor = 4
>>>
>>> ===> TX shaping filter: number of rrcos coefficients: 64, roll-off
>>> factor = 0.
>>> frame capacity = bits ( bytes)
>>>
>>> ===> USRP buffers = 64, Total buffer latency = 0. [s], USB bit
>>> rate = 123. [Mbit/s]
>>> ===> Main loop period = 0. [s], Upsampling factor = 4, MIMO
>>> channels = 1
>>> ===> Wideband I/Q sampling rate = [S/s], Channel I/Q sampling
>>> rate = [S/s]
>>> ===> Wideband I/Q samps per loop = , Channel samps per loop =
>>>
>>> ===> Starting TX streaming thread at PC time: 1. seconds
>>> ===> loops= 16, PC time= 1.52 s, Buffer full: curr,min,max 2%,
>>> 2%, 2%, CenterFreq.= .0 MHz, CPU load= 31 %, (0)
>>> ===> loops= 32, PC time= 1.56 s, Buffer full: curr,min,max 9%,
>>> 2%, 9%, CenterFreq.= .0 MHz, CPU load= 23 %, (0)
>>> ===> loops= 48, PC time= 1.59 s, Buffer full: curr,min,max 34%,
>>> 2%, 34%, CenterFreq.= .0 MHz, CPU load= 15 %, (0)
>>> ===> loops= 64, PC time= 1.62 s, Buffer full: curr,min,max 59%,
>>> 2%, 59%, CenterFreq.= .0 MHz, CPU load= 17 %, (5)
>>> ===> loops= 80, PC time= 1.64 s, Buffer full: curr,min,max 84%,
>>> 2%, 84%, CenterFreq.= .0 MHz, CPU load= 16 %, (5)
>>> ===> Starting TX streaming at PC time: 1. seconds, buffers read by
>>> USRP = 26 ( samples)
>>> ===> loops= 96, PC time= 3.08 s, Buffer full: curr,min,max 97%,
>>> 2%, 97%, CenterFreq.= .0 MHz, CPU load= 17 %, (5)
>>> ===> loops= 112, PC time= 3.24 s, Buffer full: curr,min,max 97%,
>>> 2%, 97%, CenterFreq.= .0 MHz, CPU load= 18 %, (5)
>>> ===> loops= 128, PC time= 3.41 s, Buffer full: curr,min,max 97%,
>>> 2%, 97%, CenterFreq.= .0 MHz, CPU load= 14 %, (5)
>>> ===> loops= 144, PC time= 3.57 s, Buffer full: curr,min,max 97%,
>>> 2%, 97%, CenterFreq.= .0 MHz, CPU load= 15 %, (5)
>>> ===> loops= 160, PC time= 3.74 s, Buffer full: curr,min,max 97%,
>>> 2%, 97%, CenterFreq.= .0 MHz, CPU load= 14 %, (5)
>>> ===> loops= 176, PC time= 3.90 s, Buffer full: curr,min,max 97%,
>>> 2%, 97%, CenterFreq.= .0 MHz, CPU load= 15 %, (5)
>>> ===> loops= 192, PC time= 4.07 s, Buffer full: curr,min,max 97%,
>>> 2%, 97%, CenterFreq.= .0 MHz, CPU load= 14 %, (5)
>>> ===> loops= 208, PC time= 4.23 s, Buffer full: curr,min,max 97%,
>>> 2%, 97%, CenterFreq.= .0 MHz, CPU load= 14 %, (5)
>>> ===> loops= 224, PC time= 4.40 s, Buffer full: curr,min,max 97%,
>>> 2%, 97%, CenterFreq.= .0 MHz, CPU load= 16 %, (5)
>>>
>>>
>>> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>
>>>
>>> Creating USRP with args "type=b200, num_recv_frames=512,
>>> num_send_frames=512"...
>>> -- Detected Device: B210
>>> -- Operating over USB 2.
>>> -- Detecting internal GPSDO.... Found an internal GPSDO: GPSTCXO ,
>>> Firmware Rev 0.929a
>>> -- Initialize CODEC control...
>>> -- Initialize Radio control...
>>> -- Performing register loopback test... pass
>>> -- Performing register loopback test... pass
>>> -- Performing CODEC loopback test... pass
>>> -- Performing CODEC loopback test... pass
>>> -- Asking for clock rate 16. MHz...
>>> -- Actually got clock rate 16. MHz.
>>> -- Performing timer loopback test... pass
>>> -- Performing timer loopback test... pass
>>> -- Setting master clock rate selection to 'automatic'.
>>> num. Rx channels reported by usrp: 2
>>> num. Tx channels reported by usrp: 2
>>> Subdevice Specification:
>>> Channel 0: Daughterboard A, Subdevice A
>>> Channel 1: Daughterboard A, Subdevice B
>>>
>>> Subdevice Specification:
>>> Channel 0: Daughterboard A, Subdevice A
>>> Channel 1: Daughterboard A, Subdevice B
>>>
>>> Device name: wicomtec-1 (30CD3EC)
>>> Clock source reported by usrp: internal
>>> -- 1) catch time transition at pps edge
>>> -- 2) set times next pps (synchronously)
>>> Corrected PC clock mismatch of: + milliseconds
>>> Current Time reported by USRP: 1. seconds
>>> Current Time reported by PC: 1. seconds
>>> Normalized_rx_gain for channel 0 = 0.
>>> Normalized_rx_gain for channel 1 = 0.
>>> -- Asking for clock rate 30. MHz...
>>> -- Actually got clock rate 30. MHz.
>>> -- Performing timer loopback test... pass
>>> -- Performing timer loopback test... pass
>>>
>>>
>>> Master clock rate: .
>>>
>>> Setting Rate: ....
>>> Actual Rate Tx(0): ....
>>> Actual Rate Tx(1): ....
>>> usbsize: , k: 10
>>> Setting frequencies: Rx: ., Tx: . MHz...
>>> Actual frequency Tx(0): . MHz...
>>> Actual frequency Tx(1): . MHz...
>>> Setting TX Gain: 80. dB...
>>> Antenna reported by usrp for TX channel 0: TX/RX
>>> Antenna reported by usrp for TX channel 1: TX/RX
>>> Actual TX Gain: 80....
>>> Actual TX Gain: 80....
>>> Tx: stream_args.cpu_format = fc32
>>> Tx: stream_args.otw_format = sc16
>>> Tx: stream_args.args = spp=
>>> Tx: stream_args.channel_list = 0, 1
>>> Tx: stream_args.n_channels = 2
>>> max_samps_per_usb_packet =
>>> Available sensors:
>>> temp
>>> lo_locked
>>> Checking TX: LO: locked ...
>>> Tx buffer size in samples:
>>> configusrp: Success
>>> USRP rate: ., baud rate =
>>> Corrected PC clock mismatch of: +261 milliseconds
>>>
>>> ===> DDS: table size = , frequency resolution = 0.916 [Hz]
>>>
>>> ===> Linear interpolation upsampling: upsampling factor = 4
>>>
>>> ===> TX shaping filter: number of rrcos coefficients: 64, roll-off
>>> factor = 0.
>>> frame capacity = bits ( bytes)
>>>
>>> ===> USRP buffers = 64, Total buffer latency = 1. [s], USB bit
>>> rate = 122. [Mbit/s]
>>> ===> Main loop period = 0. [s], Upsampling factor = 4, MIMO
>>> channels = 2
>>> ===> Wideband I/Q sampling rate = [S/s], Channel I/Q sampling
>>> rate = [S/s]
>>> ===> Wideband I/Q samps per loop = , Channel samps per loop =
>>>
>>> ===> Starting TX streaming thread at PC time: 1. seconds
>>> ===> loops= 16, PC time= 1.43 s, Buffer full: curr,min,max 25%,
>>> 2%, 25%, CenterFreq.= .5 MHz, CPU load= 36 %, (0)
>>> ===> loops= 32, PC time= 1.46 s, Buffer full: curr,min,max 50%,
>>> 2%, 50%, CenterFreq.= .5 MHz, CPU load= 36 %, (0)
>>> ===> loops= 48, PC time= 1.49 s, Buffer full: curr,min,max 75%,
>>> 2%, 75%, CenterFreq.= .5 MHz, CPU load= 36 %, (1)
>>> ===> Starting TX streaming at PC time: 1. seconds, buffers read by
>>> USRP = 0 (0 samples)
>>> ULLLLLLLLL===> loops= 64, PC time= 3.04 s, Buffer full:
>>> curr,min,max 97%, 2%, 97%, CenterFreq.= .5 MHz, CPU load= 38 %, (5)
>>> LLLLLLLLL===> loops= 80, PC time= 3.08 s, Buffer full: curr,min,max
>>> 97%, 2%, 97%, CenterFreq.= .5 MHz, CPU load= 18 %, (5)
>>> ===> loops= 96, PC time= 3.12 s, Buffer full: curr,min,max 97%,
>>> 2%, 97%, CenterFreq.= .5 MHz, CPU load= 18 %, (5)
>>> UU===> loops= 112, PC time= 5.35 s, Buffer full: curr,min,max
>>> 97%, 2%, 97%, CenterFreq.= .5 MHz, CPU load= 18 %, (5)
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>>
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>> _______________________________________________
>> USRP-users mailing list
>>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
------------------------------
Message: 9
Date: Thu, 12 Jan 17:49:19 -
From: Martin Braun <>
To:
Subject: Re: [USRP-users] Customising B210 software/firmware
Message-ID: <>
Content-Type: text/plain; charset=windows-
Keep in mind that Rx and Tx are both on the same chip. I don't have
isolation numbers, but it's possible that changing anything to the
analog chain will make no difference to your signal.
Changes like this would be done in software, not FPGA, and would modify
the drivers for the AD control (see host/lib/usrp/common/ad_*)
and the GPIO controls for the B200.
Before you go there, can you please be more specific what kind of
interference you're seeing?
Cheers,
Martin
On 01/10/ 11:08 PM, Rini John via USRP-users wrote:
> Good day
>
> We would like assistance regarding the Ettus B210 firmware.
>
> The issue we have with the B210 is that the noise from the Tx is jamming
> the Rx. So we would like to switch TX side off so that its noise does
> not jam the RX when receiving the RX portion of a PRI.
>
> The approach is either:
>
> 1. Control an external RF switch via firmware, , or something like GNU
> radio if that is possible.
> 2. Switch the TX chain off in the firmware.
>
> We have rebuilt the firmware using ISE 14.7, but are not sure which
> files to amend for our need. Could you assist us, or point us to where
> we can get more insight to the software/firmware or a forum post?
>
> Kind Regards
> Rini
>
> ------------------------------------------------------------------------
> This message is subject to the CSIR's copyright terms and conditions,
> legal notice, and implemented Open Document Format (ODF) standard.
> The full disclaimer details can be found at
> http://www.csir.co.za/disclaimer.html.
>
> Please consider the environment before printing this .
>
>
> _______________________________________________
> USRP-users mailing list
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 10
Date: Thu, 12 Jan 17:50:25 -
From: Derek Kozel <>
To: "" <>
Subject: [USRP-users] 3.10.1.1 Release Candidate 1 Announcement
Message-ID:
Content-Type: text/plain; charset="utf-8"
Hello all,
The release candidate of UHD version 3.10.1.1 has been tagged and is
available for testing. There have been no API or ABI breaking changes
necessary since the last release and updated FPGA and firmware images have
been uploaded.
The tag for this release:
https://github.com/EttusResearch/uhd/releases/tag/003_010_001_001_rc1
There have been 62 commits since the last release which can be viewed here:
https://github.com/EttusResearch/uhd/compare/release_003_010_001_000...003_010_001_001_rc1
## 003.010.001.001
- Docs: The protocol for Gen-3 devices is now consistently referred to as
CHDR.
- X300: Fixed EEPROM corruption bug (happened when two processes would
access
find routines on the same device at the same time). Improved
initialization
time. CE clock is now 214 MHz. Fixed channel list generation. Find
routines
now more lenient in case one devices fails (others can still be found
then).
Improve PCIe behaviour. Fix timed commands for non-TwinRX dboards. Improve
AXI Interconnect (faster, improved build timing).
- N230: Use second_addr (like X300).
- C API: Added UHD_VERSION macro. Fixed online rate change.
- Utils: Minor fixes to uhd_images_downloader.
- Build/CMake: Fixed some Py3k build issues. Fixed many compiler warnings.
Allow
to specify package names.
- RFNoC: Fixed sampling rate mismatch error. Noc-Shell uses a non-cascaded
2-clk
FIFO. Increase default FIFO sizes on DUC and DDC blocks.
- UBX: Force on RX driver to eliminate transient.
- Transport code: Fixed memory leak.
- FPGA repository: Merged usrp3_rfnoc and usrp3 directories again. Cleaned
up
superfluous files. Clean separation between Gen-3 and other devices in
usrp3.
Best regards,
Derek
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
------------------------------
Message: 11
Date: Fri, 13 Jan 10:34:08 +
From: do ber <>
To:
Subject: Re: [USRP-users] E312 - ssh connection from USRP to PC
Message-ID:
<>
Content-Type: text/plain; charset="utf-8"
Hi,
I started to use VMWare and solved the problem. It was due to firewall. It
seems that my computer was blocking E312. So I wrote the following command
on my computer's terminal
> sudo ufw allow from 192.168.10.2/24
Now, I can connect from E312 to my computer via ssh.
After the connection I installed the SDK. It did not asked me to where to
install it. By default, it was installed on /usr/local/oecore-x86_64 folder.
When I wrote ls command I got these:
$ ls /usr/local/oecore-x86_64
environment-setup-armv7ahf-vfp-neon-oe-linux-gnueabi
site-config-armv7ahf-vfp-neon-oe-linux-gnueabi
sysroots/
version-armv7ahf-vfp-neon-oe-linux-gnueabi
In the manual, it says that there should be also
usr/
inside that folder. But I don't have. Then ignoring this folder, I wrote
$ source ./environment-setup-armv7ahf-vfp-neon-oe-linux-gnueabi
$ echo $CC # This is just to confirm it worked.
According to manual, I should have gotten
arm-oe-linux-gnueabi-gcc -march=armv7-a -mfloat-abi=hard -mfpu=neon
--sysroot=~/prefix/e300/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi
But I am getting this
arm-oe-linux-gnueabi-gcc -march=armv7-a -mfloat-abi=hard -mfpu=neon
--sysroot=/usr/local/oecore-x86_64/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi
There is e300 folder in the manual, Also I dont have /usr inside the folder
where SDK is installed.
Ignoring all these facts, I continued to other steps but at the end I
couldn't be successful. Do you think my failure was resulted due to these?
Thanks,
Ali
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
------------------------------
Message: 12
Date: Fri, 13 Jan 09:35:28 +
From: Rom?n Rodr?guez P?rez <>
To: "" <>
Subject: Re: [USRP-users] USRP recv timeout, then returns zero samples
Message-ID:
<>
Content-Type: text/plain; charset="utf-8"
I checked rx_samples_to_file. It overflows time to time, but works as expected
without stopping.
I started comparing against my code, and the only difference I could find was
the rx_metadata_t &metadata parameter of the recv function: I was passing a
rx_metadata object which was class member. Now I?m declaring it each time I
call recv.
Now it works. I also get overflows time to time, just as with
rx_samples_to_file example, but the partial return followed by a zero return
has disappeared. This is a problem since I am losing samples? but I guess I
could just set a lower sampling rate, right?
Anyway, when I asked about any other way of knowing about the error code, I was
asking for this rx_metadata object of which I was not aware of.
Best regards
De: USRP-users [mailto:] En nombre de Marcus
D. Leech via USRP-users
Enviado el: jueves, 12 de enero de 16:22
Para:
Asunto: Re: [USRP-users] USRP recv timeout, then returns zero samples
On 01/12/ 10:05 AM, Marcus M?ller via USRP-users wrote:
Hi Rom?n,
thanks! Well, that is one of the better controllers; hm.
Rom?n:
The other thing to try is rx_samples_to_file (with perhaps /dev/null as the
file) to differentiate between the case of broken hardware, and
subtle bug in your code.
On 12.01. 15:07, Rom?n Rodr?guez P?rez via USRP-users wrote:
This is my USB controller:
>lspci | grep USB
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI
Controller (rev 21)
So, isn?t it possible to call uhd_get_last_error anyway, just to get more
information about the error?
Yes. You must not mix C and C++ API. Also, that call just captures info that
you would have gotten as C++ exception. No exception, no error info.
It is recv code header which specified that it returns a minor amount of
samples ?on timeout conditions?. If this is not correct, it should be
corrected to avoid future confusions.
I have edited my code for STREAM_MODE_START_CONTINUOUS usage. Now it seems to
work right for a longer time, but eventually the same ?timeout condition?
appears.
Well, that is really surprising, since the USRP produces 2e6 S/s /
S/buffer= buffer per second. So in 0.1, there really, really should be at
least one new buffer worth of data (or rather, around 999), unless the USB link
broke down (which was my suspicion, and why I asked for the USB controller :)
), or the USRP decided to stop sending packets. Maybe it's worth looking at
`dmesg` and see if there's something suspicious going on.
What else do you do in the loop where you call recv()?
Best regards,
Marcus
Any other idea?
De: USRP-users [mailto:] En nombre de Marcus
M?ller via USRP-users
Enviado el: jueves, 12 de enero de 11:58
Para:
Asunto: Re: [USRP-users] USRP recv timeout, then returns zero samples
Hello Rom?n,
So it hung in the initialization, but didn't hang before? That's surprising,
and should not happen!
Regarding error checking: The calls you fund in uhd/error.h are our "clutches"
to wrap C++ error handling for the C API. You must not mix the C API with your
C++ code!
There's no better way of really checking what's gone wrong here than what you
do, because UHD at that point can't know. However, I'm not 100% sure that 0 <
nSamples < is really a timeout condition; especially in finite
GET_NUM_SAMPS_... it should occur normally, and you should just be able to call
recv() again.
Why are you using STREAM_MODE_NUM_SAMPS_AND_MORE, especially with num=0? I
think that sounds like you might be better off with
STREAM_MODE_START_CONTINUOUS, but I'm sure there's a legit use case here, so
could you please elaborate?
I still concur with Marcus L.'s question: what is the USB controller you use?
With a sampling rate of 2e6, and a recv()-size of , a timeout of 0.1 s
should pretty much never be exceeded during streaming, so there's something
going wrong here!
Best regards,
Marcus
On 12.01. 10:26, Rom?n Rodr?guez P?rez via USRP-users wrote:
I am using USB 3.
I tried upgrading to the UHD version provided at Ettus PPA
(UHD_003.010.001.000-release). Then, it stops working. The only output I get
then is this:
linux; GNU C++ version 5.4.0 ; Boost_; UHD_003.010.001.000-release
-- Detected Device: B205mini
-- Operating over USB 3.
So I guess I will downgrade UHD versions to get it working again.
About the error, how can I check which error is happening? Getting just a
partial return and a 0 return is not a very descriptive way of telling that an
error has happened. I have found uhd_get_last_error function in
include/uhd/error.h, but despite oh having imported uhd/error.h, I get the
compilation error ?undefined reference to uhd_get_last_error? if I just call it
like this:
if(nSamples == 0){
char error_string[255];
uhd_get_last_error(error_string, 255);
std::string exceptionStr = "Error: zero returned
samples from USRP. " + std::string(error_string);
throw std::runtime_error(exceptionStr);
}
Any other suggestion?
De: [mailto:]
Enviado el: mi?rcoles, 11 de enero de 18:32
Para: Rom?n Rodr?guez P?rez <>
CC:
Asunto: Re: [USRP-users] USRP recv timeout, then returns zero samples
When an error occurs that prevents any more samples from being returned, you'll
get a partial return, followed by a 0-length return.
The question is why the error?
What type of USB controller do you have? Can you upgrade to a more recent UHD
release?
On -01-11 11:28, Rom?n Rodr?guez P?rez via USRP-users wrote:
Dear all,
I am watching a weird behavior of rx_streamer::recv function. As explained in
documentation, this function can return:
- The requested number of samples if everything went all right
- Zero samples if an error happened
- A number of read samples less than the requested number on timeout conditions.
I would expect that, in case a timeout condition happens, next time I call recv
it runs smoothly again. But that?s not what happens.
Once the timeout happens, a certain number of samples is returned from recv
function. When this happens, the number of samples returned is always the same
for the same data format configuration: 161 for stream_args_t(fc32, fc32), 431
for stream_args_t(sc16, sc16). In find that quite strange. In fact I considered
that it might be an error code, but as long as I could investigate at Google it
is not the case.
Then, if I call recv once more, zero samples are returned, even if I sleep for
a while.
I?m using USRP B205 mini with UHD_003.009.004-release on Ubuntu 16.04 with the
following configuration:
// Create a usrp device
this->usrp = usrp::multi_usrp::make(string(""));
// Lock mboard clocks
this->usrp->set_clock_source("internal");
// Set the sample rate
this->usrp->set_rx_rate(2e6);
// Set the center frequency
tune_request_t tune_request(.0);
this->usrp->set_rx_freq(tune_request);
// Set the IF filter bandwidth
this->usrp->set_rx_bandwidth(1e6);
this->usrp->set_rx_gain(100.0);
// Allow for some setup time
std::this_thread::sleep_for(std::chrono::seconds(1));
// Create a receive streamer
this->rx_stream = this->usrp->get_rx_stream(stream_args_t("sc16", "sc16"));
// Determine the package size (cannot exceed the maximum established for
given rx_stream settings)
int proposed_buffer_size = 2e3;
unsigned int max_num_samps = this->rx_stream->get_max_num_samps();
this->packageSize = (proposed_buffer_size > max_num_samps) ? max_num_samps
: proposed_buffer_size;
// Setup streaming
stream_cmd_t stream_cmd(stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_MORE);
stream_cmd.num_samps = size_t(0);
stream_cmd.stream_now = true;
stream_cmd.time_spec = time_spec_t();
this->rx_stream->issue_stream_cmd(stream_cmd);
On the other hand, I am reading from USRP with the following code:
unsigned int nSamples = this->rx_stream->recv(&buffer->front(), , md, 0.1,
false);
if(nSamples == 0){
throw std::runtime_error("Error: zero returned samples from
USRP");
}
else if(nSamples < packageSize){
BOOST_LOG_TRIVIAL(info) << format("USRP time %f - Received %d
samples - TIMEOUT!") % usrp->get_time_now().get_real_secs() % nSamples;
}
else{
// Successful wrote the expected number of samples
}
What is happening? Am I missing something?
Thanks in advance
P Please consider the environment before printing this .
________________________________
This message including any attachments may contain confidential information,
according to our Information Security Management System, and intended solely
for a specific individual to whom they are addressed. Any unauthorised copy,
disclosure or distribution of this message is strictly forbidden. If you have
received this transmission in error, please notify the sender immediately and
delete it. Thank you.
________________________________
Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener
informaci?n clasificada por su emisor como confidencial en el marco de su
Sistema de Gesti?n de Seguridad de la Informaci?n siendo para uso exclusivo del
destinatario, quedando prohibida su divulgaci?n copia o distribuci?n a terceros
sin la autorizaci?n expresa del remitente. Si Vd. ha recibido este mensaje
err?neamente, se ruega lo notifique al remitente y proceda a su borrado.
Gracias por su colaboraci?n.
________________________________
Esta mensagem, incluindo qualquer ficheiro anexo, pode conter informa??o
confidencial, de acordo com nosso Sistema de Gest?o de Seguran?a da Informa??o,
sendo para uso exclusivo do destinat?rio e estando proibida a sua divulga??o,
c?pia ou distribui??o a terceiros sem autoriza??o expressa do remetente da
mesma. Se recebeu esta mensagem por engano, por favor avise de imediato o
remetente e apague-a. Obrigado pela sua colabora??o.
________________________________
_______________________________________________
USRP-users mailing list
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
P Please consider the environment before printing this .
________________________________
This message including any attachments may contain confidential information,
according to our Information Security Management System, and intended solely
for a specific individual to whom they are addressed. Any unauthorised copy,
disclosure or distribution of this message is strictly forbidden. If you have
received this transmission in error, please notify the sender immediately and
delete it. Thank you.
________________________________
Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener
informaci?n clasificada por su emisor como confidencial en el marco de su
Sistema de Gesti?n de Seguridad de la Informaci?n siendo para uso exclusivo del
destinatario, quedando prohibida su divulgaci?n copia o distribuci?n a terceros
sin la autorizaci?n expresa del remitente. Si Vd. ha recibido este mensaje
err?neamente, se ruega lo notifique al remitente y proceda a su borrado.
Gracias por su colaboraci?n.
________________________________
Esta mensagem, incluindo qualquer ficheiro anexo, pode conter informa??o
confidencial, de acordo com nosso Sistema de Gest?o de Seguran?a da Informa??o,
sendo para uso exclusivo do destinat?rio e estando proibida a sua divulga??o,
c?pia ou distribui??o a terceiros sem autoriza??o expressa do remetente da
mesma. Se recebeu esta mensagem por engano, por favor avise de imediato o
remetente e apague-a. Obrigado pela sua colabora??o.
________________________________
_______________________________________________
USRP-users mailing list
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
P Please consider the environment before printing this .
________________________________
This message including any attachments may contain confidential information,
according to our Information Security Management System, and intended solely
for a specific individual to whom they are addressed. Any unauthorised copy,
disclosure or distribution of this message is strictly forbidden. If you have
received this transmission in error, please notify the sender immediately and
delete it. Thank you.
________________________________
Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener
informaci?n clasificada por su emisor como confidencial en el marco de su
Sistema de Gesti?n de Seguridad de la Informaci?n siendo para uso exclusivo del
destinatario, quedando prohibida su divulgaci?n copia o distribuci?n a terceros
sin la autorizaci?n expresa del remitente. Si Vd. ha recibido este mensaje
err?neamente, se ruega lo notifique al remitente y proceda a su borrado.
Gracias por su colaboraci?n.
________________________________
Esta mensagem, incluindo qualquer ficheiro anexo, pode conter informa??o
confidencial, de acordo com nosso Sistema de Gest?o de Seguran?a da Informa??o,
sendo para uso exclusivo do destinat?rio e estando proibida a sua divulga??o,
c?pia ou distribui??o a terceiros sem autoriza??o expressa do remetente da
mesma. Se recebeu esta mensagem por engano, por favor avise de imediato o
remetente e apague-a. Obrigado pela sua colabora??o.
________________________________
_______________________________________________
USRP-users mailing list
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
P Please consider the environment before printing this .
______________________
This message including any attachments may contain confidential
information, according to our Information Security Management System,
and intended solely for a specific individual to whom they are addressed.
Any unauthorised copy, disclosure or distribution of this message
is strictly forbidden. If you have received this transmission in error,
please notify the sender immediately and delete it.
______________________
Este mensaje, y en su caso, cualquier fichero anexo al mismo,
puede contener informacion clasificada por su emisor como confidencial
en el marco de su Sistema de Gestion de Seguridad de la
Informacion siendo para uso exclusivo del destinatario, quedando
prohibida su divulgacion copia o distribucion a terceros sin la
autorizacion expresa del remitente. Si Vd. ha recibido este mensaje
erroneamente, se ruega lo notifique al remitente y proceda a su borrado.
Gracias por su colaboracion.
______________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
------------------------------
Message: 13
Date: Fri, 13 Jan 15:15:34 +
From: Andre Puschmann
To: Michael West <>
Cc: "" <>
Subject: Re: [USRP-users] Multiple DSP DDC chains on RF-NoC X310
Message-ID:
<>
Content-Type: text/plain; charset=utf-8
On 13.12. 21:10, Michael West wrote:
> Hi Andre,
>
> Yes. In fact, the latest X310 FPGA image in UHD 3.10.1.0 has 4 DDC
> chains (2 DDC blocks with 2 chains each) by default to support 2 TwinRX
> daughterboards.
Hey,
just picking up this issue again after having upgraded to 3.10.01.01rc1.
I was having a load of problems with 3.10 before so wasn't looking at it
any further.
I am trying to setup a 4 channel receiver with benchmark_rate right now
but having problems to parameterize it properly. With the call below I
see 4 RX channels showing up but there seems to be an issue to receive
from them. Only passing --rx_channels "0,1" works and it receives on 2
channels.
Any hints on this? What would be the correct subdev parameter in this case?
Thanks
Andre
anpu@sdr0:~/src$ benchmark_rate --rx_rate 5e6 --rx_subdev "A:0 B:0 C:0
D:0" --rx_channels "0,1,2"
linux; GNU C++ version 4.8.4; Boost_; UHD_003.010.001.HEAD-0-gd9edfc57
UHD Warning:
Unable to set the thread priority. Performance may be negatively
affected.
Please see the general application notes in the manual for instructions.
EnvironmentError: OSError: error in pthread_setschedparam
Creating the usrp device with: ...
-- X300 initialization sequence...
-- Determining maximum frame size... bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: .3MB/s)
-- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: .6MB/s)
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
Using Device: Single USRP:
Device: X-Series Device
Mboard 0: X310
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: CBX-120 RX
RX Channel: 1
RX DSP: 0
RX Dboard: B
RX Subdev: CBX-120 RX
RX Channel: 2
RX DSP: 0
RX Dboard: B
RX Subdev: CBX-120 RX
RX Channel: 3
RX DSP: 0
RX Dboard: B
RX Subdev: CBX-120 RX
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: CBX-120 TX
TX Channel: 1
TX DSP: 0
TX Dboard: B
TX Subdev: CBX-120 TX
Setting device timestamp to 0...
-- 1) catch time transition at pps edge
-- 2) set times next pps (synchronously)
Error: RuntimeError: On node 0/DDC_1, output port 0 is already connected.
I am also attaching the uhd_usrp_probe output:
$ uhd_usrp_probe
linux; GNU C++ version 4.8.4; Boost_; UHD_003.010.001.HEAD-0-gd9edfc57
-- X300 initialization sequence...
-- Determining maximum frame size... bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: .2MB/s)
-- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: .0MB/s)
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
_____________________________________________________
/
| Device: X-Series Device
| _____________________________________________________
| /
| | Mboard: X310
| | revision: 8
| | revision_compat: 7
| | product:
| | mac-addr0: 00:80:2f:23:48:93
| | mac-addr1: 00:80:2f:23:48:94
| | gateway: 192.168.10.1
| | ip-addr0: 192.168.10.2
| | subnet0: 255.255.255.0
| | ip-addr1: 192.168.20.2
| | subnet1: 255.255.255.0
| | ip-addr2: 192.168.30.2
| | subnet2: 255.255.255.0
| | ip-addr3: 192.168.40.2
| | subnet3: 255.255.255.0
| | serial: 30B
| | FW Version: 5.1
| | FPGA Version: 33.0
| | RFNoC capable: Yes
| |
| | Time sources: internal, external, gpsdo
| | Clock sources: internal, external, gpsdo
| | Sensors: ref_locked
| | _____________________________________________________
| | /
| | | RX Dboard: A
| | | ID: CBX-120 (0x)
| | | Serial: 30B
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: CBX-120 RX
| | | | Antennas: TX/RX, RX2, CAL
| | | | Sensors: lo_locked
| | | | Freq range: .000 to .000 MHz
| | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
| | | | Bandwidth range: .0 to .0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: A
| | | | Name: ads62p48
| | | | Gain range digital: 0.0 to 6.0 step 0.5 dB
| | _____________________________________________________
| | /
| | | RX Dboard: B
| | | ID: CBX-120 (0x)
| | | Serial: 30B29A6
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: CBX-120 RX
| | | | Antennas: TX/RX, RX2, CAL
| | | | Sensors: lo_locked
| | | | Freq range: .000 to .000 MHz
| | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
| | | | Bandwidth range: .0 to .0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: B
| | | | Name: ads62p48
| | | | Gain range digital: 0.0 to 6.0 step 0.5 dB
| | _____________________________________________________
| | /
| | | TX Dboard: A
| | | ID: CBX-120 (0x)
| | | Serial: 30B
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: CBX-120 TX
| | | | Antennas: TX/RX, CAL
| | | | Sensors: lo_locked
| | | | Freq range: .000 to .000 MHz
| | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
| | | | Bandwidth range: .0 to .0 step 0.0 Hz
| | | | Connection Type: QI
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: A
| | | | Name: ad
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX Dboard: B
| | | ID: CBX-120 (0x)
| | | Serial: 30B29A6
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: CBX-120 TX
| | | | Antennas: TX/RX, CAL
| | | | Sensors: lo_locked
| | | | Freq range: .000 to .000 MHz
| | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
| | | | Bandwidth range: .0 to .0 step 0.0 Hz
| | | | Connection Type: QI
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: B
| | | | Name: ad
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | RFNoC blocks on this device:
| | |
| | | * DmaFIFO_0
| | | * Radio_0
| | | * Radio_1
| | | * DDC_0
| | | * DDC_1
| | | * DUC_0
| | | * DUC_1
>
> Regards,
> Michael
>
> On Tue, Dec 13, at 8:35 AM, Andre Puschmann via USRP-users
> < > wrote:
>
> Hi guys,
>
> we are currently thinking about transferring an existing 4 channel
> receiver design using 2x N210 connected via a MIMO cable over to a X310.
>
> The default FPGA image of the X310 (at least in UHD 3.9.4) only has two
> DDC chains. With RF-NoC, would it be possible to easily expose 4 chains
> (two per daughterboard) via UHD?
>
> Cheers
> Andre
>
> _______________________________________________
> USRP-users mailing list
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
------------------------------
Message: 14
Date: Fri, 13 Jan 07:28:04 -
From: Eric Schneider <>
To:
Subject: Re: [USRP-users] RFNoC DmaFifo -> 2x DUC -> AddSub -> Radio,
sanity check
Message-ID:
Content-Type: text/plain; charset=windows-
On 01/12/ 06:03 PM, Martin Braun via USRP-users wrote:
> On 01/12/ 12:49 PM, Eric Schneider via USRP-users wrote:
Thanks Martin!
>> I am using the UHD API directly (e.g. get_block_ctrl, create_graph,
>> connect, get_tx_stream, ...), along with a bitstream containing the
>> required blocks.
>>
>> The connection is:
>> streamer/block_id0 -> fifo_blk:0 -> duc0_blk:0 -> addsub:0 -> radio:0
>> streamer/block_id1 -> fifo_blk:1 -> duc1_blk:0 -> addsub:1
> The problem here is that the output of each DUC is 200 Msps, and they're
> both going to the AddSub. If you move the AddSub *before* the DUC, you
> should be good. If you're not engaging the CORDIC (or have both set to
> the same value), that'll even give you the same signal thanks to the
> linear property of the filters and additions involved.
>
> -- M
Yes, I forgot that the ports of a block share bandwidth. Since I do
want to use the CORDIC, it seems the best option is a custom block that
sums the output of individual DUCs internally and outputs a single 200M
stream to the radio.
The idea here is to transmit several simultaneous channels spread around
a sizable frequency range (~50M). I suppose I could try x2 DUC
(intermediate rate) -> Add -> DUC -> Radio... Ultimately I'm aiming for
3-4 independent channels, so that starts making things pretty crowded...
Thanks again.
E.
------------------------------
Message: 15
Date: Fri, 13 Jan 15:38:05 +
From: Julian Arnold <>
To:
Cc: usrp-users <>
Subject: Re: [USRP-users] Bandwidth vs Sampling rate
Message-ID: <>
Content-Type: text/plain; charset=utf-8
Hey,
the corresponding property tree entry should be something like:
/mboards/0/dboards/A/rx_frontends/0/bandwidth/value
depending on your USRP model.
Correct me if I'm wrong but I think all mboards create this entry so
that it can at least be read.
So you would need to check if the mboard subscribes to changes in the
property tree.
The tvrx2 for example has the following line in
uhd/host/lib/usrp/dboard/db_tvrx2.cpp
this->get_rx_subtree()->create("bandwidth/value").coerce(boost::bind(&tvrx2::set_bandwidth,
this, _1)).set(_bandwidth);
whereas, for example, the WBX
(uhd/host/lib/usrp/dboard/db_wbx_common.cpp) only has:
this->get_tx_subtree()->create("bandwidth/value").set(2*bw);
so no ".coerce()" here.
Cheers,
Julian
On 01/12/ 07:42 PM, Marcus D. Leech via USRP-users wrote:
>
> Off the top of my head, TVRX2 and DBS_RX2.
>
> There'd be an item in the property tree for the card, but I don't have
> access to the code right this minute.
>
>
>
>
>
>
>
> On -01-12 13:20, wrote:
>
>> Quick followups:
>>
>> Which cards support analog bandwidth specification?
>>
>> Is there something on the hardware I can query to determine if a card
>> supports analog bandwidth specification so i could take other actions
>> if not present?
>>
>> When a card doesnt support analog bandwidth parameter, is bandwidth
>> effectively sample rate or something close to that?
>>
>> Thanks,
>>
>> ------------------------------------------------------------------------
>> *From: *"tilla--- via USRP-users" <>
>> *To: *"Marcus D. Leech" <>
>> *Cc: *"usrp-users" <>
>> *Sent: *Thursday, January 12, 12:39:39 PM
>> *Subject: *Re: [USRP-users] Bandwidth vs Sampling rate
>>
>> Awesome, thanks so much for the info :)
>>
>> ------------------------------------------------------------------------
>> *From: *"Marcus D. Leech via USRP-users" <>
>> *To: *"usrp-users" <>
>> *Sent: *Thursday, January 12, 11:18:37 AM
>> *Subject: *Re: [USRP-users] Bandwidth vs Sampling rate
>>
>> On 01/12/ 11:14 AM, tilla--- via USRP-users wrote:
>>>
>>> DOH,
>>>
>>> WBX-120
>> Yup. Not configurable.
>>
>> Further, the out-of-band attenuation depth is not infinite, so even
>> with settable bandwidth, I'd expect that strong adjacent signals would
>> still be easily detectable. The point of being able to set
>> bandwidth is to reduce the amplitude of strong adjacent signals that may
>> otherwise cause a loss of dynamic range.
>>
>>
>>> ------------------------------------------------------------------------
>>> *From: *"Marcus M?ller via USRP-users" <>
>>> *To: *"usrp-users" <>
>>> *Sent: *Thursday, January 12, 10:46:48 AM
>>> *Subject: *Re: [USRP-users] Bandwidth vs Sampling rate
>>>
>>>
>>> Hi,
>>>
>>> not all devices even support the analog bandwidth setting. Which
>>> USRP/daughterboard (if applicable) are we talking about?
>>>
>>> Best regards,
>>> Marcus
>>>
>>> On 12.01. 16:39, tilla--- via USRP-users wrote:
>>>> Peeps,
>>>>
>>>> I was running an experiment and I stumbled onto something that did
>>>> not make sense to me, but I am far from an expert.
>>>>
>>>> My input signal is a tone from a signal generator playing out on 1
>>>> MHz boundaries over a 10 MHz span dwelling for 1 second.
>>>>
>>>> So, at t=0 tone is at 900 MHz, t=1 901 MHz, t=2 902 MHz, etc.
>>>>
>>>> I perform captures using rx samples to file app.
>>>>
>>>> one capture is center freq = 905, bandwidth = 2 MHz, sample rate =
>>>> 2MSA/sec
>>>>
>>>> This data set looks exactly as expected, I only see tones at
>>>> 904,905, and 906... Nothing fishy there...
>>>>
>>>> My next capture is at center freq = 905, bandwidth = 2 MHz, sample
>>>> rate = 10 MSA/sec.
>>>>
>>>> I see ALL tones over the course of 10 seconds...
>>>>
>>>> I thought the bandwidth parameter was at the analog input, so my
>>>> thought was I should still only see 904, 905, and 906 and I should
>>>> not see anything outside of the center freq / bandwidth range.
>>>>
>>>> Am I missing something?
>>>>
>>>> Thanks,
>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>>
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>>
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>>
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
> _______________________________________________
> USRP-users mailing list
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
Julian Arnold, M.Sc.
Institute for Networked Systems
RWTH Aachen University
Kackertstrasse 9
Aachen
Germany
------------------------------
Message: 16
Date: Fri, 13 Jan 08:58:19 -
From: Michael West <>
To: Andre Puschmann
Cc: "" <>
Subject: Re: [USRP-users] Multiple DSP DDC chains on RF-NoC X310
Message-ID:
<>
Content-Type: text/plain; charset="utf-8"
Hi Andre,
What happens if you leave out the subdev spec altogether (i.e.
benchmark_rate --rx_rate 5e6 --channels 0,1,2,3)?
Regards,
Michael
On Fri, Jan 13, at 6:15 AM, Andre Puschmann <
> wrote:
> On 13.12. 21:10, Michael West wrote:
> > Hi Andre,
> >
> > Yes. In fact, the latest X310 FPGA image in UHD 3.10.1.0 has 4 DDC
> > chains (2 DDC blocks with 2 chains each) by default to support 2 TwinRX
> > daughterboards.
>
> Hey,
>
> just picking up this issue again after having upgraded to 3.10.01.01rc1.
> I was having a load of problems with 3.10 before so wasn't looking at it
> any further.
>
> I am trying to setup a 4 channel receiver with benchmark_rate right now
> but having problems to parameterize it properly. With the call below I
> see 4 RX channels showing up but there seems to be an issue to receive
> from them. Only passing --rx_channels "0,1" works and it receives on 2
> channels.
>
> Any hints on this? What would be the correct subdev parameter in this case?
>
> Thanks
> Andre
>
>
>
> anpu@sdr0:~/src$ benchmark_rate --rx_rate 5e6 --rx_subdev "A:0 B:0 C:0
> D:0" --rx_channels "0,1,2"
> linux; GNU C++ version 4.8.4; Boost_; UHD_003.010.001.HEAD-0-
> gd9edfc57
>
>
> UHD Warning:
> Unable to set the thread priority. Performance may be negatively
> affected.
> Please see the general application notes in the manual for
> instructions.
> EnvironmentError: OSError: error in pthread_setschedparam
>
> Creating the usrp device with: ...
> -- X300 initialization sequence...
> -- Determining maximum frame size... bytes.
> -- Setup basic communication...
> -- Loading values from EEPROM...
> -- Setup RF frontend clocking...
> -- Radio 1x clock:200
> -- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: .3MB/s)
> -- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: .6MB/s)
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> -- Performing timer loopback test... pass
> -- Performing timer loopback test... pass
> Using Device: Single USRP:
> Device: X-Series Device
> Mboard 0: X310
> RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: CBX-120 RX
> RX Channel: 1
> RX DSP: 0
> RX Dboard: B
> RX Subdev: CBX-120 RX
> RX Channel: 2
> RX DSP: 0
> RX Dboard: B
> RX Subdev: CBX-120 RX
> RX Channel: 3
> RX DSP: 0
> RX Dboard: B
> RX Subdev: CBX-120 RX
> TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: CBX-120 TX
> TX Channel: 1
> TX DSP: 0
> TX Dboard: B
> TX Subdev: CBX-120 TX
>
> Setting device timestamp to 0...
> -- 1) catch time transition at pps edge
> -- 2) set times next pps (synchronously)
> Error: RuntimeError: On node 0/DDC_1, output port 0 is already connected.
>
>
>
> I am also attaching the uhd_usrp_probe output:
>
> $ uhd_usrp_probe
> linux; GNU C++ version 4.8.4; Boost_; UHD_003.010.001.HEAD-0-
> gd9edfc57
>
> -- X300 initialization sequence...
> -- Determining maximum frame size... bytes.
> -- Setup basic communication...
> -- Loading values from EEPROM...
> -- Setup RF frontend clocking...
> -- Radio 1x clock:200
> -- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: .2MB/s)
> -- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: .0MB/s)
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> -- Performing timer loopback test... pass
> -- Performing timer loopback test... pass
> _____________________________________________________
> /
> | Device: X-Series Device
> | _____________________________________________________
> | /
> | | Mboard: X310
> | | revision: 8
> | | revision_compat: 7
> | | product:
> | | mac-addr0: 00:80:2f:23:48:93
> | | mac-addr1: 00:80:2f:23:48:94
> | | gateway: 192.168.10.1
> | | ip-addr0: 192.168.10.2
> | | subnet0: 255.255.255.0
> | | ip-addr1: 192.168.20.2
> | | subnet1: 255.255.255.0
> | | ip-addr2: 192.168.30.2
> | | subnet2: 255.255.255.0
> | | ip-addr3: 192.168.40.2
> | | subnet3: 255.255.255.0
> | | serial: 30B
> | | FW Version: 5.1
> | | FPGA Version: 33.0
> | | RFNoC capable: Yes
> | |
> | | Time sources: internal, external, gpsdo
> | | Clock sources: internal, external, gpsdo
> | | Sensors: ref_locked
> | | _____________________________________________________
> | | /
> | | | RX Dboard: A
> | | | ID: CBX-120 (0x)
> | | | Serial: 30B
> | | | _____________________________________________________
> | | | /
> | | | | RX Frontend: 0
> | | | | Name: CBX-120 RX
> | | | | Antennas: TX/RX, RX2, CAL
> | | | | Sensors: lo_locked
> | | | | Freq range: .000 to .000 MHz
> | | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
> | | | | Bandwidth range: .0 to .0 step 0.0 Hz
> | | | | Connection Type: IQ
> | | | | Uses LO offset: No
> | | | _____________________________________________________
> | | | /
> | | | | RX Codec: A
> | | | | Name: ads62p48
> | | | | Gain range digital: 0.0 to 6.0 step 0.5 dB
> | | _____________________________________________________
> | | /
> | | | RX Dboard: B
> | | | ID: CBX-120 (0x)
> | | | Serial: 30B29A6
> | | | _____________________________________________________
> | | | /
> | | | | RX Frontend: 0
> | | | | Name: CBX-120 RX
> | | | | Antennas: TX/RX, RX2, CAL
> | | | | Sensors: lo_locked
> | | | | Freq range: .000 to .000 MHz
> | | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
> | | | | Bandwidth range: .0 to .0 step 0.0 Hz
> | | | | Connection Type: IQ
> | | | | Uses LO offset: No
> | | | _____________________________________________________
> | | | /
> | | | | RX Codec: B
> | | | | Name: ads62p48
> | | | | Gain range digital: 0.0 to 6.0 step 0.5 dB
> | | _____________________________________________________
> | | /
> | | | TX Dboard: A
> | | | ID: CBX-120 (0x)
> | | | Serial: 30B
> | | | _____________________________________________________
> | | | /
> | | | | TX Frontend: 0
> | | | | Name: CBX-120 TX
> | | | | Antennas: TX/RX, CAL
> | | | | Sensors: lo_locked
> | | | | Freq range: .000 to .000 MHz
> | | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
> | | | | Bandwidth range: .0 to .0 step 0.0 Hz
> | | | | Connection Type: QI
> | | | | Uses LO offset: No
> | | | _____________________________________________________
> | | | /
> | | | | TX Codec: A
> | | | | Name: ad
> | | | | Gain Elements: None
> | | _____________________________________________________
> | | /
> | | | TX Dboard: B
> | | | ID: CBX-120 (0x)
> | | | Serial: 30B29A6
> | | | _____________________________________________________
> | | | /
> | | | | TX Frontend: 0
> | | | | Name: CBX-120 TX
> | | | | Antennas: TX/RX, CAL
> | | | | Sensors: lo_locked
> | | | | Freq range: .000 to .000 MHz
> | | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
> | | | | Bandwidth range: .0 to .0 step 0.0 Hz
> | | | | Connection Type: QI
> | | | | Uses LO offset: No
> | | | _____________________________________________________
> | | | /
> | | | | TX Codec: B
> | | | | Name: ad
> | | | | Gain Elements: None
> | | _____________________________________________________
> | | /
> | | | RFNoC blocks on this device:
> | | |
> | | | * DmaFIFO_0
> | | | * Radio_0
> | | | * Radio_1
> | | | * DDC_0
> | | | * DDC_1
> | | | * DUC_0
> | | | * DUC_1
>
>
>
>
> >
> > Regards,
> > Michael
> >
> > On Tue, Dec 13, at 8:35 AM, Andre Puschmann via USRP-users
> > < > wrote:
> >
> > Hi guys,
> >
> > we are currently thinking about transferring an existing 4 channel
> > receiver design using 2x N210 connected via a MIMO cable over to a
> X310.
> >
> > The default FPGA image of the X310 (at least in UHD 3.9.4) only has
> two
> > DDC chains. With RF-NoC, would it be possible to easily expose 4
> chains
> > (two per daughterboard) via UHD?
> >
> > Cheers
> > Andre
> >
> > _______________________________________________
> > USRP-users mailing list
> >
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 77, Issue 10
******************************************
Comments