USRP-users Digest, Vol 69, Issue 27

[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. Re: Error using RFNoC OFDM Sync block on E310 (Martin Braun)
   2. Re: N210 FPGA Memory (Marcus M?ller)
   3. Work close to the saturation point of the power   amplifier
      (Marc Bauduin)
   4. Creating custom image ends mostly in timing problems inside
      ettus blocks (X310) (Patrick Berger)
   5. Re: Work close to the saturation point of the power amplifier
      (Marcus M?ller)
   6. Re: Work close to the saturation point of the power       amplifier
      (Ian Buckley)
   7. UHD/niusrprio lockup (Peter A Iannucci)
   8. Re: UHD/niusrprio lockup (Peter A Iannucci)
   9. Tuning Resolution of B210 RF Front end (Jeremy Hershberger)
  10. Re: Tuning Resolution of B210 RF Front end (Marcus D. Leech)
  11. Re: Tuning Resolution of B210 RF Front end (Ian Buckley)
  12. Re: Error using RFNoC OFDM Sync block on E310 (Sergio Cruz Perez)
  13. Re: Work close to the saturation point of the power       amplifier
      (Marc Bauduin)
  14. Bandwidth of USRP N210's low pass filter (Jeon)
  15. Re: Work close to the saturation point of the power amplifier
      (Marcus M?ller)
  16. Re: Bandwidth of USRP N210's low pass filter (Marcus M?ller)
  17. Re: Error using RFNoC OFDM Sync block on E310 (Philip Balister)
  18. Re: I am dead in the water due to the following error: RFNoC
      not found. (Collins, Richard)


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

Message: 1
Date: Thu, 26 May 2016 09:33:08 -0700
From: Martin Braun <martin.br...@ettus.com>
To: Sergio Cruz Perez <serchs...@hotmail.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
Message-ID: <57472544.4030...@ettus.com>
Content-Type: text/plain; charset=windows-1252

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




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

Message: 2
Date: Thu, 26 May 2016 20:59:08 +0200
From: Marcus M?ller <marcus.muel...@ettus.com>
To: "Topliff, Charles Alexander" <ctopliff1...@ku.edu>
Cc: "usrp-users@lists.ettus.com" <USRP-users@lists.ettus.com>
Subject: Re: [USRP-users] N210 FPGA Memory
Message-ID: <5747477c.3070...@ettus.com>
Content-Type: text/plain; charset="windows-1252"

So in that case, sampling with more than 50MS/s doesn't give you any
additional info on the signal you're observing (which can be at most
40MHz wide. The oversampling effect of the 100MS/s ADC is that you get
improved SNR, and that's already happening with the DSP chain as is.
So, the only problem is that at 50MS/s, you can only do 8 bit sampling,
exactly due to the Gigabit bandwidth restriction. That limits your SNR;
there's quantization noise.

So the question is to what end you want to sample at 100MS/s ? maybe we
can come up with something elegant that makes your application possible!

Best regards,
Marcus

On 26.05.2016 18:19, Topliff, Charles Alexander wrote:
>
> I am using the 40mhz SBX daugterboard. I also have access to the 40mhz
> CBX as well.
>
>
> Charles
>
> ------------------------------------------------------------------------
> *From:* USRP-users <usrp-users-boun...@lists.ettus.com> on behalf of
> Marcus M?ller via USRP-users <usrp-users@lists.ettus.com>
> *Sent:* Thursday, May 26, 2016 10:51 AM
> *To:* usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] N210 FPGA Memory
>  
> Dear Charles,
>
> On 26.05.2016 16:08, Topliff, Charles Alexander via USRP-users wrote:
>> Hello All,
>>  
>> I am interested in capturing samples at 100 MS/s using a USRP N210 at
>> a 16b (or 14-bit ADC) resolution. In the datasheet, it is mentioned
>> that the maximum host sampling rate N210 is capable of is 50MS/s at
>> 8bit resolution over Gigabit Ethernet. My understanding is that this
>> is a limitation imposed by the transfer speed over the Gigabit
>> ethernet interface.
> Exactly!
>>  
>> To utilize the full potential of ADC sampling rate, what is the best
>> way to accumulate only a second (or half a second) worth of data?
>> Specifically, I would like to know if it is possible to use the FPGA
>> to synthesize memory & record 1 sec worth of samples (at 14b *
>> 100MS/s) to that. After recording, I would read it to the host at a
>> slower speed. Are there any constraints in that path?
> (14b/real + 14bit/image) * 100 MS/s * 1s = 2.800Gb = 350MB. That's
> much more than you could fit in any FPGA, and much more than the N210
> has in on-board RAM ? in fact, the N210 already uses SRAM buffering
> itself on an 9Mbit SDRAM chip, but if I'm not mistaken, that's for TX
> data only.
>
> You could adapt that (it's called ext_fifo, IIRC) for your RX and get
> up to let's say 1/350s of buffering on the device.
>>  
>> Is there a better way of handling this? Any suggestion is appreciated.
> On the N210, I'm not quite sure.
> One thing I wanted to ask was:
>
> Which daughterboard do you intend to use? All our daughterboards
> either have <= 40MHz bandwidth, so you gain nothing compared by using
> 100MS/s (compared to 50MS/s), according to Nyquist, or >=120 MHz
> bandwidth, so that they can't be used even at 100MS/s without aliasing.
> The only exception would be an BasicRX daughterboard with your own,
> custom, prefiltering that sufficiently band-limits the signal to
> something below 50MHz on each I and Q lane.
>
> Best regards,
> Marcus

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

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

Message: 3
Date: Thu, 26 May 2016 22:00:38 +0200
From: Marc Bauduin <baudu1m...@gmail.com>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] Work close to the saturation point of the power
        amplifier
Message-ID:
        <ca+ekp-b1rzlou4mqv87j6fer1k9zwglpsgvybkhkmpa8ynw...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi everyone,

I work with 2 USRP N210 and with RFX2450. They are synchroized in frequency
with an external 10 MHz clock.

I try to see what happen when we use them close to the saturation point of
their power amplifier.

The transmitted signal is defined in fc32 with:
uhd::stream_args_t stream_args("fc32","sc8");

To see what happen, I send a step signal (which is real in baseband) with
different level of amplitudes (from 0.3 to 1.2 with a step of 0.1) each
step is maintained during 1e4 samples. On the receiver side, I can observe
a compression when the amplitude is close to 1. This is what I expected.
But for the values higher than 1, I can observe, periodically, a strong
decay in amplitude. I observe the same thing for an amplitude of 1.1 and
1.2 (this explains why the last step is longer)(blue signal in the figure).

I suppose that it doesn't come from the power amplifier. If it was the DAC,
I expected to only see a clipping, and thus, a constant signal in amplitude
(plus a noise).

I read that the maximum amplitude that we could use on I and Q was 1. Do
you know what happen when the amplitude of the input signal is higher than
1 on I or Q? The DAC can deliver an amplitude higher than 1?

I also sent this step signal with a phase of pi/4 (in red in the picture).
We can see that with an amplitude of 1.1 and 1.2 (thus 0.777 and 0.848 on I
and Q), that the amplitude of the step is reduced . In this case, the DAC
should give a sufficiently high amplitude. Is it possible that it comes
from the power amplifier? Why a so important reduction of the power output
in this case?

I observe similar results with different sampling frequencies.

Do you have an explanation for these results?

I hope that the results are easy to read.

Thanks in advance for your answer,

Marc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160526/5e3bc0af/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0mailStep.jpg
Type: image/jpeg
Size: 25706 bytes
Desc: not available
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160526/5e3bc0af/attachment-0001.jpg>

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

Message: 4
Date: Thu, 26 May 2016 22:02:31 +0200
From: Patrick Berger <pa.ber...@hotmail.com>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] Creating custom image ends mostly in timing
        problems inside ettus blocks (X310)
Message-ID: <dub121-w7a86080823356b9518847f5...@phx.gbl>
Content-Type: text/plain; charset="iso-8859-1"

Hi every body

I've created a custom block in xilinx system generator for a psd estimation 
with an iir filter. Inside system generator I can create a timing analysis 
(post route) without any problems (worst negativ slack is ~3ns).
When I create an IP core and add the core to the default Vivado project inside 
the radio.v module and try to synthezise the design I get in 90% timing 
problems with the rgpio module (rgpio_atr and the radio_clk signal). The number 
failing endpoints are about 1 to 15. Chanching the implementation and synthesis 
strategie improves the design, but it fails the timing check.

How could that be? My psd modul needs about 1-3% from the fpga ressources, so 
it isn't so big. the output bus is only 50 bits width.

Does anyone have some experience with sutch problems?

Best regards
Patrick 
                                          
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160526/1900750e/attachment-0001.html>

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

Message: 5
Date: Thu, 26 May 2016 22:26:24 +0200
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Work close to the saturation point of the
        power amplifier
Message-ID: <57475bf0.4040...@ettus.com>
Content-Type: text/plain; charset="windows-1252"

Hi Marc,
thanks for raising this here!

> Do you know what happen when the amplitude of the input signal is
> higher than 1 on I or Q? The DAC can deliver an amplitude higher than 1?
Without FPGA-modifying hacks, you won't be able to send values higher
than 1 for I or Q ? that 1 is converted to the maximum of your
on-the-wire format (for example, to 2**15-1 for the default SC16 format
that the N210 uses over ethernet).
The float32-to-SC16 converter takes care of the saturating arithmetics;
and even if you directly sent the 16bit integer values ? the highest
value is the highest value.

So, this made me think, and here's my explanation:

Now, what might happen for complexes with |.| > 1 is that arithmetic
shenanigans take place in the DSP chain when it processes these samples.
For example, due to the digital tuning capabilities in the FPGA, your
pi/4 phase signal might be rotated back to a 0-phase signal; somewhere
in that rotation, a value will occur that is higher than the maximum
value for I or Q, and in that moment, you might see things like the
numerical value "overflowing" and suddenly being small instead of very big.

So, you really shouldn't send complex values with a magnitude larger
than 1. It will confuse the DSP chain.

Best regards,
Marcus

On 26.05.2016 22:00, Marc Bauduin via USRP-users wrote:
> Hi everyone,
>
> I work with 2 USRP N210 and with RFX2450. They are synchroized in
> frequency with an external 10 MHz clock.
>
> I try to see what happen when we use them close to the saturation
> point of their power amplifier.
>
> The transmitted signal is defined in fc32 with:
> uhd::stream_args_t stream_args("fc32","sc8"); 
>
> To see what happen, I send a step signal (which is real in baseband)
> with different level of amplitudes (from 0.3 to 1.2 with a step of
> 0.1) each step is maintained during 1e4 samples. On the receiver side,
> I can observe a compression when the amplitude is close to 1. This is
> what I expected. But for the values higher than 1, I can observe,
> periodically, a strong decay in amplitude. I observe the same thing
> for an amplitude of 1.1 and 1.2 (this explains why the last step is
> longer)(blue signal in the figure).
>
> I suppose that it doesn't come from the power amplifier. If it was the
> DAC, I expected to only see a clipping, and thus, a constant signal in
> amplitude (plus a noise).
>
> I read that the maximum amplitude that we could use on I and Q was 1.
> Do you know what happen when the amplitude of the input signal is
> higher than 1 on I or Q? The DAC can deliver an amplitude higher than 1?
>
> I also sent this step signal with a phase of pi/4 (in red in the
> picture). We can see that with an amplitude of 1.1 and 1.2 (thus 0.777
> and 0.848 on I and Q), that the amplitude of the step is reduced . In
> this case, the DAC should give a sufficiently high amplitude. Is it
> possible that it comes from the power amplifier? Why a so important
> reduction of the power output in this case?
>
> I observe similar results with different sampling frequencies.
>
> Do you have an explanation for these results?
>
> I hope that the results are easy to read.
>
> Thanks in advance for your answer,
>
> Marc
>
>
> _______________________________________________
> 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/20160526/d367cd6e/attachment-0001.html>

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

Message: 6
Date: Thu, 26 May 2016 15:06:15 -0700
From: Ian Buckley <i...@ionconcepts.com>
To: Marcus M?ller <marcus.muel...@ettus.com>
Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Work close to the saturation point of the
        power   amplifier
Message-ID:
        <cam_0ocf5xe-icas-hk4-cm7nmaph1u-oxpycepzp16zw2ta...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Indeed, I fixed overflow problems in intermediate stages of the DSP logic
due to complex rotation of large amplitudes only last year on newer 3
series USRP's.
I can't recall what the situation is with N210 off the top of my head, when
in doubt leave some headroom in the digital signal.
Remember also that the amplitude into the PA is dependent on programable
analog gain values in addition to digital signal amplitude, and the point
of saturation varies across daughter boards.
In general you do not need a maximum amplitude input signal to saturate the
PA with a high gain value.
In practical terms examine the quality of your digital signal first on test
equipment by pairing it with a small analog gain value that ensures you
only will see digital signal processing issues...then increase the gain to
see analog imperfections.
-Ian


On Thu, May 26, 2016 at 1:26 PM, Marcus M?ller <usrp-users@lists.ettus.com>
wrote:

> Hi Marc,
> thanks for raising this here!
>
> Do you know what happen when the amplitude of the input signal is higher
> than 1 on I or Q? The DAC can deliver an amplitude higher than 1?
>
> Without FPGA-modifying hacks, you won't be able to send values higher than
> 1 for I or Q ? that 1 is converted to the maximum of your on-the-wire
> format (for example, to 2**15-1 for the default SC16 format that the N210
> uses over ethernet).
> The float32-to-SC16 converter takes care of the saturating arithmetics;
> and even if you directly sent the 16bit integer values ? the highest value
> is the highest value.
>
> So, this made me think, and here's my explanation:
>
> Now, what might happen for complexes with |.| > 1 is that arithmetic
> shenanigans take place in the DSP chain when it processes these samples.
> For example, due to the digital tuning capabilities in the FPGA, your pi/4
> phase signal might be rotated back to a 0-phase signal; somewhere in that
> rotation, a value will occur that is higher than the maximum value for I or
> Q, and in that moment, you might see things like the numerical value
> "overflowing" and suddenly being small instead of very big.
>
> So, you really shouldn't send complex values with a magnitude larger than
> 1. It will confuse the DSP chain.
>
> Best regards,
> Marcus
>
>
> On 26.05.2016 22:00, Marc Bauduin via USRP-users wrote:
>
> Hi everyone,
>
> I work with 2 USRP N210 and with RFX2450. They are synchroized in
> frequency with an external 10 MHz clock.
>
> I try to see what happen when we use them close to the saturation point of
> their power amplifier.
>
> The transmitted signal is defined in fc32 with:
> uhd::stream_args_t stream_args("fc32","sc8");
>
> To see what happen, I send a step signal (which is real in baseband) with
> different level of amplitudes (from 0.3 to 1.2 with a step of 0.1) each
> step is maintained during 1e4 samples. On the receiver side, I can observe
> a compression when the amplitude is close to 1. This is what I expected.
> But for the values higher than 1, I can observe, periodically, a strong
> decay in amplitude. I observe the same thing for an amplitude of 1.1 and
> 1.2 (this explains why the last step is longer)(blue signal in the figure).
>
> I suppose that it doesn't come from the power amplifier. If it was the
> DAC, I expected to only see a clipping, and thus, a constant signal in
> amplitude (plus a noise).
>
> I read that the maximum amplitude that we could use on I and Q was 1. Do
> you know what happen when the amplitude of the input signal is higher than
> 1 on I or Q? The DAC can deliver an amplitude higher than 1?
>
> I also sent this step signal with a phase of pi/4 (in red in the picture).
> We can see that with an amplitude of 1.1 and 1.2 (thus 0.777 and 0.848 on I
> and Q), that the amplitude of the step is reduced . In this case, the DAC
> should give a sufficiently high amplitude. Is it possible that it comes
> from the power amplifier? Why a so important reduction of the power output
> in this case?
>
> I observe similar results with different sampling frequencies.
>
> Do you have an explanation for these results?
>
> I hope that the results are easy to read.
>
> Thanks in advance for your answer,
>
> Marc
>
>
> _______________________________________________
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://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/20160526/adcd95e3/attachment-0001.html>

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

Message: 7
Date: Thu, 26 May 2016 22:01:30 +0000
From: Peter A Iannucci <iannu...@mit.edu>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] UHD/niusrprio lockup
Message-ID: <0820d8e1-cec1-4253-ac2f-3bdbd8162...@mit.edu>
Content-Type: text/plain; charset="utf-8"

Hi all,

I?m trying to use my NI USRP-2943R?s (they?re pretty much just rebranded 
X310?s) from Debian Jessie 8.4, kernel version 3.16.0-4-amd64.  Each time I try 
to open a UHD session, for instance via uhd_usrp_probe, I get the message

Error: RuntimeError: x300_impl: Could not initialize RIO session. Unknown 
error. (Error code -63150)

After four or so attempts, the kernel locks up and doesn?t respond to sysrq?s.

The following are freshly updated:

Debian
niusrpriok driver
BIOS
UHD
gnuradio
UHD images
USRP?s onboard flash memory FPGA bitstream (stock version)

Here?s the tail of the kernel log, collected via SSH from another machine.  No 
log messages made it out between the last invocation of uhd_usrp_probe and the 
machine locking up.  Sometimes a block of \0?s appears in the kernel log after 
rebooting.

May 25 11:14:10 clouseau kernel: [  421.172275] dmar: DRHD: handling fault 
status reg 2
May 25 11:14:10 clouseau kernel: [  421.172282] dmar: DMAR:[DMA Read] Request 
device [04:00.0] fault addr 103cb31000 
May 25 11:14:10 clouseau kernel: [  421.172282] DMAR:[fault reason 01] Present 
bit in root entry is clear
May 25 11:14:10 clouseau kernel: [  421.188285] niusrpriok: Error -63150 
(HardwareFault): programming failed
May 25 11:14:16 clouseau kernel: [  427.551925] niusrpriok: Error -63150 
(HardwareFault): timed out disabling IOPort2
May 25 11:14:28 clouseau kernel: [  439.587035] niusrpriok: Error -63150 
(HardwareFault): timed out disabling IOPort2

Can anyone offer me any pointers?

Thank you very much,
-Peter Iannucci

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

Message: 8
Date: Thu, 26 May 2016 22:11:36 +0000
From: Peter A Iannucci <iannu...@mit.edu>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] UHD/niusrprio lockup
Message-ID: <7edb0386-4023-44f6-b02a-242067f1d...@mit.edu>
Content-Type: text/plain; charset="utf-8"

Ah, just tracked it down.  Don?t use Intel VT-d with the X310.

There goes my pipe dream of using KVM PCIe passthrough with the X310.

-Peter

> On May 26, 2016, at 6:01 PM, Peter A Iannucci <iannu...@mit.edu> wrote:
> 
> Hi all,
> 
> I?m trying to use my NI USRP-2943R?s (they?re pretty much just rebranded 
> X310?s) from Debian Jessie 8.4, kernel version 3.16.0-4-amd64.  Each time I 
> try to open a UHD session, for instance via uhd_usrp_probe, I get the message
> 
> Error: RuntimeError: x300_impl: Could not initialize RIO session. Unknown 
> error. (Error code -63150)
> 
> After four or so attempts, the kernel locks up and doesn?t respond to sysrq?s.
> 
> The following are freshly updated:
> 
> Debian
> niusrpriok driver
> BIOS
> UHD
> gnuradio
> UHD images
> USRP?s onboard flash memory FPGA bitstream (stock version)
> 
> Here?s the tail of the kernel log, collected via SSH from another machine.  
> No log messages made it out between the last invocation of uhd_usrp_probe and 
> the machine locking up.  Sometimes a block of \0?s appears in the kernel log 
> after rebooting.
> 
> May 25 11:14:10 clouseau kernel: [  421.172275] dmar: DRHD: handling fault 
> status reg 2
> May 25 11:14:10 clouseau kernel: [  421.172282] dmar: DMAR:[DMA Read] Request 
> device [04:00.0] fault addr 103cb31000 
> May 25 11:14:10 clouseau kernel: [  421.172282] DMAR:[fault reason 01] 
> Present bit in root entry is clear
> May 25 11:14:10 clouseau kernel: [  421.188285] niusrpriok: Error -63150 
> (HardwareFault): programming failed
> May 25 11:14:16 clouseau kernel: [  427.551925] niusrpriok: Error -63150 
> (HardwareFault): timed out disabling IOPort2
> May 25 11:14:28 clouseau kernel: [  439.587035] niusrpriok: Error -63150 
> (HardwareFault): timed out disabling IOPort2
> 
> Can anyone offer me any pointers?
> 
> Thank you very much,
> -Peter Iannucci


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

Message: 9
Date: Thu, 26 May 2016 18:17:38 -0400
From: Jeremy Hershberger <jeremy.l.hershberger...@nd.edu>
To: usrp-users <usrp-users@lists.ettus.com>
Subject: [USRP-users] Tuning Resolution of B210 RF Front end
Message-ID:
        <camziklrj+lsxqpo2lnaipjeey+zxnjkrtl5xrmmuskvstkx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Using the functions multi_usrp::get_fe_rx_freq_range() and
multi_usrp::get_fe_tx_freq_range() I am supposed to get the low, high, and
step size of just the RF front end (without the DSP chain).  However, when
I looked at the attributes of both freq_range_t objects that were returned,
the start is 50MHz, the stop is 6GHz, but the step size was set to 0.

What is the step size of the RF Front End on the B210 (without the DSP)?

Thanks,

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

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

Message: 10
Date: Thu, 26 May 2016 18:26:32 -0400
From: "Marcus D. Leech" <mle...@ripnet.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Tuning Resolution of B210 RF Front end
Message-ID: <57477818.7020...@ripnet.com>
Content-Type: text/plain; charset=windows-1252; format=flowed

On 05/26/2016 06:17 PM, Jeremy Hershberger via USRP-users wrote:
> Using the functions multi_usrp::get_fe_rx_freq_range() and 
> multi_usrp::get_fe_tx_freq_range() I am supposed to get the low, high, 
> and step size of just the RF front end (without the DSP chain).  
> However, when I looked at the attributes of both freq_range_t objects 
> that were returned, the start is 50MHz, the stop is 6GHz, but the step 
> size was set to 0.
>
> What is the step size of the RF Front End on the B210 (without the DSP)?
>
> Thanks,
>
> -Jeremy
>
It depends on the master-clock setting, almost certainly, and the B2xx 
have variable master-clock rates.  Ettus engineers can comment
   further on why this value is set to zero, but my guess it's due to 
the above....





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

Message: 11
Date: Thu, 26 May 2016 17:34:11 -0700
From: Ian Buckley <i...@ionconcepts.com>
To: "Marcus D. Leech" <mle...@ripnet.com>
Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Tuning Resolution of B210 RF Front end
Message-ID:
        <CAM_0ocGXsSpRjE7DvS73X7SQ7Qr7RVBj=nf7ayyzunegv_c...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

2.4Hz for AD9361
-Ian

On Thu, May 26, 2016 at 3:26 PM, Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 05/26/2016 06:17 PM, Jeremy Hershberger via USRP-users wrote:
>
>> Using the functions multi_usrp::get_fe_rx_freq_range() and
>> multi_usrp::get_fe_tx_freq_range() I am supposed to get the low, high, and
>> step size of just the RF front end (without the DSP chain).  However, when
>> I looked at the attributes of both freq_range_t objects that were returned,
>> the start is 50MHz, the stop is 6GHz, but the step size was set to 0.
>>
>> What is the step size of the RF Front End on the B210 (without the DSP)?
>>
>> Thanks,
>>
>> -Jeremy
>>
>> It depends on the master-clock setting, almost certainly, and the B2xx
> have variable master-clock rates.  Ettus engineers can comment
>   further on why this value is set to zero, but my guess it's due to the
> above....
>
>
>
> _______________________________________________
> 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/20160526/2207a760/attachment-0001.html>

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

Message: 12
Date: Thu, 26 May 2016 20:40:43 -0500
From: Sergio Cruz Perez <serchs...@hotmail.com>
To: Martin Braun <martin.br...@ettus.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
Message-ID: <col128-w95322c62debebf85dc5e4bf...@phx.gbl>
Content-Type: text/plain; charset="iso-8859-1"

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




> 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
> 
                                          
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160526/e16ddaef/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: schmidl_backtrace.txt
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160526/e16ddaef/attachment-0001.txt>

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

Message: 13
Date: Fri, 27 May 2016 11:26:42 +0200
From: Marc Bauduin <baudu1m...@gmail.com>
To: Ian Buckley <i...@ionconcepts.com>
Cc: Marcus M?ller <marcus.muel...@ettus.com>,
        "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Work close to the saturation point of the
        power   amplifier
Message-ID:
        <ca+ekp-aramrlcgzzfssqv81kjv5gsqzgpmrx+a3fhsjztag...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Thank you for your answers.

The RFX2450 have a fixed gain. So I cannot increase the gain to saturate
the PA.

Marc

2016-05-27 0:06 GMT+02:00 Ian Buckley via USRP-users <
usrp-users@lists.ettus.com>:

> Indeed, I fixed overflow problems in intermediate stages of the DSP logic
> due to complex rotation of large amplitudes only last year on newer 3
> series USRP's.
> I can't recall what the situation is with N210 off the top of my head,
> when in doubt leave some headroom in the digital signal.
> Remember also that the amplitude into the PA is dependent on programable
> analog gain values in addition to digital signal amplitude, and the point
> of saturation varies across daughter boards.
> In general you do not need a maximum amplitude input signal to saturate
> the PA with a high gain value.
> In practical terms examine the quality of your digital signal first on
> test equipment by pairing it with a small analog gain value that ensures
> you only will see digital signal processing issues...then increase the gain
> to see analog imperfections.
> -Ian
>
>
> On Thu, May 26, 2016 at 1:26 PM, Marcus M?ller <usrp-users@lists.ettus.com
> > wrote:
>
>> Hi Marc,
>> thanks for raising this here!
>>
>> Do you know what happen when the amplitude of the input signal is higher
>> than 1 on I or Q? The DAC can deliver an amplitude higher than 1?
>>
>> Without FPGA-modifying hacks, you won't be able to send values higher
>> than 1 for I or Q ? that 1 is converted to the maximum of your on-the-wire
>> format (for example, to 2**15-1 for the default SC16 format that the N210
>> uses over ethernet).
>> The float32-to-SC16 converter takes care of the saturating arithmetics;
>> and even if you directly sent the 16bit integer values ? the highest value
>> is the highest value.
>>
>> So, this made me think, and here's my explanation:
>>
>> Now, what might happen for complexes with |.| > 1 is that arithmetic
>> shenanigans take place in the DSP chain when it processes these samples.
>> For example, due to the digital tuning capabilities in the FPGA, your pi/4
>> phase signal might be rotated back to a 0-phase signal; somewhere in that
>> rotation, a value will occur that is higher than the maximum value for I or
>> Q, and in that moment, you might see things like the numerical value
>> "overflowing" and suddenly being small instead of very big.
>>
>> So, you really shouldn't send complex values with a magnitude larger than
>> 1. It will confuse the DSP chain.
>>
>> Best regards,
>> Marcus
>>
>>
>> On 26.05.2016 22:00, Marc Bauduin via USRP-users wrote:
>>
>> Hi everyone,
>>
>> I work with 2 USRP N210 and with RFX2450. They are synchroized in
>> frequency with an external 10 MHz clock.
>>
>> I try to see what happen when we use them close to the saturation point
>> of their power amplifier.
>>
>> The transmitted signal is defined in fc32 with:
>> uhd::stream_args_t stream_args("fc32","sc8");
>>
>> To see what happen, I send a step signal (which is real in baseband) with
>> different level of amplitudes (from 0.3 to 1.2 with a step of 0.1) each
>> step is maintained during 1e4 samples. On the receiver side, I can observe
>> a compression when the amplitude is close to 1. This is what I expected.
>> But for the values higher than 1, I can observe, periodically, a strong
>> decay in amplitude. I observe the same thing for an amplitude of 1.1 and
>> 1.2 (this explains why the last step is longer)(blue signal in the figure).
>>
>> I suppose that it doesn't come from the power amplifier. If it was the
>> DAC, I expected to only see a clipping, and thus, a constant signal in
>> amplitude (plus a noise).
>>
>> I read that the maximum amplitude that we could use on I and Q was 1. Do
>> you know what happen when the amplitude of the input signal is higher than
>> 1 on I or Q? The DAC can deliver an amplitude higher than 1?
>>
>> I also sent this step signal with a phase of pi/4 (in red in the
>> picture). We can see that with an amplitude of 1.1 and 1.2 (thus 0.777 and
>> 0.848 on I and Q), that the amplitude of the step is reduced . In this
>> case, the DAC should give a sufficiently high amplitude. Is it possible
>> that it comes from the power amplifier? Why a so important reduction of the
>> power output in this case?
>>
>> I observe similar results with different sampling frequencies.
>>
>> Do you have an explanation for these results?
>>
>> I hope that the results are easy to read.
>>
>> Thanks in advance for your answer,
>>
>> Marc
>>
>>
>> _______________________________________________
>> USRP-users mailing 
>> listUSRP-users@lists.ettus.comhttp://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/20160527/d0a1af94/attachment-0001.html>

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

Message: 14
Date: Fri, 27 May 2016 20:01:47 +0900
From: Jeon <sjeon87+usrpus...@gmail.com>
To: USRP users mailing list <usrp-users@lists.ettus.com>
Subject: [USRP-users] Bandwidth of USRP N210's low pass filter
Message-ID:
        <cacfn7v6cda8etpzzc9hty+-raz0irspkrysryj4esternht...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Dear USRP users,

According to [this article](https://www.ruby-forum.com/topic/4416797) and
[this image](https://www.ruby-forum.com/attachment/8707/usrp_arch.png),
does the second generation USRP (e.g., N210) have a low pass filter with
bandwith of 20 MHz on a receiving chain?

If so, is it guaranteed that I can see a 20 MHz-band-limited signal through
LabView or GNU Radio?

In addition, that band-limiting value 20 MHz, can it be changed to a more
wider value, e.g., 40 or 80 MHz via software-level configuration?

Regards,
Jeon.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160527/d8456f61/attachment-0001.html>

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

Message: 15
Date: Fri, 27 May 2016 13:08:56 +0200
From: Marcus M?ller <marcus.muel...@ettus.com>
To: Marc Bauduin <baudu1m...@gmail.com>, Ian Buckley
        <i...@ionconcepts.com>
Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Work close to the saturation point of the
        power amplifier
Message-ID: <57482ac8.6070...@ettus.com>
Content-Type: text/plain; charset="utf-8"

Hi Marc,

having had another look at your plot: This is most definitely digital,
and if this really happens only for complex values with magnitudes > 1,
well, don't use those :)

I must admit that I can see why UHD doesn't ensure that on the host side
(calculate magnitude or magnitude squared is pretty CPU-intense), and I
also must admit that solving this the Buckley way :) in the FPGA was the
right thing to do for gen3 devices; now, on gen2, I think
application-side multiplication with 1/sqrt(2) will probably be the
safest way to avoid this problem, and considering the fact that you'd
end up with a value that wouldn't lead to more power output even if the
FPGA did the saturating math, you wouldn't even lose TX power.

Best regards,
Marcus

On 27.05.2016 11:26, Marc Bauduin wrote:
> Thank you for your answers. 
>
> The RFX2450 have a fixed gain. So I cannot increase the gain to
> saturate the PA.
>
> Marc
>
> 2016-05-27 0:06 GMT+02:00 Ian Buckley via USRP-users
> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>>:
>
>     Indeed, I fixed overflow problems in intermediate stages of the
>     DSP logic due to complex rotation of large amplitudes only last
>     year on newer 3 series USRP's.
>     I can't recall what the situation is with N210 off the top of my
>     head, when in doubt leave some headroom in the digital signal. 
>     Remember also that the amplitude into the PA is dependent on
>     programable analog gain values in addition to digital signal
>     amplitude, and the point of saturation varies across daughter boards.
>     In general you do not need a maximum amplitude input signal to
>     saturate the PA with a high gain value.
>     In practical terms examine the quality of your digital signal
>     first on test equipment by pairing it with a small analog gain
>     value that ensures you only will see digital signal processing
>     issues...then increase the gain to see analog imperfections.
>     -Ian
>
>
>     On Thu, May 26, 2016 at 1:26 PM, Marcus M?ller
>     <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>>
>     wrote:
>
>         Hi Marc,
>         thanks for raising this here!
>
>>         Do you know what happen when the amplitude of the input
>>         signal is higher than 1 on I or Q? The DAC can deliver an
>>         amplitude higher than 1?
>         Without FPGA-modifying hacks, you won't be able to send values
>         higher than 1 for I or Q ? that 1 is converted to the maximum
>         of your on-the-wire format (for example, to 2**15-1 for the
>         default SC16 format that the N210 uses over ethernet).
>         The float32-to-SC16 converter takes care of the saturating
>         arithmetics; and even if you directly sent the 16bit integer
>         values ? the highest value is the highest value.
>
>         So, this made me think, and here's my explanation:
>
>         Now, what might happen for complexes with |.| > 1 is that
>         arithmetic shenanigans take place in the DSP chain when it
>         processes these samples. For example, due to the digital
>         tuning capabilities in the FPGA, your pi/4 phase signal might
>         be rotated back to a 0-phase signal; somewhere in that
>         rotation, a value will occur that is higher than the maximum
>         value for I or Q, and in that moment, you might see things
>         like the numerical value "overflowing" and suddenly being
>         small instead of very big.
>
>         So, you really shouldn't send complex values with a magnitude
>         larger than 1. It will confuse the DSP chain.
>
>         Best regards,
>         Marcus
>
>
>         On 26.05.2016 22:00, Marc Bauduin via USRP-users wrote:
>>         Hi everyone,
>>
>>         I work with 2 USRP N210 and with RFX2450. They are
>>         synchroized in frequency with an external 10 MHz clock.
>>
>>         I try to see what happen when we use them close to the
>>         saturation point of their power amplifier.
>>
>>         The transmitted signal is defined in fc32 with:
>>         uhd::stream_args_t stream_args("fc32","sc8"); 
>>
>>         To see what happen, I send a step signal (which is real in
>>         baseband) with different level of amplitudes (from 0.3 to 1.2
>>         with a step of 0.1) each step is maintained during 1e4
>>         samples. On the receiver side, I can observe a compression
>>         when the amplitude is close to 1. This is what I expected.
>>         But for the values higher than 1, I can observe,
>>         periodically, a strong decay in amplitude. I observe the same
>>         thing for an amplitude of 1.1 and 1.2 (this explains why the
>>         last step is longer)(blue signal in the figure).
>>
>>         I suppose that it doesn't come from the power amplifier. If
>>         it was the DAC, I expected to only see a clipping, and thus,
>>         a constant signal in amplitude (plus a noise).
>>
>>         I read that the maximum amplitude that we could use on I and
>>         Q was 1. Do you know what happen when the amplitude of the
>>         input signal is higher than 1 on I or Q? The DAC can deliver
>>         an amplitude higher than 1?
>>
>>         I also sent this step signal with a phase of pi/4 (in red in
>>         the picture). We can see that with an amplitude of 1.1 and
>>         1.2 (thus 0.777 and 0.848 on I and Q), that the amplitude of
>>         the step is reduced . In this case, the DAC should give a
>>         sufficiently high amplitude. Is it possible that it comes
>>         from the power amplifier? Why a so important reduction of the
>>         power output in this case?
>>
>>         I observe similar results with different sampling frequencies.
>>
>>         Do you have an explanation for these results?
>>
>>         I hope that the results are easy to read.
>>
>>         Thanks in advance for your answer,
>>
>>         Marc
>>
>>
>>         _______________________________________________
>>         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
>
>
>
>     _______________________________________________
>     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
>
>

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

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

Message: 16
Date: Fri, 27 May 2016 13:30:11 +0200
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Bandwidth of USRP N210's low pass filter
Message-ID: <57482fc3.9020...@ettus.com>
Content-Type: text/plain; charset="windows-1252"

Hi Jeon:

first off: please don't cite ruby-forum.com. It's a rip-off of the GNU
Radio mailing list archive[1], made to look like and act like a forum.
The truth is, however, that answers posted on that forum don't reach the
GNU Radio mailing list, and hence will not be answered. That's why we're
trying to actively ignore that website to oblivion :)
So, your article can also be found at [2], your picture at [3], just for
future readers.

Picture [2] doesn't show an important aspect however: It neglects where
the boundary between motherboard and daughterboar is. I added a beige
background behind everything on the daughterboard so it's clearer:


So, I don't really 100% know where that picture originated from, but it
mixes USRP architecture with the implementation of a specific
daughterboard. Not all daughterboards have 20MHz I/Q filters (=40MHz
complex baseband), not all daughterboards have that
LNA/attenuator/LNA/Drive Amp architecture, it's not even that back in
2013, all daughterboards that were in heavy use and recommended for new
designs would be full duplex!

So this might really not be the picture of choice to understand how a
USRP works internally.

So:
> If so, is it guaranteed that I can see a 20 MHz-band-limited signal
through LabView or GNU Radio?

No, this depends on the daughterboard you use (and of course on the
sampling rate you request, as Nyquist dictates).

> In addition, that band-limiting value 20 MHz, can it be changed to a
more wider value,

The question whether the baseband filter is adjustable depends on the
daughterboard. However, there's no Ettus daughterboard with a 20MHz
adjustable filter in existence.

Also, you generally don't have to do that! The interpolators/decimators
in the FPGA have correct, adjustable, opaque-as-possible digital filters
that reduce your signal's bandwidth to what you ask for as sampling
rate. So, to get a 1MHz wide piece of spectrum, you just set the
sampling rate to 1MS/s. The filtering necessary to give you that
bandwidth, alias-free, is done in the FPGA automatically.

> e.g., 40 or 80 MHz via software-level configuration?

Definitely not, not even with hardware modifications. That would break
functionality.
The I and Q bandwidths sum up to be the complex baseband bandwidth; if
you used 80 MHz as filter bandwidth, you'd need to sample the I and Q
branch with 160MS/s each ? and the N210's ADC runs at 100MS/s.

Is it possible you have a specific problem you're trying to solve? Could
you explain that problem?


Best regards,
Marcus
[1] http://lists.gnu.org/archive/html/discuss-gnuradio/
[2] http://lists.gnu.org/archive/html/discuss-gnuradio/2013-09/msg00006.html
[3]
http://lists.gnu.org/archive/html/discuss-gnuradio/2013-09/pngrQSlnNrAs8.png



On 27.05.2016 13:01, Jeon via USRP-users wrote:
> Dear USRP users,
>
> According to [this article](https://www.ruby-forum.com/topic/4416797)
> and [this
> image](https://www.ruby-forum.com/attachment/8707/usrp_arch.png), does
> the second generation USRP (e.g., N210) have a low pass filter with
> bandwith of 20 MHz on a receiving chain?
>
> If so, is it guaranteed that I can see a 20 MHz-band-limited signal
> through LabView or GNU Radio?
>
> In addition, that band-limiting value 20 MHz, can it be changed to a
> more wider value, e.g., 40 or 80 MHz via software-level configuration?
>
> Regards,
> Jeon.
>
>
> _______________________________________________
> 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/20160527/4978f98f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gen2 arch.png
Type: image/png
Size: 15670 bytes
Desc: not available
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160527/4978f98f/attachment-0001.png>

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

Message: 17
Date: Fri, 27 May 2016 08:47:23 -0400
From: Philip Balister <phi...@opensdr.com>
To: Sergio Cruz Perez <serchs...@hotmail.com>,  Martin Braun
        <martin.br...@ettus.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
Message-ID: <2911dc10-be99-a6bf-98a4-bb8b99ebd...@opensdr.com>
Content-Type: text/plain; charset=windows-1252

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: 18
Date: Fri, 27 May 2016 10:59:03 -0400
From: "Collins, Richard" <richard.coll...@axenterprize.com>
To: "Swanson, Craig" <craig.swan...@gtri.gatech.edu>
Cc: Marcus M?ller <marcus.muel...@ettus.com>,   Martin Braun
        <martin.br...@ettus.com>,       Jonathon Pendlum
        <jonathon.pend...@ettus.com>,   "usrp-users@lists.ettus.com"
        <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] I am dead in the water due to the following
        error: RFNoC not found.
Message-ID:
        <CABgQ8cYrMk3r6HWoqOUc7kdRg8+BZFEW0-w=tket+e18dd0...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

I'm getting the exact same error, as follows:

[ 44%] Building CXX object lib/CMakeFiles/uhd.dir/usrp/b200/b200_impl.cpp.o
/opt/src/uhd-rfnoc/host/lib/usrp/b200/b200_impl.cpp: In constructor
?b200_impl::b200_impl(const uhd::device_addr_t&,
uhd::transport::usb_device_handle::sptr&)?:
/opt/src/uhd-rfnoc/host/lib/usrp/b200/b200_impl.cpp:624:93: error: no
matching function for call to
?uhd::usrp::ad936x_manager::loopback_self_test(radio_ctrl_core_3000::sptr&,
int, const int&)?
         _codec_mgr->loopback_self_test(perif.ctrl, TOREG(SR_CODEC_IDLE),
RB64_CODEC_READBACK);

^
In file included from
/opt/src/uhd-rfnoc/host/lib/usrp/b200/b200_impl.hpp:25:0,
                 from
/opt/src/uhd-rfnoc/host/lib/usrp/b200/b200_impl.cpp:18:
/opt/src/uhd-rfnoc/host/lib/usrp/common/ad936x_manager.hpp:82:18: note:
candidate: virtual void
uhd::usrp::ad936x_manager::loopback_self_test(boost::function<void(unsigned
int)>, boost::function<long unsigned int()>)
     virtual void loopback_self_test(
                  ^
/opt/src/uhd-rfnoc/host/lib/usrp/common/ad936x_manager.hpp:82:18: note:
candidate expects 2 arguments, 3 provided
lib/CMakeFiles/uhd.dir/build.make:4365: recipe for target
'lib/CMakeFiles/uhd.dir/usrp/b200/b200_impl.cpp.o' failed
make[2]: *** [lib/CMakeFiles/uhd.dir/usrp/b200/b200_impl.cpp.o] Error 1
CMakeFiles/Makefile2:117: recipe for target 'lib/CMakeFiles/uhd.dir/all'
failed
make[1]: *** [lib/CMakeFiles/uhd.dir/all] Error 2
Makefile:160: recipe for target 'all' failed
make: *** [all] Error 2


How I got here is by using the following commands:

(from a directory under my user's ownership and group called "src"):
$ git clone --recursive git://github.com/EttusResearch/uhd.git uhd-rfnoc
$ cd uhd-rfnoc
$ git checkout -b rfnoc-radio-redo -t origin/rfnoc-radio-redo
$ cmake -DCMAKE_INSTALL_PREFIX=/opt/uhd-rfnoc/ -DENABLE_X300=ON
-DENABLE_E300=ON -DLIB_SUFFIX=64 -Wno-dev ../

Note, I already created and chown'd and chgrp'd folder, /opt/uhd-rfnoc/,
and made a file (which I plan to "source" before attempting to run gnuradio
once installed) that consists of the following text:
BASE=/opt/gnuradio-rfnoc
export PATH=${PATH}:${BASE}/bin
export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:${BASE}/lib64
export PKG_CONFIG_PATH=${PKG_CONFIG_PATH}:${BASE}/lib64/pkgconfig
export PYTHONPATH=${PYTHONPATH}:${BASE}/lib64/python2.7/site-packages/

Should I be running cmake with a flag of -DENABLE_B200=OFF ?
Or should I not have git-clone'd recursively?

(I don't have a B200 or B210, so I'll try it with DENABLE_B200=OFF)


 - Richard


On Sun, May 8, 2016 at 8:09 PM, Swanson, Craig via USRP-users <
usrp-users@lists.ettus.com> wrote:

> ?Marcus,
>
> I just upgraded my image to e3xx-release-4 on my E310.
>
> Craig
>
>
> *Craig F. Swanson*
>
> *Research Engineer II *
> *Information and Communications Laboratory*
> *Communications, Systems, and Spectrum Division*
> *Georgia Tech Research Institute*
>
>
> *Room 560 250 14th St NW *
> *Atlanta, GA 30318*
> *Cell: 770.298.9156 <770.298.9156>*
> http://www.gtri.gatech.edu
> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
>
> ------------------------------
> *From:* Marcus M?ller <marcus.muel...@ettus.com>
> *Sent:* Saturday, May 7, 2016 2:33 PM
> *To:* Swanson, Craig; Martin Braun; Jonathon Pendlum
> *Cc:* usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] I am dead in the water due to the following
> error: RFNoC not found.
>
> You're welcome! Hope this works out.
>
> If you're aiming for using RFNoC on your E310 (which I just realized might
> be the case, looking at your -DENABLE_E300), you not only need any version
> of UHD that supports RFNoC ? you need the version (and, most importantly,
> since I guess you might be building your own FPGA images sooner or later,
> the right FPGA source code) that runs on the E310.
>
> What image are you running on the E310?
>
> Best regards,
> Marcus
>
> On 07.05.2016 20:30, Swanson, Craig wrote:
>
> Marcus,
>
> Thanks for the quick reply.
>
> Craig
>
>
>
> *Craig F. Swanson*
>
> *Research Engineer II *
> *Information and Communications Laboratory*
> *Communications, Systems, and Spectrum Division*
> *Georgia Tech Research Institute*
>
>
> *Room 560 250 14th St NW *
> *Atlanta, GA 30318*
> *Cell: 770.298.9156 <770.298.9156>*
>
> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
> http://www.gtri.gatech.edu
>
> ------------------------------
> *From:* Marcus M?ller <marcus.muel...@ettus.com>
> <marcus.muel...@ettus.com>
> *Sent:* Saturday, May 7, 2016 2:23 PM
> *To:* Swanson, Craig; Martin Braun; Jonathon Pendlum
> *Cc:* usrp-users@lists.ettus.com; Myers, David
> *Subject:* Re: [USRP-users] I am dead in the water due to the following
> error: RFNoC not found.
>
> Hi Craig,
>
> this won't work because you're (implicitly) checking out the "master"
> branch of UHD - which isn't RFNoC'ed.
>
> So, I recommend modifying your script:
>
> instead of
>
> git clone https://github.com/EttusResearch/uhd
>
> use
>
> git clone -b rfnoc-devel https://github.com/EttusResearch/uhd
> git submodule update --init ##fill the fpga-src directory with the
> matching FPGA code
>
> . Of course, if you've still got the downloaded files around, you can
> check out the right branch right now
>
> cd ~/uhd/host/build
> sudo make uninstall
> rm -r * ##cleans the build directory
> git checkout -t rfnoc-devel ## checks out the RFNoC version of UHD
> git submodule update --init ##fill the fpga-src directory with the
> matching FPGA code
> cmake -DENABLE_E300=ON ../
> make -j8 && sudo make install && sudo ldconfig
>
> cd ~/gnuradio/build
> cmake ..
> make -j8 && sudo make install && sudo ldconfig
>
> and then try building gr-ettus again.
>
> Best regards,
> Marcus
> On 07.05.2016 20:11, Swanson, Craig via USRP-users wrote:
>
> Martin,
>
> When I perform a cmake ../ in gr-ettus, I get the following error:
> CMake Error at CMakeLists.txt:113 (message):
>   RFNoC not found.
>
> Here are more details of the error:
> craig@craig-VirtualBox:~/gr-ettus/build (master)$ cmake ../
> -- The CXX compiler identification is GNU 4.8.4
> -- The C compiler identification is GNU 4.8.4
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Build type not specified: defaulting to release.
> -- Boost version: 1.54.0
> -- Found the following Boost libraries:
> --   filesystem
> --   system
> -- Found PkgConfig: /usr/bin/pkg-config (found version "0.26")
> -- Found UHD: /usr/local/lib/libuhd.so
> CMake Error at CMakeLists.txt:113 (message):
>   RFNoC not found.
>
> Here is the script I am using:
>
> git clone https://github.com/EttusResearch/uhd
> mkdir ~/uhd/host/build
> cd ~/uhd/host/build
> cmake ../ -DENABLE_E300=ON ../
> make -j8
> sudo make install -j8
> sudo ldconfig
>
> git clone --recursive <http://git.gnuradio.org/git/gnuradio.git>
> http://git.gnuradio.org/git/gnuradio.git
> mkdir ~/gnuradio/build
> cd ~/gnuradio/build
> cmake ../
> make -j8
> sudo make install -j8
> sudo ldconfig
>
> git clone https://github.com/EttusResearch/gr-ettus.git?
> <https://github.com/EttusResearch/gr-ettus.git%E2%80%8B>
> mkdir ~/gr-ettus/build
> cd ~/gr-ettus/build
> cmake ../
> make -j8
> sudo make install -j8
> sudo ldconfig
>
>
>
> Craig
>
>
> *Craig F. Swanson*
>
> *Research Engineer II *
> *Information and Communications Laboratory*
> *Communications, Systems, and Spectrum Division*
> *Georgia Tech Research Institute*
>
>
> *Room 560 250 14th St NW *
> *Atlanta, GA 30318*
> *Cell: 770.298.9156 <770.298.9156>*
> <http://www.gtri.gatech.edu>http://www.gtri.gatech.edu
>
>
>
> _______________________________________________
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://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/20160527/f0418469/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 69, Issue 27
******************************************