Re: [USRP-users] TwinRx Channel Alignment

[Marcus D. Leech via USRP-users]

On 03/15/2018 12:27 AM, Zhongyuan Zhao wrote:

Hi Marcus and Derek,

Thank you for the reply. The RFNoC and synchronization are very 
helpful. I have an additional question regarding to the timestaming in 
GNURadio.


In the VITA and CHDR format of RFNoC, there are timestamp and stream 
ID, what could I do to keep the timestamp and stream ID via a file 
sink of GNU Radio? or make 2 streams aligned within GNU Radio?
I know that there are metadata in file sink, but I am not sure if the 
metadata timestamp is from the RFNoC or the host (at the moment it 
write IQ data to file).

Is there any application notes regarding to this?

Thanks again!

Zhongyuan Zhao

PhD Candidate,
Department of Computer Science & Engineering,
University of Nebraska-Lincoln
Office Hour: WF 9:30-10:00am, Avery Hall 12,
Suite 117, Schorr Center,
Lincoln, Nebraska 68588-0115


https://gnuradio.org/doc/doxygen/page_metadata.html

They originate in the hardware, NOT the host.

If the hardware source provides timestamps, then they are carried in the 
tag stream throughout the flow-graph.



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] TwinRx Channel Alignment

[Zhongyuan Zhao via USRP-users]

Hi Marcus and Derek,

Thank you for the reply. The RFNoC and synchronization are very helpful. I
have an additional question regarding to the timestaming in GNURadio.

In the VITA and CHDR format of RFNoC, there are timestamp and stream ID,
what could I do to keep the timestamp and stream ID via a file sink of GNU
Radio? or make 2 streams aligned within GNU Radio?
I know that there are metadata in file sink, but I am not sure if the
metadata timestamp is from the RFNoC or the host (at the moment it write IQ
data to file).
Is there any application notes regarding to this?

Thanks again!

Zhongyuan Zhao

PhD Candidate,
Department of Computer Science & Engineering,
University of Nebraska-Lincoln
Office Hour: WF 9:30-10:00am, Avery Hall 12,
Suite 117, Schorr Center,
Lincoln, Nebraska 68588-0115


On Fri, Mar 9, 2018 at 1:15 PM, Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 03/09/2018 03:23 AM, Derek Kozel via USRP-users wrote:
>
> Hello,
>
> Yes, that is the purpose of the set_time_next_pps function. When combined
> with common 10 MHz and 1 PPS references this allows for stable time
> synchronization of 1 sample clock cycle, 5 ns at 200 MS/s. I recommend
> reading through the examples which show using all these commands and others
> related to streaming multiple channels.
> https://github.com/EttusResearch/uhd/tree/maint/host/examples
>
> The manual also covers these topics.
> http://files.ettus.com/manual/page_sync.html
>
> Derek
>
> There's also, of course:
>
> https://kb.ettus.com/Synchronization_and_MIMO_Capability_with_USRP_Devices
>
>
>
>
> On Thu, Mar 8, 2018 at 11:02 PM, Zhongyuan Zhao 
> wrote:
>
>> Hi Derek,
>>
>> If USRPs A & B clocked by an Octoclock, are connected to the same host, I
>> want calibrate the counter values from USRPs A and B. How can I do it? Is
>> this function supported by UHD? If not, could I update the counter values
>> in the FPGA Radio blocks? or I can only keep an calibration table of
>> counter value offsets on my host?
>>
>> Thanks!
>>
>> Zhongyuan Zhao
>>
>> PhD Candidate,
>> Department of Computer Science & Engineering,
>> University of Nebraska-Lincoln
>> Office Hour: WF 9:30-10:00am, Avery Hall 12,
>> Suite 117, Schorr Center,
>> Lincoln, Nebraska 68588-0115
>>
>>
>> On Thu, Mar 8, 2018 at 4:42 PM, Derek Kozel 
>> wrote:
>>
>>> Hello,
>>>
>>> The same commands are available in the GNU Radio environment and I
>>> believe are exposed in the pre-release Python API branch.
>>>
>>> The FPGA radio blocks contain a timekeeper which is a counter which
>>> increments at the same rate as the master_clock_rate which is the effective
>>> ADC/DAC sample rate. This allows for commands to be executed with very fine
>>> temporal precision.
>>>
>>> Regards,
>>> Derek
>>>
>>> On Thu, Mar 8, 2018 at 10:12 PM, Zhongyuan Zhao 
>>> wrote:
>>>
 Hi Derek,

 I have two questions about the rx timed samples example,
 1. is there python version for timed command?
 2. Is the time stamp from the clock on USRP or on the host?

 Thanks

 Zhongyuan Zhao

 PhD Candidate,
 Department of Computer Science & Engineering,
 University of Nebraska-Lincoln
 Office Hour: WF 9:30-10:00am, Avery Hall 12,
 Suite 117, Schorr Center,
 Lincoln, Nebraska 68588-0115


 On Thu, Mar 8, 2018 at 3:27 PM, Derek Kozel via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> The stream command object has a field for a time spec of when to start
> streaming and a boolean flag for whether to make use of that time spec.
> http://files.ettus.com/manual/structuhd_1_1stream__cmd__t.html
>
> Here we can see it used in an rx example.
> https://github.com/EttusResearch/uhd/blob/maint/host/example
> s/rx_timed_samples.cpp#L92-L93
>
> Usually it is most practical to make a call to get_time_now() and then
> add an offset from that time which is returned. The minimum offset would 
> be
> the roundtrip command time, usually a few milliseconds.
>
> Regards,
> Derek
>
> On Thu, Mar 8, 2018 at 9:03 PM, Andrew Thommesen <
> andrewjoh...@outlook.com> wrote:
>
>> No, how do you do that?
>>
>>
>> Sent from Outlook 
>> --
>> *From:* Derek Kozel 
>> *Sent:* 08 March 2018 20:58:38
>> *To:* Andrew Thommesen
>> *Cc:* usrp-users
>> *Subject:* Re: [USRP-users] TwinRx Channel Alignment
>>
>> Hello Andrew,
>>
>> Are you starting the streaming with timed commands?
>>
>> Regards,
>> Derek
>>
>> On Mar 8, 2018 7:32 PM, "Andrew Thommesen via USRP-users" <
>> usrp-users@lists.ettus.com> wrote:
>>
>> Hi all,
>>
>>
>> I have an x310 with a twinRx and would like to process coherent,
>> time aligned data within the FPGA. However, the data is 

Re: [USRP-users] UBX vs SBX

[Дмитрий via USRP-users]

I found that UBX has a bit less of spurs. I assume it is because the whole 
daughterboard is covered by heatsink panel that plays a role of EMI shield 
while SBX is open.


thanks,
Dmitry


From: Hojoon Yang via USRP-users
Sent: 14 марта 2018 г. 9:23
To: usrp-users@lists.ettus.com
Subject: [USRP-users] UBX vs SBX

Hi.
 
I have two USRP X310s and wonder which board between SBX and UBX would be the 
suitable for me.
 
I'm gonna buy four daughterboards to use it as 2x2 MIMO. One USRP X310 for Tx, 
the other USRP for Rx.
 
My target frequency is from 1.8GHz to 2.8GHz. According to datasheet, Both UBX 
and SBX work on the target frequency.

I saw the schematic of both SBX and UBX and figured it out that UBX has a 
significantly different structure from SBX.
 
I wonder, which board performs better "in the target frequency" in terms of 
MIMO performance(i.e. phase align accuracy, noise level, etc..).
 
I don't have price issue. If the UBX performs better or same as the SBX in 
target frequency(1.8GHz~2.8GHz), I would like to buy UBX since it has more wide 
frequency range.
 
Regards,


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP B210 issues with sample rate and Tx bandwidth

[Marcus D. Leech via USRP-users]

On 03/14/2018 05:36 AM, Lucas Val Terrón via USRP-users wrote:

Hi all,

Working with the example "tx_waveforms.cpp" provided in the uhd, i 
found myself with two problems trying to set the sample rate and the 
tx bandwith of the USRP B210 (UHD_3.11.0).


./tx_waveforms --rate 6144 --freq 235000 --wave-type SINE 
--wave-freq 100 --gain 40 --bw 5000 (with sc16 format)



1. The first thing I realized is that despite the sample rate was the 
maximum available, the bandwidth is limited to 40 MHz.  Furthermore, 
the following warning appears:


[WARNING] [AD936X] Selected Tx bandwidth (61.44 MHz) exceeds

So, it seems that somewhere inside the code tries to set the Tx 
bandwith to the same value as the sample rate...



./tx_waveforms --rate 5 --freq 235000 --wave-type SINE 
--wave-freq 100 --gain 40 --bw 5000 (with sc16 format)


2. With sample rates greater tham 40 MHz, I get continuous underflows 
in transmission. Does anybody knows what's happening? Is there any 
limit in the maximum sample rate transmitting only in one channel?



Thanks in advance!!
Lucas


Underflows happen because your computer isn't keeping up with the 
radio.  The radio is perfectly capable of taking in the specified 
sample-rate, but
  the computer has to be able to "keep up".   You might try playing 
with the USB buffering:


https://files.ettus.com/manual/page_transport.html#transport_usb_params

I regards to the bandwidth setting, it's generally a poor idea to have 
the analog bandwidth exceed 80% of the sample rate.


If you could share the exact invocation you used, and the complete error 
message/log output, that would be helpful.



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B200 Mini Overflow

[Marcus D. Leech via USRP-users]

On 03/14/2018 02:45 AM, Brandon Piner via USRP-users wrote:


I have found that it starts happening with low sample rates around 2 
Msps and then stops overflowing. It happens all the time with higher 
sample rates.


I tried to rule out my code from this by having it run in a thread 
that just reads from the device and then discards the data afterwards.


What happens with one of the example apps, like rx_samples_to_file, 
writing to /dev/null ?





On 2018-03-08 17:42, Marcus D. Leech via USRP-users wrote:

On 03/08/2018 08:33 AM, Brandon Piner via USRP-users wrote:

To whom it may concern

I have been implementing a transmitter and receiver application 
using the B200 mini with UHD-3.9.7. The transmitter seems to be 
working well. The strange behavior seems to be happening when I try 
using the receiver.


 1. The predominant issue I am having is that I keep getting an
overflow after X samples were read. The specific number of
samples ("X") before an overflow seems to be linked to the
samples per packet "spp" or the "receive_frame_size" parameter.
If I leave the "spp" and "receive_frame_size" as default then it
seems that the max samples per buffer per packet is 2044. So
each ->recv of samples returns 2044 samples. I can call ->recv
30 times and 2044 samples are returned. On the 31st time calling
->recv I only 389 samples along with some timestamp mismatch of
approx 65 uS. The 32nd read flags an overflow and 0 samples are
read. This "cycle" reads 61709 samples in total. Seems like it
is filling a flat buffer and not a circular buffer. Is this the
expected behavior of the device? How can I get it to not overflow?

Is the above sample-rate linked, or does it happen regardless? If it 
happens regardless, then I suspect that you have an 
off-by-some-amount error
  somewhere in your code that is causing buffers to become 
exhausted--you're not vacuuming out all available data.




1.



 2. The other issue is with starting up a receive stream. I
documented it here
https://github.com/EttusResearch/uhd/issues/68#issuecomment-369596794
. Not sure if anyone can assist with that. My current workaround
is to destroy the entire sptr to the USRP and create a new
pointer at the time that I start the receive stream.

Hope someone can provide me with some insight!

Kind regards

Brandon





Disclaimer: http://www.peralex.com/disclaimer.html



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com




___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com






Disclaimer: http://www.peralex.com/disclaimer.html



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] USRP B210 issues with sample rate and Tx bandwidth

[Lucas Val Terrón via USRP-users]

Hi all,

Working with the example "tx_waveforms.cpp" provided in the uhd, i found
myself with two problems trying to set the sample rate and the tx bandwith
of the USRP B210 (UHD_3.11.0).

./tx_waveforms --rate 6144 --freq 235000 --wave-type SINE
--wave-freq 100 --gain 40 --bw 5000 (with sc16 format)


1. The first thing I realized is that despite the sample rate was the
maximum available, the bandwidth is limited to 40 MHz. Furthermore, the
following warning appears:

[WARNING] [AD936X] Selected Tx bandwidth (61.44 MHz) exceeds

So, it seems that somewhere inside the code tries to set the Tx bandwith to
the same value as the sample rate...


./tx_waveforms --rate 5 --freq 235000 --wave-type SINE
--wave-freq 100 --gain 40 --bw 5000 (with sc16 format)

2. With sample rates greater tham 40 MHz, I get continuous underflows in
transmission. Does anybody knows what's happening? Is there any limit in
the maximum sample rate transmitting only in one channel?


Thanks in advance!!
Lucas


--
Laptop specifications
- Processor: 8x Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz
- Operating System: Ubuntu 16.04.2 LTS
- Memory: 8192 MB DDR4-2400MH
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] UBX vs SBX

[Kyeong Su Shin via USRP-users]

Hello Hojoon Yang,


Both SBX and UBX will work fine (*Assuming X3x0 series only, no N2x0 or older 
boards).

You can align the phase of the UBX and SBX boards by using the timed commands ( 
https://kb.ettus.com/Synchronization_and_MIMO_Capability_with_USRP_Devices ) , 
but you will have to correct (manually calibrate) a constant phase offset 
between the channels. Also, the accuracy of the alignment over time is not 
guaranteed by Ettus Research. ("Periodic calibration will be necessary for 
phase-coherent applications" - src: 
https://files.ettus.com/manual/page_sync.html ). So, I recommend against 
relying on the phase alignment accuracy of the daughterboards.


Other RF performance data (noise figure, etc) is available at: 
http://files.ettus.com/performance_data/ . Please note that you can'not' always 
use the max receive gain settings, due to the possible nonlinearity issues.


Personally, I like the UBX boards better than the SBX boards. But both are 
generally suitable for such experiments.


Regards,

Kyeong Su Shin


보낸 사람: Hojoon Yang via USRP-users  대신 USRP-users 

보낸 날짜: 2018년 3월 14일 수요일 오후 3:20:56
받는 사람: usrp-users@lists.ettus.com
제목: [USRP-users] UBX vs SBX


Hi.



I have two USRP X310s and wonder which board between SBX and UBX would be the 
suitable for me.



I'm gonna buy four daughterboards to use it as 2x2 MIMO. One USRP X310 for Tx, 
the other USRP for Rx.



My target frequency is from 1.8GHz to 2.8GHz. According to datasheet, Both UBX 
and SBX work on the target frequency.


I saw the schematic of both SBX and UBX and figured it out that UBX has a 
significantly different structure from SBX.



I wonder, which board performs better "in the target frequency" in terms of 
MIMO performance(i.e. phase align accuracy, noise level, etc..).



I don't have price issue. If the UBX performs better or same as the SBX in 
target frequency(1.8GHz~2.8GHz), I would like to buy UBX since it has more wide 
frequency range.



Regards,


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Reminder -- GNU Radio and RFNoC Workshops in Columbia, Maryland, USA

[Neel Pandeya via USRP-users]

==
* Reminder *
  (there is still space available)

==
Ettus Research will be running a series of free, hands-on,
technical workshops in Washington D.C. area, and you are
welcome to attend!

Tuesday March 20   -- GNU Radio Workshop

Wednesday March 21 -- RFNoC Workshop

Thursday March 22  -- GNU Radio Workshop

Friday March 23-- RFNoC Workshop

Each workshop is being run twice, in two identical sessions.

All workshops will run from 09:00 to 17:00.
Breakfast and set-up will begin at 08:30.

All workshops will be held at the address listed below.

National Instruments
7125 Thomas Edison Drive, Suite 200
Columbia, Maryland, 21046, USA

==
Workshop Description:

Full Title:
Introduction to the USRP, UHD, and GNU Radio (Open-Source Toolchain)

Abstract:
This workshop will provide a thorough and practical introduction to
the USRP hardware and the open-source software toolchain (UHD and
GNU Radio). We will examine the hardware and architecture of the
entire USRP family of software-defined radios. We will discuss topics
such as how to get started using a new USRP device, how to install and
configure the open-source software toolchain, programming the USRP
using the UHD API from C++, using GNU Radio with the USRP and creating
and running flowgraphs, using GNU Radio from both GRC and Python, and
various debugging techniques. Several exercises will be performed,
such as implementing an FM transmitter and receiver. Various
demonstrations of wireless systems will be shown. A discussion of the
embedded E310 radio and using embedded SDR will be included. Several
other open-source tools will be discussed, such as GQRX, Fosphor,
Inspectrum, and several Out-of-Tree (OOT) modules. A discussion of
cellular applications, including OpenBTS and LTE stacks, as well as
GPS/GNSS applications will be presented. Several other miscellaneous
topics such as 10 Gigabit Ethernet networking, host system performance
tuning, X300/X310 device recovery, and some best practices will be
discussed. Attendees should come away with a solid foundation and
practical understanding of how to configure, program, and use the USRP
to implement a wide range range of wireless systems.

==
Workshop Description:

Full Title:
FPGA Programming on the USRP with the RFNoC Framework

Abstract:
Ettus Research's RFNoC (RF Network-on-Chip) software framework is
designed to decrease the development time for experienced FPGA
engineers seeking to integrate IP into the USRP FPGA signal
processing chain. RFNoC is the framework for USRP devices that use
Xilinx 7-series FPGAs (E310, E312, X300, X310). RFNoC is built around
a packetized network infrastructure in the FPGA that handles the
transport of control and sample data between the host CPU and the
radio. Users target their custom algorithms to the FPGA in the form
of Computation Engines (CE), which are processing blocks that attach
to this network. CEs act as independent nodes on the network that can
receive and transmit data to any other node (e.g., another CE, the
radio block, or the host CPU).  Users can create modular,
FPGA-accelerated SDR applications by chaining CEs into a flow graph.
RFNoC is supported in UHD and GNU Radio. In this workshop, we will
present an interactive hands-on tutorial on RFNoC, including a
discussion on its design and capabilities, demonstrations of several
existing examples, and a walk-through on implementing a user-defined
CE and integrating the CE into GNU Radio.

==
Details and Logistics:

* The workshops are free, technical, and hands-on.

* Each day, coffee/donuts/bagels will be provided at 08:30,
as well as lunch at around 12:00, and an afternoon snack.

* In both workshops, both laptop computers and USRP radios will be
provided for use. Attendees do not need to bring or prepare anything.

* For the USRP/GNU Radio Workshop, attendees should have some previous
experience with Linux and using the Linux command line, and basic
familiarity with a programming language such as C, C++, or Python,
and basic fundamental concepts in DSP and RF. For the RFNoC Workshop,
attendees should also have some basic familiarity with Verilog.
Extensive or deep experience with these topics is not necessary.

* Space is limited and will be allocated on a first-come,
first-serve basis.

* Registration is required in advance, but is completely free.

* To register, please send an email to "supp...@ettus.com". Please
specify your: (1) full name; (2) email address; (3) telephone number;
(4) company/university/organization; and (5) which workshop(s) you
would like to attend (one of the two GNU Radio sessions, and/or
one of the two 

Re: [USRP-users] B200 Mini Overflow

[Brandon Piner via USRP-users]

I have found that it starts happening with low sample rates around 2 
Msps and then stops overflowing. It happens all the time with higher 
sample rates.


I tried to rule out my code from this by having it run in a thread that 
just reads from the device and then discards the data afterwards.



On 2018-03-08 17:42, Marcus D. Leech via USRP-users wrote:

On 03/08/2018 08:33 AM, Brandon Piner via USRP-users wrote:

To whom it may concern

I have been implementing a transmitter and receiver application using 
the B200 mini with UHD-3.9.7. The transmitter seems to be working 
well. The strange behavior seems to be happening when I try using the 
receiver.


 1. The predominant issue I am having is that I keep getting an
overflow after X samples were read. The specific number of
samples ("X") before an overflow seems to be linked to the
samples per packet "spp" or the "receive_frame_size" parameter.
If I leave the "spp" and "receive_frame_size" as default then it
seems that the max samples per buffer per packet is 2044. So each
->recv of samples returns 2044 samples. I can call ->recv 30
times and 2044 samples are returned. On the 31st time calling
->recv I only 389 samples along with some timestamp mismatch of
approx 65 uS. The 32nd read flags an overflow and 0 samples are
read. This "cycle" reads 61709 samples in total. Seems like it is
filling a flat buffer and not a circular buffer. Is this the
expected behavior of the device? How can I get it to not overflow?

Is the above sample-rate linked, or does it happen regardless? If it 
happens regardless, then I suspect that you have an off-by-some-amount 
error
  somewhere in your code that is causing buffers to become 
exhausted--you're not vacuuming out all available data.




1.



 2. The other issue is with starting up a receive stream. I
documented it here
https://github.com/EttusResearch/uhd/issues/68#issuecomment-369596794
. Not sure if anyone can assist with that. My current workaround
is to destroy the entire sptr to the USRP and create a new
pointer at the time that I start the receive stream.

Hope someone can provide me with some insight!

Kind regards

Brandon





Disclaimer: http://www.peralex.com/disclaimer.html



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com




___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



Disclaimer: http://www.peralex.com/disclaimer.html


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] UBX vs SBX

[Hojoon Yang via USRP-users]

Hi.I have two USRP X310s and wonder which board between SBX and UBX would be 
the suitable for me.I'm gonna buy four daughterboards to use it as 2x2 MIMO. 
One USRP X310 for Tx, the other USRP for Rx.My target frequency is from 1.8GHz 
to 2.8GHz. According to datasheet, Both UBX and SBX work on the target 
frequency.I saw the schematic of both SBX and UBX and figured it out that UBX 
has a significantly different structure from SBX.I wonder, which board performs 
better "in the target frequency" in terms of MIMO performance(i.e. phase align 
accuracy, noise level, etc..).I don't have price issue. If the UBX performs 
better or same as the SBX in target frequency(1.8GHz~2.8GHz), I would like to 
buy UBX since it has more wide frequency range.Regards,___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com