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: [RFNoC] FPGA image is 2 bytes larger than expected
(Felipe Augusto Pereira de Figueiredo)
2. rfnoc ddc block (Tobias Mitterer)
3. USRP X310 suffers from severe underflow when running ofdm
(Yang Liu)
4. Re: rfnoc ddc block (Jonathon Pendlum)
5. USRP inserts some remaining data from previous burst in head
of the next burst (Paul Elijah)
6. Re: [RFNoC] FPGA image is 2 bytes larger than expected
(Jonathon Pendlum)
7. Re: [RFNoC] FPGA image is 2 bytes larger than expected
(Juan Francisco)
8. transmitting without the host - RFNoC (J Hershberger)
9. GRC flowgraph taking longer than I think it should (Thomas Wright)
10. Re: transmitting without the host - RFNoC (Martin Braun)
11. Re: USRP X310 suffers from severe underflow when running ofdm
(Martin Braun)
12. Re: RuntimeError: basic_string::_M_construct null not valid
when using RFNoC:Radio (Martin Braun)
13. Re: X310: who generate overflow and dropped packet messages?
(Martin Braun)
14. Re: R: Install uhd on Raspberry Pi 3 (Martin Braun)
15. Re: The difference between the samp_rate in GNU Radio and
Nyquist rate (Martin Braun)
16. Re: Increase number of tx burst send timed commands in UHD
(Martin Braun)
17. Re: transmitting without the host - RFNoC (Marcus D. Leech)
18. Re: transmitting without the host - RFNoC (Nick Foster)
19. Re: uhd::io_error (Derek Kozel)
20. Re: transmitting without the host - RFNoC (J Hershberger)
21. Re: User Registers (Philipp Rudnik)
22. Re: Cannot se sent out signal in oscilloscope (Julian Arnold)
23. Re: Cannot se sent out signal in oscilloscope (Julian Arnold)
24. Re: [RFNoC] FPGA image is 2 bytes larger than expected
(Felipe Augusto Pereira de Figueiredo)
25. Re: X310-PCIe connection in Linux (do ber)
26. Re: RuntimeError: basic_string::_M_construct null not valid
when using RFNoC:Radio (Sebastian Mueller)
27. Re: Wireless data transfer (do ber)
28. Re: Wireless data transfer (Marcus M?ller)
29. Re: Wireless data transfer (Marcus M?ller)
30. Re: Cannot se sent out signal in oscilloscope (Julian Arnold)
31. Re: USRP X310 suffers from severe underflow when running ofdm
(Yang Liu)
32. Re: X310/UBX Retuning Performance (Dave NotTelling)
----------------------------------------------------------------------
Message: 1
Date: Thu, 2 Mar 2017 18:07:09 +0100
From: Felipe Augusto Pereira de Figueiredo <[email protected]>
To: Jonathon Pendlum <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] [RFNoC] FPGA image is 2 bytes larger than
expected
Message-ID:
<CA+abmwJyximd=m9Yj86=rnkxkyq-g+5hrwxqzx8o2bdb3u-...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Dear Jonathon,
Do you have any update on the 2 bytes larger bitstream issue?
I was expecting someone from ettus to give us an explanation on that
and if it is an issue.
Thanks and Best Regards,
Felipe Augusto
On Tue, Feb 28, 2017 at 9:43 AM, Felipe Augusto Pereira de Figueiredo
<[email protected]> wrote:
> Dear Jonathon,
>
> I tried what you told me. First, I ran setupenv.sh and then executed
> make X310_RFNOC_HG.
>
> The bistream was successfully generated as you can see by the messages below.
>
> Creating bitstream...
> Writing bitstream
> /home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300/build-X310_RFNOC_HG/x300.bit...
> INFO: [Vivado 12-1842] Bitgen Completed Successfully.
>
> And again, it has the same size, 15878034, as the other bitstream I
> generated with 2xDDCs, 2xDUCs and 1xFFT.
>
> -rw-rw-r-- 1 zz4fap zz4fap 15878034 Feb 27 22:47 x300.bit
>
> Could you, please, check why this difference exists? I mean, the
> difference of 2 bytes between bitstreams.
>
> While cheking the Makefile at src/uhd-fpga/usrp3/top/x300 I read what
> I think could be a clue to the problem:
>
> ## build/usrp_<product>_fpga_<image_type>.bit: Configuration
> bitstream with header
> ## build/usrp_<product>_fpga_<image_type>.bin: Configuration
> bitstream without header
>
> May the 2 bytes longer bitstream (.bit) contains a 2 bytes long header.
>
> Thanks and Best Regards,
>
> Felipe
>
> On Mon, Feb 27, 2017 at 9:07 PM, Jonathon Pendlum
> <[email protected]> wrote:
>> Hi Felipe,
>>
>> Make sure to run 'source setupenv.sh' first before make X310_RFNOC_HG
>>
>> On Mon, Feb 27, 2017 at 1:31 PM, Felipe Augusto Pereira de Figueiredo
>> <[email protected]> wrote:
>>>
>>> Hi Jonathon,
>>>
>>> Tried what you said but it didn't work. Could you please be a little
>>> bit more specific about the command I should run. I got some error
>>> regarding the syntax of the command you told me to run.
>>> See output below.
>>>
>>> Thanks and Best Regards,
>>>
>>> Felipe
>>>
>>>
>>> ---------------------------------------------------------------------------------------------------------------------------------------------------------
>>> zz4fap@imecdesktop:~/rfnoc/src/uhd-fpga/usrp3/top/x300$ make X310_RFNOC_HG
>>> make -f Makefile.x300.inc bin NAME=X310_RFNOC_HG ARCH= PART_ID=
>>> BUILD_1G=1 BUILD_10G=1 SFP0_1GBE=1 SFP1_10GBE=1 RFNOC=1 X310=1
>>> EXTRA_DEFS="BUILD_1G=1 BUILD_10G=1 SFP0_1GBE=1 SFP1_10GBE=1 RFNOC=1
>>> X310=1"
>>> find:
>>> `/home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300/build-ip/addsub_hls/solution/impl/verilog/':
>>> No such file or directory
>>> make[1]: Entering directory
>>> `/home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300'
>>> BUILDER: Checking tools...
>>> * GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)
>>> * Python 2.7.6
>>> * Vivado v2015.4.2 (64-bit)
>>> ========================================================
>>> BUILDER: Building IP ten_gig_eth_pcs_pma
>>> ========================================================
>>> BUILDER: Staging IP in build directory...
>>> BUILDER: Reserving IP location:
>>>
>>> /home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300/build-ip/ten_gig_eth_pcs_pma
>>> BUILDER: Retargeting IP to part /...
>>> ERROR: Invalid target format. Must be
>>> <arch>/<device>/<package>/<speedgrade>
>>> BUILDER: Building IP...
>>>
>>> ****** Vivado v2015.4.2 (64-bit)
>>> **** SW Build 1494164 on Fri Feb 26 04:18:54 MST 2016
>>> **** IP Build 1491208 on Wed Feb 24 03:25:39 MST 2016
>>> ** Copyright 1986-2015 Xilinx, Inc. All Rights Reserved.
>>>
>>> source
>>> /home/zz4fap/rfnoc/src/uhd-fpga/usrp3/tools/scripts/viv_generate_ip.tcl
>>> # set xci_file $::env(XCI_FILE) ;
>>> # set part_name $::env(PART_NAME) ;
>>> # set gen_example_proj $::env(GEN_EXAMPLE) ;
>>> # set synth_ip $::env(SYNTH_IP) ;
>>> # set ip_name [file rootname [file tail $xci_file]] ;
>>> # file delete -force "$xci_file.out"
>>> # create_project -part $part_name -in_memory -ip
>>> WARNING: [#UNDEF] No parts matched ''
>>> ERROR: [Coretcl 2-106] Specified part could not be found.
>>> INFO: [Common 17-206] Exiting Vivado at Mon Feb 27 20:26:39 2017...
>>> BUILDER: Releasing IP location:
>>>
>>> /home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300/build-ip/ten_gig_eth_pcs_pma
>>> make[1]: ***
>>> [/home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300/build-ip/ten_gig_eth_pcs_pma/ten_gig_eth_pcs_pma.xci.out]
>>> Error 1
>>> make[1]: Leaving directory
>>> `/home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300'
>>> make: *** [X310_RFNOC_HG] Error 2
>>>
>>> ---------------------------------------------------------------------------------------------------------------------------------------------------------
>>>
>>> On Mon, Feb 27, 2017 at 7:55 PM, Jonathon Pendlum
>>> <[email protected]> wrote:
>>> > Hi Felipe,
>>> >
>>> > What if you build the same image by running make X310_RFNOC_HG in
>>> > usrp3/top/x300? Is it still too large?
>>> >
>>> > On Mon, Feb 27, 2017 at 4:23 AM, Felipe Augusto Pereira de Figueiredo
>>> > via
>>> > USRP-users <[email protected]> wrote:
>>> >>
>>> >> Dear Sam,
>>> >>
>>> >> Many thanks for your tip, I've followed that and it worked. Just
>>> >> changed the size of the macro with the expected bitstream size.
>>> >>
>>> >> I hope someone from Ettus can explain why that problem happens and if
>>> >> it can be solved other way instead of tweaking the source code.
>>> >>
>>> >> Now the output of "uhd_usrp_probe" is like I had expected it to be.
>>> >>
>>> >> | | _____________________________________________________
>>> >> | | /
>>> >> | | | RFNoC blocks on this device:
>>> >> | | |
>>> >> | | | * DmaFIFO_0
>>> >> | | | * Radio_0
>>> >> | | | * Radio_1
>>> >> | | | * DDC_0
>>> >> | | | * DDC_1
>>> >> | | | * DUC_0
>>> >> | | | * DUC_1
>>> >> | | | * FFT_0
>>> >>
>>> >> Thanks and Best Regards,
>>> >>
>>> >> Felipe
>>> >>
>>> >> On Fri, Feb 24, 2017 at 3:27 PM, Sam Carey <[email protected]> wrote:
>>> >> > Howdy,
>>> >> >
>>> >> > I had this problem a while back. My workaround was to simply edit the
>>> >> > image
>>> >> > loader code so that it is OK with the larger file size.
>>> >> > Just do a search for the smaller byte number in the uhd/host source
>>> >> > code,
>>> >> > change it to the larger byte number, and rebuild/reinstall uhd.
>>> >> > Apparently, the byte count is not a strict requirement for image
>>> >> > loading.
>>> >> >
>>> >> > You're the second other person I've seen with this problem.
>>> >> > Maybe somebody could apply this change to the main branch or
>>> >> > something?
>>> >> >
>>> >> > -Sam
>>> >> >
>>> >> >
>>> >>
>>> >> _______________________________________________
>>> >> USRP-users mailing list
>>> >> [email protected]
>>> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>> >
>>> >
>>
>>
------------------------------
Message: 2
Date: Thu, 2 Mar 2017 19:17:47 +0100
From: "Tobias Mitterer" <[email protected]>
To: [email protected]
Subject: [USRP-users] rfnoc ddc block
Message-ID:
<trinity-629f0563-dd53-4a90-9050-4743ada0741c-1488478667929@3capp-gmx-bs48>
Content-Type: text/plain; charset="us-ascii"
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170302/5cefbb41/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 2 Mar 2017 14:19:55 -0500
From: Yang Liu <[email protected]>
To: [email protected]
Subject: [USRP-users] USRP X310 suffers from severe underflow when
running ofdm
Message-ID:
<CAD4vFMGadSZYoXSsM3vcCm-SDvVUvprHNJV=fhoqniztuqn...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear all,
Now we have USRP X310 with UBX 160 daughterboards(FPGA 33.0, FW 5.1), and
we tried to run OFDM TX code on it.
OFDM TX comes from ofdm_lookback.grc, we extracted transmitter side code
out (everything before channel model) and ran it with the device.
The problem is that the device suffers from severe underflow no matter what
sampling rate we set (from 400K to 20M ), another odd observation is that
lower sample rate seem to generate higher traffic on the Ethernet interface
(1GBASE-T). The under run issue seem to go away after sometime especially
with lower sample rate (1M or less) We ran the same code on USRP N210 (SBX)
at the same sampling rate, no underflow happens, so the application itself
can provide samples fast enough and problem should be with the device (FPGA
controller for SFP?)
We truly don't know what's going on here. Any help will be appreciated.
Thanks a lot,
Yang
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170302/83b2fdc5/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 2 Mar 2017 14:24:22 -0600
From: Jonathon Pendlum <[email protected]>
To: Tobias Mitterer <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] rfnoc ddc block
Message-ID:
<CAGdo0uRcmZX0_S4fSNGq8nonBb0cSXw+AET31Q6=um-r0ox...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Tobias,
"Input Rate" is the sample rate of the stream coming into the block.
Generally this is the sample rate you think of when you say "I want to
transmit at 10 MSPS". "Output Rate" is the sample rate of the stream being
send to the Radio Core. The radio core runs at the master clock rate, which
for the X3x0 series device is 200 MHz (unless you specifically configure it
to 184.32 MHz). So, if I wanted to transmit on at X3x0 at 10 MSPS, I would
configure Input Rate = 10e6, Output Rate = 200e6.
"Frequency (CORDIC)" should be set between (-Output Rate/2,+Output Rate/2).
Jonathon
On Thu, Mar 2, 2017 at 12:17 PM, Tobias Mitterer via USRP-users <
[email protected]> wrote:
> Hi everyone,
>
> I want to demodulate a Signal using the RFNoC DDC block and want to know
> more about it. As far as I gathered the In and Out frequency parameters in
> the block are for the decimation and the CORDIC frequency parameter is for
> the demodulation but I just can't seem to get it to work. Can someone give
> me more information or a simple example on the block as I can't find much
> information on it. I will also look at the RFNoC DDC example that exists
> but that doesn't give me any information if the three parameters are
> somehow intertwined/connected.
>
> Thanks in advance,
> Tobias
>
> _______________________________________________
> 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/20170302/c2f199a7/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 2 Mar 2017 23:37:58 +0300
From: Paul Elijah <[email protected]>
To: [email protected]
Subject: [USRP-users] USRP inserts some remaining data from previous
burst in head of the next burst
Message-ID:
<caj8gl+hgtafrnfz0yxfffuk+xdc8hkdukhpfakqhwb49zd4...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
For my project I am using two USRP B210. Devices periodically and
alternately transmit bursts/pulses (simple sine signal) to each other:
while one device transmits pulse another device receive it. Both USRP are
connected to a common PPS source for time synchronization. I am using
stream commands (USRP method issue_stream_cmd) for receiving pulses.
Receiving of pulse begins only after some time offset (half of pulse
duration) relative to the transmission start. Before starting pulse
exchange my application issues "zero" stream command in order to exclude
problem with a big enough time delay (at least for my project) for the
first stream command (this problem has already been described here
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-October/016134.html).
So application firstly receives some noise data as "zero" burst. But in the
head of first burst USRP also puts some noise samples (~20 samples for
sample rate 195312Hz) before "pulse" samples shifting their tail to the
second burst. And remaining samples from second burst are shifted to the
third and so on (just look on attached image). How can I solve this problem?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170302/25a51727/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: shifted_bursts.png
Type: image/png
Size: 122475 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170302/25a51727/attachment-0001.png>
------------------------------
Message: 6
Date: Thu, 2 Mar 2017 15:58:18 -0600
From: Jonathon Pendlum <[email protected]>
To: Felipe Augusto Pereira de Figueiredo <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] [RFNoC] FPGA image is 2 bytes larger than
expected
Message-ID:
<cagdo0urgeqd4dcuqlz8gyw8zfv3xe9zvvemswfjjttcoavb...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Felipe,
I do not currently have an explanation why the Xilinx tools generate a
bitstream with a different file size. When I run your build command, the
output bitstream size is 15878032. What OS / Xilinx tools are you building
with?
Jonathon
On Thu, Mar 2, 2017 at 11:07 AM, Felipe Augusto Pereira de Figueiredo <
[email protected]> wrote:
> Dear Jonathon,
>
> Do you have any update on the 2 bytes larger bitstream issue?
>
> I was expecting someone from ettus to give us an explanation on that
> and if it is an issue.
>
> Thanks and Best Regards,
>
> Felipe Augusto
>
> On Tue, Feb 28, 2017 at 9:43 AM, Felipe Augusto Pereira de Figueiredo
> <[email protected]> wrote:
> > Dear Jonathon,
> >
> > I tried what you told me. First, I ran setupenv.sh and then executed
> > make X310_RFNOC_HG.
> >
> > The bistream was successfully generated as you can see by the messages
> below.
> >
> > Creating bitstream...
> > Writing bitstream
> > /home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300/build-
> X310_RFNOC_HG/x300.bit...
> > INFO: [Vivado 12-1842] Bitgen Completed Successfully.
> >
> > And again, it has the same size, 15878034, as the other bitstream I
> > generated with 2xDDCs, 2xDUCs and 1xFFT.
> >
> > -rw-rw-r-- 1 zz4fap zz4fap 15878034 Feb 27 22:47 x300.bit
> >
> > Could you, please, check why this difference exists? I mean, the
> > difference of 2 bytes between bitstreams.
> >
> > While cheking the Makefile at src/uhd-fpga/usrp3/top/x300 I read what
> > I think could be a clue to the problem:
> >
> > ## build/usrp_<product>_fpga_<image_type>.bit: Configuration
> > bitstream with header
> > ## build/usrp_<product>_fpga_<image_type>.bin: Configuration
> > bitstream without header
> >
> > May the 2 bytes longer bitstream (.bit) contains a 2 bytes long header.
> >
> > Thanks and Best Regards,
> >
> > Felipe
> >
> > On Mon, Feb 27, 2017 at 9:07 PM, Jonathon Pendlum
> > <[email protected]> wrote:
> >> Hi Felipe,
> >>
> >> Make sure to run 'source setupenv.sh' first before make X310_RFNOC_HG
> >>
> >> On Mon, Feb 27, 2017 at 1:31 PM, Felipe Augusto Pereira de Figueiredo
> >> <[email protected]> wrote:
> >>>
> >>> Hi Jonathon,
> >>>
> >>> Tried what you said but it didn't work. Could you please be a little
> >>> bit more specific about the command I should run. I got some error
> >>> regarding the syntax of the command you told me to run.
> >>> See output below.
> >>>
> >>> Thanks and Best Regards,
> >>>
> >>> Felipe
> >>>
> >>>
> >>> ------------------------------------------------------------
> ------------------------------------------------------------
> ---------------------------------
> >>> zz4fap@imecdesktop:~/rfnoc/src/uhd-fpga/usrp3/top/x300$ make
> X310_RFNOC_HG
> >>> make -f Makefile.x300.inc bin NAME=X310_RFNOC_HG ARCH= PART_ID=
> >>> BUILD_1G=1 BUILD_10G=1 SFP0_1GBE=1 SFP1_10GBE=1 RFNOC=1 X310=1
> >>> EXTRA_DEFS="BUILD_1G=1 BUILD_10G=1 SFP0_1GBE=1 SFP1_10GBE=1 RFNOC=1
> >>> X310=1"
> >>> find:
> >>> `/home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300/build-ip/
> addsub_hls/solution/impl/verilog/':
> >>> No such file or directory
> >>> make[1]: Entering directory
> >>> `/home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300'
> >>> BUILDER: Checking tools...
> >>> * GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)
> >>> * Python 2.7.6
> >>> * Vivado v2015.4.2 (64-bit)
> >>> ========================================================
> >>> BUILDER: Building IP ten_gig_eth_pcs_pma
> >>> ========================================================
> >>> BUILDER: Staging IP in build directory...
> >>> BUILDER: Reserving IP location:
> >>>
> >>> /home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300/build-ip/
> ten_gig_eth_pcs_pma
> >>> BUILDER: Retargeting IP to part /...
> >>> ERROR: Invalid target format. Must be
> >>> <arch>/<device>/<package>/<speedgrade>
> >>> BUILDER: Building IP...
> >>>
> >>> ****** Vivado v2015.4.2 (64-bit)
> >>> **** SW Build 1494164 on Fri Feb 26 04:18:54 MST 2016
> >>> **** IP Build 1491208 on Wed Feb 24 03:25:39 MST 2016
> >>> ** Copyright 1986-2015 Xilinx, Inc. All Rights Reserved.
> >>>
> >>> source
> >>> /home/zz4fap/rfnoc/src/uhd-fpga/usrp3/tools/scripts/viv_
> generate_ip.tcl
> >>> # set xci_file $::env(XCI_FILE) ;
> >>> # set part_name $::env(PART_NAME) ;
> >>> # set gen_example_proj $::env(GEN_EXAMPLE) ;
> >>> # set synth_ip $::env(SYNTH_IP) ;
> >>> # set ip_name [file rootname [file tail $xci_file]] ;
> >>> # file delete -force "$xci_file.out"
> >>> # create_project -part $part_name -in_memory -ip
> >>> WARNING: [#UNDEF] No parts matched ''
> >>> ERROR: [Coretcl 2-106] Specified part could not be found.
> >>> INFO: [Common 17-206] Exiting Vivado at Mon Feb 27 20:26:39 2017...
> >>> BUILDER: Releasing IP location:
> >>>
> >>> /home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300/build-ip/
> ten_gig_eth_pcs_pma
> >>> make[1]: ***
> >>> [/home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300/build-ip/
> ten_gig_eth_pcs_pma/ten_gig_eth_pcs_pma.xci.out]
> >>> Error 1
> >>> make[1]: Leaving directory
> >>> `/home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300'
> >>> make: *** [X310_RFNOC_HG] Error 2
> >>>
> >>> ------------------------------------------------------------
> ------------------------------------------------------------
> ---------------------------------
> >>>
> >>> On Mon, Feb 27, 2017 at 7:55 PM, Jonathon Pendlum
> >>> <[email protected]> wrote:
> >>> > Hi Felipe,
> >>> >
> >>> > What if you build the same image by running make X310_RFNOC_HG in
> >>> > usrp3/top/x300? Is it still too large?
> >>> >
> >>> > On Mon, Feb 27, 2017 at 4:23 AM, Felipe Augusto Pereira de Figueiredo
> >>> > via
> >>> > USRP-users <[email protected]> wrote:
> >>> >>
> >>> >> Dear Sam,
> >>> >>
> >>> >> Many thanks for your tip, I've followed that and it worked. Just
> >>> >> changed the size of the macro with the expected bitstream size.
> >>> >>
> >>> >> I hope someone from Ettus can explain why that problem happens and
> if
> >>> >> it can be solved other way instead of tweaking the source code.
> >>> >>
> >>> >> Now the output of "uhd_usrp_probe" is like I had expected it to be.
> >>> >>
> >>> >> | | _____________________________________________________
> >>> >> | | /
> >>> >> | | | RFNoC blocks on this device:
> >>> >> | | |
> >>> >> | | | * DmaFIFO_0
> >>> >> | | | * Radio_0
> >>> >> | | | * Radio_1
> >>> >> | | | * DDC_0
> >>> >> | | | * DDC_1
> >>> >> | | | * DUC_0
> >>> >> | | | * DUC_1
> >>> >> | | | * FFT_0
> >>> >>
> >>> >> Thanks and Best Regards,
> >>> >>
> >>> >> Felipe
> >>> >>
> >>> >> On Fri, Feb 24, 2017 at 3:27 PM, Sam Carey <[email protected]>
> wrote:
> >>> >> > Howdy,
> >>> >> >
> >>> >> > I had this problem a while back. My workaround was to simply edit
> the
> >>> >> > image
> >>> >> > loader code so that it is OK with the larger file size.
> >>> >> > Just do a search for the smaller byte number in the uhd/host
> source
> >>> >> > code,
> >>> >> > change it to the larger byte number, and rebuild/reinstall uhd.
> >>> >> > Apparently, the byte count is not a strict requirement for image
> >>> >> > loading.
> >>> >> >
> >>> >> > You're the second other person I've seen with this problem.
> >>> >> > Maybe somebody could apply this change to the main branch or
> >>> >> > something?
> >>> >> >
> >>> >> > -Sam
> >>> >> >
> >>> >> >
> >>> >>
> >>> >> _______________________________________________
> >>> >> 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/20170302/816a2b27/attachment-0001.html>
------------------------------
Message: 7
Date: Thu, 2 Mar 2017 17:42:43 -0500
From: Juan Francisco <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: Felipe Augusto Pereira de Figueiredo <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] [RFNoC] FPGA image is 2 bytes larger than
expected
Message-ID:
<cace1ov_cuwsft3wys+ij0dlwzxeellnhzx7kaddmfuwyyh2...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Fwiw, I have run into this issue occasionally as well. The fix is to hack
the image loader.
-Juan
On Thu, Mar 2, 2017 at 4:58 PM, Jonathon Pendlum via USRP-users <
[email protected]> wrote:
> Hi Felipe,
>
> I do not currently have an explanation why the Xilinx tools generate a
> bitstream with a different file size. When I run your build command, the
> output bitstream size is 15878032. What OS / Xilinx tools are you building
> with?
>
>
>
> Jonathon
>
> On Thu, Mar 2, 2017 at 11:07 AM, Felipe Augusto Pereira de Figueiredo <
> [email protected]> wrote:
>
>> Dear Jonathon,
>>
>> Do you have any update on the 2 bytes larger bitstream issue?
>>
>> I was expecting someone from ettus to give us an explanation on that
>> and if it is an issue.
>>
>> Thanks and Best Regards,
>>
>> Felipe Augusto
>>
>> On Tue, Feb 28, 2017 at 9:43 AM, Felipe Augusto Pereira de Figueiredo
>> <[email protected]> wrote:
>> > Dear Jonathon,
>> >
>> > I tried what you told me. First, I ran setupenv.sh and then executed
>> > make X310_RFNOC_HG.
>> >
>> > The bistream was successfully generated as you can see by the messages
>> below.
>> >
>> > Creating bitstream...
>> > Writing bitstream
>> > /home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300/build-X310_
>> RFNOC_HG/x300.bit...
>> > INFO: [Vivado 12-1842] Bitgen Completed Successfully.
>> >
>> > And again, it has the same size, 15878034, as the other bitstream I
>> > generated with 2xDDCs, 2xDUCs and 1xFFT.
>> >
>> > -rw-rw-r-- 1 zz4fap zz4fap 15878034 Feb 27 22:47 x300.bit
>> >
>> > Could you, please, check why this difference exists? I mean, the
>> > difference of 2 bytes between bitstreams.
>> >
>> > While cheking the Makefile at src/uhd-fpga/usrp3/top/x300 I read what
>> > I think could be a clue to the problem:
>> >
>> > ## build/usrp_<product>_fpga_<image_type>.bit: Configuration
>> > bitstream with header
>> > ## build/usrp_<product>_fpga_<image_type>.bin: Configuration
>> > bitstream without header
>> >
>> > May the 2 bytes longer bitstream (.bit) contains a 2 bytes long header.
>> >
>> > Thanks and Best Regards,
>> >
>> > Felipe
>> >
>> > On Mon, Feb 27, 2017 at 9:07 PM, Jonathon Pendlum
>> > <[email protected]> wrote:
>> >> Hi Felipe,
>> >>
>> >> Make sure to run 'source setupenv.sh' first before make X310_RFNOC_HG
>> >>
>> >> On Mon, Feb 27, 2017 at 1:31 PM, Felipe Augusto Pereira de Figueiredo
>> >> <[email protected]> wrote:
>> >>>
>> >>> Hi Jonathon,
>> >>>
>> >>> Tried what you said but it didn't work. Could you please be a little
>> >>> bit more specific about the command I should run. I got some error
>> >>> regarding the syntax of the command you told me to run.
>> >>> See output below.
>> >>>
>> >>> Thanks and Best Regards,
>> >>>
>> >>> Felipe
>> >>>
>> >>>
>> >>> ------------------------------------------------------------
>> ------------------------------------------------------------
>> ---------------------------------
>> >>> zz4fap@imecdesktop:~/rfnoc/src/uhd-fpga/usrp3/top/x300$ make
>> X310_RFNOC_HG
>> >>> make -f Makefile.x300.inc bin NAME=X310_RFNOC_HG ARCH= PART_ID=
>> >>> BUILD_1G=1 BUILD_10G=1 SFP0_1GBE=1 SFP1_10GBE=1 RFNOC=1 X310=1
>> >>> EXTRA_DEFS="BUILD_1G=1 BUILD_10G=1 SFP0_1GBE=1 SFP1_10GBE=1 RFNOC=1
>> >>> X310=1"
>> >>> find:
>> >>> `/home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300/build-ip/add
>> sub_hls/solution/impl/verilog/':
>> >>> No such file or directory
>> >>> make[1]: Entering directory
>> >>> `/home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300'
>> >>> BUILDER: Checking tools...
>> >>> * GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)
>> >>> * Python 2.7.6
>> >>> * Vivado v2015.4.2 (64-bit)
>> >>> ========================================================
>> >>> BUILDER: Building IP ten_gig_eth_pcs_pma
>> >>> ========================================================
>> >>> BUILDER: Staging IP in build directory...
>> >>> BUILDER: Reserving IP location:
>> >>>
>> >>> /home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300/build-ip/ten_
>> gig_eth_pcs_pma
>> >>> BUILDER: Retargeting IP to part /...
>> >>> ERROR: Invalid target format. Must be
>> >>> <arch>/<device>/<package>/<speedgrade>
>> >>> BUILDER: Building IP...
>> >>>
>> >>> ****** Vivado v2015.4.2 (64-bit)
>> >>> **** SW Build 1494164 on Fri Feb 26 04:18:54 MST 2016
>> >>> **** IP Build 1491208 on Wed Feb 24 03:25:39 MST 2016
>> >>> ** Copyright 1986-2015 Xilinx, Inc. All Rights Reserved.
>> >>>
>> >>> source
>> >>> /home/zz4fap/rfnoc/src/uhd-fpga/usrp3/tools/scripts/viv_gene
>> rate_ip.tcl
>> >>> # set xci_file $::env(XCI_FILE) ;
>> >>> # set part_name $::env(PART_NAME) ;
>> >>> # set gen_example_proj $::env(GEN_EXAMPLE) ;
>> >>> # set synth_ip $::env(SYNTH_IP) ;
>> >>> # set ip_name [file rootname [file tail $xci_file]] ;
>> >>> # file delete -force "$xci_file.out"
>> >>> # create_project -part $part_name -in_memory -ip
>> >>> WARNING: [#UNDEF] No parts matched ''
>> >>> ERROR: [Coretcl 2-106] Specified part could not be found.
>> >>> INFO: [Common 17-206] Exiting Vivado at Mon Feb 27 20:26:39 2017...
>> >>> BUILDER: Releasing IP location:
>> >>>
>> >>> /home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300/build-ip/ten_
>> gig_eth_pcs_pma
>> >>> make[1]: ***
>> >>> [/home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300/build-ip/ten
>> _gig_eth_pcs_pma/ten_gig_eth_pcs_pma.xci.out]
>> >>> Error 1
>> >>> make[1]: Leaving directory
>> >>> `/home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300'
>> >>> make: *** [X310_RFNOC_HG] Error 2
>> >>>
>> >>> ------------------------------------------------------------
>> ------------------------------------------------------------
>> ---------------------------------
>> >>>
>> >>> On Mon, Feb 27, 2017 at 7:55 PM, Jonathon Pendlum
>> >>> <[email protected]> wrote:
>> >>> > Hi Felipe,
>> >>> >
>> >>> > What if you build the same image by running make X310_RFNOC_HG in
>> >>> > usrp3/top/x300? Is it still too large?
>> >>> >
>> >>> > On Mon, Feb 27, 2017 at 4:23 AM, Felipe Augusto Pereira de
>> Figueiredo
>> >>> > via
>> >>> > USRP-users <[email protected]> wrote:
>> >>> >>
>> >>> >> Dear Sam,
>> >>> >>
>> >>> >> Many thanks for your tip, I've followed that and it worked. Just
>> >>> >> changed the size of the macro with the expected bitstream size.
>> >>> >>
>> >>> >> I hope someone from Ettus can explain why that problem happens and
>> if
>> >>> >> it can be solved other way instead of tweaking the source code.
>> >>> >>
>> >>> >> Now the output of "uhd_usrp_probe" is like I had expected it to be.
>> >>> >>
>> >>> >> | | _____________________________________________________
>> >>> >> | | /
>> >>> >> | | | RFNoC blocks on this device:
>> >>> >> | | |
>> >>> >> | | | * DmaFIFO_0
>> >>> >> | | | * Radio_0
>> >>> >> | | | * Radio_1
>> >>> >> | | | * DDC_0
>> >>> >> | | | * DDC_1
>> >>> >> | | | * DUC_0
>> >>> >> | | | * DUC_1
>> >>> >> | | | * FFT_0
>> >>> >>
>> >>> >> Thanks and Best Regards,
>> >>> >>
>> >>> >> Felipe
>> >>> >>
>> >>> >> On Fri, Feb 24, 2017 at 3:27 PM, Sam Carey <[email protected]>
>> wrote:
>> >>> >> > Howdy,
>> >>> >> >
>> >>> >> > I had this problem a while back. My workaround was to simply
>> edit the
>> >>> >> > image
>> >>> >> > loader code so that it is OK with the larger file size.
>> >>> >> > Just do a search for the smaller byte number in the uhd/host
>> source
>> >>> >> > code,
>> >>> >> > change it to the larger byte number, and rebuild/reinstall uhd.
>> >>> >> > Apparently, the byte count is not a strict requirement for image
>> >>> >> > loading.
>> >>> >> >
>> >>> >> > You're the second other person I've seen with this problem.
>> >>> >> > Maybe somebody could apply this change to the main branch or
>> >>> >> > something?
>> >>> >> >
>> >>> >> > -Sam
>> >>> >> >
>> >>> >> >
>> >>> >>
>> >>> >> _______________________________________________
>> >>> >> 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/20170302/304167cf/attachment-0001.html>
------------------------------
Message: 8
Date: Thu, 2 Mar 2017 19:12:56 -0500
From: J Hershberger <[email protected]>
To: [email protected]
Subject: [USRP-users] transmitting without the host - RFNoC
Message-ID:
<canufeqxihdf7w-0ru9noqqbtqn8wg+9twruj_-nazlhqweg...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I am interested in transmitting directly from a stored/generated waveform @
200 MS/s on the X310. I saw in this post
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-July/021185.html>that
transmitting directly from the siggen noc-block is not supported. Is there
any idea why this is not currently possible? Is there a specific
limitation imposed by RFNoC, or is this functionality just not implemented
yet? How difficult of a challenge does this problem pose?
Cheers,
-Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170302/98a355db/attachment-0001.html>
------------------------------
Message: 9
Date: Thu, 2 Mar 2017 19:19:39 -0500
From: Thomas Wright <[email protected]>
To: [email protected]
Subject: [USRP-users] GRC flowgraph taking longer than I think it
should
Message-ID:
<CAB=d6pgkq1sq3syfssyy5ns7gdbh807zqjjnketjbro9-9y...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
I have a simple flowgraph:
usrp n210 -> low pass filter -> stream to vector decimator -> msg queue sink
with important parameters:
sample rate = .195312 MSps
vector length = 128
decimation rate = 16
msg queue length = 1
and my application is trying to capture samples of a given signal as fast
as possible. I'm using a GRC generated python script that I'm editing, and
looking at time stamps I'm creating with datetime.now(). My general code is:
TIMESTAMP1
flowgraph.usrp.set_center_freq(center freq)
TIMESTAMP2
flowgraph.set_sample_rate(samplerate) #does usrp, filter, etc.
TIMESTAMP3
flowgraph.start()
TIMESTAMP4
flowgraph.msg_queue.delete_head() #waits for there to be data in the queue
TIMESTAMP5
flowgraph.stop()
average difference between timestamps:
1 -> 2 = .5ms
2 -> 3 = 1ms
3 -> 4 = 4ms
4 -> 5 = 80ms
My issue is that I think the time between timestamps 4 and 5 should take
about 10ms:
128 samp/vector * 16 vector * (1second / 195312 samp) =~ 10ms.
My questions that arise from this:
How much overhead SWIG/python introduce, could that be significantly
hampering performance? Would a c++ version perform significantly better?
Would a higher end usrp perform significantly better?
How close I can expect to get to the theoretical minimum?
I appreciate any information anyone could provide. Thanks very much.
-Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170302/7f7e73d7/attachment-0001.html>
------------------------------
Message: 10
Date: Thu, 2 Mar 2017 16:50:47 -0800
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] transmitting without the host - RFNoC
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Jeremy,
siggen -> radio does indeed work, with some limitations. Generic
host-less RFNoC flow graphs do not work (e.g, radio -> radio) but that's
because it's a feature that hasn't been implemented yet. It's not a
simple fix, it requires some restructuring of the driver code.
Cheers,
Martin
On 03/02/2017 04:12 PM, J Hershberger via USRP-users wrote:
> I am interested in transmitting directly from a stored/generated
> waveform @ 200 MS/s on the X310. I saw in this post
> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-July/021185.html>that
> transmitting directly from the siggen noc-block is not supported. Is
> there any idea why this is not currently possible? Is there a specific
> limitation imposed by RFNoC, or is this functionality just not
> implemented yet? How difficult of a challenge does this problem pose?
>
> Cheers,
>
> -Jeremy
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 11
Date: Thu, 2 Mar 2017 16:54:33 -0800
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP X310 suffers from severe underflow when
running ofdm
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Yang,
we have confirmed some issues with the 3.10 UHD code you're running at
really high rates, but I'm not sure why they wouldn't work with lower rates.
Can you confirm that other apps also fail, e.g. uhd_siggen_gui?
Cheers,
Martin
On 03/02/2017 11:19 AM, Yang Liu via USRP-users wrote:
> Dear all,
>
> Now we have USRP X310 with UBX 160 daughterboards(FPGA 33.0, FW 5.1),
> and we tried to run OFDM TX code on it.
>
> OFDM TX comes from ofdm_lookback.grc, we extracted transmitter side code
> out (everything before channel model) and ran it with the device.
>
> The problem is that the device suffers from severe underflow no matter
> what sampling rate we set (from 400K to 20M ), another odd observation
> is that lower sample rate seem to generate higher traffic on the
> Ethernet interface (1GBASE-T). The under run issue seem to go away after
> sometime especially with lower sample rate (1M or less) We ran the same
> code on USRP N210 (SBX) at the same sampling rate, no underflow happens,
> so the application itself can provide samples fast enough and problem
> should be with the device (FPGA controller for SFP?)
>
> We truly don't know what's going on here. Any help will be appreciated.
>
> Thanks a lot,
> Yang
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 12
Date: Thu, 2 Mar 2017 16:55:40 -0800
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] RuntimeError: basic_string::_M_construct
null not valid when using RFNoC:Radio
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Can you please post the output of uhd_usrp_probe?
-- M
On 03/01/2017 09:14 AM, Sebastian Mueller via USRP-users wrote:
> Hi list,
>
> I'm currently trying to get a very basic RFNoC flowgraph running that
> looks like this:
>
> [RFNoC: Radio] -> [RFNoC: DDC] -> [RFNoC: DmaFIFO] -> [QT GUI Frequency
> Sink]
>
> When I try to run it, I get the following error:
>
> Traceback (most recent call last):
> File "/home/user/src/rfnoc/examples/top_block.py", line 307, in <module>
> main()
> File "/home/user/src/rfnoc/examples/top_block.py", line 295, in main
> tb = top_block_cls()
> File "/home/user/src/rfnoc/examples/top_block.py", line 90, in __init__
> 0, -1
> File "/usr/local/lib/python2.7/dist-packages/ettus/ettus_swig.py",
> line 2706, in make
> return _ettus_swig.rfnoc_radio_make(dev, tx_stream_args,
> rx_stream_args, radio_select, device_select)
> RuntimeError: basic_string::_M_construct null not valid
>
> I have tried with Swig version 2.0.4 as well as 3.0.8 with the same
> result. Also, I have switched DDC with DmaFIFO with no success.
> UHD, gr-ettus and fpga are all newest versions from GitHub repos. Any
> idea how I can fix this error?
>
> Cheers,
> Sebastian
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 13
Date: Thu, 2 Mar 2017 16:58:51 -0800
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] X310: who generate overflow and dropped
packet messages?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
To expand on that:
- "O" is signalled by the radio. It sends a packet to the host to notify
that an overrun occurred.
- "D" is identified (and thus signalled) by the host.
When the radio signals an overrun, it sends it directly to the host,
bypassing the DSP blocks.
3) Is not straightforward, but we're working on expanding the RFNoC API
to allow exactly that.
Cheers,
Martin
On 03/02/2017 04:50 AM, Stefano Bettelli via USRP-users wrote:
> Hi
>
>>> 1) who is responsible for generate the overflow (and dropped) messages?
>
> The messages are generated inside the function get_aligned_buffs() in
> <UHD_ROOT>/host/lib/transport/super_recv_packet_handler.hpp and sent to the
> UHD_MSG(fastpath) stream.
>
> You can even intercept them if you provide a callback with
> uhd::msg::register_handler.
>
> I would assume that the error conditions are detected by the part of the UHD
> system that resides in your PC, not by the FPGA, but I may be wrong.
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 14
Date: Thu, 2 Mar 2017 17:05:54 -0800
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] R: Install uhd on Raspberry Pi 3
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Compile against maint branch, and you'll be fine. In the meantime, let
us reach out to SRS to fix this.
Cheers,
M
On 03/02/2017 12:53 AM, Crozzoli Maurizio via USRP-users wrote:
> srsLTE
>
> -----Messaggio originale-----
> Da: USRP-users [mailto:[email protected]] Per conto di
> Martin Braun via USRP-users
> Inviato: gioved? 2 marzo 2017 01:36
> A: [email protected]
> Oggetto: Re: [USRP-users] Install uhd on Raspberry Pi 3
>
> uhd::msg was removed on master branch recently (see my post with subject
> "Logging Infrastructure changes on master branch"). What's the software
> you're compiling?
>
> -- M
>
> On 03/01/2017 03:15 PM, Disco Daniele via USRP-users wrote:
>> Hi!
>>
>> In these days I'm trying to install the uhd library on Raspberry Pi 3
>> Model B.
>>
>> Starting from
>>
>> https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Tool
>> chain_(UHD_and_GNU_Radio)_on_Linux
>> <https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Too
>> lchain_%28UHD_and_GNU_Radio%29_on_Linux>, I used like image for the Pi
>> ubuntu mate.
>>
>> Is a porting of ubuntu for the Pi with version 16.04.
>>
>> I erased all the applications non
>> necessary, upgraded the distribution and installed all the application
>> reported for 16.04 (fyi some packages are reported twice like
>> doxygen).
>>
>> Than I used the uhd-master version (using the download from uhd github
>> site) and at the end I installed uhd.
>>
>> Running the tests no error was reported.
>>
>> Than I compiled another sw that use the namespace uhd::msg and it
>> failed because the namespace in the master is not present (if you look
>> in /usr/local/include/uhd/utils/msg.hpp is not present).
>>
>>
>> Looking in the repository I verified that in the master distribution
>> this header file is not present but in the other releases (like the
>> last
>> one) this header is present.
>>
>>
>> So using the procedure
>>
>> git clone https://github.com/EttusResearch/uhd
>> cd uhd
>>
>> git checkout release_00X_00y_00z
>>
>> I download the last release of uhd. I ported this directory on
>> raspberry pi and the compilation goes on just to build the uhd.so
>> library.
>>
>> Then compiling the first of test example the code crash for errors.
>>
>> Please, could you help me to solve this strange case?
>> Thank you
>> Daniele
>> PS: If I'm interested only on uhd but not in gnuradio, it is possible
>> to separate in the page
>> https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Tool
>> chain_(UHD_and_GNU_Radio)_on_Linux
>> <https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Too
>> lchain_%28UHD_and_GNU_Radio%29_on_Linux>,
>>
>> the apps/libs necessary for uhd respect to the apps/libs necessary to
>> gnuradio.
>> Thank you again
>>
>>
>>
>> Questo messaggio e i suoi allegati sono indirizzati esclusivamente
>> alle persone indicate. La diffusione, copia o qualsiasi altra azione
>> derivante dalla conoscenza di queste informazioni sono rigorosamente
>> vietate. Qualora abbiate ricevuto questo documento per errore siete
>> cortesemente pregati di darne immediata comunicazione al mittente e di
>> provvedere alla sua distruzione, Grazie.
>>
>> /This e-mail and any attachments// is //confidential and may contain
>> privileged information intended for the addressee(s) only.
>> Dissemination, copying, printing or use by anybody else is unauthorised.
>> If you are not the intended recipient, please delete this message and
>> any attachments and advise the sender by return e-mail, Thanks./
>>
>> *rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se
>> non ? necessario.*
>>
>>
>>
>> _______________________________________________
>> 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
>
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
> abbiate ricevuto questo documento per errore siete cortesemente pregati di
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie.
>
> This e-mail and any attachments is confidential and may contain privileged
> information intended for the addressee(s) only. Dissemination, copying,
> printing or use by anybody else is unauthorised. If you are not the intended
> recipient, please delete this message and any attachments and advise the
> sender by return e-mail, Thanks.
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 15
Date: Thu, 2 Mar 2017 17:07:31 -0800
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: Re: [USRP-users] The difference between the samp_rate in GNU
Radio and Nyquist rate
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Thanks Nate :)
-- M
On 03/01/2017 05:46 PM, Nate Temple wrote:
> Hi Bob,
>
> Just clarifying a value in Martin's reply:
>
> "So, in a B210, let's say you set the sampling rate to 10 MHz, and a
> center frequency of 900 MHz. Then, you will get the spectrum from 890
> MHz to 910 MHz *in complex baseband*."
>
> Should be "sampling rate to 20 MHz..." for that example.
>
> Regards,
> Nate
>
>
>
>> On Mar 1, 2017, at 5:31 PM, Martin Braun via USRP-users
>> <[email protected]> wrote:
>>
>> Bob,
>>
>> we tend to avoid the term 'Nyquist Rate' because it often comes up in
>> DSP 101 classes along with the (incomplete/incorrect) statement that
>> "the sampling rate must be twice the highest frequency".
>>
>> Since we're dealing with complex samples, the width of any Nyquist zone
>> is the sampling rate, i.e., the number of *complex* samples per second.
>>
>> So, in a B210, let's say you set the sampling rate to 10 MHz, and a
>> center frequency of 900 MHz. Then, you will get the spectrum from 890
>> MHz to 910 MHz *in complex baseband*.
>>
>> A 20 kHz signal won't get picked up with a B210, which goes down to 70
>> MHz. But let's say it did, you could either set your frequency to 20
>> kHz, and then you would have you signal at baseband, or you set your
>> frequency to 0 Hz, and do the mixing in software. Yes, GNU Radio would
>> let you do that.
>>
>> -- M
>>
>> On 02/27/2017 11:33 PM, Bob via USRP-users wrote:
>>> Hello,
>>> How to understand the sample rate in the DSP and the sample rate in the
>>> hardware?
>>>
>>> In generally, we use the USRP B210 to receive the RF signal, and finally
>>> get the baseband signal (the signal carrier frequency is 0Hz)
>>> and the lower IF signal (assuming the carrier frequency is 20kHz), then
>>> what are these two cases of Nyquist rate?
>>>
>>> And, then use USRP B210 to process this signal, and what is the sample
>>> rate in the block? Is it Nyquist rate?
>>>
>>> Finally, If a low-IF signal with a carrier frequency of 20 kHZ is
>>> down-converted to a baseband signal (carrier frequency 0 Hz),
>>> is it possible to implement blocks in GNU Radio using the C ++ language?
>>>
>>> Thank you very much for your answers. I am looking forward to your
>>> reply as soon as possible and as detailed as possible.
>>> Thanks!
>>>
>>> Bob
>>>
>>>
>>>
>>> _______________________________________________
>>> 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: 16
Date: Thu, 2 Mar 2017 17:08:44 -0800
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Increase number of tx burst send timed
commands in UHD
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Jacob,
how many commands do you want to queue up?
You can increase the command queue size in the FPGA, but I'm interested
what exactly you're trying to achieve.
-- M
On 03/01/2017 01:34 PM, jacob.cooper--- via USRP-users wrote:
> Hello,
>
>
>
> Does anyone know how to increase the buffer size for the number of sends
> that I can load in the future with successive calls to the send function
> in UHD?
>
>
>
> I am using an X310 over 10 Gigabit Ethernet with UHD 3.11. I want to be
> able to get very reliable TX sends at specific times in the future but
> occasionally the Linux OS gets held up and delays the delivery of the
> send to the X310. So if you buffer numerous send commands, any hang-ups
> in the OS can be alleviated and bursts will be sent at the correct time.
>
>
>
> Anyone have this buffering experience or suggestions?
>
>
>
> Jacob Cooper
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 17
Date: Thu, 02 Mar 2017 20:13:42 -0500
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] transmitting without the host - RFNoC
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 03/02/2017 07:50 PM, Martin Braun via USRP-users wrote:
> Jeremy,
>
> siggen -> radio does indeed work, with some limitations. Generic
> host-less RFNoC flow graphs do not work (e.g, radio -> radio) but that's
> because it's a feature that hasn't been implemented yet. It's not a
> simple fix, it requires some restructuring of the driver code.
>
> Cheers,
> Martin
There's the whole "setup of the hardware" thing which conceivably
*could* be done in the FPGA (I'm thinking things like understanding how
to set gain, frequency, etc), but would take up a lot of space in the
FPGA, and it's near-trivial for the host to do that.
>
> On 03/02/2017 04:12 PM, J Hershberger via USRP-users wrote:
>> I am interested in transmitting directly from a stored/generated
>> waveform @ 200 MS/s on the X310. I saw in this post
>> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-July/021185.html>that
>> transmitting directly from the siggen noc-block is not supported. Is
>> there any idea why this is not currently possible? Is there a specific
>> limitation imposed by RFNoC, or is this functionality just not
>> implemented yet? How difficult of a challenge does this problem pose?
>>
>> Cheers,
>>
>> -Jeremy
>>
>>
>> _______________________________________________
>> 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: 18
Date: Fri, 03 Mar 2017 01:19:47 +0000
From: Nick Foster <[email protected]>
To: "Marcus D. Leech" <[email protected]>, [email protected]
Subject: Re: [USRP-users] transmitting without the host - RFNoC
Message-ID:
<ca+jmmq8cqw-fnrnwehdmf3h1+rry_hyupxd-r-lla_pccch...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
It is not difficult to configure a radio-radio RFNoC flowgraph, either in
plain UHD or in Gnuradio with gr-ettus, but a few modifications are
necessary to UHD and gr-ettus. I can put together a tutorial if folks are
interested.
--n
On Thu, Mar 2, 2017, 5:14 PM Marcus D. Leech via USRP-users <
[email protected]> wrote:
> On 03/02/2017 07:50 PM, Martin Braun via USRP-users wrote:
> > Jeremy,
> >
> > siggen -> radio does indeed work, with some limitations. Generic
> > host-less RFNoC flow graphs do not work (e.g, radio -> radio) but that's
> > because it's a feature that hasn't been implemented yet. It's not a
> > simple fix, it requires some restructuring of the driver code.
> >
> > Cheers,
> > Martin
> There's the whole "setup of the hardware" thing which conceivably
> *could* be done in the FPGA (I'm thinking things like understanding how
> to set gain, frequency, etc), but would take up a lot of space in the
> FPGA, and it's near-trivial for the host to do that.
>
>
> >
> > On 03/02/2017 04:12 PM, J Hershberger via USRP-users wrote:
> >> I am interested in transmitting directly from a stored/generated
> >> waveform @ 200 MS/s on the X310. I saw in this post
> >> <
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-July/021185.html
> >that
> >> transmitting directly from the siggen noc-block is not supported. Is
> >> there any idea why this is not currently possible? Is there a specific
> >> limitation imposed by RFNoC, or is this functionality just not
> >> implemented yet? How difficult of a challenge does this problem pose?
> >>
> >> Cheers,
> >>
> >> -Jeremy
> >>
> >>
> >> _______________________________________________
> >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170303/1e32a2b1/attachment-0001.html>
------------------------------
Message: 19
Date: Thu, 2 Mar 2017 17:46:34 -0800
From: Derek Kozel <[email protected]>
To: "Nigel Steed (XENINT)" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] uhd::io_error
Message-ID:
<CAA+K=tvydkcguefovbbkqthicagab4jb3c5_bwrmr_icfuu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks for the update Nigel, I'm glad it's working for you.
On Tue, Feb 28, 2017 at 5:04 AM, Nigel Steed (XENINT) <
[email protected]> wrote:
> Hi David,
>
>
>
> Thought I would let you know. We replaced with a cheaper hub (only USB2)
> and we no longer get this error J
>
>
>
> Thanks,
>
>
>
> Nigel
>
>
>
> *From:* Derek Kozel [mailto:[email protected]]
> *Sent:* Wednesday, February 22, 2017 6:22 PM
> *To:* Nigel Steed (XENINT) <[email protected]>
> *Cc:* [email protected]
> *Subject:* Re: [USRP-users] uhd::io_error
>
>
>
> Hi Nigel,
>
> Do you have external DC power supplied to each B210? To the hub (how much
> current per port in that case)?
>
> How much total bandwidth are you trying to transfer? I don't have a number
> but could imagine there being overhead to the hub and (de)muxing of the
> connections. Is it an apparently good quality hub?
>
>
>
> Thanks,
>
> Derek
>
>
>
> On Wed, Feb 22, 2017 at 9:59 AM, Nigel Steed (XENINT) via USRP-users <
> [email protected]> wrote:
>
> Hi All,
>
>
>
> Has anyone experienced this error ? I am connected to 4 B210?s via a USB3
> hub and quite regularly I lose connection with the following error output
> from GNURadio:
>
>
>
> terminate called after throwing an instance of 'uhd::io_error'
>
> what(): EnvironmentError: IOError: usb tx2 transfer status:
> LIBUSB_TRANSFER_ERROR/
>
>
>
> So far this seems to be linked to when I am regularly sending frequency
> re-tune message into the message port of the UHD Source blocks.
>
>
>
> I am using UHD 3.10.1.1 and GNURadio 3.7.10.1
>
>
>
> Any comments much appreciated.
>
>
>
> Nigel
>
>
>
>
>
>
> _______________________________________________
> 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/20170302/ccafda88/attachment-0001.html>
------------------------------
Message: 20
Date: Fri, 3 Mar 2017 01:25:26 -0500
From: J Hershberger <[email protected]>
To: Martin Braun <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] transmitting without the host - RFNoC
Message-ID:
<canufequ3n3hqzwfxnvo5bd7v_ef9vs7u59poa_4ynjaprnm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Martin,
This is interesting to find out. What are the limitations you speak of?
I set up RFNoC with an X310 and was able to run the rfnoc_siggen.grc
example as well as the rfnoc_rxtx.grc example successfully. However, when
I put a RFNoC:SigGen -> RFNoC: Radio I get no signal out, no errors or
underflows, just nothing. Is there some secret sauce I am overlooking. I
tried various configs like: (siggen->duc->radio) and
(siggen->fifo->duc->radio) but I was still unable to actually get any tx
signal out.
Thanks
-Jeremy
On Thu, Mar 2, 2017 at 7:50 PM, Martin Braun via USRP-users <
[email protected]> wrote:
> Jeremy,
>
> siggen -> radio does indeed work, with some limitations. Generic
> host-less RFNoC flow graphs do not work (e.g, radio -> radio) but that's
> because it's a feature that hasn't been implemented yet. It's not a
> simple fix, it requires some restructuring of the driver code.
>
> Cheers,
> Martin
>
> On 03/02/2017 04:12 PM, J Hershberger via USRP-users wrote:
> > I am interested in transmitting directly from a stored/generated
> > waveform @ 200 MS/s on the X310. I saw in this post
> > <http://lists.ettus.com/pipermail/usrp-users_lists.
> ettus.com/2016-July/021185.html>that
> > transmitting directly from the siggen noc-block is not supported. Is
> > there any idea why this is not currently possible? Is there a specific
> > limitation imposed by RFNoC, or is this functionality just not
> > implemented yet? How difficult of a challenge does this problem pose?
> >
> > Cheers,
> >
> > -Jeremy
> >
> >
> > _______________________________________________
> > 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/20170303/127c7aa2/attachment-0001.html>
------------------------------
Message: 21
Date: Fri, 3 Mar 2017 09:57:24 +0100
From: Philipp Rudnik <[email protected]>
To: Sugandha Gupta <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] User Registers
Message-ID:
<CADk_VqFWMnfX2=AmoXC=lffgm4cbknu5jgtcadqfjjy96yn...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Sugnadha, hi everybody!
I couldn't solve my problem yet, so I try to describe it more precisely.
I have a modified modul, which works like the gpio_atr modul, except that
it outputs certain patterns, if there is a receiving signal. It all works
out, when I write the n patterns and the two timing constants in my verilog
modul.
The goal now ist to make this more flexible in a way, that I can change the
patterns and timing constants, without touching the verilog code. The idea
was to write them into user registers from the host and to access and
process the content in the verilog modul.
I guess, the set_user_registers UHD-command will be fine to write into the
user registers from my host, but I am quite not sure how I get access to
them in the gpio_atr modul.
Thanks for your help
Philipp
2017-01-24 21:35 GMT+01:00 Sugandha Gupta <[email protected]>:
> Hi Philipp
>
> The setting_reg is used to write to registers only.
>
> But if you want to read a value back, you will need to use the readback
> path through the noc_shell.
>
> You can use usrp3/lib/rfnoc/noc_block_fft.v as an example:
>
> // Readback registers
> always @*
> case(rb_addr)
> 8'd0 : rb_data <= {63'd0, fft_reset};
> 8'd1 : rb_data <= {62'd0, magnitude_out};
> default : rb_data <= 64'h0BADC0DE0BADC0DE;
> endcase
>
> Using user_reg_read64(), you can read back the value on the host side.
>
> Sugandha
>
>
>
> On Tue, Jan 24, 2017 at 12:47 AM, Philipp Rudnik via USRP-users <
> [email protected]> wrote:
>
>> Hi everybody,
>>
>> I have a quick question about user registers.
>> I want to pass some data from my host to my FPGA (x310) via the user
>> registers, to use them in an custom modul.
>> So my question is how to access the user registers in my verilog code. Do
>> I use the setting_reg modul to read the registers?
>>
>> setting_reg #(.my_addr(0), .width(1)) reg_user1 (
>> .clk(clk),.rst(reset),.strobe(set_stb),.addr(0), .in(??),
>> .out(content_user_register),.changed());
>>
>> What's my input in in that case, since I don't want to write into the
>> register, but read out of it?
>>
>> Thanks for your help
>>
>> Philipp
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
>
> --
> Sugandha Gupta
> Staff Software Engineer
> Ettus Research
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170303/2d612978/attachment-0001.html>
------------------------------
Message: 22
Date: Fri, 3 Mar 2017 10:06:32 +0100
From: Julian Arnold <[email protected]>
To: Carin <[email protected]>
Cc: Olof Sj?din <[email protected]>, usrp-users <[email protected]>
Subject: Re: [USRP-users] Cannot se sent out signal in oscilloscope
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi Carin,
the complex samples you sent to the UHD sink represent the complex low
pass signal equivalent to a real valued band-pass (signals that are not
centered around 0 Hz) representation of the signal. It is a mathematical
construct that comes in very handy when dealing with communication
signals as it lets you represent amplitude and phase easily. The
band-pass signal s_T(t) can be represented by the equivalent complex
low-pass signal and the center frequency f0 as follows:
\documentclass{article}
\usepackage[utf8x]{inputenc}
\pagestyle{empty}
\begin{document}
$s(t) = Re\{ s_T(t) e^{j2 \pi f_0 t} \}$
\end{document}
[1]
In your case the USRP is doing this conversion for you. It uses a
quadrature mixer to perform this step.
Hope this helps. If you have more questions, let me know.
[1] Ohm und L?ke, Signal?bertragung
Cheers,
Julian
On 03/02/2017 03:01 PM, Carin wrote:
> Hi Julian,
>
> Thank you for your answer, we got a signal at last. I have a more theoretical
> question regarding the UHD sink: why is its input specified as complex and
> not as float? I mean why would you and how can you transmit a complex signal?
> What is actually transmitted is a varying voltage, I would expect it to be
> sent based on a float-worth function of time??
>
> Just to explain why I ask this question: It seems that when I send a signal
> with non-zero imaginary part (a complex sinewave) into the uhdsink I dont get
> a signal on the oscilloscope, however, when I send in a signal with zero
> imaginary part (a float sin wave that has been converted to a complex signal)
> I do get a signal. Seems like sending in a non-zero imaginary part creates a
> problem in the UHD sink..?
>
> Thanks a lot!
> Carin
>
>
>> 1 mars 2017 kl. 18:14 skrev Julian Arnold <[email protected]>:
>>
>> Hi Carin,
>>
>> maybe you could elaborate a little bit more on you setup?
>> - How does you flow graph look like?
>> - What scope are you using (max BW?)
>>
>> Generally you will not be able to see just the signal you generate using
>> the signal source block on your scope as the USRP is up-converting that
>> signal to RF (to the center freq. you set in the UHD USRP Sink block).
>> Therefore, your scope needs to support a bandwidth that is greater than
>> the center freq. you chose in order to get a meaningful result.
>>
>> Hope that helps.
>> Cheers,
>> Julian
>>
>> On 03/01/2017 03:17 PM, Carin via USRP-users wrote:
>>>
>>>
>>>> Hi,
>>>>
>>>> We are working on an SDR solution for satellite communication using
>>>> your USRP B210 along with GNU Radio Companion. We got stuck on the
>>>> first step, i.e. transmitting a simple sine-signal created in GNU
>>>> radio to an oscilloscope. We are however getting some kind of signal,
>>>> but it doesn?t seem to be related to the frequency and amplitude of
>>>> the signal source, but rather to the center frequency of the uhd sink.
>>>>
>>>> We have also tried following the tutorial "Building a QPSK
>>>> Transmitter ? on your website but with the same results. Do you have
>>>> any ideas on what can be wrong?
>>>>
>>>> Regards,
>>>> Carin
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>> --
>> Julian Arnold, M.Sc.
>>
>> Institute for Networked Systems
>> RWTH Aachen University
>>
>> Kackertstrasse 9
>> 52072 Aachen
>> Germany
>
--
Julian Arnold, M.Sc.
Institute for Networked Systems
RWTH Aachen University
Kackertstrasse 9
52072 Aachen
Germany
------------------------------
Message: 23
Date: Fri, 3 Mar 2017 10:23:15 +0100
From: Julian Arnold <[email protected]>
To: Carin <[email protected]>
Cc: usrp-users <[email protected]>, Olof Sj?din
<[email protected]>
Subject: Re: [USRP-users] Cannot se sent out signal in oscilloscope
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170303/506f645f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-10.png
Type: image/png
Size: 1849 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170303/506f645f/attachment-0001.png>
------------------------------
Message: 24
Date: Fri, 3 Mar 2017 11:10:56 +0100
From: Felipe Augusto Pereira de Figueiredo <[email protected]>
To: Juan Francisco <[email protected]>
Cc: Jonathon Pendlum <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] [RFNoC] FPGA image is 2 bytes larger than
expected
Message-ID:
<ca+abmw+abmfbe6jmm-evjtkvtgghpsn3fqeidbldt-epg7o...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hey guys,
Yes, I tweaked the image loader script and it worked. I just wanted to
understand it better.
@Jonathon
I'm using Ubuntu 14.04.5 and Vivado 2015.4.2.
Thanks and Best Regards,
Felipe
On Thu, Mar 2, 2017 at 11:42 PM, Juan Francisco
<[email protected]> wrote:
> Fwiw, I have run into this issue occasionally as well. The fix is to hack
> the image loader.
>
> -Juan
>
> On Thu, Mar 2, 2017 at 4:58 PM, Jonathon Pendlum via USRP-users
> <[email protected]> wrote:
>>
>> Hi Felipe,
>>
>> I do not currently have an explanation why the Xilinx tools generate a
>> bitstream with a different file size. When I run your build command, the
>> output bitstream size is 15878032. What OS / Xilinx tools are you building
>> with?
>>
>>
>>
>> Jonathon
>>
>> On Thu, Mar 2, 2017 at 11:07 AM, Felipe Augusto Pereira de Figueiredo
>> <[email protected]> wrote:
>>>
>>> Dear Jonathon,
>>>
>>> Do you have any update on the 2 bytes larger bitstream issue?
>>>
>>> I was expecting someone from ettus to give us an explanation on that
>>> and if it is an issue.
>>>
>>> Thanks and Best Regards,
>>>
>>> Felipe Augusto
>>>
>>> On Tue, Feb 28, 2017 at 9:43 AM, Felipe Augusto Pereira de Figueiredo
>>> <[email protected]> wrote:
>>> > Dear Jonathon,
>>> >
>>> > I tried what you told me. First, I ran setupenv.sh and then executed
>>> > make X310_RFNOC_HG.
>>> >
>>> > The bistream was successfully generated as you can see by the messages
>>> > below.
>>> >
>>> > Creating bitstream...
>>> > Writing bitstream
>>> >
>>> > /home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300/build-X310_RFNOC_HG/x300.bit...
>>> > INFO: [Vivado 12-1842] Bitgen Completed Successfully.
>>> >
>>> > And again, it has the same size, 15878034, as the other bitstream I
>>> > generated with 2xDDCs, 2xDUCs and 1xFFT.
>>> >
>>> > -rw-rw-r-- 1 zz4fap zz4fap 15878034 Feb 27 22:47 x300.bit
>>> >
>>> > Could you, please, check why this difference exists? I mean, the
>>> > difference of 2 bytes between bitstreams.
>>> >
>>> > While cheking the Makefile at src/uhd-fpga/usrp3/top/x300 I read what
>>> > I think could be a clue to the problem:
>>> >
>>> > ## build/usrp_<product>_fpga_<image_type>.bit: Configuration
>>> > bitstream with header
>>> > ## build/usrp_<product>_fpga_<image_type>.bin: Configuration
>>> > bitstream without header
>>> >
>>> > May the 2 bytes longer bitstream (.bit) contains a 2 bytes long header.
>>> >
>>> > Thanks and Best Regards,
>>> >
>>> > Felipe
>>> >
>>> > On Mon, Feb 27, 2017 at 9:07 PM, Jonathon Pendlum
>>> > <[email protected]> wrote:
>>> >> Hi Felipe,
>>> >>
>>> >> Make sure to run 'source setupenv.sh' first before make X310_RFNOC_HG
>>> >>
>>> >> On Mon, Feb 27, 2017 at 1:31 PM, Felipe Augusto Pereira de Figueiredo
>>> >> <[email protected]> wrote:
>>> >>>
>>> >>> Hi Jonathon,
>>> >>>
>>> >>> Tried what you said but it didn't work. Could you please be a little
>>> >>> bit more specific about the command I should run. I got some error
>>> >>> regarding the syntax of the command you told me to run.
>>> >>> See output below.
>>> >>>
>>> >>> Thanks and Best Regards,
>>> >>>
>>> >>> Felipe
>>> >>>
>>> >>>
>>> >>>
>>> >>> ---------------------------------------------------------------------------------------------------------------------------------------------------------
>>> >>> zz4fap@imecdesktop:~/rfnoc/src/uhd-fpga/usrp3/top/x300$ make
>>> >>> X310_RFNOC_HG
>>> >>> make -f Makefile.x300.inc bin NAME=X310_RFNOC_HG ARCH= PART_ID=
>>> >>> BUILD_1G=1 BUILD_10G=1 SFP0_1GBE=1 SFP1_10GBE=1 RFNOC=1 X310=1
>>> >>> EXTRA_DEFS="BUILD_1G=1 BUILD_10G=1 SFP0_1GBE=1 SFP1_10GBE=1 RFNOC=1
>>> >>> X310=1"
>>> >>> find:
>>> >>>
>>> >>> `/home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300/build-ip/addsub_hls/solution/impl/verilog/':
>>> >>> No such file or directory
>>> >>> make[1]: Entering directory
>>> >>> `/home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300'
>>> >>> BUILDER: Checking tools...
>>> >>> * GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)
>>> >>> * Python 2.7.6
>>> >>> * Vivado v2015.4.2 (64-bit)
>>> >>> ========================================================
>>> >>> BUILDER: Building IP ten_gig_eth_pcs_pma
>>> >>> ========================================================
>>> >>> BUILDER: Staging IP in build directory...
>>> >>> BUILDER: Reserving IP location:
>>> >>>
>>> >>>
>>> >>> /home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300/build-ip/ten_gig_eth_pcs_pma
>>> >>> BUILDER: Retargeting IP to part /...
>>> >>> ERROR: Invalid target format. Must be
>>> >>> <arch>/<device>/<package>/<speedgrade>
>>> >>> BUILDER: Building IP...
>>> >>>
>>> >>> ****** Vivado v2015.4.2 (64-bit)
>>> >>> **** SW Build 1494164 on Fri Feb 26 04:18:54 MST 2016
>>> >>> **** IP Build 1491208 on Wed Feb 24 03:25:39 MST 2016
>>> >>> ** Copyright 1986-2015 Xilinx, Inc. All Rights Reserved.
>>> >>>
>>> >>> source
>>> >>>
>>> >>> /home/zz4fap/rfnoc/src/uhd-fpga/usrp3/tools/scripts/viv_generate_ip.tcl
>>> >>> # set xci_file $::env(XCI_FILE) ;
>>> >>> # set part_name $::env(PART_NAME) ;
>>> >>> # set gen_example_proj $::env(GEN_EXAMPLE) ;
>>> >>> # set synth_ip $::env(SYNTH_IP) ;
>>> >>> # set ip_name [file rootname [file tail $xci_file]] ;
>>> >>> # file delete -force "$xci_file.out"
>>> >>> # create_project -part $part_name -in_memory -ip
>>> >>> WARNING: [#UNDEF] No parts matched ''
>>> >>> ERROR: [Coretcl 2-106] Specified part could not be found.
>>> >>> INFO: [Common 17-206] Exiting Vivado at Mon Feb 27 20:26:39 2017...
>>> >>> BUILDER: Releasing IP location:
>>> >>>
>>> >>>
>>> >>> /home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300/build-ip/ten_gig_eth_pcs_pma
>>> >>> make[1]: ***
>>> >>>
>>> >>> [/home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300/build-ip/ten_gig_eth_pcs_pma/ten_gig_eth_pcs_pma.xci.out]
>>> >>> Error 1
>>> >>> make[1]: Leaving directory
>>> >>> `/home/zz4fap/rfnoc/src/uhd-fpga/usrp3/top/x300'
>>> >>> make: *** [X310_RFNOC_HG] Error 2
>>> >>>
>>> >>>
>>> >>> ---------------------------------------------------------------------------------------------------------------------------------------------------------
>>> >>>
>>> >>> On Mon, Feb 27, 2017 at 7:55 PM, Jonathon Pendlum
>>> >>> <[email protected]> wrote:
>>> >>> > Hi Felipe,
>>> >>> >
>>> >>> > What if you build the same image by running make X310_RFNOC_HG in
>>> >>> > usrp3/top/x300? Is it still too large?
>>> >>> >
>>> >>> > On Mon, Feb 27, 2017 at 4:23 AM, Felipe Augusto Pereira de
>>> >>> > Figueiredo
>>> >>> > via
>>> >>> > USRP-users <[email protected]> wrote:
>>> >>> >>
>>> >>> >> Dear Sam,
>>> >>> >>
>>> >>> >> Many thanks for your tip, I've followed that and it worked. Just
>>> >>> >> changed the size of the macro with the expected bitstream size.
>>> >>> >>
>>> >>> >> I hope someone from Ettus can explain why that problem happens and
>>> >>> >> if
>>> >>> >> it can be solved other way instead of tweaking the source code.
>>> >>> >>
>>> >>> >> Now the output of "uhd_usrp_probe" is like I had expected it to
>>> >>> >> be.
>>> >>> >>
>>> >>> >> | | _____________________________________________________
>>> >>> >> | | /
>>> >>> >> | | | RFNoC blocks on this device:
>>> >>> >> | | |
>>> >>> >> | | | * DmaFIFO_0
>>> >>> >> | | | * Radio_0
>>> >>> >> | | | * Radio_1
>>> >>> >> | | | * DDC_0
>>> >>> >> | | | * DDC_1
>>> >>> >> | | | * DUC_0
>>> >>> >> | | | * DUC_1
>>> >>> >> | | | * FFT_0
>>> >>> >>
>>> >>> >> Thanks and Best Regards,
>>> >>> >>
>>> >>> >> Felipe
>>> >>> >>
>>> >>> >> On Fri, Feb 24, 2017 at 3:27 PM, Sam Carey <[email protected]>
>>> >>> >> wrote:
>>> >>> >> > Howdy,
>>> >>> >> >
>>> >>> >> > I had this problem a while back. My workaround was to simply
>>> >>> >> > edit the
>>> >>> >> > image
>>> >>> >> > loader code so that it is OK with the larger file size.
>>> >>> >> > Just do a search for the smaller byte number in the uhd/host
>>> >>> >> > source
>>> >>> >> > code,
>>> >>> >> > change it to the larger byte number, and rebuild/reinstall uhd.
>>> >>> >> > Apparently, the byte count is not a strict requirement for image
>>> >>> >> > loading.
>>> >>> >> >
>>> >>> >> > You're the second other person I've seen with this problem.
>>> >>> >> > Maybe somebody could apply this change to the main branch or
>>> >>> >> > something?
>>> >>> >> >
>>> >>> >> > -Sam
>>> >>> >> >
>>> >>> >> >
>>> >>> >>
>>> >>> >> _______________________________________________
>>> >>> >> 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: 25
Date: Fri, 3 Mar 2017 14:12:03 +0300
From: do ber <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] X310-PCIe connection in Linux
Message-ID:
<cabldf_f30wgy09akkqhoxqu6bgv7oomjbvq0gcn5zdixle9...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
Thanks for the reply. I will try what you said and come back if any
problems occurs.
Ali
2017-03-02 18:26 GMT+03:00 Marcus D. Leech via USRP-users <
[email protected]>:
> On 03/02/2017 02:52 AM, do ber via USRP-users wrote:
>
> Hi to all,
>
> I want to work with a wideband signal. The bandwidth will be very high (I
> will push the limits). I have X310, UBX-160 and PCI-Express Connectivity
> Kit (PCIe ? Desktop) <https://www.ettus.com/product/details/PCIE-KIT>.
> There is Intel 8 series/C220 chipset in my desktop computer.
>
> I searched the Ettus' website and find this
> <https://files.ettus.com/manual/page_ni_rio_kernel.html>.
>
> ** In Windows Labview 2015
> When I run NI USRP-Configuration Utility, I get:
> Device ID: RIO0
> Connection: PCIe
> Type/Revision: X310/UBX-160 v1/rev8
>
> Then I run an example program and get the error:
> USRP RIO: Hardware is too new for this version of the Configuration
> Instrument Design Library.
>
> Anyway, I already know that Labview does not support UBX card. So I left
> working on Labview. Actually, I do not know much about Labview.
>
> **In Linux
> I installed the given NI USRPRIO kernels. When I write the
> "uhd_usrp_probe", UHD sees the device.
> ...
> -- Connecting to niusrpriopc at localhost:5444...
> ...
>
> So it is working. But then, how can I use USRP in Linux? I actually want
> to work with GNURadio. Is it possible to work on GNURadio with PCIe
> connection? Or do I have to write in Python? I did not see any example of
> usage in Linux on the internet.
>
> In short, please tell me how can I record I/Q data of a wideband signal
> with PCIe connection in Linux, prefferably by GNURadio?
>
> Best regards,
> Ali
>
> If you just want to record, you can use the 'uhd_rx_cfile' utility that is
> part of Gnu Radio.
>
> You can also use 'rx_samples_to_file' that is part of UHD.
>
> Be aware that making high-bandwidth recording work requires both a FAST
> computer, and a suitable SSD-based disk subsystem.
>
> In either case, you'd just specify "resource=RIO0" in the device
> arguments when using the UHD utilities, or Gnu Radio programs.
>
>
>
>
>
>
> _______________________________________________
> 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/20170303/5393e4be/attachment-0001.html>
------------------------------
Message: 26
Date: Fri, 3 Mar 2017 12:58:41 +0100
From: Sebastian Mueller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] RuntimeError: basic_string::_M_construct
null not valid when using RFNoC:Radio
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hello Martin,
This is what I get from uhd_usrp_probe after flashing it with my custom
FPGA image. In addition, I still get the same error with the default
FPGA image regardless:
linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_004.000.000.rfnoc-devel-641-g8773fb2c
-- X300 initialization sequence...
-- Determining maximum frame size... 1472 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- Detecting internal GPSDO.... No GPSDO found
UHD Error:
get_stat(): unsupported GPS or no GPS detected
-- [RFNOC] ------- Block Setup -----------
-- Setting up NoC-Shell Control for port #0 (SID: 00:00>02:30)...OK
-- Port 48: Found NoC-Block with ID F1F0D00000000000.
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/dma_fifo.xml
-- Setting up NoC-Shell Control for port #1 (SID: 00:01>02:31)...OK
-- [RFNoC Factory] block_ctrl_base::make()
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/dma_fifo.xml
-- [RFNoC Factory] Using controller key 'DmaFIFO' and block name 'DmaFIFO'
-- block_ctrl_base()
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/dma_fifo.xml
-- Found valid blockdef
-- NOC ID: 0xF1F0D00000000000 Block ID: 0/DmaFIFO_0
-- [0/DmaFIFO_0] block_ctrl_base::clear()
-- [0/DmaFIFO_0] node_ctrl_base::clear()
-- [0/DmaFIFO_0] block_ctrl_base::_clear()
-- [0/DmaFIFO_0] block_ctrl_base::_clear()
-- [0/DmaFIFO_0] Adding port definition at xbar/DmaFIFO_0/ports/in/0:
type = '' pkt_size = '0' vlen = '0'
-- [0/DmaFIFO_0] Adding port definition at xbar/DmaFIFO_0/ports/in/1:
type = '' pkt_size = '0' vlen = '0'
-- [0/DmaFIFO_0] Adding port definition at xbar/DmaFIFO_0/ports/out/0:
type = '' pkt_size = '0' vlen = '0'
-- [0/DmaFIFO_0] Adding port definition at xbar/DmaFIFO_0/ports/out/1:
type = '' pkt_size = '0' vlen = '0'
-- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1296.1MB/s)
-- [NocScript] Executing and asserting code: EQUAL($base_addr, 0) OR
IS_PWR_OF_2($base_addr)
-- [NocScript] Executing and asserting code: IS_PWR_OF_2($depth)
-- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1293.4MB/s)
-- [NocScript] Executing and asserting code: EQUAL($base_addr, 0) OR
IS_PWR_OF_2($base_addr)
-- [NocScript] Executing and asserting code: IS_PWR_OF_2($depth)
-- [RFNOC] ------- Block Setup -----------
-- Setting up NoC-Shell Control for port #0 (SID: 00:02>02:40)...OK
-- Port 64: Found NoC-Block with ID 12AD100000000001.
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/radio_x300.xml
-- Setting up NoC-Shell Control for port #1 (SID: 00:03>02:41)...OK
-- [RFNoC Factory] block_ctrl_base::make()
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/radio_x300.xml
-- [RFNoC Factory] Using controller key 'X300Radio' and block name 'Radio'
-- block_ctrl_base()
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/radio_x300.xml
-- Found valid blockdef
-- NOC ID: 0x12AD100000000001 Block ID: 0/Radio_0
-- [0/Radio_0] block_ctrl_base::clear()
-- [0/Radio_0] node_ctrl_base::clear()
-- [0/Radio_0] block_ctrl_base::_clear()
-- [0/Radio_0] block_ctrl_base::_clear()
-- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/in/0: type =
'sc16' pkt_size = '0' vlen = '0'
-- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/in/1: type =
'sc16' pkt_size = '0' vlen = '0'
-- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/out/0: type
= 'sc16' pkt_size = '0' vlen = '0'
-- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/out/1: type
= 'sc16' pkt_size = '0' vlen = '0'
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- [0/Radio_0] radio_ctrl_impl::_update_spp(): Requested spp: 364
-- [0/Radio_0] radio_ctrl_impl::_update_spp(): Setting spp to: 364
-- [0/Radio_0] x300_radio_ctrl_impl::ctor()
-- [0/Radio_0] radio_ctrl_impl::_update_spp(): Requested spp: 364
-- [0/Radio_0] radio_ctrl_impl::_update_spp(): Setting spp to: 364
-- [RFNOC] ------- Block Setup -----------
-- Setting up NoC-Shell Control for port #0 (SID: 00:04>02:50)...OK
-- Port 80: Found NoC-Block with ID 12AD100000000001.
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/radio_x300.xml
-- Setting up NoC-Shell Control for port #1 (SID: 00:05>02:51)...OK
-- [RFNoC Factory] block_ctrl_base::make()
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/radio_x300.xml
-- [RFNoC Factory] Using controller key 'X300Radio' and block name 'Radio'
-- block_ctrl_base()
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/radio_x300.xml
-- Found valid blockdef
-- NOC ID: 0x12AD100000000001 Block ID: 0/Radio_1
-- [0/Radio_1] block_ctrl_base::clear()
-- [0/Radio_1] node_ctrl_base::clear()
-- [0/Radio_1] block_ctrl_base::_clear()
-- [0/Radio_1] block_ctrl_base::_clear()
-- [0/Radio_1] Adding port definition at xbar/Radio_1/ports/in/0: type =
'sc16' pkt_size = '0' vlen = '0'
-- [0/Radio_1] Adding port definition at xbar/Radio_1/ports/in/1: type =
'sc16' pkt_size = '0' vlen = '0'
-- [0/Radio_1] Adding port definition at xbar/Radio_1/ports/out/0: type
= 'sc16' pkt_size = '0' vlen = '0'
-- [0/Radio_1] Adding port definition at xbar/Radio_1/ports/out/1: type
= 'sc16' pkt_size = '0' vlen = '0'
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- [0/Radio_1] radio_ctrl_impl::_update_spp(): Requested spp: 364
-- [0/Radio_1] radio_ctrl_impl::_update_spp(): Setting spp to: 364
-- [0/Radio_1] x300_radio_ctrl_impl::ctor()
-- [0/Radio_1] radio_ctrl_impl::_update_spp(): Requested spp: 364
-- [0/Radio_1] radio_ctrl_impl::_update_spp(): Setting spp to: 364
-- [RFNOC] ------- Block Setup -----------
-- Setting up NoC-Shell Control for port #0 (SID: 00:06>02:60)...OK
-- Port 96: Found NoC-Block with ID 000000000000514C.
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/sync.xml
-- [RFNoC Factory] block_ctrl_base::make()
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/sync.xml
-- [RFNoC Factory] Using controller key 'Block' and block name 'sync'
-- block_ctrl_base()
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/sync.xml
-- Found valid blockdef
-- NOC ID: 0x000000000000514C Block ID: 0/sync_0
-- [0/sync_0] block_ctrl_base::clear()
-- [0/sync_0] node_ctrl_base::clear()
-- [0/sync_0] block_ctrl_base::_clear()
-- [0/sync_0] Adding port definition at xbar/sync_0/ports/in/0: type =
'' pkt_size = '0' vlen = '0'
-- [0/sync_0] Adding port definition at xbar/sync_0/ports/out/0: type =
'' pkt_size = '0' vlen = '0'
-- [RFNOC] ------- Block Setup -----------
-- Setting up NoC-Shell Control for port #0 (SID: 00:07>02:70)...OK
-- Port 112: Found NoC-Block with ID DDC0000000000000.
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/ddc.xml
-- Setting up NoC-Shell Control for port #1 (SID: 00:08>02:71)...OK
-- [RFNoC Factory] block_ctrl_base::make()
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/ddc.xml
-- [RFNoC Factory] Using controller key 'DDC' and block name 'DDC'
-- block_ctrl_base()
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/ddc.xml
-- Found valid blockdef
-- NOC ID: 0xDDC0000000000000 Block ID: 0/DDC_0
-- [0/DDC_0] block_ctrl_base::clear()
-- [0/DDC_0] node_ctrl_base::clear()
-- [0/DDC_0] block_ctrl_base::_clear()
-- [0/DDC_0] block_ctrl_base::_clear()
-- [0/DDC_0] Adding port definition at xbar/DDC_0/ports/in/0: type =
'sc16' pkt_size = '0' vlen = '0'
-- [0/DDC_0] Adding port definition at xbar/DDC_0/ports/in/1: type =
'sc16' pkt_size = '0' vlen = '0'
-- [0/DDC_0] Adding port definition at xbar/DDC_0/ports/out/0: type =
'sc16' pkt_size = '0' vlen = '0'
-- [0/DDC_0] Adding port definition at xbar/DDC_0/ports/out/1: type =
'sc16' pkt_size = '0' vlen = '0'
-- [NocScript] Executing and asserting code: GE($input_rate, 0.0)
-- [NocScript] Executing and asserting code: GE($output_rate, 0.0)
-- [NocScript] Executing and asserting code: GE($fullscale, 0.0)
-- [NocScript] Executing and asserting code: GE($input_rate, 0.0)
-- [NocScript] Executing and asserting code: GE($output_rate, 0.0)
-- [NocScript] Executing and asserting code: GE($fullscale, 0.0)
-- [0/DDC_0] sr_write(CORDIC_FREQ, 00000000) ==>
-- [0/DDC_0] sr_write(DECIM_WORD, 00000001) ==>
-- [0/DDC_0] sr_write(N, 00000001) ==>
-- [0/DDC_0] sr_write(M, 00000001) ==>
-- [0/DDC_0] sr_write(SCALE_IQ, 00004DAB) ==>
-- [NocScript] Executing and asserting code: GE($output_rate, 0.0)
-- [0/DDC_0] sr_write(N, 00000001) ==>
-- [0/DDC_0] sr_write(M, 00000001) ==>
-- [0/DDC_0] sr_write(CONFIG, 00000001) ==>
-- [0/DDC_0] sr_write(CORDIC_FREQ, 00000000) ==>
-- [0/DDC_0] sr_write(DECIM_WORD, 00000001) ==>
-- [0/DDC_0] sr_write(N, 00000001) ==>
-- [0/DDC_0] sr_write(M, 00000001) ==>
-- [0/DDC_0] sr_write(SCALE_IQ, 00004DAB) ==>
-- [NocScript] Executing and asserting code: GE($output_rate, 0.0)
-- [0/DDC_0] sr_write(N, 00000001) ==>
-- [0/DDC_0] sr_write(M, 00000001) ==>
-- [0/DDC_0] sr_write(CONFIG, 00000001) ==>
-- [RFNOC] ------- Block Setup -----------
-- Setting up NoC-Shell Control for port #0 (SID: 00:09>02:80)...OK
-- Port 128: Found NoC-Block with ID DDC0000000000000.
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/ddc.xml
-- Setting up NoC-Shell Control for port #1 (SID: 00:0a>02:81)...OK
-- [RFNoC Factory] block_ctrl_base::make()
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/ddc.xml
-- [RFNoC Factory] Using controller key 'DDC' and block name 'DDC'
-- block_ctrl_base()
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/ddc.xml
-- Found valid blockdef
-- NOC ID: 0xDDC0000000000000 Block ID: 0/DDC_1
-- [0/DDC_1] block_ctrl_base::clear()
-- [0/DDC_1] node_ctrl_base::clear()
-- [0/DDC_1] block_ctrl_base::_clear()
-- [0/DDC_1] block_ctrl_base::_clear()
-- [0/DDC_1] Adding port definition at xbar/DDC_1/ports/in/0: type =
'sc16' pkt_size = '0' vlen = '0'
-- [0/DDC_1] Adding port definition at xbar/DDC_1/ports/in/1: type =
'sc16' pkt_size = '0' vlen = '0'
-- [0/DDC_1] Adding port definition at xbar/DDC_1/ports/out/0: type =
'sc16' pkt_size = '0' vlen = '0'
-- [0/DDC_1] Adding port definition at xbar/DDC_1/ports/out/1: type =
'sc16' pkt_size = '0' vlen = '0'
-- [NocScript] Executing and asserting code: GE($input_rate, 0.0)
-- [NocScript] Executing and asserting code: GE($output_rate, 0.0)
-- [NocScript] Executing and asserting code: GE($fullscale, 0.0)
-- [NocScript] Executing and asserting code: GE($input_rate, 0.0)
-- [NocScript] Executing and asserting code: GE($output_rate, 0.0)
-- [NocScript] Executing and asserting code: GE($fullscale, 0.0)
-- [0/DDC_1] sr_write(CORDIC_FREQ, 00000000) ==>
-- [0/DDC_1] sr_write(DECIM_WORD, 00000001) ==>
-- [0/DDC_1] sr_write(N, 00000001) ==>
-- [0/DDC_1] sr_write(M, 00000001) ==>
-- [0/DDC_1] sr_write(SCALE_IQ, 00004DAB) ==>
-- [NocScript] Executing and asserting code: GE($output_rate, 0.0)
-- [0/DDC_1] sr_write(N, 00000001) ==>
-- [0/DDC_1] sr_write(M, 00000001) ==>
-- [0/DDC_1] sr_write(CONFIG, 00000001) ==>
-- [0/DDC_1] sr_write(CORDIC_FREQ, 00000000) ==>
-- [0/DDC_1] sr_write(DECIM_WORD, 00000001) ==>
-- [0/DDC_1] sr_write(N, 00000001) ==>
-- [0/DDC_1] sr_write(M, 00000001) ==>
-- [0/DDC_1] sr_write(SCALE_IQ, 00004DAB) ==>
-- [NocScript] Executing and asserting code: GE($output_rate, 0.0)
-- [0/DDC_1] sr_write(N, 00000001) ==>
-- [0/DDC_1] sr_write(M, 00000001) ==>
-- [0/DDC_1] sr_write(CONFIG, 00000001) ==>
-- [RFNOC] ------- Block Setup -----------
-- Setting up NoC-Shell Control for port #0 (SID: 00:0b>02:90)...OK
-- Port 144: Found NoC-Block with ID D0C0000000000000.
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/duc.xml
-- [RFNoC Factory] block_ctrl_base::make()
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/duc.xml
-- [RFNoC Factory] Using controller key 'DUC' and block name 'DUC'
-- block_ctrl_base()
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/duc.xml
-- Found valid blockdef
-- NOC ID: 0xD0C0000000000000 Block ID: 0/DUC_0
-- [0/DUC_0] block_ctrl_base::clear()
-- [0/DUC_0] node_ctrl_base::clear()
-- [0/DUC_0] block_ctrl_base::_clear()
-- [0/DUC_0] Adding port definition at xbar/DUC_0/ports/in/0: type =
'sc16' pkt_size = '0' vlen = '0'
-- [0/DUC_0] Adding port definition at xbar/DUC_0/ports/out/0: type =
'sc16' pkt_size = '0' vlen = '0'
-- [NocScript] Executing and asserting code: GE($input_rate, 0.0)
-- [NocScript] Executing and asserting code: GE($output_rate, 0.0)
-- [NocScript] Executing and asserting code: GE($fullscale, 0.0)
-- [0/DUC_0] sr_write(CORDIC_FREQ, 00000000) ==>
-- [0/DUC_0] sr_write(INTERP_WORD, 00000001) ==>
-- [0/DUC_0] sr_write(N, 00000001) ==>
-- [0/DUC_0] sr_write(M, 00000001) ==>
-- [0/DUC_0] sr_write(SCALE_IQ, 00006DEE) ==>
-- [NocScript] Executing and asserting code: GE($input_rate, 0.0)
-- [0/DUC_0] sr_write(N, 00000001) ==>
-- [0/DUC_0] sr_write(M, 00000001) ==>
-- [0/DUC_0] sr_write(CONFIG, 00000001) ==>
-- [RFNOC] ------- Block Setup -----------
-- Setting up NoC-Shell Control for port #0 (SID: 00:0c>02:a0)...OK
-- Port 160: Found NoC-Block with ID D0C0000000000000.
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/duc.xml
-- [RFNoC Factory] block_ctrl_base::make()
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/duc.xml
-- [RFNoC Factory] Using controller key 'DUC' and block name 'DUC'
-- block_ctrl_base()
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/duc.xml
-- Found valid blockdef
-- NOC ID: 0xD0C0000000000000 Block ID: 0/DUC_1
-- [0/DUC_1] block_ctrl_base::clear()
-- [0/DUC_1] node_ctrl_base::clear()
-- [0/DUC_1] block_ctrl_base::_clear()
-- [0/DUC_1] Adding port definition at xbar/DUC_1/ports/in/0: type =
'sc16' pkt_size = '0' vlen = '0'
-- [0/DUC_1] Adding port definition at xbar/DUC_1/ports/out/0: type =
'sc16' pkt_size = '0' vlen = '0'
-- [NocScript] Executing and asserting code: GE($input_rate, 0.0)
-- [NocScript] Executing and asserting code: GE($output_rate, 0.0)
-- [NocScript] Executing and asserting code: GE($fullscale, 0.0)
-- [0/DUC_1] sr_write(CORDIC_FREQ, 00000000) ==>
-- [0/DUC_1] sr_write(INTERP_WORD, 00000001) ==>
-- [0/DUC_1] sr_write(N, 00000001) ==>
-- [0/DUC_1] sr_write(M, 00000001) ==>
-- [0/DUC_1] sr_write(SCALE_IQ, 00006DEE) ==>
-- [NocScript] Executing and asserting code: GE($input_rate, 0.0)
-- [0/DUC_1] sr_write(N, 00000001) ==>
-- [0/DUC_1] sr_write(M, 00000001) ==>
-- [0/DUC_1] sr_write(CONFIG, 00000001) ==>
-- [RFNOC] ------- Block Setup -----------
-- Setting up NoC-Shell Control for port #0 (SID: 00:0d>02:b0)...OK
-- Port 176: Found NoC-Block with ID F1F0000000000000.
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/fifo.xml
-- [RFNoC Factory] block_ctrl_base::make()
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/fifo.xml
-- [RFNoC Factory] Using controller key 'Block' and block name 'FIFO'
-- block_ctrl_base()
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/fifo.xml
-- Found valid blockdef
-- NOC ID: 0xF1F0000000000000 Block ID: 0/FIFO_0
-- [0/FIFO_0] block_ctrl_base::clear()
-- [0/FIFO_0] node_ctrl_base::clear()
-- [0/FIFO_0] block_ctrl_base::_clear()
-- [0/FIFO_0] Adding port definition at xbar/FIFO_0/ports/in/0: type =
'' pkt_size = '0' vlen = '0'
-- [0/FIFO_0] Adding port definition at xbar/FIFO_0/ports/out/0: type =
'' pkt_size = '0' vlen = '0'
-- [RFNOC] ------- Block Setup -----------
-- Setting up NoC-Shell Control for port #0 (SID: 00:0e>02:c0)...OK
-- Port 192: Found NoC-Block with ID F1F0000000000000.
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/fifo.xml
-- [RFNoC Factory] block_ctrl_base::make()
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/fifo.xml
-- [RFNoC Factory] Using controller key 'Block' and block name 'FIFO'
-- block_ctrl_base()
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/fifo.xml
-- Found valid blockdef
-- NOC ID: 0xF1F0000000000000 Block ID: 0/FIFO_1
-- [0/FIFO_1] block_ctrl_base::clear()
-- [0/FIFO_1] node_ctrl_base::clear()
-- [0/FIFO_1] block_ctrl_base::_clear()
-- [0/FIFO_1] Adding port definition at xbar/FIFO_1/ports/in/0: type =
'' pkt_size = '0' vlen = '0'
-- [0/FIFO_1] Adding port definition at xbar/FIFO_1/ports/out/0: type =
'' pkt_size = '0' vlen = '0'
-- [RFNOC] ------- Block Setup -----------
-- Setting up NoC-Shell Control for port #0 (SID: 00:0f>02:d0)...OK
-- Port 208: Found NoC-Block with ID F1F0000000000000.
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/fifo.xml
-- [RFNoC Factory] block_ctrl_base::make()
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/fifo.xml
-- [RFNoC Factory] Using controller key 'Block' and block name 'FIFO'
-- block_ctrl_base()
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/fifo.xml
-- Found valid blockdef
-- NOC ID: 0xF1F0000000000000 Block ID: 0/FIFO_2
-- [0/FIFO_2] block_ctrl_base::clear()
-- [0/FIFO_2] node_ctrl_base::clear()
-- [0/FIFO_2] block_ctrl_base::_clear()
-- [0/FIFO_2] Adding port definition at xbar/FIFO_2/ports/in/0: type =
'' pkt_size = '0' vlen = '0'
-- [0/FIFO_2] Adding port definition at xbar/FIFO_2/ports/out/0: type =
'' pkt_size = '0' vlen = '0'
-- [RFNOC] ------- Block Setup -----------
-- Setting up NoC-Shell Control for port #0 (SID: 00:10>02:e0)...OK
-- Port 224: Found NoC-Block with ID F1F0000000000000.
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/fifo.xml
-- [RFNoC Factory] block_ctrl_base::make()
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/fifo.xml
-- [RFNoC Factory] Using controller key 'Block' and block name 'FIFO'
-- block_ctrl_base()
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/fifo.xml
-- Found valid blockdef
-- NOC ID: 0xF1F0000000000000 Block ID: 0/FIFO_3
-- [0/FIFO_3] block_ctrl_base::clear()
-- [0/FIFO_3] node_ctrl_base::clear()
-- [0/FIFO_3] block_ctrl_base::_clear()
-- [0/FIFO_3] Adding port definition at xbar/FIFO_3/ports/in/0: type =
'' pkt_size = '0' vlen = '0'
-- [0/FIFO_3] Adding port definition at xbar/FIFO_3/ports/out/0: type =
'' pkt_size = '0' vlen = '0'
-- [RFNOC] ------- Block Setup -----------
-- Setting up NoC-Shell Control for port #0 (SID: 00:11>02:f0)...OK
-- Port 240: Found NoC-Block with ID F1F0000000000000.
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/fifo.xml
-- [RFNoC Factory] block_ctrl_base::make()
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/fifo.xml
-- [RFNoC Factory] Using controller key 'Block' and block name 'FIFO'
-- block_ctrl_base()
-- Reading XML file: /usr/local/share/uhd/rfnoc/blocks/fifo.xml
-- Found valid blockdef
-- NOC ID: 0xF1F0000000000000 Block ID: 0/FIFO_4
-- [0/FIFO_4] block_ctrl_base::clear()
-- [0/FIFO_4] node_ctrl_base::clear()
-- [0/FIFO_4] block_ctrl_base::_clear()
-- [0/FIFO_4] Adding port definition at xbar/FIFO_4/ports/in/0: type =
'' pkt_size = '0' vlen = '0'
-- [0/FIFO_4] Adding port definition at xbar/FIFO_4/ports/out/0: type =
'' pkt_size = '0' vlen = '0'
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
_____________________________________________________
/
| Device: X-Series Device
| _____________________________________________________
| /
| | Mboard: X310
| | revision: 6
| | product: 30410
| | mac-addr0: 00:80:2f:21:37:a6
| | mac-addr1: 00:80:2f:21:37:a7
| | gateway: 192.168.10.1
| | ip-addr0: 192.168.10.3
| | subnet0: 255.255.255.0
| | ip-addr1: 192.168.20.2
| | subnet1: 255.255.255.0
| | ip-addr2: 192.168.30.2
| | subnet2: 255.255.255.0
| | ip-addr3: 192.168.40.2
| | subnet3: 255.255.255.0
| | serial: 30907F1
| | FW Version: 5.1
| | FPGA Version: 33.0
| | RFNoC capable: Yes
| |
| | Time sources: internal, external, gpsdo
| | Clock sources: internal, external, gpsdo
| | Sensors: ref_locked
| | _____________________________________________________
| | /
| | | RX Dboard: A
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: Unknown (0xffff) - 0
| | | | Antennas:
| | | | Sensors:
| | | | Freq range: 0.000 to 0.000 MHz
| | | | Gain Elements: None
| | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: A
| | | | Name: ads62p48
| | | | Gain range digital: 0.0 to 6.0 step 0.5 dB
| | _____________________________________________________
| | /
| | | RX Dboard: B
| | | ID: UBX-160 v1 (0x007a)
| | | Serial: 3090F8A
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: UBX RX
| | | | Antennas: TX/RX, RX2, CAL
| | | | Sensors: lo_locked
| | | | Freq range: 10.000 to 6000.000 MHz
| | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
| | | | Bandwidth range: 160000000.0 to 160000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: B
| | | | Name: ads62p48
| | | | Gain range digital: 0.0 to 6.0 step 0.5 dB
| | _____________________________________________________
| | /
| | | TX Dboard: A
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: Unknown (0xffff) - 0
| | | | Antennas:
| | | | Sensors:
| | | | Freq range: 0.000 to 0.000 MHz
| | | | Gain Elements: None
| | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: A
| | | | Name: ad9146
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX Dboard: B
| | | ID: UBX-160 v1 (0x0079)
| | | Serial: 3090F8A
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: UBX TX
| | | | Antennas: TX/RX, CAL
| | | | Sensors: lo_locked
| | | | Freq range: 10.000 to 6000.000 MHz
| | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
| | | | Bandwidth range: 160000000.0 to 160000000.0 step 0.0 Hz
| | | | Connection Type: QI
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: B
| | | | Name: ad9146
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | RFNoC blocks on this device:
| | |
| | | * DmaFIFO_0
| | | * Radio_0
| | | * Radio_1
| | | * sync_0
| | | * DDC_0
| | | * DDC_1
| | | * DUC_0
| | | * DUC_1
| | | * FIFO_0
| | | * FIFO_1
| | | * FIFO_2
| | | * FIFO_3
| | | * FIFO_4
You can notice that this X310 device has only one db (UBX-160) in the B
slot, which I thought was the source of the problem. In that case I made
myself sure to select 'B' in the RFNoC:Radio Block, but the error kept
appearing.
Just as a test, I tried the same flowgraph with the same .bit in another
computer (with the latest UHD, GNURadio and gr-ettus as well) that we
have at the lab and the same X310, so that I could check if the
enumeration of the daughterboards was being an issue. However in that
computer I can run the fg without any problem, even when selecting 'A'
in radio, where no db is present, which resulted even more confusing.
Please let me know if there is any more information I can provide.
- N
On 03.03.2017 01:55, Martin Braun via USRP-users wrote:
> Can you please post the output of uhd_usrp_probe?
>
> -- M
>
> On 03/01/2017 09:14 AM, Sebastian Mueller via USRP-users wrote:
>> Hi list,
>>
>> I'm currently trying to get a very basic RFNoC flowgraph running that
>> looks like this:
>>
>> [RFNoC: Radio] -> [RFNoC: DDC] -> [RFNoC: DmaFIFO] -> [QT GUI Frequency
>> Sink]
>>
>> When I try to run it, I get the following error:
>>
>> Traceback (most recent call last):
>> File "/home/user/src/rfnoc/examples/top_block.py", line 307, in <module>
>> main()
>> File "/home/user/src/rfnoc/examples/top_block.py", line 295, in main
>> tb = top_block_cls()
>> File "/home/user/src/rfnoc/examples/top_block.py", line 90, in __init__
>> 0, -1
>> File "/usr/local/lib/python2.7/dist-packages/ettus/ettus_swig.py",
>> line 2706, in make
>> return _ettus_swig.rfnoc_radio_make(dev, tx_stream_args,
>> rx_stream_args, radio_select, device_select)
>> RuntimeError: basic_string::_M_construct null not valid
>>
>> I have tried with Swig version 2.0.4 as well as 3.0.8 with the same
>> result. Also, I have switched DDC with DmaFIFO with no success.
>> UHD, gr-ettus and fpga are all newest versions from GitHub repos. Any
>> idea how I can fix this error?
>>
>> Cheers,
>> Sebastian
>>
>>
>>
>> _______________________________________________
>> 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: 27
Date: Fri, 3 Mar 2017 16:25:10 +0300
From: do ber <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Wireless data transfer
Message-ID:
<CABLDF_eWbM5M2+fDi-GEtDPLMeitf4J3dbxy85tMtp9=76+...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
Thanks for the replies. What I understand is that I should send the
starting times to the local computers for X310 case. Then the local
computers do their job and then I just collect the stored data.
For E312s, I think I can use wifi for data transfer via USB interface (for
my case(1MHz sampling rate for each channel) it is hard to realize over a
wireless network but in general I think it is possible). I think it is
better to store the data on a storage disk(i.e. flash drive) for E312 case.
Best regards,
Ali
2017-03-02 19:30 GMT+03:00 Marcus M?ller via USRP-users <
[email protected]>:
> Hi Ali,
>
> so, ok, what you need is pretty clearly a computer at every USRP, because
> for 1MS/s, you'll need to transport 32 Mb/s ? and that's typically a lot
> more than you can cheaply transfer over wireless networks (i.e. WiFi or
> LTE). You record the data on these computers, they don't have to be strong
> for these rates, and then collected the data later on.
>
> You coordinate the start of all the USRPs as discussed by synchronizing
> device to GPS time and using the same timed command on every device. Since
> the time in the timed command needs to be the same for every computer, the
> easiest way seems to be to equip every computer with just any cellular (2G,
> 3G, LTE, whatever) network access (i.e. a cellular modem), and send the
> times to the computers by having some really simple program on your
> computers that ask for the times to start and stop recording from a central
> server (eg. very simply using SSH).
>
> Best regards,
>
> Marcus
> On 03/02/2017 06:31 AM, do ber via USRP-users wrote:
>
> Hi,
>
> @Marcus, I need 4 channels and each channel will operate with a sampling
> rate of 1MHz.
>
> @Julian, I never used LTE modems. From what you said, I understand that I
> can communicate and receive data from USRPs by using LTE modems? If it is
> true, then I need to learn how to do that.
>
> @Julian, yes I need to start the experiment at all locations at the same
> time. So I am thinking only ONE computer controlling 2 USRPs. But somehow I
> need to get the I/Q data recorded at the same time interval. I did not
> unterstand what you mean by imlpying storing at local machines? Actually,
> the second option you said seems to be more convenient to my problem.
>
> I want to start and stop 4 channels at the same time. Then I will analyze
> the stored I/Q data OFFLINE. To be more specific, I want to implement a
> localization algorithm. So I need I/Q data from 4 channels and they must be
> synchronized in time and frequency. So it is important that USRPs start and
> stop recording data at the same time.
>
> Another option may be recording samples with their TIME TAGs. I mean at
> what time they are recorded. So may be then I can start two USRPs with the
> help of a friend. Then I can analyze the data by inspecting their time
> tags. But it would not be professional and I do not know is it possible in
> GNURadio. Also, adding time tag to communication will decrease the channel
> capacity.
>
> Thanks,
> Ali
>
>
> 2017-03-01 14:13 GMT+03:00 Julian Arnold <[email protected]>:
>
>> Hey,
>>
>> If I understood it correctly he only needs a control channel to start the
>> experiment at all locations at the same time. The actual data is then
>> stored on the local machines. Or did I get that wrong?
>> Streaming the whole data to a central location would of course be a
>> completely different story.
>>
>> Cheers,
>>
>> Julian Arnold, M.Sc
>>
>> On 1 Mar 2017, at 10:55, Marcus M?ller <[email protected]> wrote:
>>
>> I'd like to agree with Julian here. IQ data is typically very high-rate,
>> and you must tell us which rates you need to achieve on your six channels
>> before we can recommend anything.
>>
>> Also note that the x3x0 has pretty universally compatible 10 gigabit
>> Ethernet SFP+ ports, so the most intuitive way would simply be coming up
>> with a dedicated fibre optic network based e.g. on 10 GBase-LR.
>>
>> Best regards,
>> Marcus
>>
>> Am 1. M?rz 2017 09:29:33 MEZ schrieb Julian Arnold via USRP-users <
>> [email protected]>:
>>>
>>> Hi Ali,
>>>
>>> I could imagine that using something like LTE modems in the PCs
>>> controlling the USRPs could be a quick way to get a control channel up
>>> and running.
>>> Also, you could of course try to use the USRPs themselves to establish
>>> the control channel. However, I think this would be more involved than
>>> using an existing mobile network.
>>>
>>> Cheers,
>>> Julian
>>>
>>> On 03/01/2017 06:24 AM, do ber via USRP-users wrote:
>>>>
>>>> Hi,
>>>>
>>>> I think I explained my problem in a wrong way. I am normally using GNU
>>>> radio and I can synchronize them by using GPSDO. So far there is no
>>>> problem.
>>>>
>>>> Lets say there is 1km distance between 2 USRPs. What I am asking is how
>>>> can I start two distant USRP's from one computer. How can I get the I/Q
>>>> data from them. For example, can I control them via a kind of dongle
>>>> instead of an ethernet cable?
>>>>
>>>> In other words, I am saying that the USRPs are far away from me and I
>>>> cannot use cables. Is there a wireless solution?
>>>>
>>>> Best regards,
>>>> Ali
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------
>>>>
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>> -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>
>> _______________________________________________
> USRP-users mailing
> [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/20170303/a732c55f/attachment-0001.html>
------------------------------
Message: 28
Date: Fri, 3 Mar 2017 15:06:44 +0100
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Wireless data transfer
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
I doubt it will be possible with a wireless network in practice; 2x
1MS/s would mean 64 Mb/s, and that does work under theoretical perfect
situations with draft-N WiFi so far. In practice, I've never seen a WiFi
Connection reliably sustain that rate. Much less over a longer distance.
Local storage is very likely what you want.
Best regards,
Marcus
On 03/03/2017 02:25 PM, do ber via USRP-users wrote:
> Hi,
>
> Thanks for the replies. What I understand is that I should send the
> starting times to the local computers for X310 case. Then the local
> computers do their job and then I just collect the stored data.
>
> For E312s, I think I can use wifi for data transfer via USB interface
> (for my case(1MHz sampling rate for each channel) it is hard to
> realize over a wireless network but in general I think it is
> possible). I think it is better to store the data on a storage
> disk(i.e. flash drive) for E312 case.
>
> Best regards,
> Ali
>
> 2017-03-02 19:30 GMT+03:00 Marcus M?ller via USRP-users
> <[email protected] <mailto:[email protected]>>:
>
> Hi Ali,
>
> so, ok, what you need is pretty clearly a computer at every USRP,
> because for 1MS/s, you'll need to transport 32 Mb/s ? and that's
> typically a lot more than you can cheaply transfer over wireless
> networks (i.e. WiFi or LTE). You record the data on these
> computers, they don't have to be strong for these rates, and then
> collected the data later on.
>
> You coordinate the start of all the USRPs as discussed by
> synchronizing device to GPS time and using the same timed command
> on every device. Since the time in the timed command needs to be
> the same for every computer, the easiest way seems to be to equip
> every computer with just any cellular (2G, 3G, LTE, whatever)
> network access (i.e. a cellular modem), and send the times to the
> computers by having some really simple program on your computers
> that ask for the times to start and stop recording from a central
> server (eg. very simply using SSH).
>
> Best regards,
>
> Marcus
>
> On 03/02/2017 06:31 AM, do ber via USRP-users wrote:
>> Hi,
>>
>> @Marcus, I need 4 channels and each channel will operate with a
>> sampling rate of 1MHz.
>>
>> @Julian, I never used LTE modems. From what you said, I
>> understand that I can communicate and receive data from USRPs by
>> using LTE modems? If it is true, then I need to learn how to do that.
>>
>> @Julian, yes I need to start the experiment at all locations at
>> the same time. So I am thinking only ONE computer controlling 2
>> USRPs. But somehow I need to get the I/Q data recorded at the
>> same time interval. I did not unterstand what you mean by
>> imlpying storing at local machines? Actually, the second option
>> you said seems to be more convenient to my problem.
>>
>> I want to start and stop 4 channels at the same time. Then I will
>> analyze the stored I/Q data OFFLINE. To be more specific, I want
>> to implement a localization algorithm. So I need I/Q data from 4
>> channels and they must be synchronized in time and frequency. So
>> it is important that USRPs start and stop recording data at the
>> same time.
>>
>> Another option may be recording samples with their TIME TAGs. I
>> mean at what time they are recorded. So may be then I can start
>> two USRPs with the help of a friend. Then I can analyze the data
>> by inspecting their time tags. But it would not be professional
>> and I do not know is it possible in GNURadio. Also, adding time
>> tag to communication will decrease the channel capacity.
>>
>> Thanks,
>> Ali
>>
>>
>> 2017-03-01 14:13 GMT+03:00 Julian Arnold <[email protected]
>> <mailto:[email protected]>>:
>>
>> Hey,
>>
>> If I understood it correctly he only needs a control channel
>> to start the experiment at all locations at the same time.
>> The actual data is then stored on the local machines. Or did
>> I get that wrong?
>> Streaming the whole data to a central location would of
>> course be a completely different story.
>>
>> Cheers,
>>
>> Julian Arnold, M.Sc
>>
>> On 1 Mar 2017, at 10:55, Marcus M?ller
>> <[email protected] <mailto:[email protected]>>
>> wrote:
>>
>>> I'd like to agree with Julian here. IQ data is typically
>>> very high-rate, and you must tell us which rates you need to
>>> achieve on your six channels before we can recommend anything.
>>>
>>> Also note that the x3x0 has pretty universally compatible 10
>>> gigabit Ethernet SFP+ ports, so the most intuitive way would
>>> simply be coming up with a dedicated fibre optic network
>>> based e.g. on 10 GBase-LR.
>>>
>>> Best regards,
>>> Marcus
>>>
>>> Am 1. M?rz 2017 09:29:33 MEZ schrieb Julian Arnold via
>>> USRP-users <[email protected]
>>> <mailto:[email protected]>>:
>>>
>>> Hi Ali,
>>>
>>> I could imagine that using something like LTE modems in the PCs
>>> controlling the USRPs could be a quick way to get a control
>>> channel up
>>> and running.
>>> Also, you could of course try to use the USRPs themselves to
>>> establish
>>> the control channel. However, I think this would be more
>>> involved than
>>> using an existing mobile network.
>>>
>>> Cheers,
>>> Julian
>>>
>>> On 03/01/2017 06:24 AM, do ber via USRP-users wrote:
>>>
>>> Hi, I think I explained my problem in a wrong way. I
>>> am normally using GNU radio and I can synchronize
>>> them by using GPSDO. So far there is no problem.
>>> Lets say there is 1km distance between 2 USRPs. What
>>> I am asking is how can I start two distant USRP's
>>> from one computer. How can I get the I/Q data from
>>> them. For example, can I control them via a kind of
>>> dongle instead of an ethernet cable? In other words,
>>> I am saying that the USRPs are far away from me and
>>> I cannot use cables. Is there a wireless solution?
>>> Best regards, Ali
>>>
>>> ------------------------------------------------------------------------
>>> USRP-users mailing list [email protected]
>>> <mailto:[email protected]>
>>>
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>>>
>>>
>>> -- Sent from my Android device with K-9 Mail. Please excuse
>>> my brevity.
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
> _______________________________________________ USRP-users mailing
> list [email protected]
> <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> <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/20170303/45e8597e/attachment-0001.html>
------------------------------
Message: 29
Date: Fri, 3 Mar 2017 15:08:06 +0100
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Wireless data transfer
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
I doubt it will be possible with a wireless network in practice; 2x
1MS/s would mean 64 Mb/s, and that does work under theoretical perfect
situations with draft-N WiFi so far. In practice, I've never seen a WiFi
Connection reliably sustain that rate. Much less over a longer distance.
Local storage is very likely what you want. Really, you're about to
shuffle a couple Gigabytes of data per minute (if you do six channels a
1 MS/s). That's a bit much for anything but wired networks (and maybe,
dedicated microwave links).
Best regards,
Marcus
On 03/03/2017 02:25 PM, do ber via USRP-users wrote:
> Hi,
>
> Thanks for the replies. What I understand is that I should send the
> starting times to the local computers for X310 case. Then the local
> computers do their job and then I just collect the stored data.
>
> For E312s, I think I can use wifi for data transfer via USB interface
> (for my case(1MHz sampling rate for each channel) it is hard to
> realize over a wireless network but in general I think it is
> possible). I think it is better to store the data on a storage
> disk(i.e. flash drive) for E312 case.
>
> Best regards,
> Ali
>
> 2017-03-02 19:30 GMT+03:00 Marcus M?ller via USRP-users
> <[email protected] <mailto:[email protected]>>:
>
> Hi Ali,
>
> so, ok, what you need is pretty clearly a computer at every USRP,
> because for 1MS/s, you'll need to transport 32 Mb/s ? and that's
> typically a lot more than you can cheaply transfer over wireless
> networks (i.e. WiFi or LTE). You record the data on these
> computers, they don't have to be strong for these rates, and then
> collected the data later on.
>
> You coordinate the start of all the USRPs as discussed by
> synchronizing device to GPS time and using the same timed command
> on every device. Since the time in the timed command needs to be
> the same for every computer, the easiest way seems to be to equip
> every computer with just any cellular (2G, 3G, LTE, whatever)
> network access (i.e. a cellular modem), and send the times to the
> computers by having some really simple program on your computers
> that ask for the times to start and stop recording from a central
> server (eg. very simply using SSH).
>
> Best regards,
>
> Marcus
>
> On 03/02/2017 06:31 AM, do ber via USRP-users wrote:
>> Hi,
>>
>> @Marcus, I need 4 channels and each channel will operate with a
>> sampling rate of 1MHz.
>>
>> @Julian, I never used LTE modems. From what you said, I
>> understand that I can communicate and receive data from USRPs by
>> using LTE modems? If it is true, then I need to learn how to do that.
>>
>> @Julian, yes I need to start the experiment at all locations at
>> the same time. So I am thinking only ONE computer controlling 2
>> USRPs. But somehow I need to get the I/Q data recorded at the
>> same time interval. I did not unterstand what you mean by
>> imlpying storing at local machines? Actually, the second option
>> you said seems to be more convenient to my problem.
>>
>> I want to start and stop 4 channels at the same time. Then I will
>> analyze the stored I/Q data OFFLINE. To be more specific, I want
>> to implement a localization algorithm. So I need I/Q data from 4
>> channels and they must be synchronized in time and frequency. So
>> it is important that USRPs start and stop recording data at the
>> same time.
>>
>> Another option may be recording samples with their TIME TAGs. I
>> mean at what time they are recorded. So may be then I can start
>> two USRPs with the help of a friend. Then I can analyze the data
>> by inspecting their time tags. But it would not be professional
>> and I do not know is it possible in GNURadio. Also, adding time
>> tag to communication will decrease the channel capacity.
>>
>> Thanks,
>> Ali
>>
>>
>> 2017-03-01 14:13 GMT+03:00 Julian Arnold <[email protected]
>> <mailto:[email protected]>>:
>>
>> Hey,
>>
>> If I understood it correctly he only needs a control channel
>> to start the experiment at all locations at the same time.
>> The actual data is then stored on the local machines. Or did
>> I get that wrong?
>> Streaming the whole data to a central location would of
>> course be a completely different story.
>>
>> Cheers,
>>
>> Julian Arnold, M.Sc
>>
>> On 1 Mar 2017, at 10:55, Marcus M?ller
>> <[email protected] <mailto:[email protected]>>
>> wrote:
>>
>>> I'd like to agree with Julian here. IQ data is typically
>>> very high-rate, and you must tell us which rates you need to
>>> achieve on your six channels before we can recommend anything.
>>>
>>> Also note that the x3x0 has pretty universally compatible 10
>>> gigabit Ethernet SFP+ ports, so the most intuitive way would
>>> simply be coming up with a dedicated fibre optic network
>>> based e.g. on 10 GBase-LR.
>>>
>>> Best regards,
>>> Marcus
>>>
>>> Am 1. M?rz 2017 09:29:33 MEZ schrieb Julian Arnold via
>>> USRP-users <[email protected]
>>> <mailto:[email protected]>>:
>>>
>>> Hi Ali,
>>>
>>> I could imagine that using something like LTE modems in the PCs
>>> controlling the USRPs could be a quick way to get a control
>>> channel up
>>> and running.
>>> Also, you could of course try to use the USRPs themselves to
>>> establish
>>> the control channel. However, I think this would be more
>>> involved than
>>> using an existing mobile network.
>>>
>>> Cheers,
>>> Julian
>>>
>>> On 03/01/2017 06:24 AM, do ber via USRP-users wrote:
>>>
>>> Hi, I think I explained my problem in a wrong way. I
>>> am normally using GNU radio and I can synchronize
>>> them by using GPSDO. So far there is no problem.
>>> Lets say there is 1km distance between 2 USRPs. What
>>> I am asking is how can I start two distant USRP's
>>> from one computer. How can I get the I/Q data from
>>> them. For example, can I control them via a kind of
>>> dongle instead of an ethernet cable? In other words,
>>> I am saying that the USRPs are far away from me and
>>> I cannot use cables. Is there a wireless solution?
>>> Best regards, Ali
>>>
>>> ------------------------------------------------------------------------
>>> USRP-users mailing list [email protected]
>>> <mailto:[email protected]>
>>>
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>>>
>>>
>>> -- Sent from my Android device with K-9 Mail. Please excuse
>>> my brevity.
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
> _______________________________________________ USRP-users mailing
> list [email protected]
> <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> <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/20170303/593e9bc6/attachment-0001.html>
------------------------------
Message: 30
Date: Fri, 3 Mar 2017 16:14:03 +0100
From: Julian Arnold <[email protected]>
To: Carin <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Cannot se sent out signal in oscilloscope
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hey,
I'm sorry, there was a slight mistake in my last mail.
> The band-pass signal s_T(t) can be represented by the equivalent complex
> low-pass signal and the center frequency f0 as follows
should be:
The band-pass signal s(t) can be represented by the equivalent complex
low-pass signal s_T(t) and the center frequency f0 ...
I guess this already answers your question ;)
You send a complex signal (s_T(t)) to the USRP. The USRP takes this
signal and a center frequency and converts the complex signal
to a real valued band-pass signal s(t).
Cheers,
On 03/03/2017 03:56 PM, Carin wrote:
> Hello again,
>
> Im not sure I understand fully, a couple of questions:
>
> So it is a complex low pass signal s_T(t)e^(i2pif_0t) that is created in the
> signal source? But in the signal source there is nowhere to assign center
> frequency so the e^(i2pif_0t) has to be added in the uhd sink, no?
>
> In the formulae you sent S(t) is what the uhd sends to the usrp hardware,
> right?
>
>
>
>> 3 mars 2017 kl. 10:06 skrev Julian Arnold <[email protected]>:
>>
>> Hi Carin,
>>
>> the complex samples you sent to the UHD sink represent the complex low
>> pass signal equivalent to a real valued band-pass (signals that are not
>> centered around 0 Hz) representation of the signal. It is a mathematical
>> construct that comes in very handy when dealing with communication
>> signals as it lets you represent amplitude and phase easily. The
>> band-pass signal s_T(t) can be represented by the equivalent complex
>> low-pass signal and the center frequency f0 as follows:
>>
>> \documentclass{article}
>> \usepackage[utf8x]{inputenc}
>> \pagestyle{empty}
>> \begin{document}
>> $s(t) = Re\{ s_T(t) e^{j2 \pi f_0 t} \}$
>> \end{document}
>> [1]
>>
>> In your case the USRP is doing this conversion for you. It uses a
>> quadrature mixer to perform this step.
>>
>> Hope this helps. If you have more questions, let me know.
>>
>> [1] Ohm und L?ke, Signal?bertragung
>>
>> Cheers,
>> Julian
>>
>> On 03/02/2017 03:01 PM, Carin wrote:
>>> Hi Julian,
>>>
>>> Thank you for your answer, we got a signal at last. I have a more
>>> theoretical question regarding the UHD sink: why is its input specified as
>>> complex and not as float? I mean why would you and how can you transmit a
>>> complex signal? What is actually transmitted is a varying voltage, I would
>>> expect it to be sent based on a float-worth function of time??
>>>
>>> Just to explain why I ask this question: It seems that when I send a signal
>>> with non-zero imaginary part (a complex sinewave) into the uhdsink I dont
>>> get a signal on the oscilloscope, however, when I send in a signal with
>>> zero imaginary part (a float sin wave that has been converted to a complex
>>> signal) I do get a signal. Seems like sending in a non-zero imaginary part
>>> creates a problem in the UHD sink..?
>>>
>>> Thanks a lot!
>>> Carin
>>>
>>>
>>>> 1 mars 2017 kl. 18:14 skrev Julian Arnold <[email protected]>:
>>>>
>>>> Hi Carin,
>>>>
>>>> maybe you could elaborate a little bit more on you setup?
>>>> - How does you flow graph look like?
>>>> - What scope are you using (max BW?)
>>>>
>>>> Generally you will not be able to see just the signal you generate using
>>>> the signal source block on your scope as the USRP is up-converting that
>>>> signal to RF (to the center freq. you set in the UHD USRP Sink block).
>>>> Therefore, your scope needs to support a bandwidth that is greater than
>>>> the center freq. you chose in order to get a meaningful result.
>>>>
>>>> Hope that helps.
>>>> Cheers,
>>>> Julian
>>>>
>>>> On 03/01/2017 03:17 PM, Carin via USRP-users wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> We are working on an SDR solution for satellite communication using
>>>>>> your USRP B210 along with GNU Radio Companion. We got stuck on the
>>>>>> first step, i.e. transmitting a simple sine-signal created in GNU
>>>>>> radio to an oscilloscope. We are however getting some kind of signal,
>>>>>> but it doesn?t seem to be related to the frequency and amplitude of
>>>>>> the signal source, but rather to the center frequency of the uhd sink.
>>>>>>
>>>>>> We have also tried following the tutorial "Building a QPSK
>>>>>> Transmitter ? on your website but with the same results. Do you have
>>>>>> any ideas on what can be wrong?
>>>>>>
>>>>>> Regards,
>>>>>> Carin
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> [email protected]
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>> --
>>>> Julian Arnold, M.Sc.
>>>>
>>>> Institute for Networked Systems
>>>> RWTH Aachen University
>>>>
>>>> Kackertstrasse 9
>>>> 52072 Aachen
>>>> Germany
>> --
>> Julian Arnold, M.Sc.
>>
>> Institute for Networked Systems
>> RWTH Aachen University
>>
>> Kackertstrasse 9
>> 52072 Aachen
>> Germany
--
Julian Arnold, M.Sc.
Institute for Networked Systems
RWTH Aachen University
Kackertstrasse 9
52072 Aachen
Germany
------------------------------
Message: 31
Date: Fri, 3 Mar 2017 10:22:26 -0500
From: Yang Liu <[email protected]>
To: Martin Braun <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] USRP X310 suffers from severe underflow when
running ofdm
Message-ID:
<cad4vfmev9grk4euvd_+d-9bgpx2pv3scqqvdo3fe9kebkaq...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Martin,
Thanks a lot for your help.
I tried uhd_siggen_gui and there is no underflow until the sample rate is
very high (around 30Msps).
We are running with 3.11UHD and gnuradio 3.7.10 . I can understand that
when the sample rate is really high, then underflow will happen when
running ofdm tx. However, when I set the sample rate to be 1Msps which is
not high and can be supported by the USRP N210, severe underflow still
happens with x310. This bothers me a lot.
Another question, when I try to run the ofdm tx code with X310, compared
with N210, I am wondering whether I need to set more parameters in the code
side to make it work? The current set up is in the following:
self.sink = uhd.usrp_sink(",".join(("addr=192.168.10.4", "")),
uhd.stream_args(
cpu_format="fc32",
channels=range(1),
),
)
self.sink.set_samp_rate(samp_rate)
self.sink.set_center_freq(2.45e9, 0)
self.sink.set_gain(30, 0)
self.sink.set_antenna('TX/RX', 0)
self.sink.set_subdev_spec('A:0', 0)
Thanks,
Yang
On Thu, Mar 2, 2017 at 7:54 PM, Martin Braun via USRP-users <
[email protected]> wrote:
> Yang,
>
> we have confirmed some issues with the 3.10 UHD code you're running at
> really high rates, but I'm not sure why they wouldn't work with lower
> rates.
>
> Can you confirm that other apps also fail, e.g. uhd_siggen_gui?
>
> Cheers,
> Martin
>
> On 03/02/2017 11:19 AM, Yang Liu via USRP-users wrote:
> > Dear all,
> >
> > Now we have USRP X310 with UBX 160 daughterboards(FPGA 33.0, FW 5.1),
> > and we tried to run OFDM TX code on it.
> >
> > OFDM TX comes from ofdm_lookback.grc, we extracted transmitter side code
> > out (everything before channel model) and ran it with the device.
> >
> > The problem is that the device suffers from severe underflow no matter
> > what sampling rate we set (from 400K to 20M ), another odd observation
> > is that lower sample rate seem to generate higher traffic on the
> > Ethernet interface (1GBASE-T). The under run issue seem to go away after
> > sometime especially with lower sample rate (1M or less) We ran the same
> > code on USRP N210 (SBX) at the same sampling rate, no underflow happens,
> > so the application itself can provide samples fast enough and problem
> > should be with the device (FPGA controller for SFP?)
> >
> > We truly don't know what's going on here. Any help will be appreciated.
> >
> > Thanks a lot,
> > 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/20170303/cc8864db/attachment-0001.html>
------------------------------
Message: 32
Date: Fri, 3 Mar 2017 10:27:34 -0500
From: Dave NotTelling <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310/UBX Retuning Performance
Message-ID:
<cak6gvupvdd--jbq1swn919tb1dkde121i1irnsxmngqknus...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Can performance mode help with the > 100ms tuning time between the two
bands? I seem to recall the performance mode setting relating to when the
unused PA is powered off. Also, is the long tuning time something that the
UHD code causes or is that just a number that the developer should keep in
mind when switching bands?
Thanks!
On Fri, Feb 24, 2017 at 3:41 PM, Dave NotTelling <[email protected]>
wrote:
> Thanks!
>
> On Fri, Feb 24, 2017 at 3:32 PM, Marcus M?ller via USRP-users <
> [email protected]> wrote:
>
>> Largely: Yes; the UBX160 and UBX40 only differ in their baseband filters'
>> passive component values (see the schematics).
>>
>> There's a bit of a difference on how you can clock the UBX on N210, but
>> that won't change behaviour all that much. Also, due to the 100 MHz instead
>> of X3xx's 200 MHz master clock rate, your timing granularity is twice as
>> bad :)
>>
>> Best regards,
>>
>> Marcus
>> On 24.02.2017 21:24, Dave NotTelling via USRP-users wrote:
>>
>> Do these tuning/settling times also hold true for the UBX-40 in an N210?
>>
>> On Fri, Feb 24, 2017 at 2:47 PM, Derek Kozel via USRP-users <
>> [email protected]> wrote:
>>
>>> Hi Jason,
>>>
>>> If you use the set_command_time function to cause the tune to occur at a
>>> specific time then you can use the in-band timestamps from the recv call to
>>> identify the sample when the tune action started. The 500us of samples
>>> following that timestamp are the ones you would want to discard.
>>>
>>> An example of setting the execution time for a command:
>>> https://github.com/EttusResearch/uhd/blob/master/host/exampl
>>> es/test_timed_commands.cpp#L96
>>>
>>> An example of starting streaming at a set time:
>>> https://github.com/EttusResearch/uhd/blob/master/host/exampl
>>> es/test_timed_commands.cpp#L129
>>>
>>> Regards,
>>> Derek
>>>
>>>
>>> On Fri, Feb 24, 2017 at 11:27 AM, Jason Roehm via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> On 02/24/2017 01:24 PM, Michael West via USRP-users wrote:
>>>>
>>>>> Hi Devin,
>>>>>
>>>>> I have measured the UBX tune time. The SPI writes to tune the LO take
>>>>> ~30-60us and the LO lock time is 400us. I recommend discarding at least
>>>>> 500us of samples after the LO tune. I also recommend continuous streaming
>>>>> of samples so the frontend components are not switched on and off, which
>>>>> can cause long transients. For the UBX-160, set the dboard_clock_rate to
>>>>> 20e6 and tune the LO in steps of 160 MHz. If using a sample rate <200
>>>>> Msps, use DSP tuning (which takes < 1us) for the frequencies between the
>>>>> 160MHz steps. With that, you should be able to tune across the full 6GHz
>>>>> in ~18ms in theory. There is one caveat. There are 2 LNAs on the UBX, one
>>>>> for <1.5 GHz and one for above. Only one can be powered on at a time and
>>>>> the warm up time is significant (in the 100s of milliseconds for the low
>>>>> band LNA and 10s of milliseconds for the high band LNA),, so you would be
>>>>> best suited using one daughterboard for the low band and one for the high
>>>>> band for the fastest sweep time.
>>>>>
>>>>> Unfortunately, I do not have the same experience with the TwinRX, so i
>>>>> cannot advise on it.
>>>>>
>>>>
>>>> Not to hijack this thread, but do you have any recommendations on the
>>>> most effective way to properly time the "discard 500us of samples after the
>>>> LO tune?" One of the drawbacks of using the USRP family for applications
>>>> that require fast retuning is that there isn't (from what I can tell) any
>>>> in-band indication of what center frequency the radio is tuned to. The
>>>> control interface (e.g. through multi_usrp::set_rx_center_freq()) is
>>>> completely separate from the data streaming interface, so if I call
>>>> set_rx_center_freq() at time T, I have no way of accurately estimating when
>>>> the tune will actually be complete in the data stream.
>>>>
>>>> This seems to be a disadvantage of the CHDR protocol that contemporary
>>>> USRPs use; they seem to carry data samples and timetags, but nothing else.
>>>> VITA 49 is nice in that it can provide full context in timetagged packets,
>>>> so you can get updates as to the radio state (e.g. frequency, gain) that
>>>> are aligned as closely as possible with the associated samples from the
>>>> SDR.
>>>>
>>>> Jason
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>> [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/20170303/1cf643ef/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 79, Issue 3
*****************************************
