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. Re: How can I get successful transmission using the QPSK
transmitter and receiver USRP? (Marcus M?ller)
2. Re: I am dead in the water due to the following error: RFNoC
not found. (Swanson, Craig)
3. Re: master clock of X300 (john liu)
4. gr-ettus RFNoC 1024 Bin FFT Limit? (Dave NotTelling)
5. Re: gr-ettus RFNoC 1024 Bin FFT Limit? (Marcus D. Leech)
6. Re: gr-ettus RFNoC 1024 Bin FFT Limit? (Dave NotTelling)
7. Re: RFNoC: RuntimeError: On node 0/CostasLoop_0, output port
0 is already connected (Jason Matusiak)
8. Re: RFNoC: RuntimeError: On node 0/CostasLoop_0, output port
0 is already connected (Jason Matusiak)
9. Re: RFNoC: RuntimeError: On node 0/CostasLoop_0, output port
0 is already connected (Sylvain Munaut)
10. Re: Thunderbolt? 3 on Laptop to 10 Gigabit Ethernet
(Claudio Cicconetti)
11. Re: Thunderbolt? 3 on Laptop to 10 Gigabit Ethernet
(Marcus M?ller)
12. Re: Fwd: USRP E310_Overrun, Underrun and Latency. (BHUSHAN PAWAR)
13. Re: Fwd: USRP E310_Overrun, Underrun and Latency. (Marcus M?ller)
14. X310 MTU Issue in Ubuntu 14.04 (Dave NotTelling)
15. Re: Thunderbolt? 3 on Laptop to 10 Gigabit Ethernet
(Claudio Cicconetti)
----------------------------------------------------------------------
Message: 1
Date: Sun, 8 May 2016 21:19:50 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] How can I get successful transmission using
the QPSK transmitter and receiver USRP?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Dear Wenyu,
as I'm no longer on flakey mobile internet, I had a chance to download
and look at your attachments.
I was hoping you had actually generated a spectrum plot of the receive
and the transmit signal, or done something similar to understand what
might be going wrong; instead, you only pasted the parametrization and
the garbled output. Please avoid posting images of text ? just copy &
paste the text as is instead next time; much easier to handle.
So, to your actual problem:
there's millions of ways that a transmission might be influenced to be
non-perfect. In fact, for any real system it is (stochastically
speaking) that for an arbitrarily long observation, a bit error will appear.
Hence, you'll need to start your debugging yourself. Remotely, it's
impossible to tell what you're doing, how your setup influences the
signal and so on.
A few hints:
* Make sure transmitter and receiver are at the same frequency, and the
antenna you use is suitable. Verify reception by looking at your receive
signal in a plot!
* Make sure the gain on RX and TX are appropriate. Generally, start with
a medium-to-high TX gain, and a medium-to-high RX gain. Increase either
gain, verifying you increase the signal-to-noise ratio, which you can,
in these simple modulations, again, do through looking at the signal (or
its spectrum) in a plot.
* Work step by step: as soon as you're sure that with the settings you
chose the receiver gets the signal "loud and clear", try again with your
QPSK receiver.
Good luck with your Master's thesis! Reproducing a program that
Mathworks wrote surely is only the basis of your work, so spending a lot
of time on getting the basics right, and honing your debugging and
signal-hunting skills will definitely pay later on. Don't worry if
things don't work at first.
Best regards,
Marcus
On 07.05.2016 22:22, Zhang, Wenyu via USRP-users wrote:
>
> I am now using two USRPs (NI 2920) as the QPSK transmitter and
> receiver using the scripts
> *http://uk.mathworks.com/help/supportpkg/usrpradio/examples/qpsk-transmitter-with-usrp-r-hardware.html*
> and
> *http://uk.mathworks.com/help/supportpkg/usrpradio/examples/qpsk-receiver-with-usrp-r-hardware.html?searchHighlight=QPSK%20Receiver%20with%20USRP%C2%AE%20Hardware*.
> First, I wonder are these two USRPs share the same IP address which is
> 192.168.10.2? Second, I do not know where I am wrong as when I use
> different IP address for transmitter and receiver, I get messy codes
> which are attached by the screenshots. Do I have to update both USRP
> firmware and FPGA images and UHD version (
> *http://uk.mathworks.com/help/supportpkg/usrpradio/ug/support-package-hardware-setup.html*)
> Thanks very much
>
>
>
> _______________________________________________
> 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/20160508/480dd936/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 9 May 2016 00:09:51 +0000
From: "Swanson, Craig" <[email protected]>
To: Marcus M?ller <[email protected]>, Martin Braun
<[email protected]>, Jonathon Pendlum
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] I am dead in the water due to the following
error: RFNoC not found.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
?Marcus,
I just upgraded my image to e3xx-release-4 on my E310.
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
________________________________
From: Marcus M?ller <[email protected]>
Sent: Saturday, May 7, 2016 2:33 PM
To: Swanson, Craig; Martin Braun; Jonathon Pendlum
Cc: [email protected]
Subject: Re: [USRP-users] I am dead in the water due to the following error:
RFNoC not found.
You're welcome! Hope this works out.
If you're aiming for using RFNoC on your E310 (which I just realized might be
the case, looking at your -DENABLE_E300), you not only need any version of UHD
that supports RFNoC ? you need the version (and, most importantly, since I
guess you might be building your own FPGA images sooner or later, the right
FPGA source code) that runs on the E310.
What image are you running on the E310?
Best regards,
Marcus
On 07.05.2016 20:30, Swanson, Craig wrote:
Marcus,
Thanks for the quick reply.
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>http://www.gtri.gatech.edu
________________________________
From: Marcus M?ller <[email protected]><mailto:[email protected]>
Sent: Saturday, May 7, 2016 2:23 PM
To: Swanson, Craig; Martin Braun; Jonathon Pendlum
Cc: [email protected]<mailto:[email protected]>; Myers, David
Subject: Re: [USRP-users] I am dead in the water due to the following error:
RFNoC not found.
Hi Craig,
this won't work because you're (implicitly) checking out the "master" branch of
UHD - which isn't RFNoC'ed.
So, I recommend modifying your script:
instead of
git clone https://github.com/EttusResearch/uhd
use
git clone -b rfnoc-devel https://github.com/EttusResearch/uhd
git submodule update --init ##fill the fpga-src directory with the matching
FPGA code
. Of course, if you've still got the downloaded files around, you can check out
the right branch right now
cd ~/uhd/host/build
sudo make uninstall
rm -r * ##cleans the build directory
git checkout -t rfnoc-devel ## checks out the RFNoC version of UHD
git submodule update --init ##fill the fpga-src directory with the matching
FPGA code
cmake -DENABLE_E300=ON ../
make -j8 && sudo make install && sudo ldconfig
cd ~/gnuradio/build
cmake ..
make -j8 && sudo make install && sudo ldconfig
and then try building gr-ettus again.
Best regards,
Marcus
On 07.05.2016 20:11, Swanson, Craig via USRP-users wrote:
Martin,
When I perform a cmake ../ in gr-ettus, I get the following error:
CMake Error at CMakeLists.txt:113 (message):
RFNoC not found.
Here are more details of the error:
craig@craig-VirtualBox:~/gr-ettus/build (master)$ cmake ../
-- The CXX compiler identification is GNU 4.8.4
-- The C compiler identification is GNU 4.8.4
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Build type not specified: defaulting to release.
-- Boost version: 1.54.0
-- Found the following Boost libraries:
-- filesystem
-- system
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.26")
-- Found UHD: /usr/local/lib/libuhd.so
CMake Error at CMakeLists.txt:113 (message):
RFNoC not found.
Here is the script I am using:
git clone https://github.com/EttusResearch/uhd
mkdir ~/uhd/host/build
cd ~/uhd/host/build
cmake ../ -DENABLE_E300=ON ../
make -j8
sudo make install -j8
sudo ldconfig
git clone --recursive <http://git.gnuradio.org/git/gnuradio.git>
http://git.gnuradio.org/git/gnuradio.git
mkdir ~/gnuradio/build
cd ~/gnuradio/build
cmake ../
make -j8
sudo make install -j8
sudo ldconfig
git clone
https://github.com/EttusResearch/gr-ettus.git?<https://github.com/EttusResearch/gr-ettus.git%E2%80%8B>
mkdir ~/gr-ettus/build
cd ~/gr-ettus/build
cmake ../
make -j8
sudo make install -j8
sudo ldconfig
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
<http://www.gtri.gatech.edu>http://www.gtri.gatech.edu
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[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/20160509/8674a675/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 9 May 2016 08:46:04 +0800
From: john liu <[email protected]>
To: Ashish Chaudhari <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] master clock of X300
Message-ID:
<caf6nntk3y4orkj_kvygozct7fnsrsyya5cffjyubftrcqwv...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,Ashish,
thank you.i will try it.
John
On Sat, May 7, 2016 at 2:14 AM, Ashish Chaudhari <[email protected]
> wrote:
> Hi John,
>
> Support for master clock rates of 120MHz and 184.32MHz is considered
> experimental and it does not go though our full validation cycle. We
> only guarantee radio performance with a clock rate of 200MHz.
>
> That said, you can ask UHD to try to calibrate its FPGA interfaces to
> work with a custom master clock rate. You can do so by specifying the
> "self_cal_adc_delay" device argument. Here is an example:
>
> $ uhd_usrp_probe --args="addr=<device IP>,self_cal_adc_delay"
>
> When you specify this additional argument, UHD will run through a
> timing calibration sequence during initialization and should print out
> status information and the calibration offset to the console. Please
> note that this will only work in UHD 3.9.0 or later.
>
> Thanks,
>
> Ashish Chaudhari
> Ashish Chaudhari | Senior Software Engineer | Software Defined Radio
> Ettus Research, A National Instruments Company
> [email protected]
>
>
> On Thu, May 5, 2016 at 8:15 PM, john liu via USRP-users
> <[email protected]> wrote:
> > Dear all,
> > We set master clock of usrp X300 200M or 120M,it is OK.But
> when
> > we set master clock 184.32M,the errors output:
> >
> > Error: RuntimeError: ADC self-test failed! Ramp checker status:
> > {ADC0_I=Good,
> > ADC0_Q=Good,ADC1_I=Bit Errors!, ADC1_Q=Bit Errors!}
> >
> > We had changed UHD version,but the error keep same.
> > can you give some davices.
> >
> > thank you for your help
> > best regards
> > John
> >
> > _______________________________________________
> > 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/20160509/f9416a4a/attachment-0001.html>
------------------------------
Message: 4
Date: Sun, 8 May 2016 23:28:28 -0400
From: Dave NotTelling <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] gr-ettus RFNoC 1024 Bin FFT Limit?
Message-ID:
<CAK6GVuP4pw1SpHyw=cvtg0lf5hhhwgqnxszbtg_zvza3q5c...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Is the RFNoC FFT block limited to 1024 points? The drop down shows up to
4096, but the block errors out in GNU Radio if put over 1024. Is that
intentional? If so, is there a specific reason why the FFT block is
limited that low?
Thank you!
-Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160508/73604b5b/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 09 May 2016 00:08:39 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] gr-ettus RFNoC 1024 Bin FFT Limit?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 05/08/2016 11:28 PM, Dave NotTelling via USRP-users wrote:
> Is the RFNoC FFT block limited to 1024 points? The drop down shows up
> to 4096, but the block errors out in GNU Radio if put over 1024. Is
> that intentional? If so, is there a specific reason why the FFT block
> is limited that low?
>
> Thank you!
>
> -Dave
>
FFT outputs are done as single UDP frames in RFNoC, so you're limited to
whatever your Ethernet NIC can give you. For 1024-bin FFTs, that
requires a minimum of 4096bytes, without considering required VITA
overhead, etc. So, your NIC needs to be programmed for about 4500
bytes MTU. Most 1GiGe NICs won't go a whole lot over that, although
10GiGe NICs will allow and MTU of 9000, allowing 2048-bin FFTs.
------------------------------
Message: 6
Date: Mon, 9 May 2016 00:18:47 -0400
From: Dave NotTelling <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] gr-ettus RFNoC 1024 Bin FFT Limit?
Message-ID:
<CAK6GVuNDeG-ESyCTdxYze+bZAP41VJSULVM=FzHhyTyuxW=4...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Ahh, that makes perfect sense. Thank you!
On May 9, 2016 12:09 AM, "Marcus D. Leech via USRP-users" <
[email protected]> wrote:
> On 05/08/2016 11:28 PM, Dave NotTelling via USRP-users wrote:
>
>> Is the RFNoC FFT block limited to 1024 points? The drop down shows up to
>> 4096, but the block errors out in GNU Radio if put over 1024. Is that
>> intentional? If so, is there a specific reason why the FFT block is
>> limited that low?
>>
>> Thank you!
>>
>> -Dave
>>
>> FFT outputs are done as single UDP frames in RFNoC, so you're limited to
> whatever your Ethernet NIC can give you. For 1024-bin FFTs, that
> requires a minimum of 4096bytes, without considering required VITA
> overhead, etc. So, your NIC needs to be programmed for about 4500
> bytes MTU. Most 1GiGe NICs won't go a whole lot over that, although
> 10GiGe NICs will allow and MTU of 9000, allowing 2048-bin FFTs.
>
>
>
> _______________________________________________
> 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/20160509/eb21e7f2/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 9 May 2016 07:31:49 -0400
From: Jason Matusiak <[email protected]>
To: Martin Braun <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNoC: RuntimeError: On node 0/CostasLoop_0,
output port 0 is already connected
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
> No, I strongly suspect either a gr-ettus or UHD issue here. I'll look
> into it.
Martin, Any luck tracking this down? TIA.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160509/ca9fe9eb/attachment-0001.html>
------------------------------
Message: 8
Date: Mon, 9 May 2016 07:41:40 -0400
From: Jason Matusiak <[email protected]>
To: Sylvain Munaut <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNoC: RuntimeError: On node 0/CostasLoop_0,
output port 0 is already connected
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
> But that's probably a bug in my FPGA code, I actually probably just
> found it (using wrong src SID in the CHDR headers), but I'll be able
> to confirm that once synthesis is done.
Did that seem to solve your issue? I ask because one of the changes I made
early on was to modify my src_sid on the three outputs to:
assign src_sid[0] = {m_axis_data_tuser[71:68], // Steal this block's SID
from the header. Not ideal, but works. Soon NoC Shell will provide the SID as
an output signal.
4'd0}; // Block port
assign src_sid[1] = {m_axis_data_tuser[71:68],4'd1};
assign src_sid[2] = {m_axis_data_tuser[71:68],4'd2};
But, I am not sure if that is correct......
Also, your fix you sent int the diff was just the addition of the one line with
the '+' right (I'be never been good at ready through monochrome git diffs)?
~J
------------------------------
Message: 9
Date: Mon, 9 May 2016 14:10:27 +0200
From: Sylvain Munaut <[email protected]>
To: Jason Matusiak <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNoC: RuntimeError: On node 0/CostasLoop_0,
output port 0 is already connected
Message-ID:
<cahl+j0_yuagtpdp0qjwymzncpcphbwogsyue-dbedcptcsa...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi,
> Did that seem to solve your issue? I ask because one of the changes I made
> early on was to modify my src_sid on the three outputs to:
> assign src_sid[0] = {m_axis_data_tuser[71:68], // Steal this block's SID
> from the header. Not ideal, but works. Soon NoC Shell will provide the SID
> as an output signal.
> 4'd0}; // Block port
> assign src_sid[1] = {m_axis_data_tuser[71:68],4'd1};
> assign src_sid[2] = {m_axis_data_tuser[71:68],4'd2};
>
> But, I am not sure if that is correct......
Yes, that's the change I had to make.
And it improved the situation.
Now the flowgraph starts and data is flowing but I get _weird_ issues
and inconsistent (depends on the run) as well:ut
- Gnuradio message passing doesn't work any more with the block
(message handler never called)
- flowgraph can't terminate (i.e. when calling tb->stop(), it never
actually stops and quite).
If only connect one of the output port (and configure the fpga core to
not send any data on the other ports), then everything works fine.
I suspect some weird memory corruption or threading/locking issue or
some really weird stuff like that.
> Also, your fix you sent int the diff was just the addition of the one line
> with the '+' right (I'be never been good at ready through monochrome git
> diffs)?
Yes
Cheers,
Sylvain
------------------------------
Message: 10
Date: Mon, 9 May 2016 14:56:02 +0200
From: Claudio Cicconetti <[email protected]>
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: [USRP-users] Thunderbolt? 3 on Laptop to 10 Gigabit
Ethernet
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Dear Serge,
Did you try using the SanLink2 adapter on a MacBook with Linux?
Unfortunately, I am having no luck in using the Sonnet adapter on a
MacBook using the GNU Radio Live distro (obscure errors appear in system
logs when the adapter is switched on).
Best regards,
Claudio
On 05/06/2016 08:49 PM, Serge Malo wrote:
> Hi all,
>
> We have been using the Promise Technologies SanLink2 successfully under
> MacOS, Windows and Linux Ubuntu (Macbook and Asus ROG laptops). Its a
> Thunderbol2 to 10GbE converter.
> http://www.promise.com/Products/SANLink/SANLink2
>
> However, newer laptops come with Thunderbolt3 (via a USB Type C connector),
> and we have not found any solution yet to connect Thunderbolt3 to a X300.
> StartTech should have a Thunderbolt3 to Thnderbolt2 converter in June (
> https://www.startech.com/Cables/thunderbolt-3-cables/thunderbolt-3-usb-c-thunderbolt-adapter~TBT3TBTADAP
> )
> But we would prefer to find a direct Thunderbolt3 to 10GbE SFP+ converter.
> If by any chance anyone finds such adapter, I'll be happy to buy/try one!
>
> Regards,
> Serge
>
>
> On 6 May 2016 at 13:22, Zhihong Luo via USRP-users <
> [email protected]> wrote:
>
>> Claudio,
>>
>> Thanks a lot for the information!
>>
>> Zhihong
>>
>> On Fri, May 6, 2016 at 5:40 AM, Claudio Cicconetti via USRP-users <
>> [email protected]> wrote:
>>
>>> Dear Marcus,
>>> Will try asap (downloading DVD live right now).
>>>
>>> If it works I owe you a pint.
>>>
>>> Best regards,
>>> Claudio
>>>
>>> On 05/06/2016 10:43 AM, Marcus M?ller wrote:
>>>> You sparked my own initiative: Went to the sonnettech website, clicked
>>>> through to the presto 10GE card that's inside the box, got the windows
>>>> driver, looked at the URL: It's a Myricom Myri10GE !
>>>> If it works over thunderbird, too, then there should be drivers in the
>>>> upstream linux kernel since 2.6.something :) ; module name is
>>>> "myri10ge", iirc.
>>>>
>>>>
>>>> Cheers,
>>>> Marcus
>>>>
>>>> On 06.05.2016 10:32, Claudio Cicconetti wrote:
>>>>> Dear Marcus,
>>>>> If it worked, that would make my life soooo much easier.
>>>>>
>>>>> Frankly, I didn't even try since I had to install a (Mac OS X only)
>>>>> driver on the MacBook to make the adapter work.
>>>>>
>>>>> Yet, I will give it a try and will keep the list posted on this.
>>>>>
>>>>> Best regards,
>>>>> Claudio
>>>>>
>>>>> On 05/06/2016 10:09 AM, Marcus M?ller via USRP-users wrote:
>>>>>> Out of personal curiosity:
>>>>>> does that thunderbolt/10GE adapter work under linux, e.g. with the GNU
>>>>>> Radio Live DVD?
>>>>>>
>>>>>> Best regards,
>>>>>> Marcus
>>>>>>
>>>>>> On 06.05.2016 09:10, Claudio Cicconetti via USRP-users wrote:
>>>>>>> Dear Zhihong
>>>>>>> I am able to receive at 100 MS/s (i.e., ~3.3 Gb/s over the wire).
>>>>>>>
>>>>>>> At that rate I only experience under-runs when the OS runs background
>>>>>>> jobs (such as re-building indexes of the spotlight or iTunes
>>> database)
>>>>>>> that choke all CPUs and my application as well.
>>>>>>>
>>>>>>> I am trying to disable all such background jobs, which is proving
>>> more
>>>>>>> painful than it should reasonably be because of my lack of experience
>>>>>>> with Mac OS X...
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Claudio
>>>>>>>
>>>>>>> On 05/05/2016 06:28 PM, Zhihong Luo wrote:
>>>>>>>> Hi Claudio,
>>>>>>>>
>>>>>>>> Thank you so much for the sharing. Problem is that there seems to
>>> be no
>>>>>>>> available adapter for Thunderbolt3 to Thunderbolt 2/1 yet... What's
>>> the
>>>>>>>> highest sample rate you can run without having any underrun issues?
>>> I am
>>>>>>>> looking for roughly 60 MS/s, if it can work on this rate, I can try
>>> to use
>>>>>>>> a laptop with old Thunderbolt port.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Zhihong
>>>>>>>>
>>>>>>>> On Thu, May 5, 2016 at 2:57 AM, Claudio Cicconetti <
>>> [email protected]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Dear Zhihong,
>>>>>>>>> I have successfully set up a MacBook + X300 connected via 10 GbE.
>>>>>>>>>
>>>>>>>>> I used this product:
>>>>>>>>>
>>>>>>>>> http://www.sonnettech.com/product/echoexpresssel_10gbeadapter.html
>>>>>>>>>
>>>>>>>>> to adapt Thunderbolt to 10 GbE. It worked out-of-the-box.
>>>>>>>>>
>>>>>>>>> The only (major!) issue I have now is that the host cannot keep my
>>>>>>>>> desired sampling rate (92.16 Msamples/s) without buffer underruns.
>>> Since
>>>>>>>>> the CPU is far from being overloaded, I suspect it might have
>>> something
>>>>>>>>> to do with interrupts and how the OS handles them.
>>>>>>>>>
>>>>>>>>> If anyone has experience or guidelines on how to optimize
>>> host-to-radio
>>>>>>>>> communication on Mac OS X I would appreciate it very much if you
>>> could
>>>>>>>>> share.
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Claudio
>>>>>>>>>
>>>>>>>>> On 05/05/2016 07:24 AM, Zhihong Luo via USRP-users wrote:
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> I am currently trying to set up 10 Gigabit Ethernet on laptop
>>> through a
>>>>>>>>>> Thunderbolt? 3 port. Thunderbolt? 3 supports up to 40Gbps, so
>>> that I
>>>>>>>>>> suppose it can be adapted to a 10 Gigabit Ethernet port (or PCI).
>>> But I
>>>>>>>>> am
>>>>>>>>>> not sure how to do it, and I didn't find any material on this yet.
>>>>>>>>>>
>>>>>>>>>> Please let me know if you have any suggestions.
>>>>>>>>>>
>>>>>>>>>> Thanks for any help,
>>>>>>>>>> Zhihong
>>>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
>
------------------------------
Message: 11
Date: Mon, 9 May 2016 16:47:43 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Thunderbolt? 3 on Laptop to 10 Gigabit
Ethernet
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Out of interest: what kind of obscure errors?
Best regards,
Marcus
On 09.05.2016 14:56, Claudio Cicconetti via USRP-users wrote:
> Dear Serge,
> Did you try using the SanLink2 adapter on a MacBook with Linux?
>
> Unfortunately, I am having no luck in using the Sonnet adapter on a
> MacBook using the GNU Radio Live distro (obscure errors appear in system
> logs when the adapter is switched on).
>
> Best regards,
> Claudio
>
> On 05/06/2016 08:49 PM, Serge Malo wrote:
>> Hi all,
>>
>> We have been using the Promise Technologies SanLink2 successfully under
>> MacOS, Windows and Linux Ubuntu (Macbook and Asus ROG laptops). Its a
>> Thunderbol2 to 10GbE converter.
>> http://www.promise.com/Products/SANLink/SANLink2
>>
>> However, newer laptops come with Thunderbolt3 (via a USB Type C connector),
>> and we have not found any solution yet to connect Thunderbolt3 to a X300.
>> StartTech should have a Thunderbolt3 to Thnderbolt2 converter in June (
>> https://www.startech.com/Cables/thunderbolt-3-cables/thunderbolt-3-usb-c-thunderbolt-adapter~TBT3TBTADAP
>> )
>> But we would prefer to find a direct Thunderbolt3 to 10GbE SFP+ converter.
>> If by any chance anyone finds such adapter, I'll be happy to buy/try one!
>>
>> Regards,
>> Serge
>>
>>
>> On 6 May 2016 at 13:22, Zhihong Luo via USRP-users <
>> [email protected]> wrote:
>>
>>> Claudio,
>>>
>>> Thanks a lot for the information!
>>>
>>> Zhihong
>>>
>>> On Fri, May 6, 2016 at 5:40 AM, Claudio Cicconetti via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> Dear Marcus,
>>>> Will try asap (downloading DVD live right now).
>>>>
>>>> If it works I owe you a pint.
>>>>
>>>> Best regards,
>>>> Claudio
>>>>
>>>> On 05/06/2016 10:43 AM, Marcus M?ller wrote:
>>>>> You sparked my own initiative: Went to the sonnettech website, clicked
>>>>> through to the presto 10GE card that's inside the box, got the windows
>>>>> driver, looked at the URL: It's a Myricom Myri10GE !
>>>>> If it works over thunderbird, too, then there should be drivers in the
>>>>> upstream linux kernel since 2.6.something :) ; module name is
>>>>> "myri10ge", iirc.
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Marcus
>>>>>
>>>>> On 06.05.2016 10:32, Claudio Cicconetti wrote:
>>>>>> Dear Marcus,
>>>>>> If it worked, that would make my life soooo much easier.
>>>>>>
>>>>>> Frankly, I didn't even try since I had to install a (Mac OS X only)
>>>>>> driver on the MacBook to make the adapter work.
>>>>>>
>>>>>> Yet, I will give it a try and will keep the list posted on this.
>>>>>>
>>>>>> Best regards,
>>>>>> Claudio
>>>>>>
>>>>>> On 05/06/2016 10:09 AM, Marcus M?ller via USRP-users wrote:
>>>>>>> Out of personal curiosity:
>>>>>>> does that thunderbolt/10GE adapter work under linux, e.g. with the GNU
>>>>>>> Radio Live DVD?
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Marcus
>>>>>>>
>>>>>>> On 06.05.2016 09:10, Claudio Cicconetti via USRP-users wrote:
>>>>>>>> Dear Zhihong
>>>>>>>> I am able to receive at 100 MS/s (i.e., ~3.3 Gb/s over the wire).
>>>>>>>>
>>>>>>>> At that rate I only experience under-runs when the OS runs background
>>>>>>>> jobs (such as re-building indexes of the spotlight or iTunes
>>>> database)
>>>>>>>> that choke all CPUs and my application as well.
>>>>>>>>
>>>>>>>> I am trying to disable all such background jobs, which is proving
>>>> more
>>>>>>>> painful than it should reasonably be because of my lack of experience
>>>>>>>> with Mac OS X...
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Claudio
>>>>>>>>
>>>>>>>> On 05/05/2016 06:28 PM, Zhihong Luo wrote:
>>>>>>>>> Hi Claudio,
>>>>>>>>>
>>>>>>>>> Thank you so much for the sharing. Problem is that there seems to
>>>> be no
>>>>>>>>> available adapter for Thunderbolt3 to Thunderbolt 2/1 yet... What's
>>>> the
>>>>>>>>> highest sample rate you can run without having any underrun issues?
>>>> I am
>>>>>>>>> looking for roughly 60 MS/s, if it can work on this rate, I can try
>>>> to use
>>>>>>>>> a laptop with old Thunderbolt port.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Zhihong
>>>>>>>>>
>>>>>>>>> On Thu, May 5, 2016 at 2:57 AM, Claudio Cicconetti <
>>>> [email protected]>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Dear Zhihong,
>>>>>>>>>> I have successfully set up a MacBook + X300 connected via 10 GbE.
>>>>>>>>>>
>>>>>>>>>> I used this product:
>>>>>>>>>>
>>>>>>>>>> http://www.sonnettech.com/product/echoexpresssel_10gbeadapter.html
>>>>>>>>>>
>>>>>>>>>> to adapt Thunderbolt to 10 GbE. It worked out-of-the-box.
>>>>>>>>>>
>>>>>>>>>> The only (major!) issue I have now is that the host cannot keep my
>>>>>>>>>> desired sampling rate (92.16 Msamples/s) without buffer underruns.
>>>> Since
>>>>>>>>>> the CPU is far from being overloaded, I suspect it might have
>>>> something
>>>>>>>>>> to do with interrupts and how the OS handles them.
>>>>>>>>>>
>>>>>>>>>> If anyone has experience or guidelines on how to optimize
>>>> host-to-radio
>>>>>>>>>> communication on Mac OS X I would appreciate it very much if you
>>>> could
>>>>>>>>>> share.
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Claudio
>>>>>>>>>>
>>>>>>>>>> On 05/05/2016 07:24 AM, Zhihong Luo via USRP-users wrote:
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> I am currently trying to set up 10 Gigabit Ethernet on laptop
>>>> through a
>>>>>>>>>>> Thunderbolt? 3 port. Thunderbolt? 3 supports up to 40Gbps, so
>>>> that I
>>>>>>>>>>> suppose it can be adapted to a 10 Gigabit Ethernet port (or PCI).
>>>> But I
>>>>>>>>>> am
>>>>>>>>>>> not sure how to do it, and I didn't find any material on this yet.
>>>>>>>>>>>
>>>>>>>>>>> Please let me know if you have any suggestions.
>>>>>>>>>>>
>>>>>>>>>>> Thanks for any help,
>>>>>>>>>>> Zhihong
>>>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 12
Date: Mon, 9 May 2016 16:48:30 +0200
From: BHUSHAN PAWAR <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: [USRP-users] Fwd: USRP E310_Overrun, Underrun and
Latency.
Message-ID:
<cafvcn_8gvmmnv2fpbpfy6qj+feoebbluc+ud2w2pptjy_vz...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear Marcus,
As per your instructions in the earlier mail, I have made few changes in my
design.
1. The bandwidth in UHD Source & Sink is set as required nyquist rate
ie. 1e9 for the frequency of 500e6
2. In USRP Source and Multiply const. blocks, Min and Max Output Buffer
is set to 0.
3. Number of Multiply const. (Constant =1) blocks per channel increased
by 8.
4. The ratio between master clock rate and sampling rate is kept as an
even integer. The different selected sampling rates are (1e6, 80e3, 50e3,
40e3, 36036, 31250)
However the output in the console still remains the same. A continuous
series of UULLLLL...LLL...UULLL..LLL is observed (less for low samp rates
like 31250 and more for samp rates like 1e6 ).
*Thanks & Regards,*
*Bhushan R.V. Pawar.*
*(+49-17685263152)*
On Mon, May 2, 2016 at 6:18 PM, Marcus M?ller <[email protected]>
wrote:
> Dear Bhushan,
>
> my first intuition is that the graphical sinks might really be a limiting
> factor here (though the rate really seems a bit low) ? you're drawing
> everything over X11 without any hardware acceleration, and probably over
> network.
> By the way, the bandwidth you set in the graphical sinks should be your
> nyquist rate, i.e. the sampling rate, not the analog frontend bandwidth!
> The sink really just sees the flow of samples as sequence of numbers, and
> interprets them according to the setting.
>
> But, the other Marcus is absolutely right: GNU Radio, by default, gives
> the USRP source a bit of a "headstart", so that it can produce samples
> before the USRP sink starts to consume (and hence: need!) them.
> However, that headroom is very limited. At a default GNU Radio buffer size
> of let's say 1024 items, the critical path (output buffer of USRP source,
> output buffer of multiply const) is > 1024 items long, which means that at
> your sampling rate, 25ms is by default spent filling the first input
> buffer. From the sink's perspective, that looks like extremely "choppy"
> sample streaming.
>
> also, I'd recommend trying to limit the buffer size: In the USRP source
> and multiply const blocks, go to the "advanced" tab and reduce the maximum
> output buffer.
>
> As selection of master clock is done automatically in E310,
>
> That's a feature you can use, but also can suppress by explicitely setting
> a clock rate in the USRP block options to any specific value (aside from
> "default").
>
> can you explain how to find the minimum sampling rate for the system? or
> How the Samp_rate (40e3) relate to the actual sampling frequency?
>
> The sample rate you get should be the sample rate you set, unless you get
> a warning that the rate was impossible, and another rate was used.
> So, the "actual sampling rate" you're referring to is probably the master
> clock rate ? from a hardware point of view, the baseband sampling rate of
> the AD9361. From that hardware sampling rate, using decimators with
> appropriate filters, your sampling rate subbandwidth is chosen:
> [image: bandwidths]
> [image: $f_\text{RF}$] is the frequency of the RX or TX LO, [image:
> $f_\text{offset}$] is the digital tuning offset (basically, the baseband
> gets multiplied with a [image: $e^{j2\pi f_\text{offset}n}$]), [image:
> $b_\text{analog}$] is the bandwidth of the analog filter, and the master
> clock rate (not shown) here must be at least as large as that (to avoid
> aliasing).
>
> The ratio between master clock rate and sampling rate must be an integer.
> I recommend using even factors.
>
> Best regards,
> Marcus
>
>
> On 02.05.2016 16:30, BHUSHAN PAWAR wrote:
>
> Hello,
>
> I am trying to achieve MIMO Rx to Tx Loopback in E310 using Gnu-radio.
> Please find attached herewith .png file to see my Gnu-radio design.
>
> Settings for my UHD USRP Sink and Source blocks are as follows,
> Samp_rate : 40e3
> clock rate : default
> BW ch0 & ch1 : 6e6
> Center Freq. ch0 & ch1 : 500e6
>
>
> The output of Gnu-radio is as follows,
>
> Generating: '/home/root/top_block.py'
>
> Executing: '/usr/bin/python -u /home/root/top_block.py'
>
> linux; GNU C++ version 4.9.2; Boost_105700; UHD_003.009.002-0-unknown
>
> -- Loading FPGA image: /usr/share/uhd/images/usrp_e310_fpga.bit... done
> -- Detecting internal GPSDO .... found
> -- Initializing core control...
> -- Performing register loopback test... pass
> -- Performing register loopback test... pass
> -- Performing register loopback test... pass
> -- Performing CODEC loopback test... pass
> -- Performing CODEC loopback test... pass
> -- Setting time source to internal
> -- Asking for clock rate 16 MHz
> -- Actually got clock rate 16 MHz
> -- Performing timer loopback test... pass
> -- Performing timer loopback test... pass
> Using Volk machine: neon_hardfp
> UULLLLLLLLLLLLLLLLLLLLLLLLLLLLLLUULLLLLLLLLLLLLLLLLLLLUULLLLLLL
> LLLLLLLLLUULLLLLLLLLLLLLLLLLLLLLLLLUULLLLLLLLLLLLLLLLLLUULLLLLL
> LLLLLLLLLLLLUULLLLLLLLLLLLLLLLLLLLLLLLUULLLLLLLLLLLLLLLLUULLUUL
> LLLLLLLLLLLLLLLUULLLLLLLLLLLLLLUULLLLLLLLLLLLLLLLLLLLLLLLUULLLLL
> LLLLLLLLLLLUULLLLLLLLLLLLLLLLLLLLLLUULLLLLLLLLLLLLLLLLLLLLLLLUUL
> LLLLLLLLLLLLLLLLLLLUULLLLLLLLLLLLLLLLLUULL
>
>
> 1. What is the reason for so many overflows and latency in the output?
> What changes are required to eliminate this? The Tx stops transmitting the
> signal after one point due to this.
> 2. As selection of master clock is done automatically in E310, can you
> explain how to find the minimum sampling rate for the system? or How the
> Samp_rate (40e3) relate to the actual sampling frequency?
>
>
> *Thanks & Regards,*
>
> *Bhushan R.V. Pawar.*
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160509/a3148099/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-5.png
Type: image/png
Size: 851 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160509/a3148099/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bw_vis.png
Type: image/png
Size: 10467 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160509/a3148099/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-8.png
Type: image/png
Size: 854 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160509/a3148099/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-6.png
Type: image/png
Size: 1057 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160509/a3148099/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-7.png
Type: image/png
Size: 723 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160509/a3148099/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: E310_modified.png
Type: image/png
Size: 47795 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160509/a3148099/attachment-0011.png>
------------------------------
Message: 13
Date: Mon, 9 May 2016 16:58:37 +0200
From: Marcus M?ller <[email protected]>
To: BHUSHAN PAWAR <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: [USRP-users] Fwd: USRP E310_Overrun, Underrun and
Latency.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Bhushan,
On 09.05.2016 16:48, BHUSHAN PAWAR wrote:
> Dear Marcus,
>
> As per your instructions in the earlier mail, I have made few changes
> in my design.
>
> 1. The bandwidth in UHD Source & Sink is set as required nyquist
> rate ie. 1e9 for the frequency of 500e6
>
500e6 is your center frequency, not the complex baseband bandwidth.
Please don't confuse those!
>
> 1. In USRP Source and Multiply const. blocks, Min and Max Output
> Buffer is set to 0.
>
Which do exactly nothing; 0 is not a valid value, so it falls back to
the default.
>
> 1. Number of Multiply const. (Constant =1) blocks per channel
> increased by 8.
>
That will increase buffering, but not make the source start earlier; so
this is practically the opposite of what you want.
>
> 1. The ratio between master clock rate and sampling rate is kept as
> an even integer. The different selected sampling rates are (1e6,
> 80e3, 50e3, 40e3, 36036, 31250)
>
> However the output in the console still remains the same. A continuous
> series of UULLLLL...LLL...UULLL..LLL is observed (less for low samp
> rates like 31250 and more for samp rates like 1e6 ).
>
You really need to give your source more time advantage; you can do a
lot of things, but for a first (non-deterministic timing) test, use a
"delay" block with a significant negative delay (e.g. samp_rate / 10).
Best regards,
Marcus
>
>
>
> *Thanks & Regards,*
>
> *Bhushan R.V. Pawar.*
> /(+49-17685263152)/
> //
>
> On Mon, May 2, 2016 at 6:18 PM, Marcus M?ller
> <[email protected] <mailto:[email protected]>> wrote:
>
> Dear Bhushan,
>
> my first intuition is that the graphical sinks might really be a
> limiting factor here (though the rate really seems a bit low) ?
> you're drawing everything over X11 without any hardware
> acceleration, and probably over network.
> By the way, the bandwidth you set in the graphical sinks should be
> your nyquist rate, i.e. the sampling rate, not the analog frontend
> bandwidth! The sink really just sees the flow of samples as
> sequence of numbers, and interprets them according to the setting.
>
> But, the other Marcus is absolutely right: GNU Radio, by default,
> gives the USRP source a bit of a "headstart", so that it can
> produce samples before the USRP sink starts to consume (and hence:
> need!) them.
> However, that headroom is very limited. At a default GNU Radio
> buffer size of let's say 1024 items, the critical path (output
> buffer of USRP source, output buffer of multiply const) is > 1024
> items long, which means that at your sampling rate, 25ms is by
> default spent filling the first input buffer. From the sink's
> perspective, that looks like extremely "choppy" sample streaming.
>
> also, I'd recommend trying to limit the buffer size: In the USRP
> source and multiply const blocks, go to the "advanced" tab and
> reduce the maximum output buffer.
>> As selection of master clock is done automatically in E310,
> That's a feature you can use, but also can suppress by explicitely
> setting a clock rate in the USRP block options to any specific
> value (aside from "default").
>> can you explain how to find the minimum sampling rate for the
>> system? or How the Samp_rate (40e3) relate to the actual sampling
>> frequency?
> The sample rate you get should be the sample rate you set, unless
> you get a warning that the rate was impossible, and another rate
> was used.
> So, the "actual sampling rate" you're referring to is probably the
> master clock rate ? from a hardware point of view, the baseband
> sampling rate of the AD9361. From that hardware sampling rate,
> using decimators with appropriate filters, your sampling rate
> subbandwidth is chosen:
> bandwidths
> $f_\text{RF}$ is the frequency of the RX or TX LO,
> $f_\text{offset}$ is the digital tuning offset (basically, the
> baseband gets multiplied with a $e^{j2\pi f_\text{offset}n}$),
> $b_\text{analog}$ is the bandwidth of the analog filter, and the
> master clock rate (not shown) here must be at least as large as
> that (to avoid aliasing).
>
> The ratio between master clock rate and sampling rate must be an
> integer. I recommend using even factors.
>
> Best regards,
> Marcus
>
>
> On 02.05.2016 16:30, BHUSHAN PAWAR wrote:
>> Hello,
>>
>> I am trying to achieve MIMO Rx to Tx Loopback in E310 using
>> Gnu-radio. Please find attached herewith .png file to see my
>> Gnu-radio design.
>>
>> Settings for my UHD USRP Sink and Source blocks are as follows,
>> Samp_rate : 40e3
>> clock rate : default
>> BW ch0 & ch1 : 6e6
>> Center Freq. ch0 & ch1 : 500e6
>>
>>
>> The output of Gnu-radio is as follows,
>>
>> Generating: '/home/root/top_block.py'
>>
>> Executing: '/usr/bin/python -u /home/root/top_block.py'
>>
>> linux; GNU C++ version 4.9.2; Boost_105700; UHD_003.009.002-0-unknown
>>
>> -- Loading FPGA image:
>> /usr/share/uhd/images/usrp_e310_fpga.bit... done
>> -- Detecting internal GPSDO .... found
>> -- Initializing core control...
>> -- Performing register loopback test... pass
>> -- Performing register loopback test... pass
>> -- Performing register loopback test... pass
>> -- Performing CODEC loopback test... pass
>> -- Performing CODEC loopback test... pass
>> -- Setting time source to internal
>> -- Asking for clock rate 16 MHz
>> -- Actually got clock rate 16 MHz
>> -- Performing timer loopback test... pass
>> -- Performing timer loopback test... pass
>> Using Volk machine: neon_hardfp
>> UULLLLLLLLLLLLLLLLLLLLLLLLLLLLLLUULLLLLLLLLLLLLLLLLLLLUULLLLLLL
>> LLLLLLLLLUULLLLLLLLLLLLLLLLLLLLLLLLUULLLLLLLLLLLLLLLLLLUULLLLLL
>> LLLLLLLLLLLLUULLLLLLLLLLLLLLLLLLLLLLLLUULLLLLLLLLLLLLLLLUULLUUL
>> LLLLLLLLLLLLLLLUULLLLLLLLLLLLLLUULLLLLLLLLLLLLLLLLLLLLLLLUULLLLL
>> LLLLLLLLLLLUULLLLLLLLLLLLLLLLLLLLLLUULLLLLLLLLLLLLLLLLLLLLLLLUUL
>> LLLLLLLLLLLLLLLLLLLUULLLLLLLLLLLLLLLLLUULL
>>
>> 1. What is the reason for so many overflows and latency in the
>> output? What changes are required to eliminate this? The Tx
>> stops transmitting the signal after one point due to this.
>> 2. As selection of master clock is done automatically in E310,
>> can you explain how to find the minimum sampling rate for the
>> system? or How the Samp_rate (40e3) relate to the actual
>> sampling frequency?
>>
>>
>> *Thanks & Regards,*
>>
>> *Bhushan R.V. Pawar.*
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160509/0e78c1d0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 10467 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160509/0e78c1d0/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 723 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160509/0e78c1d0/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 854 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160509/0e78c1d0/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1057 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160509/0e78c1d0/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 851 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160509/0e78c1d0/attachment-0009.png>
------------------------------
Message: 14
Date: Mon, 9 May 2016 11:06:51 -0400
From: Dave NotTelling <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] X310 MTU Issue in Ubuntu 14.04
Message-ID:
<CAK6GVuPBWnTLb5fVQH-KDj65=r8u7wmblys3by5uxee8sre...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I am trying to set the MTU of my Intel X710 10 gigabit card to 9000 in
Ubuntu 14.04 but when I try to run osmocom_fft I get the error below. I
changed both the net.core.rmem_max and net.core.wmem_max sysctl values to
what is listed on http://files.ettus.com/manual/page_usrp_x3x0_config.html.
I've gotten it to work before, but sadly I did not write down the magic
commands that made it work and then reformatted the machine. Oh, and the
error pops up if I lower the sampling rate down to 25e6 as well.
If I back the MTU down to 2400 things work fine. Past that I get the same
error. I am using the X710 driver from Intel instead of the stock driver
as that was the only way I was able to get things working before nuking the
machine.
[error]
osmocom_fft -F -f 5.8e9 -s 200e6
linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-202-g9e0861e1
gr-osmosdr v0.1.4-72-g164a09fc (0.1.5git) gnuradio 885b5a75
built-in source types: file fcd rtl_tcp uhd hackrf rfspace redpitaya
-- X300 initialization sequence...
-- Determining maximum frame size... 8000 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- Initialize Radio0 control...
-- Performing register loopback test... pass
FATAL: EnvironmentError: IOError: Radio ctrl (A) packet parse error -
AssertionError: packet_info.packet_count == (seq_to_ack & 0xfff)
in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
at /opt/git/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:264
Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to gnuradio bug #528.
[/error]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160509/5b1401ef/attachment-0001.html>
------------------------------
Message: 15
Date: Mon, 9 May 2016 17:37:56 +0200
From: Claudio Cicconetti <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Thunderbolt? 3 on Laptop to 10 Gigabit
Ethernet
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Dear Marcus,
I rebooted the Mac to copy/paste errors in response to your email, but
surprisingly it worked!
After a few tries, I discovered that the device is only recognized by
the Linux kernel if it is plugged in at boot, otherwise bad things
happen. Not a blocking issue for me.
I was able to run the benchmark rate at 100 MS/s with out-of-the-box
configuration, see "proof" at the following Dropbox links, also
including the testbed set-up:
https://dl.dropboxusercontent.com/u/3247031/usrp/benchmark_rate.png
https://dl.dropboxusercontent.com/u/3247031/usrp/setup.jpg
Thank you very much for assistance, I will install immediately Linux on
the MacBook and (presumably) live happy with it.
Best regards,
Claudio
On 05/09/2016 04:47 PM, Marcus M?ller via USRP-users wrote:
> Out of interest: what kind of obscure errors?
>
> Best regards,
> Marcus
>
> On 09.05.2016 14:56, Claudio Cicconetti via USRP-users wrote:
>> Dear Serge,
>> Did you try using the SanLink2 adapter on a MacBook with Linux?
>>
>> Unfortunately, I am having no luck in using the Sonnet adapter on a
>> MacBook using the GNU Radio Live distro (obscure errors appear in system
>> logs when the adapter is switched on).
>>
>> Best regards,
>> Claudio
>>
>> On 05/06/2016 08:49 PM, Serge Malo wrote:
>>> Hi all,
>>>
>>> We have been using the Promise Technologies SanLink2 successfully under
>>> MacOS, Windows and Linux Ubuntu (Macbook and Asus ROG laptops). Its a
>>> Thunderbol2 to 10GbE converter.
>>> http://www.promise.com/Products/SANLink/SANLink2
>>>
>>> However, newer laptops come with Thunderbolt3 (via a USB Type C connector),
>>> and we have not found any solution yet to connect Thunderbolt3 to a X300.
>>> StartTech should have a Thunderbolt3 to Thnderbolt2 converter in June (
>>> https://www.startech.com/Cables/thunderbolt-3-cables/thunderbolt-3-usb-c-thunderbolt-adapter~TBT3TBTADAP
>>> )
>>> But we would prefer to find a direct Thunderbolt3 to 10GbE SFP+ converter.
>>> If by any chance anyone finds such adapter, I'll be happy to buy/try one!
>>>
>>> Regards,
>>> Serge
>>>
>>>
>>> On 6 May 2016 at 13:22, Zhihong Luo via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> Claudio,
>>>>
>>>> Thanks a lot for the information!
>>>>
>>>> Zhihong
>>>>
>>>> On Fri, May 6, 2016 at 5:40 AM, Claudio Cicconetti via USRP-users <
>>>> [email protected]> wrote:
>>>>
>>>>> Dear Marcus,
>>>>> Will try asap (downloading DVD live right now).
>>>>>
>>>>> If it works I owe you a pint.
>>>>>
>>>>> Best regards,
>>>>> Claudio
>>>>>
>>>>> On 05/06/2016 10:43 AM, Marcus M?ller wrote:
>>>>>> You sparked my own initiative: Went to the sonnettech website, clicked
>>>>>> through to the presto 10GE card that's inside the box, got the windows
>>>>>> driver, looked at the URL: It's a Myricom Myri10GE !
>>>>>> If it works over thunderbird, too, then there should be drivers in the
>>>>>> upstream linux kernel since 2.6.something :) ; module name is
>>>>>> "myri10ge", iirc.
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Marcus
>>>>>>
>>>>>> On 06.05.2016 10:32, Claudio Cicconetti wrote:
>>>>>>> Dear Marcus,
>>>>>>> If it worked, that would make my life soooo much easier.
>>>>>>>
>>>>>>> Frankly, I didn't even try since I had to install a (Mac OS X only)
>>>>>>> driver on the MacBook to make the adapter work.
>>>>>>>
>>>>>>> Yet, I will give it a try and will keep the list posted on this.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Claudio
>>>>>>>
>>>>>>> On 05/06/2016 10:09 AM, Marcus M?ller via USRP-users wrote:
>>>>>>>> Out of personal curiosity:
>>>>>>>> does that thunderbolt/10GE adapter work under linux, e.g. with the GNU
>>>>>>>> Radio Live DVD?
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Marcus
>>>>>>>>
>>>>>>>> On 06.05.2016 09:10, Claudio Cicconetti via USRP-users wrote:
>>>>>>>>> Dear Zhihong
>>>>>>>>> I am able to receive at 100 MS/s (i.e., ~3.3 Gb/s over the wire).
>>>>>>>>>
>>>>>>>>> At that rate I only experience under-runs when the OS runs background
>>>>>>>>> jobs (such as re-building indexes of the spotlight or iTunes
>>>>> database)
>>>>>>>>> that choke all CPUs and my application as well.
>>>>>>>>>
>>>>>>>>> I am trying to disable all such background jobs, which is proving
>>>>> more
>>>>>>>>> painful than it should reasonably be because of my lack of experience
>>>>>>>>> with Mac OS X...
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Claudio
>>>>>>>>>
>>>>>>>>> On 05/05/2016 06:28 PM, Zhihong Luo wrote:
>>>>>>>>>> Hi Claudio,
>>>>>>>>>>
>>>>>>>>>> Thank you so much for the sharing. Problem is that there seems to
>>>>> be no
>>>>>>>>>> available adapter for Thunderbolt3 to Thunderbolt 2/1 yet... What's
>>>>> the
>>>>>>>>>> highest sample rate you can run without having any underrun issues?
>>>>> I am
>>>>>>>>>> looking for roughly 60 MS/s, if it can work on this rate, I can try
>>>>> to use
>>>>>>>>>> a laptop with old Thunderbolt port.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Zhihong
>>>>>>>>>>
>>>>>>>>>> On Thu, May 5, 2016 at 2:57 AM, Claudio Cicconetti <
>>>>> [email protected]>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Dear Zhihong,
>>>>>>>>>>> I have successfully set up a MacBook + X300 connected via 10 GbE.
>>>>>>>>>>>
>>>>>>>>>>> I used this product:
>>>>>>>>>>>
>>>>>>>>>>> http://www.sonnettech.com/product/echoexpresssel_10gbeadapter.html
>>>>>>>>>>>
>>>>>>>>>>> to adapt Thunderbolt to 10 GbE. It worked out-of-the-box.
>>>>>>>>>>>
>>>>>>>>>>> The only (major!) issue I have now is that the host cannot keep my
>>>>>>>>>>> desired sampling rate (92.16 Msamples/s) without buffer underruns.
>>>>> Since
>>>>>>>>>>> the CPU is far from being overloaded, I suspect it might have
>>>>> something
>>>>>>>>>>> to do with interrupts and how the OS handles them.
>>>>>>>>>>>
>>>>>>>>>>> If anyone has experience or guidelines on how to optimize
>>>>> host-to-radio
>>>>>>>>>>> communication on Mac OS X I would appreciate it very much if you
>>>>> could
>>>>>>>>>>> share.
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>> Claudio
>>>>>>>>>>>
>>>>>>>>>>> On 05/05/2016 07:24 AM, Zhihong Luo via USRP-users wrote:
>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>
>>>>>>>>>>>> I am currently trying to set up 10 Gigabit Ethernet on laptop
>>>>> through a
>>>>>>>>>>>> Thunderbolt? 3 port. Thunderbolt? 3 supports up to 40Gbps, so
>>>>> that I
>>>>>>>>>>>> suppose it can be adapted to a 10 Gigabit Ethernet port (or PCI).
>>>>> But I
>>>>>>>>>>> am
>>>>>>>>>>>> not sure how to do it, and I didn't find any material on this yet.
>>>>>>>>>>>>
>>>>>>>>>>>> Please let me know if you have any suggestions.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for any help,
>>>>>>>>>>>> Zhihong
>>>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> 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
>
------------------------------
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 69, Issue 9
*****************************************
