USRP-users Digest, Vol 70, Issue 7

[usrp-users-request]

Send USRP-users mailing list submissions to
        usrp-users@lists.ettus.com

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
        usrp-users-requ...@lists.ettus.com

You can reach the person managing the list at
        usrp-users-ow...@lists.ettus.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."


Today's Topics:

   1. RFNoC with system containing an N210 and X310 (Dave NotTelling)
   2. Re: RFNoC with system containing an N210 and X310
      (Dave NotTelling)
   3. RFNoC block in GNURadio not appearing under UHD (Jason Matusiak)
   4. Re: RFNoC - No radio block found (Jonathon Pendlum)
   5. Re: Unable to get Vivado Hardware Manager to recognize the
      Chipscope ILA cores in the Ettus x310 (Jonathon Pendlum)
   6. Zero sample rx_time tag value not zero (Jacob Gilbert)
   7. AddSub example port not connected error (Kieran Lea)
   8. Re: RFNoC block in GNURadio not appearing under UHD (Martin Braun)
   9. Re: RFNoC with system containing an N210 and X310 (Martin Braun)
  10. Re: Cross Compiling RFNoC for E310 (Martin Braun)
  11. Re: AddSub example port not connected error (Martin Braun)
  12. Re: Cross Compiling RFNoC for E310 (Sean Nowlan)
  13. Re: RFNoC with system containing an N210 and X310
      (Dave NotTelling)
  14. Re: gr-ettus RFNoC 1024 Bin FFT Limit? (Martin Braun)
  15. Re: RFNoC with system containing an N210 and X310 (Martin Braun)
  16. Re: Error using RFNoC OFDM Sync block on E310 (Martin Braun)
  17. Re: gr-ettus RFNoC 1024 Bin FFT Limit? (Dave NotTelling)
  18. Re: Cross Compiling RFNoC for E310 (Philip Balister)
  19. run a program when the E310 boot start (Ekko)
  20. Re: RFNoC block in GNURadio not appearing under UHD
      (Marcus M?ller)
  21. Re: run a program when the E310 boot start (Philip Balister)
  22. Re: RFNoC block in GNURadio not appearing under UHD
      (Jason Matusiak)
  23. Re: AddSub example port not connected error (Kieran Lea)


----------------------------------------------------------------------

Message: 1
Date: Mon, 6 Jun 2016 12:38:12 -0400
From: Dave NotTelling <dmp250...@gmail.com>
To: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] RFNoC with system containing an N210 and X310
Message-ID:
        <CAK6GVuPodz3vVrKPWN57D8DAs-DymabOe20YVdk7Kds=_0m...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

I have both an N210 and an X310 hooked up to the same desktop.  I was going
to test out running RFNoC for the X310 but realized that the N210 no longer
worked.  I knew that the RFNoC FPGA goodness would not work on the N210
because of the Spartan FPGA, but I assumed that the RFNoC codebase would
still be able to use the normal UHD API to access the N210.  While I can
initialize the N210 with no issue, things go bad when I try to stream
samples.  As a sanity check I also tried uhd_fft and it bombs out with the
exception below.  When I updated the FPGA image with the newest from the
rfnoc-radio-redo code it would always complain about having the wrong image.

Is it even possible to run an N210 off of the RFNoC code?

[exception]
uhd_fft -a addr=192.168.10.2 -f 4e9
linux; GNU C++ version 4.8.4; Boost_105400;
UHD_003.010.rfnoc-radio-redo-547-ge915cbee

-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes

UHD Warning:
    Unable to set the thread priority. Performance may be negatively
affected.
    Please see the general application notes in the manual for instructions.
    EnvironmentError: OSError: error in pthread_setschedparam
Traceback (most recent call last):
  File "/usr/local/bin/uhd_fft", line 448, in <module>
    main()
  File "/usr/local/bin/uhd_fft", line 431, in main
    tb = uhd_fft(args)
  File "/usr/local/bin/uhd_fft", line 128, in __init__
    self.setup_usrp(uhd.usrp_source, args)
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_app.py",
line 137, in setup_usrp
    channels=self.channels,
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
line 122, in constructor_interceptor
    return old_constructor(*args)
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
line 2249, in make
    return _uhd_swig.usrp_source_make(*args)
RuntimeError: LookupError: IndexError: multi_usrp::mb_root(21809472) -
vector::_M_range_check
[/exception]



Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160606/3d261de7/attachment-0001.html>

------------------------------

Message: 2
Date: Mon, 6 Jun 2016 12:42:56 -0400
From: Dave NotTelling <dmp250...@gmail.com>
To: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] RFNoC with system containing an N210 and
        X310
Message-ID:
        <CAK6GVuMRV54f1fg68-B1q6MC=+o5eehsrfahuzyizvxrxlj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Oh, and here is the code I was using to test with:

[code]
#include <stdlib.h>
#include <stdio.h>
#include <uhd/usrp/multi_usrp.hpp>

int main(){
    uhd::usrp::multi_usrp::sptr usrp =
uhd::usrp::multi_usrp::make(uhd::device_addr_t("addr=192.168.10.2"));
    uhd::rx_streamer::sptr rx =
usrp->get_rx_stream(uhd::stream_args_t("fc32", "sc16"));
    return 0;
}
[/code]

Compiled with 'g++ test.cpp -o test -luhd'


The error I get is (even though I have run the supplied commands and
rebooted the radio):

./test
linux; GNU C++ version 4.8.4; Boost_105400;
UHD_003.010.rfnoc-radio-redo-547-ge915cbee

-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
terminate called after throwing an instance of 'uhd::runtime_error'
  what():  RuntimeError:
Please update the firmware and FPGA images for your device.
See the application notes for USRP2/N-Series for instructions.
Expected FPGA compatibility number 11, but got 10:
The FPGA build is not compatible with the host code build.
Please run:

 "/usr/local/lib/uhd/utils/uhd_images_downloader.py"
 "/usr/local/bin/uhd_image_loader" \
    --args="type=usrp2,addr=192.168.10.2"



I'm trying to avoid having multiple versions of UHD on the same system
since so many other things depend on UHD.

On Mon, Jun 6, 2016 at 12:38 PM, Dave NotTelling <dmp250...@gmail.com>
wrote:

> I have both an N210 and an X310 hooked up to the same desktop.  I was
> going to test out running RFNoC for the X310 but realized that the N210 no
> longer worked.  I knew that the RFNoC FPGA goodness would not work on the
> N210 because of the Spartan FPGA, but I assumed that the RFNoC codebase
> would still be able to use the normal UHD API to access the N210.  While I
> can initialize the N210 with no issue, things go bad when I try to stream
> samples.  As a sanity check I also tried uhd_fft and it bombs out with the
> exception below.  When I updated the FPGA image with the newest from the
> rfnoc-radio-redo code it would always complain about having the wrong image.
>
> Is it even possible to run an N210 off of the RFNoC code?
>
> [exception]
> uhd_fft -a addr=192.168.10.2 -f 4e9
> linux; GNU C++ version 4.8.4; Boost_105400;
> UHD_003.010.rfnoc-radio-redo-547-ge915cbee
>
> -- Opening a USRP2/N-Series device...
> -- Current recv frame size: 1472 bytes
> -- Current send frame size: 1472 bytes
>
> UHD Warning:
>     Unable to set the thread priority. Performance may be negatively
> affected.
>     Please see the general application notes in the manual for
> instructions.
>     EnvironmentError: OSError: error in pthread_setschedparam
> Traceback (most recent call last):
>   File "/usr/local/bin/uhd_fft", line 448, in <module>
>     main()
>   File "/usr/local/bin/uhd_fft", line 431, in main
>     tb = uhd_fft(args)
>   File "/usr/local/bin/uhd_fft", line 128, in __init__
>     self.setup_usrp(uhd.usrp_source, args)
>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_app.py",
> line 137, in setup_usrp
>     channels=self.channels,
>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
> line 122, in constructor_interceptor
>     return old_constructor(*args)
>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> line 2249, in make
>     return _uhd_swig.usrp_source_make(*args)
> RuntimeError: LookupError: IndexError: multi_usrp::mb_root(21809472) -
> vector::_M_range_check
> [/exception]
>
>
>
> Thanks!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160606/bea2ba6d/attachment-0001.html>

------------------------------

Message: 3
Date: Mon, 6 Jun 2016 12:57:39 -0400
From: Jason Matusiak <ja...@gardettoengineering.com>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] RFNoC block in GNURadio not appearing under UHD
Message-ID: <5755ab83.4000...@gardettoengineering.com>
Content-Type: text/plain; charset=utf-8; format=flowed

What am I doing wrong when I create a new gr-something block? Whenever I 
create a new block, it shows up under "none" in the block list in GRC; 
yet I would expect it to show up in UHD->RFNOC.

I have a feeling it has something to do with the block_tree.xml I put in 
my gr-something/grc folder, but I can't figure out what.  My current one 
looks like:
<?xml version="1.0"?>
<!--
###################################################
##Block Tree for uhd blocks.
###################################################
  -->
<cat>
     <name></name> <!-- Blank for Root Name -->
     <cat>
         <name>UHD</name>
         <cat>
             <name>RFNoC</name>
             <block>uhd_rfnoc_freq_shift.xml</block>
         </cat>
     </cat>
</cat>

What am I missing?



------------------------------

Message: 4
Date: Mon, 6 Jun 2016 12:34:01 -0500
From: Jonathon Pendlum <jonathon.pend...@ettus.com>
To: Dave NotTelling <dmp250...@gmail.com>
Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] RFNoC - No radio block found
Message-ID:
        <CAGdo0uSwt9bT+dLRaVb84GEEExZBZeCEOeNHsTq6kh=rqrv...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hey Dave,

We haven't made an image package for the rfnoc-radio-redo branch, so you'll
need to build a FPGA image. Once everything is merged back to rfnoc-devel
we'll make an image package.



Jonathon

On Mon, Jun 6, 2016 at 10:45 AM, Dave NotTelling via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I am compiled the newest rfnoc-radio-redo for uhd and gr-ettus and now
> when I try to run the example graphs in GNU Radio I get the following error:
>
> -- ========== Full list of RFNoC blocks: ============
> -- * 0/Block_0
> -- * 0/Block_1
> -- * 0/AddSub_0
> -- * 0/FIR_0
> -- * 0/FFT_0
> -- * 0/Window_0
> -- * 0/NullSrcSink_0
> -- * 0/LogPwr_0
> -- * 0/MovingAverage_0
> -- * 0/VectorIIR_0
> -- * 0/KeepOneInN_0
> -- No Radio Block found. Assuming radio-less operation.
> [Then later]
> Traceback (most recent call last):
>   File "/opt/git/gr-ettus/examples/rfnoc/rfnoc_fft.py", line 248, in
> <module>
>     main()
>   File "/opt/git/gr-ettus/examples/rfnoc/rfnoc_fft.py", line 236, in main
>     tb = top_block_cls()
>   File "/opt/git/gr-ettus/examples/rfnoc/rfnoc_fft.py", line 92, in
> __init__
>     0, -1
>   File "/usr/local/lib/python2.7/dist-packages/ettus/ettus_swig.py", line
> 2692, in make
>     return _ettus_swig.rfnoc_radio_make(*args, **kwargs)
> RuntimeError: Cannot find a block for ID: Radio_0
>
> The FIFO block is also missing from that list.
>
> I had to run cmake with -DENABLE_B200=No and I added in
> -DCMAKE_BUILD_TYPE=Debug just because.  No other special options were
> used.  I am running on Ubuntu 14.04.4 and using and X310 with the UBX-160
> over 10G Ethernet.  I ran the downloader script and updated the image on
> the radio using the commands that uhd_fft output for me.
>
> Thanks!
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> 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/20160606/4f72aea0/attachment-0001.html>

------------------------------

Message: 5
Date: Mon, 6 Jun 2016 12:40:48 -0500
From: Jonathon Pendlum <jonathon.pend...@ettus.com>
To: "Swanson, Craig" <craig.swan...@gtri.gatech.edu>
Cc: Martin Braun <martin.br...@ettus.com>, Marcus M?ller
        <marcus.muel...@ettus.com>,     "usrp-users@lists.ettus.com"
        <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Unable to get Vivado Hardware Manager to
        recognize the Chipscope ILA cores in the Ettus x310
Message-ID:
        <cagdo0usrc-fvg1_i4+p8qnqnb7p-dacxxm4qdmq6nwy5teq...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hey Craig,

By default, ce_clk is hooked up to radio_clk in rfnoc_ce_auto_inst_x310.v.
Did your new image work? Are you still getting the ADC error?



Jonathon

On Mon, May 30, 2016 at 12:59 AM, Swanson, Craig <
craig.swan...@gtri.gatech.edu> wrote:

> Jonathon,
>
> Thank you for your speedy reply.
>
>    1. ??According to the directions you sent me a while ago, I ran in GUI
>    mode such as "make GUI=1 X310_RFNOC_HGS"
>    2. I interrupted Vivado and created the debug cores in the synthesis
>    step, using your example in noc_block_moving_avg.  (* dont_touch = "true",
>    mark_debug = "true" *)
>    3. I continued on with Vivado creating a bit file x300.bit
>    4. I used the uhd_image_loader with the x300.bit file.
>    5. When I ran "uhd_usrp_probe --init-only, I got a really weird result
>    which is telling me something is not right about the x300.bit file.  Error:
>    RuntimeError: self_cal_adc_capture_delay: Self calibration failed.
>    Convergence error.?
>    6. I am going to run "make X310_RFNOC_HGS" and hope that the
>    timing.xdc file will now automatically find my ILA_0 (signals triggering
>    off of bus_clk) and ILA_1 (signals triggering off of ce_clk).  I am
>    expecting it to produce a usrp_x310_rfnoc_fpga_HGS.bit file.
>    7. I am not sure what you mean by the radio_clk.  In
>    noc_block_moving_avg I am guessing the radio_clk you are referring to is
>    the ce_clk.
>
> Craig
>
>
> *Craig F. Swanson*
>
> *Research Engineer II *
> *Information and Communications Laboratory*
> *Communications, Systems, and Spectrum Division*
> *Georgia Tech Research Institute*
>
>
> *Room 560 250 14th St NW *
> *Atlanta, GA 30318*
> *Cell: 770.298.9156 <770.298.9156>*
> http://www.gtri.gatech.edu
> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
>
> ------------------------------
> *From:* Jonathon Pendlum <jonathon.pend...@ettus.com>
> *Sent:* Monday, May 30, 2016 1:27 AM
> *To:* Swanson, Craig
> *Cc:* Martin Braun; Marcus M?ller; usrp-users@lists.ettus.com
> *Subject:* Re: Unable to get Vivado Hardware Manager to recognize the
> Chipscope ILA cores in the Ettus x310
>
> Craig,
>
> Are your cores using radio_clk? If so, you need to run uhd_usrp_probe to
> initialize radio_clk.
>
>
>
> Jonathon
>
> On Sun, May 29, 2016 at 11:39 PM, Swanson, Craig <
> craig.swan...@gtri.gatech.edu> wrote:
>
>> Jonathon,
>>
>> Is there anything I might be doing wrong to get Chipscope to open?
>>
>>    1. ?I created two ILA debug cores during synthesis
>>    2. Created a new .bit file and used uhd_image_loader to put the new
>>    x300.bit in the x310.
>>    3. Powered off and on the x310.
>>    4. Connected the USB JTAG cable to the x310
>>    5. Opened up a new target in the Hardware manager and it sees the
>>    Digilent xc7k410t_0 but says there are no debug cores.
>>
>> Craig
>>
>>
>>
>> *Craig F. Swanson*
>>
>> *Research Engineer II *
>> *Information and Communications Laboratory*
>> *Communications, Systems, and Spectrum Division*
>> *Georgia Tech Research Institute*
>>
>>
>> *Room 560 250 14th St NW *
>> *Atlanta, GA 30318*
>> *Cell: 770.298.9156 <770.298.9156>*
>> http://www.gtri.gatech.edu
>> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160606/9d5c5ddf/attachment-0001.html>

------------------------------

Message: 6
Date: Mon, 6 Jun 2016 13:45:53 -0600
From: Jacob Gilbert <mrjacobagilb...@gmail.com>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] Zero sample rx_time tag value not zero
Message-ID:
        <CAC52AkARGJGKH==fmDMFrfKkiH-q=cvKCNLtMvbZpjmw=we...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

I am working on an application that requires very precise rx/tx time
synchronization and have noticed something unexpected that I am looking for
a little clarification on. The USRP is a B200 mini and UHD release 3.9.2.
Currently I start my flowgraph as follows so that I know exactly when it
started - in this case, at time = {1, 0.0}.

1) tb = <tb setup here, just a USRP source, tag debug and null sink>
2) tb.usrp_src.set_time_unknown_pps(uhd.time_spec_t(0.0))
3) tb.usrp_src.set_start_time(uhd.time_spec_t(1.0))
4) tb.run()

I would therefore expect the first sample received to be representative of
the signal digitized at time {1, 0.0} within a small margin due to
decimation. I would also expect to receive a rx_time tag on the first
sample with value {1, 0.0} however I receive a tag with the floating point
component of the tuple off by some number of microseconds. This number is
precisely repeatable upon consecutive runs, and depends on master clock
rate and FPGA decimation and nothing else I can see:

For example (B200 Mini):
1) Master Rate = 32M, decim = 100, output = 320k: rx_time = {1 0.000112531}
2) Master Rate = 16M, decim = 50, output = 320k: rx_time = {1 7.68125e-05}
3) Master Rate = 32M, decim = 50, output = 640k: rx_time = {1 3.84063e-05}
4) Master Rate = 16M, decim = 20, output = 800k: rx_time =  {1 4.75625e-05}
5) Master Rate = 32M, decim = 20, output = 1.6M: rx_time = {1 2.37812e-05}
6) Master Rate = 16M, decim = 10, output = 1.6M: rx_time = {1 1.68125e-05}

I am assuming this is due to internal FPGA filter group delay as for a
particular decimation the offset represents the same number of samples but
want to verify.

Is my initial assumption that the 0th sample was digitized at exactly {1,
0.0} correct? Is there an identical delay on the transmit path (or some
other delay that can be calculated) so transmission (at DAC) relative to
receive (at ADC) can be synchronized within a sample or two? Is this even
necessary?

Thank you,
Jacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160606/7fc05834/attachment-0001.html>

------------------------------

Message: 7
Date: Mon, 6 Jun 2016 13:44:21 +0000
From: Kieran Lea <kieran....@unb.ca>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] AddSub example port not connected error
Message-ID:
        
<sn2pr04mb2304a4d867662ec9b88310bef3...@sn2pr04mb2304.namprd04.prod.outlook.com>
        
Content-Type: text/plain; charset="iso-8859-1"

Hi,


I tried using the addsub example here: 
https://github.com/EttusResearch/gr-ettus/tree/master/examples/rfnoc


and I get an error:


thread[thread-per-block[3]: <block uhd_rfnoc_AddSub (1)>]: RuntimeError: On 
node 0/AddSub_0, input port 0 is already connected.


I saw another person on the list ask this question earlier and you guys had 
said it was GNURadio getting confused with an output to a regular block and an 
RFNoC block, but I'm wondering if that's the case, because it seems both ports 
are connected to a regular block? I also tried a few other configurations and 
they resulted in the same error. I'm on the devel branch with an X310, any idea 
how to get it working?


Thanks

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160606/aae54706/attachment-0001.html>

------------------------------

Message: 8
Date: Mon, 6 Jun 2016 14:56:35 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] RFNoC block in GNURadio not appearing under
        UHD
Message-ID: <5755f193.3060...@ettus.com>
Content-Type: text/plain; charset=windows-1252

Does your block XML file have its own <category> maybe?

On 06/06/2016 09:57 AM, Jason Matusiak via USRP-users wrote:
> What am I doing wrong when I create a new gr-something block? Whenever I
> create a new block, it shows up under "none" in the block list in GRC;
> yet I would expect it to show up in UHD->RFNOC.
> 
> I have a feeling it has something to do with the block_tree.xml I put in
> my gr-something/grc folder, but I can't figure out what.  My current one
> looks like:
> <?xml version="1.0"?>
> <!--
> ###################################################
> ##Block Tree for uhd blocks.
> ###################################################
>  -->
> <cat>
>     <name></name> <!-- Blank for Root Name -->
>     <cat>
>         <name>UHD</name>
>         <cat>
>             <name>RFNoC</name>
>             <block>uhd_rfnoc_freq_shift.xml</block>
>         </cat>
>     </cat>
> </cat>
> 
> What am I missing?
> 
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com




------------------------------

Message: 9
Date: Mon, 6 Jun 2016 14:57:28 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] RFNoC with system containing an N210 and
        X310
Message-ID: <5755f1c8.10...@ettus.com>
Content-Type: text/plain; charset=windows-1252

Dave,

looks like you've stumbled on a bug. Which branch is this? rfnoc-devel
or rfnoc-radio-redo?

M

On 06/06/2016 09:42 AM, Dave NotTelling via USRP-users wrote:
> Oh, and here is the code I was using to test with:
> 
> [code]
> #include <stdlib.h>
> #include <stdio.h>
> #include <uhd/usrp/multi_usrp.hpp>
> 
> int main(){
>     uhd::usrp::multi_usrp::sptr usrp =
> uhd::usrp::multi_usrp::make(uhd::device_addr_t("addr=192.168.10.2"));
>     uhd::rx_streamer::sptr rx =
> usrp->get_rx_stream(uhd::stream_args_t("fc32", "sc16"));
>     return 0;
> }
> [/code]
> 
> Compiled with 'g++ test.cpp -o test -luhd'
> 
> 
> The error I get is (even though I have run the supplied commands and
> rebooted the radio):
> 
> ./test 
> linux; GNU C++ version 4.8.4; Boost_105400;
> UHD_003.010.rfnoc-radio-redo-547-ge915cbee
> 
> -- Opening a USRP2/N-Series device...
> -- Current recv frame size: 1472 bytes
> -- Current send frame size: 1472 bytes
> terminate called after throwing an instance of 'uhd::runtime_error'
>   what():  RuntimeError: 
> Please update the firmware and FPGA images for your device.
> See the application notes for USRP2/N-Series for instructions.
> Expected FPGA compatibility number 11, but got 10:
> The FPGA build is not compatible with the host code build.
> Please run:
> 
>  "/usr/local/lib/uhd/utils/uhd_images_downloader.py"
>  "/usr/local/bin/uhd_image_loader" \
>     --args="type=usrp2,addr=192.168.10.2"
> 
> 
> 
> I'm trying to avoid having multiple versions of UHD on the same system
> since so many other things depend on UHD.
> 
> On Mon, Jun 6, 2016 at 12:38 PM, Dave NotTelling <dmp250...@gmail.com
> <mailto:dmp250...@gmail.com>> wrote:
> 
>     I have both an N210 and an X310 hooked up to the same desktop.  I
>     was going to test out running RFNoC for the X310 but realized that
>     the N210 no longer worked.  I knew that the RFNoC FPGA goodness
>     would not work on the N210 because of the Spartan FPGA, but I
>     assumed that the RFNoC codebase would still be able to use the
>     normal UHD API to access the N210.  While I can initialize the N210
>     with no issue, things go bad when I try to stream samples.  As a
>     sanity check I also tried uhd_fft and it bombs out with the
>     exception below.  When I updated the FPGA image with the newest from
>     the rfnoc-radio-redo code it would always complain about having the
>     wrong image.
> 
>     Is it even possible to run an N210 off of the RFNoC code?
> 
>     [exception]
>     uhd_fft -a addr=192.168.10.2 -f 4e9
>     linux; GNU C++ version 4.8.4; Boost_105400;
>     UHD_003.010.rfnoc-radio-redo-547-ge915cbee
> 
>     -- Opening a USRP2/N-Series device...
>     -- Current recv frame size: 1472 bytes
>     -- Current send frame size: 1472 bytes
> 
>     UHD Warning:
>         Unable to set the thread priority. Performance may be negatively
>     affected.
>         Please see the general application notes in the manual for
>     instructions.
>         EnvironmentError: OSError: error in pthread_setschedparam
>     Traceback (most recent call last):
>       File "/usr/local/bin/uhd_fft", line 448, in <module>
>         main()
>       File "/usr/local/bin/uhd_fft", line 431, in main
>         tb = uhd_fft(args)
>       File "/usr/local/bin/uhd_fft", line 128, in __init__
>         self.setup_usrp(uhd.usrp_source, args)
>       File
>     "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_app.py",
>     line 137, in setup_usrp
>         channels=self.channels,
>       File
>     "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
>     line 122, in constructor_interceptor
>         return old_constructor(*args)
>       File
>     "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
>     line 2249, in make
>         return _uhd_swig.usrp_source_make(*args)
>     RuntimeError: LookupError: IndexError: multi_usrp::mb_root(21809472)
>     - vector::_M_range_check
>     [/exception]
> 
> 
> 
>     Thanks!
> 
> 
> 
> 
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 




------------------------------

Message: 10
Date: Mon, 6 Jun 2016 14:58:58 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Cross Compiling RFNoC for E310
Message-ID: <5755f222.7030...@ettus.com>
Content-Type: text/plain; charset=windows-1252

On 06/06/2016 08:07 AM, Sam Carey via USRP-users wrote:
> As I understand it, cross-compiling means that the building takes place
> on my desktop machine and then the results are installed on the E310.

Yep.

> So I install the SDK toolchain on my desktop in /usr/local/.

Please never do that. You can screw up your system that way. Just pick a
dir in your home dir and do everything in there.

Also, please look at Sean's response.

M


> 
> Then I run
> .
> /usr/local/oecore-x86_64/environment-setup-armv7ahf-vfp-neon-oe-linux-gnueabi
> cmake -DCMAKE_TOOLCHAIN_FILE=../host/cmake/Toolchains/oe-sdk_cross.cmake
> -DCMAKE_INSTALL_PREFIX=/usr -DENABLE_E300=ON -DENABLE_B200=OFF ..
> 
> which means that the resulting files will be installed to /usr on my
> desktop machine. At this point it seems there's a gap in the
> instructions where I need to install to the E310, either by setting
> CMAKE_INSTALL_PREFIX to the /usr directory on the E310 via sshfs, or by
> setting DESTDIR to the E310 via sshfs when I install.
> 
> Anyway, I install uhd and gnuradio to the E310 in this manner.
> 
> Then when I try to build gr-ettus:
> 
> cmake
> -DCMAKE_TOOLCHAIN_FILE=/home/samcarey/GNURadio/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake
> -DCMAKE_INSTALL_PREFIX=/usr -DENABLE_DOXYGEN=OFF ..
> 
> it can't find the correct rfnoc-radio-redo uhd library, apparently
> because it is looking where I installed the SDK on the machine (which I
> assume has non-rfnoc libraries) instead of where I installed the correct
> libraries on the E310:
> 
> ...
> -- Found PkgConfig:
> /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/pkg-config
> (found version "0.28")
> -- Found UHD:
> /usr/local/oecore-x86_64/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/lib/libuhd.so
>  
> CMake Error at CMakeLists.txt:113 (message):
>   RFNoC not found.
> 
> I suppose I could set the CMAKE_INSTALL_PREFIX to the SDK installation,
> where it is looking for the libraries. But this would contradict the
> instructed location of "/usr" and I'd have to also install everything to
> the E310 afterward.
> 
> Could someone please help me understand how this is supposed to work?
> 
> Thanks,
> Sam Carey
> 
> 
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 




------------------------------

Message: 11
Date: Mon, 6 Jun 2016 15:00:27 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] AddSub example port not connected error
Message-ID: <5755f27b.4030...@ettus.com>
Content-Type: text/plain; charset=windows-1252

Is port 0 connected to an RFNoC block, but 1 to a GNU Radio block?

-- Martin

On 06/06/2016 06:44 AM, Kieran Lea via USRP-users wrote:
> Hi,
> 
> 
> I tried using the addsub example here:
> https://github.com/EttusResearch/gr-ettus/tree/master/examples/rfnoc
> 
> 
> and I get an error:
> 
> 
> thread[thread-per-block[3]: <block uhd_rfnoc_AddSub (1)>]: RuntimeError:
> On node 0/AddSub_0, input port 0 is already connected.
> 
> 
> I saw another person on the list ask this question earlier and you guys
> had said it was GNURadio getting confused with an output to a regular
> block and an RFNoC block, but I'm wondering if that's the case, because
> it seems both ports are connected to a regular block? I also tried a few
> other configurations and they resulted in the same error. I'm on the
> devel branch with an X310, any idea how to get it working?
> 
> 
> Thanks
> 
> 
> 
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 




------------------------------

Message: 12
Date: Mon, 6 Jun 2016 18:33:52 -0400
From: Sean Nowlan <nowl...@gmail.com>
To: Martin Braun <martin.br...@ettus.com>
Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Cross Compiling RFNoC for E310
Message-ID:
        <CAGmpSnr-MVmN=RQ7m1b-B7XHERYh==wzhjvadwjb8vpmg8h...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Sam, I'll echo Martin's suggestion to pick a location in your home
directory, or alternatively in /opt/sdk.

I think the SDK installer script defaults to /usr/local/oecore-sdk (or
similar). It'd probably be a good thing to make the default /opt/oecore-sdk
or something else to help users avoid putting funky things into the host
machine's search paths, although it's easy enough for the user to override
the setting from the installer prompt. I looked for a bit where this can be
set in an OpenEmbedded variable or bbappend file but I didn't look too
hard. I believe it's "target_sdk_dir" in [1], but I'm not sure where that
can be set from a bitbake recipe.

[1]
http://cgit.openembedded.org/cgit.cgi/openembedded-core/tree/meta/classes/populate_sdk_ext.bbclass?h=fido

Sean

On Mon, Jun 6, 2016 at 5:58 PM, Martin Braun via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 06/06/2016 08:07 AM, Sam Carey via USRP-users wrote:
> > As I understand it, cross-compiling means that the building takes place
> > on my desktop machine and then the results are installed on the E310.
>
> Yep.
>
> > So I install the SDK toolchain on my desktop in /usr/local/.
>
> Please never do that. You can screw up your system that way. Just pick a
> dir in your home dir and do everything in there.
>
> Also, please look at Sean's response.
>
> M
>
>
> >
> > Then I run
> > .
> >
> /usr/local/oecore-x86_64/environment-setup-armv7ahf-vfp-neon-oe-linux-gnueabi
> > cmake -DCMAKE_TOOLCHAIN_FILE=../host/cmake/Toolchains/oe-sdk_cross.cmake
> > -DCMAKE_INSTALL_PREFIX=/usr -DENABLE_E300=ON -DENABLE_B200=OFF ..
> >
> > which means that the resulting files will be installed to /usr on my
> > desktop machine. At this point it seems there's a gap in the
> > instructions where I need to install to the E310, either by setting
> > CMAKE_INSTALL_PREFIX to the /usr directory on the E310 via sshfs, or by
> > setting DESTDIR to the E310 via sshfs when I install.
> >
> > Anyway, I install uhd and gnuradio to the E310 in this manner.
> >
> > Then when I try to build gr-ettus:
> >
> > cmake
> >
> -DCMAKE_TOOLCHAIN_FILE=/home/samcarey/GNURadio/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake
> > -DCMAKE_INSTALL_PREFIX=/usr -DENABLE_DOXYGEN=OFF ..
> >
> > it can't find the correct rfnoc-radio-redo uhd library, apparently
> > because it is looking where I installed the SDK on the machine (which I
> > assume has non-rfnoc libraries) instead of where I installed the correct
> > libraries on the E310:
> >
> > ...
> > -- Found PkgConfig:
> > /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/pkg-config
> > (found version "0.28")
> > -- Found UHD:
> >
> /usr/local/oecore-x86_64/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/lib/libuhd.so
> >
> > CMake Error at CMakeLists.txt:113 (message):
> >   RFNoC not found.
> >
> > I suppose I could set the CMAKE_INSTALL_PREFIX to the SDK installation,
> > where it is looking for the libraries. But this would contradict the
> > instructed location of "/usr" and I'd have to also install everything to
> > the E310 afterward.
> >
> > Could someone please help me understand how this is supposed to work?
> >
> > Thanks,
> > Sam Carey
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160606/1d8695c3/attachment-0001.html>

------------------------------

Message: 13
Date: Mon, 6 Jun 2016 18:44:27 -0400
From: Dave NotTelling <dmp250...@gmail.com>
To: Martin Braun <martin.br...@ettus.com>
Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] RFNoC with system containing an N210 and
        X310
Message-ID:
        <cak6gvunpiawsoo8j8qfbpdvarkldmalaud0fjz9v33s5kwg...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Martin,

      It's radio-redo.  So I take it that the N210 is supposed to work with
the RFNoC code (obviously not for the nifty FPGA CEs)?

Thanks!

On Mon, Jun 6, 2016 at 5:57 PM, Martin Braun via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Dave,
>
> looks like you've stumbled on a bug. Which branch is this? rfnoc-devel
> or rfnoc-radio-redo?
>
> M
>
> On 06/06/2016 09:42 AM, Dave NotTelling via USRP-users wrote:
> > Oh, and here is the code I was using to test with:
> >
> > [code]
> > #include <stdlib.h>
> > #include <stdio.h>
> > #include <uhd/usrp/multi_usrp.hpp>
> >
> > int main(){
> >     uhd::usrp::multi_usrp::sptr usrp =
> > uhd::usrp::multi_usrp::make(uhd::device_addr_t("addr=192.168.10.2"));
> >     uhd::rx_streamer::sptr rx =
> > usrp->get_rx_stream(uhd::stream_args_t("fc32", "sc16"));
> >     return 0;
> > }
> > [/code]
> >
> > Compiled with 'g++ test.cpp -o test -luhd'
> >
> >
> > The error I get is (even though I have run the supplied commands and
> > rebooted the radio):
> >
> > ./test
> > linux; GNU C++ version 4.8.4; Boost_105400;
> > UHD_003.010.rfnoc-radio-redo-547-ge915cbee
> >
> > -- Opening a USRP2/N-Series device...
> > -- Current recv frame size: 1472 bytes
> > -- Current send frame size: 1472 bytes
> > terminate called after throwing an instance of 'uhd::runtime_error'
> >   what():  RuntimeError:
> > Please update the firmware and FPGA images for your device.
> > See the application notes for USRP2/N-Series for instructions.
> > Expected FPGA compatibility number 11, but got 10:
> > The FPGA build is not compatible with the host code build.
> > Please run:
> >
> >  "/usr/local/lib/uhd/utils/uhd_images_downloader.py"
> >  "/usr/local/bin/uhd_image_loader" \
> >     --args="type=usrp2,addr=192.168.10.2"
> >
> >
> >
> > I'm trying to avoid having multiple versions of UHD on the same system
> > since so many other things depend on UHD.
> >
> > On Mon, Jun 6, 2016 at 12:38 PM, Dave NotTelling <dmp250...@gmail.com
> > <mailto:dmp250...@gmail.com>> wrote:
> >
> >     I have both an N210 and an X310 hooked up to the same desktop.  I
> >     was going to test out running RFNoC for the X310 but realized that
> >     the N210 no longer worked.  I knew that the RFNoC FPGA goodness
> >     would not work on the N210 because of the Spartan FPGA, but I
> >     assumed that the RFNoC codebase would still be able to use the
> >     normal UHD API to access the N210.  While I can initialize the N210
> >     with no issue, things go bad when I try to stream samples.  As a
> >     sanity check I also tried uhd_fft and it bombs out with the
> >     exception below.  When I updated the FPGA image with the newest from
> >     the rfnoc-radio-redo code it would always complain about having the
> >     wrong image.
> >
> >     Is it even possible to run an N210 off of the RFNoC code?
> >
> >     [exception]
> >     uhd_fft -a addr=192.168.10.2 -f 4e9
> >     linux; GNU C++ version 4.8.4; Boost_105400;
> >     UHD_003.010.rfnoc-radio-redo-547-ge915cbee
> >
> >     -- Opening a USRP2/N-Series device...
> >     -- Current recv frame size: 1472 bytes
> >     -- Current send frame size: 1472 bytes
> >
> >     UHD Warning:
> >         Unable to set the thread priority. Performance may be negatively
> >     affected.
> >         Please see the general application notes in the manual for
> >     instructions.
> >         EnvironmentError: OSError: error in pthread_setschedparam
> >     Traceback (most recent call last):
> >       File "/usr/local/bin/uhd_fft", line 448, in <module>
> >         main()
> >       File "/usr/local/bin/uhd_fft", line 431, in main
> >         tb = uhd_fft(args)
> >       File "/usr/local/bin/uhd_fft", line 128, in __init__
> >         self.setup_usrp(uhd.usrp_source, args)
> >       File
> >     "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_app.py",
> >     line 137, in setup_usrp
> >         channels=self.channels,
> >       File
> >     "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
> >     line 122, in constructor_interceptor
> >         return old_constructor(*args)
> >       File
> >     "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> >     line 2249, in make
> >         return _uhd_swig.usrp_source_make(*args)
> >     RuntimeError: LookupError: IndexError: multi_usrp::mb_root(21809472)
> >     - vector::_M_range_check
> >     [/exception]
> >
> >
> >
> >     Thanks!
> >
> >
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160606/7e62f74d/attachment-0001.html>

------------------------------

Message: 14
Date: Mon, 6 Jun 2016 15:56:01 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] gr-ettus RFNoC 1024 Bin FFT Limit?
Message-ID: <5755ff81.9000...@ettus.com>
Content-Type: text/plain; charset=windows-1252

PCIe has the same max packet size (8000).

M

On 06/04/2016 08:56 AM, Dave NotTelling via USRP-users wrote:
> Marcus,
> 
>      Does the FFT size limit also apply to PCIe?
> 
> -Dave
> 
> On Mon, May 9, 2016 at 12:18 AM, Dave NotTelling <dmp250...@gmail.com
> <mailto:dmp250...@gmail.com>> wrote:
> 
>     Ahh, that makes perfect sense.   Thank you!
> 
>     On May 9, 2016 12:09 AM, "Marcus D. Leech via USRP-users"
>     <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote:
> 
>         On 05/08/2016 11:28 PM, Dave NotTelling via USRP-users wrote:
> 
>             Is the RFNoC FFT block limited to 1024 points?  The drop
>             down shows up to 4096, but the block errors out in GNU Radio
>             if put over 1024.  Is that intentional?  If so, is there a
>             specific reason why the FFT block is limited that low?
> 
>             Thank you!
> 
>             -Dave
> 
>         FFT outputs are done as single UDP frames in RFNoC, so you're
>         limited to whatever your Ethernet NIC can give you.  For
>         1024-bin FFTs, that
>           requires a minimum of 4096bytes, without considering required
>         VITA overhead, etc.  So, your NIC needs to be programmed for
>         about 4500
>           bytes MTU.  Most 1GiGe NICs won't go a whole lot over that,
>         although 10GiGe NICs will allow and MTU of 9000, allowing
>         2048-bin FFTs.
> 
> 
> 
>         _______________________________________________
>         USRP-users mailing list
>         USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
>         http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 
> 
> 
> 
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 




------------------------------

Message: 15
Date: Mon, 6 Jun 2016 15:57:25 -0700
From: Martin Braun <martin.br...@ettus.com>
To: "'USRP-users@lists.ettus.com'" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] RFNoC with system containing an N210 and
        X310
Message-ID: <5755ffd5.3050...@ettus.com>
Content-Type: text/plain; charset=utf-8

OK thanks, I'll check it out. To be clear, you can use the multi_usrp
API with N210 even on rfnoc-* branches. None of the other features though.

Cheers,
M

On 06/06/2016 03:44 PM, Dave NotTelling wrote:
> Martin,
> 
>       It's radio-redo.  So I take it that the N210 is supposed to work
> with the RFNoC code (obviously not for the nifty FPGA CEs)?
> 
> Thanks!
> 
> On Mon, Jun 6, 2016 at 5:57 PM, Martin Braun via USRP-users
> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote:
> 
>     Dave,
> 
>     looks like you've stumbled on a bug. Which branch is this? rfnoc-devel
>     or rfnoc-radio-redo?
> 
>     M
> 
>     On 06/06/2016 09:42 AM, Dave NotTelling via USRP-users wrote:
>     > Oh, and here is the code I was using to test with:
>     >
>     > [code]
>     > #include <stdlib.h>
>     > #include <stdio.h>
>     > #include <uhd/usrp/multi_usrp.hpp>
>     >
>     > int main(){
>     >     uhd::usrp::multi_usrp::sptr usrp =
>     > uhd::usrp::multi_usrp::make(uhd::device_addr_t("addr=192.168.10.2"));
>     >     uhd::rx_streamer::sptr rx =
>     > usrp->get_rx_stream(uhd::stream_args_t("fc32", "sc16"));
>     >     return 0;
>     > }
>     > [/code]
>     >
>     > Compiled with 'g++ test.cpp -o test -luhd'
>     >
>     >
>     > The error I get is (even though I have run the supplied commands and
>     > rebooted the radio):
>     >
>     > ./test
>     > linux; GNU C++ version 4.8.4; Boost_105400;
>     > UHD_003.010.rfnoc-radio-redo-547-ge915cbee
>     >
>     > -- Opening a USRP2/N-Series device...
>     > -- Current recv frame size: 1472 bytes
>     > -- Current send frame size: 1472 bytes
>     > terminate called after throwing an instance of 'uhd::runtime_error'
>     >   what():  RuntimeError:
>     > Please update the firmware and FPGA images for your device.
>     > See the application notes for USRP2/N-Series for instructions.
>     > Expected FPGA compatibility number 11, but got 10:
>     > The FPGA build is not compatible with the host code build.
>     > Please run:
>     >
>     >  "/usr/local/lib/uhd/utils/uhd_images_downloader.py"
>     >  "/usr/local/bin/uhd_image_loader" \
>     >     --args="type=usrp2,addr=192.168.10.2"
>     >
>     >
>     >
>     > I'm trying to avoid having multiple versions of UHD on the same system
>     > since so many other things depend on UHD.
>     >
>     > On Mon, Jun 6, 2016 at 12:38 PM, Dave NotTelling
>     <dmp250...@gmail.com <mailto:dmp250...@gmail.com>
>     > <mailto:dmp250...@gmail.com <mailto:dmp250...@gmail.com>>> wrote:
>     >
>     >     I have both an N210 and an X310 hooked up to the same desktop.  I
>     >     was going to test out running RFNoC for the X310 but realized that
>     >     the N210 no longer worked.  I knew that the RFNoC FPGA goodness
>     >     would not work on the N210 because of the Spartan FPGA, but I
>     >     assumed that the RFNoC codebase would still be able to use the
>     >     normal UHD API to access the N210.  While I can initialize the
>     N210
>     >     with no issue, things go bad when I try to stream samples.  As a
>     >     sanity check I also tried uhd_fft and it bombs out with the
>     >     exception below.  When I updated the FPGA image with the
>     newest from
>     >     the rfnoc-radio-redo code it would always complain about
>     having the
>     >     wrong image.
>     >
>     >     Is it even possible to run an N210 off of the RFNoC code?
>     >
>     >     [exception]
>     >     uhd_fft -a addr=192.168.10.2 -f 4e9
>     >     linux; GNU C++ version 4.8.4; Boost_105400;
>     >     UHD_003.010.rfnoc-radio-redo-547-ge915cbee
>     >
>     >     -- Opening a USRP2/N-Series device...
>     >     -- Current recv frame size: 1472 bytes
>     >     -- Current send frame size: 1472 bytes
>     >
>     >     UHD Warning:
>     >         Unable to set the thread priority. Performance may be
>     negatively
>     >     affected.
>     >         Please see the general application notes in the manual for
>     >     instructions.
>     >         EnvironmentError: OSError: error in pthread_setschedparam
>     >     Traceback (most recent call last):
>     >       File "/usr/local/bin/uhd_fft", line 448, in <module>
>     >         main()
>     >       File "/usr/local/bin/uhd_fft", line 431, in main
>     >         tb = uhd_fft(args)
>     >       File "/usr/local/bin/uhd_fft", line 128, in __init__
>     >         self.setup_usrp(uhd.usrp_source, args)
>     >       File
>     >     "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_app.py",
>     >     line 137, in setup_usrp
>     >         channels=self.channels,
>     >       File
>     >     "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
>     >     line 122, in constructor_interceptor
>     >         return old_constructor(*args)
>     >       File
>     >     "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
>     >     line 2249, in make
>     >         return _uhd_swig.usrp_source_make(*args)
>     >     RuntimeError: LookupError: IndexError:
>     multi_usrp::mb_root(21809472)
>     >     - vector::_M_range_check
>     >     [/exception]
>     >
>     >
>     >
>     >     Thanks!
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > USRP-users mailing list
>     > USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
>     > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>     >
> 
> 
>     _______________________________________________
>     USRP-users mailing list
>     USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
>     http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 
> 




------------------------------

Message: 16
Date: Mon, 6 Jun 2016 15:59:59 -0700
From: Martin Braun <martin.br...@ettus.com>
To: "'USRP-users@lists.ettus.com'" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
Message-ID: <5756006f.80...@ettus.com>
Content-Type: text/plain; charset=windows-1252

OK, this is a bit useful. It's segfaulting in gr-ettus, not UHD.

Sergio, can you please start a new thread here and tell us which flow
graph is failing on which branches of UHD and gr-ettus? This thread is
getting hard to follow now.

Cheers,
Martin

On 05/29/2016 08:17 PM, Sergio Cruz Perez wrote:
> Thanks Philip. I mounted the build machine filesystem onto the  E310 and
> then I run the gdb tool again in this way:
> 
> gdb /usr/local/python core -d ~/PC           where ~/PC is the mounted
> file system
> 
> I attached the backtrace output. 
> 
> Thanks
> 
> Sergio
> 
> 
> 
>> Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
>> To: serchs...@hotmail.com; martin.br...@ettus.com
>> CC: usrp-users@lists.ettus.com
>> From: phi...@opensdr.com
>> Date: Fri, 27 May 2016 08:47:23 -0400
>>
>> On 05/26/2016 09:40 PM, Sergio Cruz Perez via USRP-users wrote:
>> > Martin,
>> > Thanks for your help. I'm new in debugging tools like that. I
> attached the backtrace output. What I noticed is that the path in which
> the application is looking for the io_signature.cc file is
> /home/sheko/E310_SW/gnuradio/gnuradio, that is a path on my PC not on
> the E310. The way I've been working with gnuradio is that I generate the
> .py file on my PC and then I copy that file to the E310. That was
> working in other applications.
>> > Sergio
>>
>> I skimmed things quickly, the path you refer to is the path to the
>> source file. gdb is looking for that for some line info and can't find
>> it on the device. This isn't the actual problem. If you want to have gsb
>> find the file, you can use sshfs to mount the build machine onto the
>> e310 file system. Be careful how you do this to make the paths just work.
>>
>> Philip
>>
>>
>> >
>> >
>> >
>> >
>> >> Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
>> >> To: serchs...@hotmail.com
>> >> CC: usrp-users@lists.ettus.com
>> >> From: martin.br...@ettus.com
>> >> Date: Thu, 26 May 2016 09:33:08 -0700
>> >>
>> >> Sergio,
>> >>
>> >> my bad, I meant to ask for a backtrace on a core dump, not the core
> dump
>> >> itself. Could you please send that instead?
>> >>
>> >> Thanks,
>> >> Martin
>> >>
>> >>
>> >> On 05/24/2016 08:41 PM, Sergio Cruz Perez wrote:
>> >>> Hi Martin,
>> >>>
>> >>> Yes, I rebuilt and reinstalled uhd (rfnoc-ofdm, replacing the
>> >>> schmidlcox.xml), gnuradio (3.7.9.2) and gr-ettus (replacing
>> >>> uhd_rfnoc_schmidlcox). I attached the core dump file
>> >>>
>> >>> Thanks
>> >>>
>> >>> Sergio
>> >>>
>> >>>
>> >>>
>> >>>> To: usrp-users@lists.ettus.com
>> >>>> Date: Mon, 23 May 2016 10:06:38 -0700
>> >>>> Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
>> >>>> From: usrp-users@lists.ettus.com
>> >>>>
>> >>>> Did you rebuild and reinstall UHD, GNU Radio and gr-ettus? Can you
>> >>>> provide a core dump?
>> >>>>
>> >>>> Thanks,
>> >>>> Martin
>> >>>>
>> >>>> On 05/22/2016 08:19 AM, Sergio Cruz Perez via USRP-users wrote:
>> >>>>> Hi Jonathon,
>> >>>>>
>> >>>>>
>> >>>>> I found that the problem was that the schmidlcox. xml file
> located in
>> >>>>> {uhd_installation_path}/share/uhd/rfnoc/blocks doesn't have the
> correct
>> >>>>> registers declared. I modified that file and
> uhd_rfnoc_schmidlcox.xml
>> >>>>> in my local copy of uhd and gr-ettus repos. I reinstalled both
> on my pc
>> >>>>> and cross-compiled for the E310. Now, I can see how the
> registers are
>> >>>>> correctly added to the xbar:
>> >>>>>
>> >>>>>
>> >>>>> The problem now is that every program that I run on the E310
> using my
>> >>>>> fpga image sends a message of segmentation fault.
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> root@ettus-e300:~/rfnoc# ./schmidl.py
>> >>>>>
>> >>>>> linux; GNU C++ version 4.9.2; Boost_105700;
>> >>> UHD_003.010.rfnoc-308-g63b98f87
>> >>>>>
>> >>>>>
>> >>>>> -- Loading FPGA image: /home/root/usrp_e310_rfnoc_fpga.bit... done
>> >>>>>
>> >>>>> -- Initializing core control...
>> >>>>>
>> >>>>> -- Performing register loopback test... pass
>> >>>>>
>> >>>>> -- Setting up dest map for ep 0 to be stream 1
>> >>>>>
>> >>>>> -- Performing register loopback test... pass
>> >>>>>
>> >>>>>
>> >>>>> [...]
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> -- [RFNOC] ------- Block Setup -----------
>> >>>>>
>> >>>>> -- Setting up dest map for ep 2 to be stream 7
>> >>>>>
>> >>>>> -- Setting up NoC-Shell Control #0 (SID: 00:02>02:30)...OK
>> >>>>>
>> >>>>> -- Port 48: Found NoC-Block with ID 5CC0000000000000.
>> >>>>>
>> >>>>> -- base_path = "/usr/share/uhd/rfnoc"
>> >>>>>
>> >>>>> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/schmidlcox.xml
>> >>>>>
>> >>>>> -- [RFNoC Factory] block_ctrl_base::make()
>> >>>>>
>> >>>>> -- base_path = "/usr/share/uhd/rfnoc"
>> >>>>>
>> >>>>> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/schmidlcox.xml
>> >>>>>
>> >>>>> -- [RFNoC Factory] Using controller key 'Block' and block name
>> >>> 'SchmidlCox'
>> >>>>>
>> >>>>> -- block_ctrl_base()
>> >>>>>
>> >>>>> -- base_path = "/usr/share/uhd/rfnoc"
>> >>>>>
>> >>>>> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/schmidlcox.xml
>> >>>>>
>> >>>>> -- Found valid blockdef
>> >>>>>
>> >>>>> -- NOC ID: 0x5CC0000000000000 Block ID: 0/SchmidlCox_0
>> >>>>>
>> >>>>> -- [0/SchmidlCox_0] Adding port definition at
>> >>>>> xbar/SchmidlCox_0/ports/in/0: type = 'sc16' pkt_size = '0' vlen
> = '0'
>> >>>>>
>> >>>>> -- [0/SchmidlCox_0] Adding port definition at
>> >>>>> xbar/SchmidlCox_0/ports/out/0: type = 'sc16' pkt_size = '%vlen'
> vlen =
>> >>>>> '$fftsize'
>> >>>>>
>> >>>>> -- added arg path: xbar/SchmidlCox_0/args/0/fftsize/value
>> >>>>>
>> >>>>> -- added arg path: xbar/SchmidlCox_0/args/0/frame_len/value
>> >>>>>
>> >>>>> -- added arg path: xbar/SchmidlCox_0/args/0/gap_len/value
>> >>>>>
>> >>>>> -- added arg path: xbar/SchmidlCox_0/args/0/offset/value
>> >>>>>
>> >>>>> -- added arg path: xbar/SchmidlCox_0/args/0/max_num_symbols/value
>> >>>>>
>> >>>>> -- added arg path: xbar/SchmidlCox_0/args/0/short_num_symbols/value
>> >>>>>
>> >>>>> -- added arg path: xbar/SchmidlCox_0/args/0/threshold/value
>> >>>>>
>> >>>>> -- added arg path: xbar/SchmidlCox_0/args/0/agc_ref_level/value
>> >>>>>
>> >>>>> -- [NocScript] Executing and asserting code:
> SR_WRITE("FRAME_LENGTH",
>> >>>>> $frame_len)
>> >>>>>
>> >>>>> -- [NocScript] Executing SR_WRITE()
>> >>>>>
>> >>>>> -- [0/SchmidlCox_0] sr_write(FRAME_LENGTH, 00000040) ==>
>> >>>>> [0/SchmidlCox_0] sr_write(129, 00000040, 0)
>> >>>>>
>> >>>>> -- [NocScript] Executing and asserting code: SR_WRITE("GAP_LENGTH",
>> >>>>> $gap_len)
>> >>>>>
>> >>>>> -- [NocScript] Executing SR_WRITE()
>> >>>>>
>> >>>>> -- [0/SchmidlCox_0] sr_write(GAP_LENGTH, 00000010) ==>
>> >>>>> [0/SchmidlCox_0] sr_write(130, 00000010, 0)
>> >>>>>
>> >>>>> -- [NocScript] Executing and asserting code: SR_WRITE("OFFSET",
> $offset)
>> >>>>>
>> >>>>> -- [NocScript] Executing SR_WRITE()
>> >>>>>
>> >>>>> -- [0/SchmidlCox_0] sr_write(OFFSET, 00000010) ==> [0/SchmidlCox_0]
>> >>>>> sr_write(131, 00000010, 0)
>> >>>>>
>> >>>>> -- [NocScript] Executing and asserting code:
> GE($max_num_symbols, 0) AND
>> >>>>> LE($max_num_symbols, 1000)
>> >>>>>
>> >>>>> -- [NocScript] Executing and asserting code:
> SR_WRITE("NUM_SYMBOLS_MAX",
>> >>>>> $max_num_symbols)
>> >>>>>
>> >>>>> -- [NocScript] Executing SR_WRITE()
>> >>>>>
>> >>>>> -- [0/SchmidlCox_0] sr_write(NUM_SYMBOLS_MAX, 0000000C) ==>
>> >>>>> [0/SchmidlCox_0] sr_write(132, 0000000C, 0)
>> >>>>>
>> >>>>> -- [NocScript] Executing and asserting code:
> GE($short_num_symbols, 0)
>> >>>>> AND LE($short_num_symbols, 1000)
>> >>>>>
>> >>>>> -- [NocScript] Executing and asserting code:
>> >>>>> SR_WRITE("NUM_SYMBOLS_SHORT", $short_num_symbols)
>> >>>>>
>> >>>>> -- [NocScript] Executing SR_WRITE()
>> >>>>>
>> >>>>> -- [0/SchmidlCox_0] sr_write(NUM_SYMBOLS_SHORT, 00000008) ==>
>> >>>>> [0/SchmidlCox_0] sr_write(133, 00000008, 0)
>> >>>>>
>> >>>>> -- [NocScript] Executing and asserting code: GE($threshold, 0.0) AND
>> >>>>> LE($threshold, 1.0)
>> >>>>>
>> >>>>> -- [NocScript] Executing and asserting code: SR_WRITE("THRESHOLD",
>> >>>>> IROUND(MULT(16384.0, $threshold)))
>> >>>>>
>> >>>>> -- [NocScript] Executing SR_WRITE()
>> >>>>>
>> >>>>> -- [0/SchmidlCox_0] sr_write(THRESHOLD, 00003800) ==>
>> >>>>> [0/SchmidlCox_0] sr_write(134, 00003800, 0)
>> >>>>>
>> >>>>> -- [NocScript] Executing and asserting code: GE($agc_ref_level,
> 0.0) AND
>> >>>>> LE($agc_ref_level, 1.0)
>> >>>>>
>> >>>>> -- [NocScript] Executing and asserting code:
> SR_WRITE("AGC_REF_LEVEL",
>> >>>>> IROUND(MULT(32768.0, $agc_ref_level)))
>> >>>>>
>> >>>>> -- [NocScript] Executing SR_WRITE()
>> >>>>>
>> >>>>> -- [0/SchmidlCox_0] sr_write(AGC_REF_LEVEL, 00001000) ==>
>> >>>>> [0/SchmidlCox_0] sr_write(135, 00001000, 0)
>> >>>>>
>> >>>>> -- ========== Full list of RFNoC blocks: ============
>> >>>>>
>> >>>>> -- * 0/Radio_0
>> >>>>>
>> >>>>> -- * 0/Radio_1
>> >>>>>
>> >>>>> -- * 0/SchmidlCox_0
>> >>>>>
>> >>>>> -- [0/Radio_0] block_ctrl_base::clear()
>> >>>>>
>> >>>>> -- node_ctrl_base::clear()
>> >>>>>
>> >>>>> -- [0/Radio_1] block_ctrl_base::clear()
>> >>>>>
>> >>>>> -- node_ctrl_base::clear()
>> >>>>>
>> >>>>> -- [0/SchmidlCox_0] block_ctrl_base::clear()
>> >>>>>
>> >>>>> -- node_ctrl_base::clear()
>> >>>>>
>> >>>>> -- [0/SchmidlCox_0] block_ctrl_base::_clear()
>> >>>>>
>> >>>>> -- [0/SchmidlCox_0] sr_write(126, 00C1EA12, 0)
>> >>>>>
>> >>>>> -- [0/Radio_0] _resolve_port_def()
>> >>>>>
>> >>>>> -- [0/Radio_0] item type: sc16
>> >>>>>
>> >>>>> -- [0/Radio_0] vector length: 0
>> >>>>>
>> >>>>> -- [0/Radio_0] packet size: 0
>> >>>>>
>> >>>>> -- [0/Radio_0] _resolve_port_def()
>> >>>>>
>> >>>>> -- [0/Radio_0] item type: sc16
>> >>>>>
>> >>>>> -- [0/Radio_0] vector length: 0
>> >>>>>
>> >>>>> -- [0/Radio_0] packet size: 0
>> >>>>>
>> >>>>>
>> >>>>> UHD Warning:
>> >>>>>
>> >>>>> The hardware does not support the requested RX sample rate:
>> >>>>>
>> >>>>> Target sample rate: 10.000000 MSps
>> >>>>>
>> >>>>> Actual sample rate: 8.000000 MSps
>> >>>>>
>> >>>>> enabling rx dc offset removal: 1
>> >>>>>
>> >>>>> -- [0/SchmidlCox_0] _resolve_port_def()
>> >>>>>
>> >>>>> -- [0/SchmidlCox_0] item type: sc16
>> >>>>>
>> >>>>> -- [0/SchmidlCox_0] vector length: 0
>> >>>>>
>> >>>>> -- [0/SchmidlCox_0] packet size: 0
>> >>>>>
>> >>>>> -- [0/SchmidlCox_0] _resolve_port_def()
>> >>>>>
>> >>>>> -- [0/SchmidlCox_0] item type: sc16
>> >>>>>
>> >>>>> -- [0/SchmidlCox_0] vector length: 64
>> >>>>>
>> >>>>> -- [0/SchmidlCox_0] packet size: 64
>> >>>>>
>> >>>>> -- [NocScript] Executing and asserting code:
> SR_WRITE("FRAME_LENGTH",
>> >>>>> $frame_len)
>> >>>>>
>> >>>>> -- [NocScript] Executing SR_WRITE()
>> >>>>>
>> >>>>> -- [0/SchmidlCox_0] sr_write(FRAME_LENGTH, 00000010) ==>
>> >>>>> [0/SchmidlCox_0] sr_write(129, 00000010, 0)
>> >>>>>
>> >>>>> -- [NocScript] Executing and asserting code: SR_WRITE("GAP_LENGTH",
>> >>>>> $gap_len)
>> >>>>>
>> >>>>> -- [NocScript] Executing SR_WRITE()
>> >>>>>
>> >>>>> -- [0/SchmidlCox_0] sr_write(GAP_LENGTH, 00000010) ==>
>> >>>>> [0/SchmidlCox_0] sr_write(130, 00000010, 0)
>> >>>>>
>> >>>>> -- [NocScript] Executing and asserting code: SR_WRITE("OFFSET",
> $offset)
>> >>>>>
>> >>>>> -- [NocScript] Executing SR_WRITE()
>> >>>>>
>> >>>>> -- [0/SchmidlCox_0] sr_write(OFFSET, 00000000) ==> [0/SchmidlCox_0]
>> >>>>> sr_write(131, 00000000, 0)
>> >>>>>
>> >>>>> -- [NocScript] Executing and asserting code:
> GE($max_num_symbols, 0) AND
>> >>>>> LE($max_num_symbols, 1000)
>> >>>>>
>> >>>>> -- [NocScript] Executing and asserting code:
> SR_WRITE("NUM_SYMBOLS_MAX",
>> >>>>> $max_num_symbols)
>> >>>>>
>> >>>>> -- [NocScript] Executing SR_WRITE()
>> >>>>>
>> >>>>> -- [0/SchmidlCox_0] sr_write(NUM_SYMBOLS_MAX, 0000000C) ==>
>> >>>>> [0/SchmidlCox_0] sr_write(132, 0000000C, 0)
>> >>>>>
>> >>>>> -- [NocScript] Executing and asserting code:
> GE($short_num_symbols, 0)
>> >>>>> AND LE($short_num_symbols, 1000)
>> >>>>>
>> >>>>> -- [NocScript] Executing and asserting code:
>> >>>>> SR_WRITE("NUM_SYMBOLS_SHORT", $short_num_symbols)
>> >>>>>
>> >>>>> -- [NocScript] Executing SR_WRITE()
>> >>>>>
>> >>>>> -- [0/SchmidlCox_0] sr_write(NUM_SYMBOLS_SHORT, 00000008) ==>
>> >>>>> [0/SchmidlCox_0] sr_write(133, 00000008, 0)
>> >>>>>
>> >>>>> -- [NocScript] Executing and asserting code: GE($threshold, 0.0) AND
>> >>>>> LE($threshold, 1.0)
>> >>>>>
>> >>>>> -- [NocScript] Executing and asserting code: SR_WRITE("THRESHOLD",
>> >>>>> IROUND(MULT(16384.0, $threshold)))
>> >>>>>
>> >>>>> -- [NocScript] Executing SR_WRITE()
>> >>>>>
>> >>>>> -- [0/SchmidlCox_0] sr_write(THRESHOLD, 00003800) ==>
>> >>>>> [0/SchmidlCox_0] sr_write(134, 00003800, 0)
>> >>>>>
>> >>>>> -- [NocScript] Executing and asserting code: GE($agc_ref_level,
> 0.0) AND
>> >>>>> LE($agc_ref_level, 1.0)
>> >>>>>
>> >>>>> -- [NocScript] Executing and asserting code:
> SR_WRITE("AGC_REF_LEVEL",
>> >>>>> IROUND(MULT(32768.0, $agc_ref_level)))
>> >>>>>
>> >>>>> -- [NocScript] Executing SR_WRITE()
>> >>>>>
>> >>>>> -- [0/SchmidlCox_0] sr_write(AGC_REF_LEVEL, 00001000) ==>
>> >>>>> [0/SchmidlCox_0] sr_write(135, 00001000, 0)
>> >>>>>
>> >>>>> Segmentation fault
>> >>>>>
>> >>>>>
>> >>>>> I attached the files I modified. Any suggestion of what can I do
> now?
>> >>>>>
>> >>>>> Thanks
>> >>>>>
>> >>>>> Sergio
>> >>>>>
>> >>>>>
>> >>>>>
> ------------------------------------------------------------------------
>> >>>>> To: jonathon.pend...@ettus.com
>> >>>>> Date: Thu, 31 Mar 2016 18:37:34 -0600
>> >>>>> Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
>> >>>>> From: usrp-users@lists.ettus.com
>> >>>>> CC: usrp-users@lists.ettus.com
>> >>>>>
>> >>>>> Jonathon,
>> >>>>>
>> >>>>> I'm compiling uhd locally on the E310. I installed this branch:
>> >>>>>
>> >>>>> root@ettus-e300:~/uhd# git status
>> >>>>> On branch rfnoc-ofdm
>> >>>>> Your branch is up-to-date with 'origin/rfnoc-ofdm'.
>> >>>>>
>> >>>>> root@ettus-e300:~/uhd/fpga-src# git status
>> >>>>> HEAD detached at b2d9bca
>> >>>>>
>> >>>>> I did it using the next commands:
>> >>>>>
>> >>>>> cmake -DCMAKE_INSTALL_PREFIX=/usr -DENABLE_USRP1=OFF
> -DENABLE_USRP2=OFF
>> >>>>> DENABLE_B100=OFF -DENABLE_E100=OFF -DENABLE_X300=ON
> -DENABLE_B200=OFF
>> >>>>> -DENABLE_E300=ON ..
>> >>>>>
>> >>>>> make and make install. No errors were detected when it finished.
>> >>>>>
>> >>>>> Is this ok or I need to cross compile UHD? If I use just the
> rfnoc FIFO
>> >>>>> block, I don't have the problem.
>> >>>>>
>> >>>>> Sergio
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
> ------------------------------------------------------------------------
>> >>>>> From: jonathon.pend...@ettus.com
>> >>>>> Date: Thu, 31 Mar 2016 17:19:13 -0700
>> >>>>> Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
>> >>>>> To: serchs...@hotmail.com
>> >>>>> CC: usrp-users@lists.ettus.com
>> >>>>>
>> >>>>> Hi Sergio,
>> >>>>>
>> >>>>> Are you cross compiling UHD using the rfnoc-ofdm branch? If you
> use the
>> >>>>> built in UHD on the fido test image it won't work since it isn't
> built
>> >>>>> from the correct commit.
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> Jonathon
>> >>>>>
>> >>>>> On Thu, Mar 31, 2016 at 4:56 PM, Sergio Cruz Perez
>> >>>>> <serchs...@hotmail.com <mailto:serchs...@hotmail.com>> wrote:
>> >>>>>
>> >>>>> Hi Jonathon,
>> >>>>>
>> >>>>> I'm already tested the schmidl_cox block using the rfnoc-branch
>> >>>>> branch and using the commit commit
>> >>>>> *b2d9bca4907d74059e7db5ed295df10c045e054e *for the fpga-src, but I
>> >>>>> still having the next error:
>> >>>>>
>> >>>>> /Traceback (most recent call last):/
>> >>>>> / File "./schmidl.py", line 192, in <module>/
>> >>>>> / main()/
>> >>>>> / File "./schmidl.py", line 181, in main/
>> >>>>> / tb = top_block_cls(chan_est=options.chan_est,
>> >>>>> freq=options.freq, gain=options.gain, lo_offset=options.lo_offset,
>> >>>>> samp_rate=options.samp_rate)/
>> >>>>> / File "./schmidl.py", line 93, in __init__/
>> >>>>> / self.uhd_rfnoc_ofdm_schmidlcox_0.set_arg("offset", 77)/
>> >>>>> / File
>> >>>>> "/usr/local/lib/python2.7/site-packages/ettus/ettus_swig.py", line
>> >>>>> 3002, in set_arg/
>> >>>>> / return _ettus_swig.rfnoc_generic_sptr_set_arg(self, *args)/
>> >>>>> /RuntimeError: LookupError: Path not found in tree:
>> >>>>> /mboards/0/xbar/SchmidlCox_0/args/0/offset/value/
>> >>>>>
>> >>>>> Do you think I need to upgrade the firmware also to solve this? I'm
>> >>>>> currently using the
>> >>>>> alpha/fido_rfnoc_test/sdimage-gnuradio-dev.direct.xz
>> >>>>>
>> >>>>> Thanks
>> >>>>> Sergio
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
> ------------------------------------------------------------------------
>> >>>>> From: jonathon.pend...@ettus.com <mailto:jonathon.pend...@ettus.com>
>> >>>>> Date: Wed, 30 Mar 2016 13:34:45 -0700
>> >>>>>
>> >>>>> Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
>> >>>>> To: serchs...@hotmail.com <mailto:serchs...@hotmail.com>
>> >>>>> CC: usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>
>> >>>>>
>> >>>>> Hey Sergio,
>> >>>>>
>> >>>>> I updated the commit fpga-src is pointing at in uhd/rfnoc-ofdm. Give
>> >>>>> it try now.
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> Jonathon
>> >>>>>
>> >>>>>
>> >>>>> On Wed, Mar 30, 2016 at 12:31 PM, Sergio Cruz Perez
>> >>>>> <serchs...@hotmail.com <mailto:serchs...@hotmail.com>> wrote:
>> >>>>>
>> >>>>> Hi Jonathon,
>> >>>>>
>> >>>>> I used the rfnoc-ofdm branch to make the fpga image. Now I have
>> >>>>> the same problem that I had when I used the rfnoc-devel branch:
>> >>>>>
>> >>>>> ERROR: [Synth 8-448] named port connection 's_axis_phase_tlast'
>> >>>>> does not exist for instance 'cfo_corrector' of module
>> >>>>> 'cordic_rotator'
>> >>>>> [/home/sheko/uhd/fpga-src/usrp3/lib/rfnoc/schmidl_cox.v:163]
>> >>>>>
>> >>>>> The commit of the fpga-src folder that I'm using is:
>> >>>>> 8fc97e5eeb3abfcccfb5b71e2d28717ec9b673a0 and
>> >>>>> uhd commit: 8cbec5e4b8ab5fd7c8f04c09c995d337bc0ba603.
>> >>>>>
>> >>>>> I saw that the schmidl_cox.v that is contained in this branch of
>> >>>>> fpga-src is older than the version in the rfnoc-ofdm branch.
>> >>>>>
>> >>>>> When I installed uhd I changed to rfnoc-ofmd branch and then I
>> >>>>> updated the fpga-src submodule. Is this correct?
>> >>>>>
>> >>>>> Thanks
>> >>>>>
>> >>>>> Sergio
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
> ------------------------------------------------------------------------
>> >>>>> From: jonathon.pend...@ettus.com <mailto:jonathon.pend...@ettus.com>
>> >>>>> Date: Mon, 28 Mar 2016 09:53:09 -0700
>> >>>>>
>> >>>>> Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
>> >>>>> To: serchs...@hotmail.com <mailto:serchs...@hotmail.com>
>> >>>>> CC: usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>
>> >>>>>
>> >>>>> Hi Sergio,
>> >>>>>
>> >>>>> I just pushed a branch on uhd called rfnoc-ofdm. Give that one a
>> >>>>> try.
>> >>>>>
>> >>>>>
>> >>>>> Jonathon
>> >>>>>
>> >>>>>
>> >>>>> On Thu, Mar 24, 2016 at 11:35 AM, Sergio Cruz Perez
>> >>>>> <serchs...@hotmail.com <mailto:serchs...@hotmail.com>> wrote:
>> >>>>>
>> >>>>> Hi Jonathon,
>> >>>>>
>> >>>>> I'm using commit b7546712aa0091f87b793ef4c4a9e9c084467173
>> >>>>>
>> >>>>> Thanks
>> >>>>>
>> >>>>> Sergio
>> >>>>>
>> >>>>>
> ------------------------------------------------------------------------
>> >>>>> From: jonathon.pend...@ettus.com
>> >>>>> <mailto:jonathon.pend...@ettus.com>
>> >>>>> Date: Wed, 23 Mar 2016 20:12:59 -0700
>> >>>>>
>> >>>>> Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block
>> >>>>> on E310
>> >>>>> To: serchs...@hotmail.com <mailto:serchs...@hotmail.com>
>> >>>>> CC: usrp-users@lists.ettus.com
>> >>>>> <mailto:usrp-users@lists.ettus.com>
>> >>>>>
>> >>>>> Hi Sergio,
>> >>>>>
>> >>>>> Looks like the block is being enumerated but UHD is not
>> >>>>> populating the property tree correctly. What commit of UHD
>> >>>>> rfnoc-devel are you using?
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> Jonathon
>> >>>>>
>> >>>>> On Wed, Mar 23, 2016 at 11:15 AM, Sergio Cruz Perez
>> >>>>> <serchs...@hotmail.com <mailto:serchs...@hotmail.com>> wrote:
>> >>>>>
>> >>>>> Hi Jonathon,
>> >>>>>
>> >>>>> Finally I could make the image updating the e300_core.v
>> >>>>> file as you said. I ran the uhd_usrp_probe init only and
>> >>>>> now I can see the rfnoc blocks schmidl_cox and fifo.
>> >>>>>
>> >>>>> /-- ========== Full list of RFNoC blocks: ============/
>> >>>>> /-- * 0/Radio_0/
>> >>>>> /-- * 0/Radio_1/
>> >>>>> /-- * 0/FIFO_0/
>> >>>>> /-- * 0/SchmidlCox_0/
>> >>>>>
>> >>>>> But, when i run my application I got again the same problem:
>> >>>>>
>> >>>>> ...
>> >>>>> /-- [0/SchmidlCox_0] _resolve_port_def()/
>> >>>>> /-- [0/SchmidlCox_0] item type: sc16/
>> >>>>> /-- [0/SchmidlCox_0] vector length: 0/
>> >>>>> /-- [0/SchmidlCox_0] packet size: 0/
>> >>>>> /-- [0/SchmidlCox_0] _resolve_port_def()/
>> >>>>> /-- [0/SchmidlCox_0] item type: sc16/
>> >>>>> /-- [0/SchmidlCox_0] vector length: 64/
>> >>>>> /-- [0/SchmidlCox_0] packet size: 64/
>> >>>>> /-- [NocScript] Executing and asserting code:
>> >>>>> SR_WRITE("CP_LENGTH", $cp_len)/
>> >>>>> /-- [NocScript] Executing SR_WRITE() /
>> >>>>> /-- [0/SchmidlCox_0] sr_write(CP_LENGTH, 00000040) ==>
>> >>>>> [0/SchmidlCox_0] sr_write(130, 00000040, 0)/
>> >>>>> /-- [NocScript] Executing and asserting code:
>> >>>>> GE($threshold, 0.0) AND LE($threshold, 1.0)/
>> >>>>> /-- [NocScript] Executing and asserting code:
>> >>>>> SR_WRITE("THRESHOLD", IROUND(MULT(32768.0, $threshold)))/
>> >>>>> /-- [NocScript] Executing SR_WRITE() /
>> >>>>> /-- [0/SchmidlCox_0] sr_write(THRESHOLD, 00007000) ==>
>> >>>>> [0/SchmidlCox_0] sr_write(134, 00007000, 0)/
>> >>>>> /Traceback (most recent call last):/
>> >>>>> / File "./rx_rfnoc.py", line 207, in <module>/
>> >>>>> / main()/
>> >>>>> / File "./rx_rfnoc.py", line 196, in main/
>> >>>>> / tb = top_block_cls(chan_est=options.chan_est,
>> >>>>> freq=options.freq, gain=options.gain,
>> >>>>> lo_offset=options.lo_offset, samp_rate=options.samp_rate)/
>> >>>>> / File "./rx_rfnoc.py", line 97, in __init__/
>> >>>>> / self.uhd_rfnoc_ofdm_schmidlcox_0.set_arg("offset", 77)/
>> >>>>> / File
>> >>>>> "/usr/local/lib/python2.7/site-packages/ettus/ettus_swig.py",
>> >>>>> line 3002, in set_arg/
>> >>>>> / return _ettus_swig.rfnoc_generic_sptr_set_arg(self,
>> >>>>> *args)/
>> >>>>> /RuntimeError: LookupError: Path not found in tree:
>> >>>>> /mboards/0/xbar/SchmidlCox_0/args/0/offset/value/
>> >>>>> ...
>> >>>>>
>> >>>>> How is that path generated? I can't find it on the E310
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
> ------------------------------------------------------------------------
>> >>>>> From: jonathon.pend...@ettus.com
>> >>>>> <mailto:jonathon.pend...@ettus.com>
>> >>>>> Date: Tue, 22 Mar 2016 15:17:40 -0700
>> >>>>> Subject: Re: [USRP-users] Error using RFNoC OFDM Sync
>> >>>>> block on E310
>> >>>>> To: serchs...@hotmail.com <mailto:serchs...@hotmail.com>
>> >>>>> CC: usrp-users@lists.ettus.com
>> >>>>> <mailto:usrp-users@lists.ettus.com>
>> >>>>>
>> >>>>> Sergio,
>> >>>>>
>> >>>>> rfnoc-ofdm has gotten a little out of sync with UHD
>> >>>>> rfnoc-devel. The compat number on line 172 in
>> >>>>> e300_core.v needs to be updated to RB32_CORE_COMPAT :
>> >>>>> rb_data <= {8'hAC, 8'h0, 8'h255, 8'h0};
>> >>>>>
>> >>>>> I am going to merge rfnoc-ofdm into rfnoc-radio-redo
>> >>>>> soon which will fix this issue. This temporary fix
>> >>>>> should hold you over until the merge.
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> Jonathon
>> >>>>>
>> >>>>> On Tue, Mar 22, 2016 at 3:07 PM, Sergio Cruz Perez
>> >>>>> <serchs...@hotmail.com <mailto:serchs...@hotmail.com>>
>> >>>>> wrote:
>> >>>>>
>> >>>>>
>> >>>>> Hi Jonathon,
>> >>>>>
>> >>>>> It's a GNU radio flowgraph and I'm using my rfnoc
>> >>>>> fpga image. I copied the image that I made on my PC
>> >>>>> using the rfnoc-ofdm branches to the E310. My
>> >>>>> flowgraph has the root to that image in the device3
>> >>>>> args so when I run my applications I can see that
>> >>>>> it's loading my image.
>> >>>>>
>> >>>>> root@ettus-e300:~/pruebas# ./rx_rfnoc.py
>> >>>>> linux; GNU C++ version 4.9.2; Boost_105700;
>> >>>>> UHD_003.010.rfnoc-316-gb7546712
>> >>>>>
>> >>>>> -- Loading FPGA image:
>> >>>>> /home/root/sheko/usrp_e310_rfnoc_fpga.bit... done
>> >>>>> -- Initializing core control...
>> >>>>> -- Performing register loopback test... pass .
>> >>>>> ....
>> >>>>>
>> >>>>> When I don't use the rfnoc-ofdm branches I can make
>> >>>>> the image and run it on the E310 but I return to the
>> >>>>> first problem of this thread.
>> >>>>>
>> >>>>> Thanks
>> >>>>>
>> >>>>> Sergio
>> >>>>>
>> >>>>>
> ------------------------------------------------------------------------
>> >>>>> From: jonathon.pend...@ettus.com
>> >>>>> <mailto:jonathon.pend...@ettus.com>
>> >>>>> Date: Tue, 22 Mar 2016 14:23:28 -0700
>> >>>>>
>> >>>>> Subject: Re: [USRP-users] Error using RFNoC OFDM
>> >>>>> Sync block on E310
>> >>>>> To: serchs...@hotmail.com <mailto:serchs...@hotmail.com>
>> >>>>> CC: usrp-users@lists.ettus.com
>> >>>>> <mailto:usrp-users@lists.ettus.com>
>> >>>>>
>> >>>>> Hi Sergio,
>> >>>>>
>> >>>>> You need copy your bitstream to the E310 and replace
>> >>>>> /usr/share/uhd/images/usrp_e300_fpga.bit. How are
>> >>>>> you running your application? Is it a GNU Radio
>> >>>>> flowgraph?
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> Jonathon
>> >>>>>
>> >>>>> On Tue, Mar 22, 2016 at 10:56 AM, Sergio Cruz Perez
>> >>>>> <serchs...@hotmail.com
>> >>>>> <mailto:serchs...@hotmail.com>> wrote:
>> >>>>>
>> >>>>>
>> >>>>> Hi Jonathon,
>> >>>>>
>> >>>>> I installed uhd rfnoc-devel version with the
>> >>>>> rfnoc-ofdm branches on both the PC and the E310
>> >>>>> (UHD_003.010.rfnoc-316-gb7546712). I made the
>> >>>>> image with the schmidl_cox block but when I run
>> >>>>> my application, I got the next error:
>> >>>>>
>> >>>>> RuntimeError: Expected FPGA compatibility number
>> >>>>> 255.x, but got 7.0:
>> >>>>> The FPGA build is not compatible with the host
>> >>>>> code build.
>> >>>>>
>> >>>>> What should I update on my PC to make a
>> >>>>> compatible image with the E310?
>> >>>>>
>> >>>>> Regards
>> >>>>> Sergio
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
> ------------------------------------------------------------------------
>> >>>>> From: jonathon.pend...@ettus.com
>> >>>>> <mailto:jonathon.pend...@ettus.com>
>> >>>>> Date: Wed, 9 Mar 2016 13:05:58 -0800
>> >>>>>
>> >>>>> Subject: Re: [USRP-users] Error using RFNoC OFDM
>> >>>>> Sync block on E310
>> >>>>> To: serchs...@hotmail.com
>> >>>>> <mailto:serchs...@hotmail.com>
>> >>>>> CC: usrp-users@lists.ettus.com
>> >>>>> <mailto:usrp-users@lists.ettus.com>
>> >>>>>
>> >>>>> Hi Sergio,
>> >>>>>
>> >>>>> Try using the "rfnoc-ofdm" branches for uhd and
>> >>>>> gr-ettus and rebuild your FPGA image. Make sure
>> >>>>> to add the schmidl_cox block to
>> >>>>> rfnoc_e310_ce_auto_inst.v and run 'make
>> >>>>> cleanall' before building the FPGA image.
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> Jonathon
>> >>>>>
>> >>>>> On Tue, Mar 8, 2016 at 8:31 PM, Sergio Cruz
>> >>>>> Perez <serchs...@hotmail.com
>> >>>>> <mailto:serchs...@hotmail.com>> wrote:
>> >>>>>
>> >>>>> Hi Jonathon,
>> >>>>>
>> >>>>> Yes, I followed the RFNoC:Getting started
>> >>>>> guide to install the rfnoc-devel branch and
>> >>>>> the gr-ettus OOT module. I forgot to
>> >>>>> mention that in my first attempt to make the
>> >>>>> fpga image I had the next error:
>> >>>>>
>> >>>>> ERROR: [Synth 8-448] named port connection
>> >>>>> 's_axis_phase_tlast' does not exist for
>> >>>>> instance 'cfo_corrector' of module
>> >>>>> 'cordic_rotator'
>> >>>>> [/home/sheko/uhd/fpga-src/usrp3/lib/rfnoc/schmidl_cox.v:163]
>> >>>>>
>> >>>>>
>> >>>>> I removed that port in the schmidl_cox.v
>> >>>>> file and then it was possible to make the
>> >>>>> image with the schmidl_cox block.
>> >>>>>
>> >>>>> Thanks
>> >>>>>
>> >>>>> Sergio
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
> ------------------------------------------------------------------------
>> >>>>> From: jonathon.pend...@ettus.com
>> >>>>> <mailto:jonathon.pend...@ettus.com>
>> >>>>> Date: Tue, 8 Mar 2016 16:51:20 -0800
>> >>>>> Subject: Re: [USRP-users] Error using RFNoC
>> >>>>> OFDM Sync block on E310
>> >>>>> To: serchs...@hotmail.com
>> >>>>> <mailto:serchs...@hotmail.com>
>> >>>>> CC: usrp-users@lists.ettus.com
>> >>>>> <mailto:usrp-users@lists.ettus.com>
>> >>>>>
>> >>>>>
>> >>>>> Hi Sergio,
>> >>>>>
>> >>>>> Are you using the rfnoc-ofdm branches for
>> >>>>> uhd and gr-ettus?
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> Jonathon
>> >>>>>
>> >>>>> On Tue, Mar 8, 2016 at 4:31 PM, Sergio Cruz
>> >>>>> Perez via USRP-users
>> >>>>> <usrp-users@lists.ettus.com
>> >>>>> <mailto:usrp-users@lists.ettus.com>> wrote:
>> >>>>>
>> >>>>>
>> >>>>> Hi,
>> >>>>>
>> >>>>> I'm learning to use RFNoC to implement
>> >>>>> an OFDM receiver on a E310. The
>> >>>>> original FPGA image had just 3 RFNoC
>> >>>>> blocks: FIFO, Window and FFT, so I made
>> >>>>> a new image removing the window and the
>> >>>>> FFT blocks and replacing them for a
>> >>>>> schmidl_cox block. When I run my
>> >>>>> application with the new image I get the
>> >>>>> next error:
>> >>>>>
>> >>>>> File
>> >>>>> "/usr/local/lib/python2.7/site-packages/ettus/ettus_swig.py",
>> >>>>> line 3002, in set_arg
>> >>>>> return
>> >>>>> _ettus_swig.rfnoc_generic_sptr_set_arg(self,
>> >>>>> *args)
>> >>>>>
>> >>>>> RuntimeError: LookupError: Path not
>> >>>>> found in tree:
>> >>>>> /mboards/0/xbar/SchmidlCox_0/args/0/offset/value
>> >>>>>
>> >>>>> Has anyone run into the same problem?
>> >>>>>
>> >>>>> I'm using UHD_003.010.rfnoc-314-gf773e72b
>> >>>>>
>> >>>>> Thanks
>> >>>>>
>> >>>>> Sergio Cruz
>> >>>>>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> USRP-users mailing list
>> >>>>> USRP-users@lists.ettus.com
>> >>>>> <mailto:USRP-users@lists.ettus.com>
>> >>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> _______________________________________________ USRP-users
> mailing list
>> >>>>> USRP-users@lists.ettus.com
>> >>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> >>>>>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> USRP-users mailing list
>> >>>>> USRP-users@lists.ettus.com
>> >>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> >>>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> USRP-users mailing list
>> >>>> USRP-users@lists.ettus.com
>> >>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> >>
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > USRP-users mailing list
>> > USRP-users@lists.ettus.com
>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> >
>>




------------------------------

Message: 17
Date: Mon, 6 Jun 2016 19:11:26 -0400
From: Dave NotTelling <dmp250...@gmail.com>
To: Martin Braun <martin.br...@ettus.com>
Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] gr-ettus RFNoC 1024 Bin FFT Limit?
Message-ID:
        <CAK6GVuMk_ymv41-=wht2bpmd8mhgpdezfhgzoxezvjmasr4...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Okay, thank you!

On Mon, Jun 6, 2016 at 6:56 PM, Martin Braun via USRP-users <
usrp-users@lists.ettus.com> wrote:

> PCIe has the same max packet size (8000).
>
> M
>
> On 06/04/2016 08:56 AM, Dave NotTelling via USRP-users wrote:
> > Marcus,
> >
> >      Does the FFT size limit also apply to PCIe?
> >
> > -Dave
> >
> > On Mon, May 9, 2016 at 12:18 AM, Dave NotTelling <dmp250...@gmail.com
> > <mailto:dmp250...@gmail.com>> wrote:
> >
> >     Ahh, that makes perfect sense.   Thank you!
> >
> >     On May 9, 2016 12:09 AM, "Marcus D. Leech via USRP-users"
> >     <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>>
> wrote:
> >
> >         On 05/08/2016 11:28 PM, Dave NotTelling via USRP-users wrote:
> >
> >             Is the RFNoC FFT block limited to 1024 points?  The drop
> >             down shows up to 4096, but the block errors out in GNU Radio
> >             if put over 1024.  Is that intentional?  If so, is there a
> >             specific reason why the FFT block is limited that low?
> >
> >             Thank you!
> >
> >             -Dave
> >
> >         FFT outputs are done as single UDP frames in RFNoC, so you're
> >         limited to whatever your Ethernet NIC can give you.  For
> >         1024-bin FFTs, that
> >           requires a minimum of 4096bytes, without considering required
> >         VITA overhead, etc.  So, your NIC needs to be programmed for
> >         about 4500
> >           bytes MTU.  Most 1GiGe NICs won't go a whole lot over that,
> >         although 10GiGe NICs will allow and MTU of 9000, allowing
> >         2048-bin FFTs.
> >
> >
> >
> >         _______________________________________________
> >         USRP-users mailing list
> >         USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
> >
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> 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/20160606/083d0ef9/attachment-0001.html>

------------------------------

Message: 18
Date: Mon, 6 Jun 2016 22:10:04 -0400
From: Philip Balister <phi...@opensdr.com>
To: Sean Nowlan <nowl...@gmail.com>, Martin Braun
        <martin.br...@ettus.com>
Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Cross Compiling RFNoC for E310
Message-ID: <040943b4-1153-ccad-8361-4d8c14dd9...@opensdr.com>
Content-Type: text/plain; charset=windows-1252

On 06/06/2016 06:33 PM, Sean Nowlan via USRP-users wrote:
> Sam, I'll echo Martin's suggestion to pick a location in your home
> directory, or alternatively in /opt/sdk.
> 
> I think the SDK installer script defaults to /usr/local/oecore-sdk (or
> similar). It'd probably be a good thing to make the default /opt/oecore-sdk

I like to install sdks in my home directory in something like
~/sdks/release-4.

Philip

> or something else to help users avoid putting funky things into the host
> machine's search paths, although it's easy enough for the user to override
> the setting from the installer prompt. I looked for a bit where this can be
> set in an OpenEmbedded variable or bbappend file but I didn't look too
> hard. I believe it's "target_sdk_dir" in [1], but I'm not sure where that
> can be set from a bitbake recipe.
> 
> [1]
> http://cgit.openembedded.org/cgit.cgi/openembedded-core/tree/meta/classes/populate_sdk_ext.bbclass?h=fido
> 
> Sean
> 
> On Mon, Jun 6, 2016 at 5:58 PM, Martin Braun via USRP-users <
> usrp-users@lists.ettus.com> wrote:
> 
>> On 06/06/2016 08:07 AM, Sam Carey via USRP-users wrote:
>>> As I understand it, cross-compiling means that the building takes place
>>> on my desktop machine and then the results are installed on the E310.
>>
>> Yep.
>>
>>> So I install the SDK toolchain on my desktop in /usr/local/.
>>
>> Please never do that. You can screw up your system that way. Just pick a
>> dir in your home dir and do everything in there.
>>
>> Also, please look at Sean's response.
>>
>> M
>>
>>
>>>
>>> Then I run
>>> .
>>>
>> /usr/local/oecore-x86_64/environment-setup-armv7ahf-vfp-neon-oe-linux-gnueabi
>>> cmake -DCMAKE_TOOLCHAIN_FILE=../host/cmake/Toolchains/oe-sdk_cross.cmake
>>> -DCMAKE_INSTALL_PREFIX=/usr -DENABLE_E300=ON -DENABLE_B200=OFF ..
>>>
>>> which means that the resulting files will be installed to /usr on my
>>> desktop machine. At this point it seems there's a gap in the
>>> instructions where I need to install to the E310, either by setting
>>> CMAKE_INSTALL_PREFIX to the /usr directory on the E310 via sshfs, or by
>>> setting DESTDIR to the E310 via sshfs when I install.
>>>
>>> Anyway, I install uhd and gnuradio to the E310 in this manner.
>>>
>>> Then when I try to build gr-ettus:
>>>
>>> cmake
>>>
>> -DCMAKE_TOOLCHAIN_FILE=/home/samcarey/GNURadio/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake
>>> -DCMAKE_INSTALL_PREFIX=/usr -DENABLE_DOXYGEN=OFF ..
>>>
>>> it can't find the correct rfnoc-radio-redo uhd library, apparently
>>> because it is looking where I installed the SDK on the machine (which I
>>> assume has non-rfnoc libraries) instead of where I installed the correct
>>> libraries on the E310:
>>>
>>> ...
>>> -- Found PkgConfig:
>>> /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/pkg-config
>>> (found version "0.28")
>>> -- Found UHD:
>>>
>> /usr/local/oecore-x86_64/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/lib/libuhd.so
>>>
>>> CMake Error at CMakeLists.txt:113 (message):
>>>   RFNoC not found.
>>>
>>> I suppose I could set the CMAKE_INSTALL_PREFIX to the SDK installation,
>>> where it is looking for the libraries. But this would contradict the
>>> instructed location of "/usr" and I'd have to also install everything to
>>> the E310 afterward.
>>>
>>> Could someone please help me understand how this is supposed to work?
>>>
>>> Thanks,
>>> Sam Carey
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
> 
> 
> 
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 




------------------------------

Message: 19
Date: Tue, 7 Jun 2016 17:48:06 +0800
From: Ekko <chai18740449...@gmail.com>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] run a program when the E310 boot start
Message-ID:
        <caggob6bxlip0ja5jhjysryxqzn504dtkj6vzrq4-1t3xvan...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

hello  all
i want to set an order to be run when the E310 boot start
and i see that i can modify the /etc/rc.local to accomplish this ,but i can
not find the rc.local on e310,
and the order i want to run is in the /usr/local/sbin,and i want to know
how to solve this on e310.

or give me some instruction about this system of e310

thank you

--Ekko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160607/97b0eb42/attachment-0001.html>

------------------------------

Message: 20
Date: Tue, 7 Jun 2016 12:12:24 +0200
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] RFNoC block in GNURadio not appearing under
        UHD
Message-ID: <57569e08.7070...@ettus.com>
Content-Type: text/plain; charset=windows-1252

And, in GRC's "help" menu, is there something under "Parser Errors"?

On 06.06.2016 23:56, Martin Braun via USRP-users wrote:
> Does your block XML file have its own <category> maybe?
>
> On 06/06/2016 09:57 AM, Jason Matusiak via USRP-users wrote:
>> What am I doing wrong when I create a new gr-something block? Whenever I
>> create a new block, it shows up under "none" in the block list in GRC;
>> yet I would expect it to show up in UHD->RFNOC.
>>
>> I have a feeling it has something to do with the block_tree.xml I put in
>> my gr-something/grc folder, but I can't figure out what.  My current one
>> looks like:
>> <?xml version="1.0"?>
>> <!--
>> ###################################################
>> ##Block Tree for uhd blocks.
>> ###################################################
>>  -->
>> <cat>
>>     <name></name> <!-- Blank for Root Name -->
>>     <cat>
>>         <name>UHD</name>
>>         <cat>
>>             <name>RFNoC</name>
>>             <block>uhd_rfnoc_freq_shift.xml</block>
>>         </cat>
>>     </cat>
>> </cat>
>>
>> What am I missing?
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com




------------------------------

Message: 21
Date: Tue, 7 Jun 2016 07:35:07 -0400
From: Philip Balister <phi...@opensdr.com>
To: Ekko <chai18740449...@gmail.com>,   "usrp-users@lists.ettus.com"
        <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] run a program when the E310 boot start
Message-ID: <81da3f0b-13ab-86b5-a535-a0c0fb339...@opensdr.com>
Content-Type: text/plain; charset=windows-1252

On 06/07/2016 05:48 AM, Ekko via USRP-users wrote:
> hello  all
> i want to set an order to be run when the E310 boot start
> and i see that i can modify the /etc/rc.local to accomplish this ,but i can
> not find the rc.local on e310,
> and the order i want to run is in the /usr/local/sbin,and i want to know
> how to solve this on e310.
> 
> or give me some instruction about this system of e310

The use of rc.local has decreased to the point most Linux distributions
no longer support it. Write a proper init file.

Philip


> 
> thank you
> 
> --Ekko
> 
> 
> 
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 




------------------------------

Message: 22
Date: Tue, 7 Jun 2016 08:25:36 -0400
From: Jason Matusiak <ja...@gardettoengineering.com>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>, Marcus
        M?ller <marcus.muel...@ettus.com>,      Martin Braun
        <martin.br...@ettus.com>
Subject: Re: [USRP-users] RFNoC block in GNURadio not appearing under
        UHD
Message-ID: <5756bd40.6030...@gardettoengineering.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

>/Does your block XML file have its own <category> maybe? I don't 
//believe// so. Here is what the beginning of my block looks like: <?xml 
version="1.0"?> <block> <name>RFNoC: Frequency Shift</name> 
<key>uhd_rfnoc_streamer_freq_shift</key> <import>import ettus</import> 
<make>ettus.rfnoc_generic( self.device3, uhd.stream_args( \# TX Stream 
Args cpu_format="$type", otw_format="$otw", args="", ), uhd.stream_args( 
\# RX Stream Args cpu_format="$type", otw_format="$otw", args="", ), 
"FreqShift", $block_index, $device_index, ) 
self.$(id).set_arg("freq_off", $freq_off) 
self.$(id).set_arg("samp_rate", $samp_rate) </make> /



> And, in GRC's "help" menu, is there something under "Parser Errors"?
No, it looks fine.  These blocks will work OK, I just have to search for them 
instead of looking at the UHD->RFNOC dropdown.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160607/3bca5ef0/attachment-0001.html>

------------------------------

Message: 23
Date: Tue, 7 Jun 2016 14:18:48 +0000
From: Kieran Lea <kieran....@unb.ca>
To: Martin Braun <martin.br...@ettus.com>,
        "usrp-users@lists.ettus.com"    <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] AddSub example port not connected error
Message-ID:
        
<sn2pr04mb2304d9afe193211da18033adf3...@sn2pr04mb2304.namprd04.prod.outlook.com>
        
Content-Type: text/plain; charset="us-ascii"

Hi,


Both input ports are the same as the example too, so they're both coming from 
GNU Radio blocks. I have tried other configurations too for input blocks and 
none of them have solved the error yet.

________________________________
From: USRP-users <usrp-users-boun...@lists.ettus.com> on behalf of Martin Braun 
via USRP-users <usrp-users@lists.ettus.com>
Sent: Monday, June 6, 2016 7:00:27 PM
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] AddSub example port not connected error

Is port 0 connected to an RFNoC block, but 1 to a GNU Radio block?

-- Martin

On 06/06/2016 06:44 AM, Kieran Lea via USRP-users wrote:
> Hi,
>
>
> I tried using the addsub example here:
> https://github.com/EttusResearch/gr-ettus/tree/master/examples/rfnoc
>
>
> and I get an error:
>
>
> thread[thread-per-block[3]: <block uhd_rfnoc_AddSub (1)>]: RuntimeError:
> On node 0/AddSub_0, input port 0 is already connected.
>
>
> I saw another person on the list ask this question earlier and you guys
> had said it was GNURadio getting confused with an output to a regular
> block and an RFNoC block, but I'm wondering if that's the case, because
> it seems both ports are connected to a regular block? I also tried a few
> other configurations and they resulted in the same error. I'm on the
> devel branch with an X310, any idea how to get it working?
>
>
> Thanks
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>


_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160607/7920eda1/attachment-0001.html>

------------------------------

Subject: Digest Footer

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


------------------------------

End of USRP-users Digest, Vol 70, Issue 7
*****************************************