Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Overflow (Yang Liu)
2. Re: Transmit number to FPGA (Jonathon Pendlum)
3. Re: Inputting data into FPGA (Jonathon Pendlum)
4. Max Sampling Rate supported by NI USRP 2901 (Ammar Mahmood)
5. Re: Max Sampling Rate supported by NI USRP 2901 (Derek Kozel)
6. Re: Overflow (Nicolas Cuervo)
7. Re: Overflow (Derek Kozel)
----------------------------------------------------------------------
Message: 1
Date: Mon, 24 Apr 2017 16:44:38 -0400
From: Yang Liu <[email protected]>
To: [email protected]
Subject: [USRP-users] Overflow
Message-ID:
<CAD4vFMEQ3si4vtqKqUPNSwj-MUmVZ=k_s+0gghr17lt9pqp...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
We have an ofdm recevier at 25Msps and we notice oveflow "O", which from
uhd documentation means that device buffer shuts off streaming due to back
pressure.
Results of overflow: while the transmitter keeps sending data (4000 packets
in total), packets gets dropped after around 500 packets, then the receiver
will pick up again at around 3000 packets, that is, around 2500 packets
gets dropped!
Is there any buffer size that we can increase so that "O" doesn't happen?
We have increased Linux kernel buffers for tcp, but we still see the "O".
Thanks a lot for your help.
Yang
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170424/aa2ff682/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 24 Apr 2017 16:18:27 -0500
From: Jonathon Pendlum <[email protected]>
To: Rohit Dilip <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Transmit number to FPGA
Message-ID:
<CAGdo0uS84K7LJ_n8=whkjkinxofjkhakjycwn3mua-8wld9...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
What device are you using? In the E3xx and X3xx series devices, you can use
RFNoC.
For other devices, you can use "set_user_register()". See this mailing list
question:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-August/015333.html
On Apr 22, 2017 5:23 PM, "Rohit Dilip via USRP-users" <
[email protected]> wrote:
> Hi,
>
> I modified an FPGA on a USRP device to generate and output a wave using a
> lookup table. Is there a way to use gnuradio to input a number to the FPGA,
> so I could generate that number of waves, summed together? I'd like to be
> able to input several numbers -- say f1,f2,f3... -- to the FPGA, then
> output sin(f1*t) + sin(f2*t) + ... If I have the ability to input a series
> of numbers I can easily modify the verilog code. It seems that there should
> be a way, since I can pass the master_clock_rate in the existing blocks,
> but I haven't been able to find exactly where in the Ettus github
> repository those parameters are.
>
> Best,
> Rohit
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170424/83981aad/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 24 Apr 2017 16:25:04 -0500
From: Jonathon Pendlum <[email protected]>
To: Rohit Dilip <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Inputting data into FPGA
Message-ID:
<CAGdo0uS3ypukqv5rU8pE1XG7E4YCG8+Js=fschec9iy7u0v...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
For more information on how to use DSP slices, I suggest reading Xilinx's
documentation on the topic "DSP: Designed for Optimal Results" (
https://www.xilinx.com/publications/archives/books/dsp.pdf). While that
guide is targeting Virtex 4 devices, the advice generally applies to other
Xilinx devices as well. You'll want to keep in mind that the Spartan-6 DSP
slices have 18x18 multipliers instead of 25x18.
On Sun, Apr 16, 2017 at 12:42 AM, Rohit Dilip via USRP-users <
[email protected]> wrote:
> Hey all,
>
> Two questions I was hoping for assistance with. I'm using a USRP B200, and
> have programmed the FPGA with a routine that responds to externally
> acquired data. Similar to how I can set radio_clk by setting the
> master_clock_rate through gnuradio (or through the terminal), I was
> wondering how to declare pass a parameter from software into the fpga
> without having to hard code it and recompile each time?
>
> My second question, how do I use the DSP slices to perform multiplication
> on the FPGA? I haven't been able to find too many resources online on this
> subject.
>
> Thanks
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170424/dcd8b70d/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 25 Apr 2017 11:33:23 +0500
From: Ammar Mahmood <[email protected]>
To: [email protected]
Subject: [USRP-users] Max Sampling Rate supported by NI USRP 2901
Message-ID:
<CAOZxRwhKwvP=48ajwCmFgFEPbn=dgtjkdwgtrjusra5febb...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I am trying to send an rectangular impulse through NI USRP 2901 to check
the effects of wideband channel on the receiver. As the wideband channel
becomes visible only when we increase the sampling rate/bandwidth of
the system so I wanted to know that what is the maximum sampling rate
supported by NI USRP 2901 ?
Regards,
Ammar
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170425/205edb96/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 25 Apr 2017 11:22:34 +0100
From: Derek Kozel <[email protected]>
To: Ammar Mahmood <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Max Sampling Rate supported by NI USRP 2901
Message-ID:
<CAA+K=tu4DnY3zaJ==d4za6vgrirxykyubwussy0jtrp6agg...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Ammar,
The specifications for the NI USRP 2901 can be found at the following link:
http://www.ni.com/pdf/manuals/374925b.pdf
The support library has a number of documents which may be useful to you.
http://www.ni.com/en-us/support/model.usrp-2901.html
Additionally for more information about the hardware you can look on the
Ettus Knowledge Base. The NI USRP 2901 is the same hardware as the B210,
but with different software support out of the box.
https://kb.ettus.com/B200/B210/B200mini/B205mini
The maximum sample rate is 61.44 MS/s when in single channel mode.
Depending on the software support and your hardware it may only be possible
to achieve these rates in bursts.
Regards,
Derek
On Tue, Apr 25, 2017 at 7:33 AM, Ammar Mahmood via USRP-users <
[email protected]> wrote:
> Hi,
>
> I am trying to send an rectangular impulse through NI USRP 2901 to check
> the effects of wideband channel on the receiver. As the wideband channel
> becomes visible only when we increase the sampling rate/bandwidth of
> the system so I wanted to know that what is the maximum sampling rate
> supported by NI USRP 2901 ?
>
>
> Regards,
> Ammar
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170425/999f51d8/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 25 Apr 2017 14:47:21 +0200
From: Nicolas Cuervo <[email protected]>
To: Yang Liu <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Overflow
Message-ID:
<caoupcvhw2z_mlt4okbyf3k-rfpjds8k52gwe1pfgjijp94l...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Yang Liu,
You can have a look at the transport notes [1] for different ways of
tweaking the interfaces in such ways that the performance can be improved.
When these settings are not enough, then varying the sampling rate is also
an option. When the sample rate has to be fixed because of application and
design constraints, then your implementation itself may have some
bottlenecks that are generating the overflows. You can see if your
application is having a heavy load on the CPU by running a process viewer
(such as 'top' or 'htop', if you are using a Unix machine), and if that is
the case, then you could also optimize your design (with the help of tools
such as Valgrind).
Regards,
- Nicolas
[1] https://files.ettus.com/manual/page_transport.html
On Mon, Apr 24, 2017 at 10:44 PM, Yang Liu via USRP-users <
[email protected]> wrote:
> Hello,
>
> We have an ofdm recevier at 25Msps and we notice oveflow "O", which from
> uhd documentation means that device buffer shuts off streaming due to back
> pressure.
>
> Results of overflow: while the transmitter keeps sending data (4000
> packets in total), packets gets dropped after around 500 packets, then the
> receiver will pick up again at around 3000 packets, that is, around 2500
> packets gets dropped!
>
> Is there any buffer size that we can increase so that "O" doesn't happen?
> We have increased Linux kernel buffers for tcp, but we still see the "O".
>
> Thanks a lot for your help.
>
> Yang
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170425/da0b1467/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 25 Apr 2017 14:40:03 +0100
From: Derek Kozel <[email protected]>
To: Nicolas Cuervo <[email protected]>
Cc: Yang Liu <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] Overflow
Message-ID:
<CAA+K=tt5ghfs0hxmslgchpr7nqjcaqkplwvwxf_st509tev...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Yang Liu,
What connection are you using to the USRP? And what type of USRP are you
connected to? 25 MS/s is right at the edge of what 1 Gigabit Ethernet can
sustain. Nicholas' recommendation of reviewing the CPU usage and the manual
page on transport tuning has recommendations for a variety of transport
types and operating systems.
Regards,
Derek
On Tue, Apr 25, 2017 at 1:47 PM, Nicolas Cuervo via USRP-users <
[email protected]> wrote:
> Hello Yang Liu,
>
> You can have a look at the transport notes [1] for different ways of
> tweaking the interfaces in such ways that the performance can be improved.
> When these settings are not enough, then varying the sampling rate is also
> an option. When the sample rate has to be fixed because of application and
> design constraints, then your implementation itself may have some
> bottlenecks that are generating the overflows. You can see if your
> application is having a heavy load on the CPU by running a process viewer
> (such as 'top' or 'htop', if you are using a Unix machine), and if that is
> the case, then you could also optimize your design (with the help of tools
> such as Valgrind).
>
> Regards,
> - Nicolas
>
> [1] https://files.ettus.com/manual/page_transport.html
>
> On Mon, Apr 24, 2017 at 10:44 PM, Yang Liu via USRP-users <
> [email protected]> wrote:
>
>> Hello,
>>
>> We have an ofdm recevier at 25Msps and we notice oveflow "O", which from
>> uhd documentation means that device buffer shuts off streaming due to back
>> pressure.
>>
>> Results of overflow: while the transmitter keeps sending data (4000
>> packets in total), packets gets dropped after around 500 packets, then the
>> receiver will pick up again at around 3000 packets, that is, around 2500
>> packets gets dropped!
>>
>> Is there any buffer size that we can increase so that "O" doesn't happen?
>> We have increased Linux kernel buffers for tcp, but we still see the "O".
>>
>> Thanks a lot for your help.
>>
>> Yang
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170425/572db8b0/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 80, Issue 25
******************************************
