Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Help diagnosing loss of USB 3.0 on B200 (Ryan Bosley)
2. Re: Help diagnosing loss of USB 3.0 on B200 (Marcus D. Leech)
3. Re: Help diagnosing loss of USB 3.0 on B200 (Ian Buckley)
4. Re: Help diagnosing loss of USB 3.0 on B200 (Ryan Bosley)
5. Re: Creating custom image ends mostly in timing problems
inside ettus blocks (X310) (Jonathon Pendlum)
6. Re: Error using RFNoC OFDM Sync block on E310 (Sergio Cruz Perez)
7. Unable to get Vivado Hardware Manager to recognize the
Chipscope ILA cores in the Ettus x310 (Swanson, Craig)
8. Re: Unable to get Vivado Hardware Manager to recognize the
Chipscope ILA cores in the Ettus x310 (Jonathon Pendlum)
9. Re: Unable to get Vivado Hardware Manager to recognize the
Chipscope ILA cores in the Ettus x310 (Swanson, Craig)
10. Re: build environment (Derek Kozel)
11. Re: Changing center frequency automatically (Derek Kozel)
----------------------------------------------------------------------
Message: 1
Date: Sun, 29 May 2016 20:30:28 -0400
From: Ryan Bosley <[email protected]>
To: [email protected]
Subject: [USRP-users] Help diagnosing loss of USB 3.0 on B200
Message-ID:
<CANBLnD8TXxJ_v_=8i4YX=t=dz6dfde07k+brwwqra-yhm4n...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Until very recently I had very little trouble getting USB 3 connectivity to
my B200.
Really nothing has changed.... Same computer, no upgrades to Ubuntu or
GnuRadio.
Then this weekend, I've started having issues where I can only connect with
USB 2.
I've tried several different USB 3 cables which doesn't seem to help.
I've even tried different computers that seem to have worked in the past
with no luck.
In a couple cases where the cable had a 1/2 twist (putting a bit of extra
downward pressure on the B200 side of the connector) between the computer
and B200, I was able to get USB 3 to work for a little while. However, it
is not repeatable.. and the USB 3 connector on the B200 board is pretty
solid (no wiggle).
I've ohmed out the connections in the cable (from the side of the cable
that plugs into the PC to the pins on the B200 board) and all the contacts
"appear" to be ok.
So, I'm wondering has anyone else has experienced this issue?
Does this sound like a lose USB connector? Bad Cable? Something awry with
the FX3 chip?
Any suggestions on next steps in diagnosis are appreciated,
Ryan (N4ONS)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160529/d9610748/attachment-0001.html>
------------------------------
Message: 2
Date: Sun, 29 May 2016 20:42:39 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Help diagnosing loss of USB 3.0 on B200
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 05/29/2016 08:30 PM, Ryan Bosley via USRP-users wrote:
> Until very recently I had very little trouble getting USB 3
> connectivity to my B200.
> Really nothing has changed.... Same computer, no upgrades to Ubuntu or
> GnuRadio.
> Then this weekend, I've started having issues where I can only connect
> with USB 2.
>
> I've tried several different USB 3 cables which doesn't seem to help.
> I've even tried different computers that seem to have worked in the
> past with no luck.
>
> In a couple cases where the cable had a 1/2 twist (putting a bit of
> extra downward pressure on the B200 side of the connector) between
> the computer and B200, I was able to get USB 3 to work for a little
> while. However, it is not repeatable.. and the USB 3 connector on the
> B200 board is pretty solid (no wiggle).
>
> I've ohmed out the connections in the cable (from the side of the
> cable that plugs into the PC to the pins on the B200 board) and all
> the contacts "appear" to be ok.
>
> So, I'm wondering has anyone else has experienced this issue?
> Does this sound like a lose USB connector? Bad Cable? Something awry
> with the FX3 chip?
>
> Any suggestions on next steps in diagnosis are appreciated,
> Ryan (N4ONS)
>
I would inspect the board for cold solder connections or cracked traces.
------------------------------
Message: 3
Date: Sun, 29 May 2016 18:15:24 -0700
From: Ian Buckley <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Help diagnosing loss of USB 3.0 on B200
Message-ID:
<cam_0ochrwf0oy2fkyjktdtakuxn9ymjvi0roumuo4gkkulv...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
To add to Marcus's comment...USB3 SS being 5Gbps is super fussy about
signal integrity, damage/wear on a scale thats not easy to see could cause
it to fall back to USB2 rates. Is this an older board with a micro
connector or one of the newer ones with the nice meaty full size connector?
If you know someone esle with a B2x0 that might be your quickest sanity
test to eliminate your USRP as the issue, the multimeter might not cut it.
On Sun, May 29, 2016 at 5:42 PM, Marcus D. Leech via USRP-users <
[email protected]> wrote:
> On 05/29/2016 08:30 PM, Ryan Bosley via USRP-users wrote:
>
>> Until very recently I had very little trouble getting USB 3 connectivity
>> to my B200.
>> Really nothing has changed.... Same computer, no upgrades to Ubuntu or
>> GnuRadio.
>> Then this weekend, I've started having issues where I can only connect
>> with USB 2.
>>
>> I've tried several different USB 3 cables which doesn't seem to help.
>> I've even tried different computers that seem to have worked in the past
>> with no luck.
>>
>> In a couple cases where the cable had a 1/2 twist (putting a bit of extra
>> downward pressure on the B200 side of the connector) between the computer
>> and B200, I was able to get USB 3 to work for a little while. However, it
>> is not repeatable.. and the USB 3 connector on the B200 board is pretty
>> solid (no wiggle).
>>
>> I've ohmed out the connections in the cable (from the side of the cable
>> that plugs into the PC to the pins on the B200 board) and all the contacts
>> "appear" to be ok.
>>
>> So, I'm wondering has anyone else has experienced this issue?
>> Does this sound like a lose USB connector? Bad Cable? Something awry
>> with the FX3 chip?
>>
>> Any suggestions on next steps in diagnosis are appreciated,
>> Ryan (N4ONS)
>>
>>
> I would inspect the board for cold solder connections or cracked traces.
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160529/9068446a/attachment-0001.html>
------------------------------
Message: 4
Date: Sun, 29 May 2016 22:37:18 -0400
From: Ryan Bosley <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Help diagnosing loss of USB 3.0 on B200
Message-ID:
<canblnd-y8lwpzyve4hvj+ewdfzvkdtp1fjt6bp7mtwg6wyk...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks for the suggestions. It is a micro connector on one of the first
version of b200 (white board)
I'll see if I can find someone with a B200 and take a close look at the
board under a microscope next chance I get.
I was thinking the small blade contacts inside B200 connector might be
wearing... I guess worst case, a replacement USB connector wouldn't be too
hard. I'm well outside the warranty at this point.... so it's probably
cheaper/quicker to place an order to Digikey and fire up the soldering iron.
On Sun, May 29, 2016 at 9:15 PM, Ian Buckley via USRP-users <
[email protected]> wrote:
> To add to Marcus's comment...USB3 SS being 5Gbps is super fussy about
> signal integrity, damage/wear on a scale thats not easy to see could cause
> it to fall back to USB2 rates. Is this an older board with a micro
> connector or one of the newer ones with the nice meaty full size connector?
> If you know someone esle with a B2x0 that might be your quickest sanity
> test to eliminate your USRP as the issue, the multimeter might not cut it.
>
> On Sun, May 29, 2016 at 5:42 PM, Marcus D. Leech via USRP-users <
> [email protected]> wrote:
>
>> On 05/29/2016 08:30 PM, Ryan Bosley via USRP-users wrote:
>>
>>> Until very recently I had very little trouble getting USB 3 connectivity
>>> to my B200.
>>> Really nothing has changed.... Same computer, no upgrades to Ubuntu or
>>> GnuRadio.
>>> Then this weekend, I've started having issues where I can only connect
>>> with USB 2.
>>>
>>> I've tried several different USB 3 cables which doesn't seem to help.
>>> I've even tried different computers that seem to have worked in the past
>>> with no luck.
>>>
>>> In a couple cases where the cable had a 1/2 twist (putting a bit of
>>> extra downward pressure on the B200 side of the connector) between the
>>> computer and B200, I was able to get USB 3 to work for a little while.
>>> However, it is not repeatable.. and the USB 3 connector on the B200 board
>>> is pretty solid (no wiggle).
>>>
>>> I've ohmed out the connections in the cable (from the side of the cable
>>> that plugs into the PC to the pins on the B200 board) and all the contacts
>>> "appear" to be ok.
>>>
>>> So, I'm wondering has anyone else has experienced this issue?
>>> Does this sound like a lose USB connector? Bad Cable? Something awry
>>> with the FX3 chip?
>>>
>>> Any suggestions on next steps in diagnosis are appreciated,
>>> Ryan (N4ONS)
>>>
>>>
>> I would inspect the board for cold solder connections or cracked traces.
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160529/f9378471/attachment-0001.html>
------------------------------
Message: 5
Date: Sun, 29 May 2016 21:46:05 -0500
From: Jonathon Pendlum <[email protected]>
To: Patrick Berger <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Creating custom image ends mostly in timing
problems inside ettus blocks (X310)
Message-ID:
<CAGdo0uQYp0a5L9PtmRGxBC=sukffnvfy+etgagyrvw1xuyx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Patrick,
What device are targeting? What clock rate did you use for timing? Are you
working off master or maint? How and where is your design inserted in the
radio.v processing chain?
Jonathon
On Thu, May 26, 2016 at 3:02 PM, Patrick Berger via USRP-users <
[email protected]> wrote:
> 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
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160529/17413b16/attachment-0001.html>
------------------------------
Message: 6
Date: Sun, 29 May 2016 22:17:18 -0500
From: Sergio Cruz Perez <[email protected]>
To: Philip Balister <[email protected]>, Martin Braun
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Thanks Philip. I mounted the build machine filesystem onto the E310 and then I
run the gdb tool again in this way:
gdb /usr/local/python core -d ~/PC where ~/PC is the mounted file
system
I attached the backtrace output.
Thanks
Sergio
> Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
> To: [email protected]; [email protected]
> CC: [email protected]
> From: [email protected]
> Date: Fri, 27 May 2016 08:47:23 -0400
>
> On 05/26/2016 09:40 PM, Sergio Cruz Perez via USRP-users wrote:
> > Martin,
> > Thanks for your help. I'm new in debugging tools like that. I attached the
> > backtrace output. What I noticed is that the path in which the application
> > is looking for the io_signature.cc file is
> > /home/sheko/E310_SW/gnuradio/gnuradio, that is a path on my PC not on the
> > E310. The way I've been working with gnuradio is that I generate the .py
> > file on my PC and then I copy that file to the E310. That was working in
> > other applications.
> > Sergio
>
> I skimmed things quickly, the path you refer to is the path to the
> source file. gdb is looking for that for some line info and can't find
> it on the device. This isn't the actual problem. If you want to have gsb
> find the file, you can use sshfs to mount the build machine onto the
> e310 file system. Be careful how you do this to make the paths just work.
>
> Philip
>
>
> >
> >
> >
> >
> >> Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
> >> To: [email protected]
> >> CC: [email protected]
> >> From: [email protected]
> >> 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: [email protected]
> >>>> Date: Mon, 23 May 2016 10:06:38 -0700
> >>>> Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
> >>>> From: [email protected]
> >>>>
> >>>> 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: [email protected]
> >>>>> Date: Thu, 31 Mar 2016 18:37:34 -0600
> >>>>> Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
> >>>>> From: [email protected]
> >>>>> CC: [email protected]
> >>>>>
> >>>>> 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: [email protected]
> >>>>> Date: Thu, 31 Mar 2016 17:19:13 -0700
> >>>>> Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
> >>>>> To: [email protected]
> >>>>> CC: [email protected]
> >>>>>
> >>>>> 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
> >>>>> <[email protected] <mailto:[email protected]>> 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: [email protected] <mailto:[email protected]>
> >>>>> Date: Wed, 30 Mar 2016 13:34:45 -0700
> >>>>>
> >>>>> Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
> >>>>> To: [email protected] <mailto:[email protected]>
> >>>>> CC: [email protected] <mailto:[email protected]>
> >>>>>
> >>>>> 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
> >>>>> <[email protected] <mailto:[email protected]>> 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: [email protected] <mailto:[email protected]>
> >>>>> Date: Mon, 28 Mar 2016 09:53:09 -0700
> >>>>>
> >>>>> Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block on E310
> >>>>> To: [email protected] <mailto:[email protected]>
> >>>>> CC: [email protected] <mailto:[email protected]>
> >>>>>
> >>>>> 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
> >>>>> <[email protected] <mailto:[email protected]>> wrote:
> >>>>>
> >>>>> Hi Jonathon,
> >>>>>
> >>>>> I'm using commit b7546712aa0091f87b793ef4c4a9e9c084467173
> >>>>>
> >>>>> Thanks
> >>>>>
> >>>>> Sergio
> >>>>>
> >>>>> ------------------------------------------------------------------------
> >>>>> From: [email protected]
> >>>>> <mailto:[email protected]>
> >>>>> Date: Wed, 23 Mar 2016 20:12:59 -0700
> >>>>>
> >>>>> Subject: Re: [USRP-users] Error using RFNoC OFDM Sync block
> >>>>> on E310
> >>>>> To: [email protected] <mailto:[email protected]>
> >>>>> CC: [email protected]
> >>>>> <mailto:[email protected]>
> >>>>>
> >>>>> 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
> >>>>> <[email protected] <mailto:[email protected]>> 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: [email protected]
> >>>>> <mailto:[email protected]>
> >>>>> Date: Tue, 22 Mar 2016 15:17:40 -0700
> >>>>> Subject: Re: [USRP-users] Error using RFNoC OFDM Sync
> >>>>> block on E310
> >>>>> To: [email protected] <mailto:[email protected]>
> >>>>> CC: [email protected]
> >>>>> <mailto:[email protected]>
> >>>>>
> >>>>> 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
> >>>>> <[email protected] <mailto:[email protected]>>
> >>>>> 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: [email protected]
> >>>>> <mailto:[email protected]>
> >>>>> Date: Tue, 22 Mar 2016 14:23:28 -0700
> >>>>>
> >>>>> Subject: Re: [USRP-users] Error using RFNoC OFDM
> >>>>> Sync block on E310
> >>>>> To: [email protected] <mailto:[email protected]>
> >>>>> CC: [email protected]
> >>>>> <mailto:[email protected]>
> >>>>>
> >>>>> 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
> >>>>> <[email protected]
> >>>>> <mailto:[email protected]>> 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: [email protected]
> >>>>> <mailto:[email protected]>
> >>>>> Date: Wed, 9 Mar 2016 13:05:58 -0800
> >>>>>
> >>>>> Subject: Re: [USRP-users] Error using RFNoC OFDM
> >>>>> Sync block on E310
> >>>>> To: [email protected]
> >>>>> <mailto:[email protected]>
> >>>>> CC: [email protected]
> >>>>> <mailto:[email protected]>
> >>>>>
> >>>>> 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 <[email protected]
> >>>>> <mailto:[email protected]>> 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: [email protected]
> >>>>> <mailto:[email protected]>
> >>>>> Date: Tue, 8 Mar 2016 16:51:20 -0800
> >>>>> Subject: Re: [USRP-users] Error using RFNoC
> >>>>> OFDM Sync block on E310
> >>>>> To: [email protected]
> >>>>> <mailto:[email protected]>
> >>>>> CC: [email protected]
> >>>>> <mailto:[email protected]>
> >>>>>
> >>>>>
> >>>>> 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
> >>>>> <[email protected]
> >>>>> <mailto:[email protected]>> 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
> >>>>> [email protected]
> >>>>> <mailto:[email protected]>
> >>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________ USRP-users mailing list
> >>>>> [email protected]
> >>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> USRP-users mailing list
> >>>>> [email protected]
> >>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> USRP-users mailing list
> >>>> [email protected]
> >>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>
> >
> >
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected]
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160529/09658b59/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: schmidl_backtrace_2.txt
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160529/09658b59/attachment-0001.txt>
------------------------------
Message: 7
Date: Mon, 30 May 2016 04:39:33 +0000
From: "Swanson, Craig" <[email protected]>
To: Jonathon Pendlum <[email protected]>, Martin Braun
<[email protected]>, Marcus M?ller
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: [USRP-users] Unable to get Vivado Hardware Manager to
recognize the Chipscope ILA cores in the Ettus x310
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Jonathon,
Is there anything I might be doing wrong to get Chipscope to open?
1. ?I created two ILA debug cores during synthesis
2. Created a new .bit file and used uhd_image_loader to put the new x300.bit
in the x310.
3. Powered off and on the x310.
4. Connected the USB JTAG cable to the x310
5. Opened up a new target in the Hardware manager and it sees the Digilent
xc7k410t_0 but says there are no debug cores.
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160530/fdc72394/attachment-0001.html>
------------------------------
Message: 8
Date: Mon, 30 May 2016 00:27:57 -0500
From: Jonathon Pendlum <[email protected]>
To: "Swanson, Craig" <[email protected]>
Cc: Martin Braun <[email protected]>, Marcus M?ller
<[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] Unable to get Vivado Hardware Manager to
recognize the Chipscope ILA cores in the Ettus x310
Message-ID:
<cagdo0uqnrh9r9x3wrjxg0fftvfb-vqro0coy-g6zz+shvj2...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Craig,
Are your cores using radio_clk? If so, you need to run uhd_usrp_probe to
initialize radio_clk.
Jonathon
On Sun, May 29, 2016 at 11:39 PM, Swanson, Craig <
[email protected]> wrote:
> Jonathon,
>
> Is there anything I might be doing wrong to get Chipscope to open?
>
> 1. ?I created two ILA debug cores during synthesis
> 2. Created a new .bit file and used uhd_image_loader to put the new
> x300.bit in the x310.
> 3. Powered off and on the x310.
> 4. Connected the USB JTAG cable to the x310
> 5. Opened up a new target in the Hardware manager and it sees the
> Digilent xc7k410t_0 but says there are no debug cores.
>
> Craig
>
>
>
> *Craig F. Swanson*
>
> *Research Engineer II *
> *Information and Communications Laboratory*
> *Communications, Systems, and Spectrum Division*
> *Georgia Tech Research Institute*
>
>
> *Room 560 250 14th St NW *
> *Atlanta, GA 30318*
> *Cell: 770.298.9156 <770.298.9156>*
> http://www.gtri.gatech.edu
> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160530/ea19c3f7/attachment-0001.html>
------------------------------
Message: 9
Date: Mon, 30 May 2016 05:59:49 +0000
From: "Swanson, Craig" <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: Martin Braun <[email protected]>, Marcus M?ller
<[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] Unable to get Vivado Hardware Manager to
recognize the Chipscope ILA cores in the Ettus x310
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Jonathon,
Thank you for your speedy reply.
1. ??According to the directions you sent me a while ago, I ran in GUI mode
such as "make GUI=1 X310_RFNOC_HGS"
2. I interrupted Vivado and created the debug cores in the synthesis step,
using your example in noc_block_moving_avg. (* dont_touch = "true", mark_debug
= "true" *)
3. I continued on with Vivado creating a bit file x300.bit
4. I used the uhd_image_loader with the x300.bit file.
5. When I ran "uhd_usrp_probe --init-only, I got a really weird result which
is telling me something is not right about the x300.bit file. Error:
RuntimeError: self_cal_adc_capture_delay: Self calibration failed. Convergence
error.?
6. I am going to run "make X310_RFNOC_HGS" and hope that the timing.xdc file
will now automatically find my ILA_0 (signals triggering off of bus_clk) and
ILA_1 (signals triggering off of ce_clk). I am expecting it to produce a
usrp_x310_rfnoc_fpga_HGS.bit file.
7. I am not sure what you mean by the radio_clk. In noc_block_moving_avg I
am guessing the radio_clk you are referring to is the ce_clk.
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
________________________________
From: Jonathon Pendlum <[email protected]>
Sent: Monday, May 30, 2016 1:27 AM
To: Swanson, Craig
Cc: Martin Braun; Marcus M?ller; [email protected]
Subject: Re: Unable to get Vivado Hardware Manager to recognize the Chipscope
ILA cores in the Ettus x310
Craig,
Are your cores using radio_clk? If so, you need to run uhd_usrp_probe to
initialize radio_clk.
Jonathon
On Sun, May 29, 2016 at 11:39 PM, Swanson, Craig
<[email protected]<mailto:[email protected]>> wrote:
Jonathon,
Is there anything I might be doing wrong to get Chipscope to open?
1. ?I created two ILA debug cores during synthesis
2. Created a new .bit file and used uhd_image_loader to put the new x300.bit
in the x310.
3. Powered off and on the x310.
4. Connected the USB JTAG cable to the x310
5. Opened up a new target in the Hardware manager and it sees the Digilent
xc7k410t_0 but says there are no debug cores.
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156<tel:770.298.9156>
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160530/f365f1a6/attachment-0001.html>
------------------------------
Message: 10
Date: Mon, 30 May 2016 00:53:28 -0700
From: Derek Kozel <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] build environment
Message-ID:
<CAA+K=tvwBg7=ysosvvix7f3cddr8qelcfyuic9tjjgqg7f1...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Mark,
While I won't disagree with Marcus that development on Linux is both more
common and easier in general, we do support Windows 7+ with Visual Studio
2012+. One of our knowledge base articles covers building UHD from source.
https://kb.ettus.com/Building_and_Installing_the_USRP_Open_Source_Toolchain_%28UHD_and_GNU_Radio%29_on_Windows
In addition, there is an upcoming article on authoring and compiling C++
programs using UHD on Windows.
When the choice is available though, a modern Linux distribution (generally
Ubuntu 14.04 or 16.04) is the simplest environment. I use the CLion IDE on
Ubuntu 16.04 as my development environment for both UHD and GNU Radio.
Others use Eclipse and many of us use Vim as the main or secondary editor.
Regards,
Derek
On Sat, May 28, 2016 at 2:19 PM, Marcus M?ller <[email protected]>
wrote:
> Hi Mark,
>
> so, the Ettus folks are mostly Linux and OS X. I think the same goes for
> the majority of the GNU Radio community? there's now a great effort to make
> GR work well again under Windows, but I think we can still call that work
> in progress.
>
> When it comes to Linux, I think it's a happy mixture of Ubuntu, Fedora,
> Arch (probably?), CentOS/RedHat.
>
> Now, freshly, Ubuntu 16.04 + pybombs works pretty neatly nowadays to give
> you a flexible from-source installation of the libraries, tools, and
> specific GNU Radio out-of-tree modules (i.e. GNU Radio blocks and GNU Radio
> applications that are not part of the main GNU Radio source). So that's
> what I'd really recommend to give you fresh install. The beauty of pybombs
> is that you can have as many installation prefixes as you want ? say you
> want to try something that might horribly break your bleeding edge GNU
> Radio half of the day, then do some work with a specific version of UHD,
> GNU Radio and other half ? and lets you just select what you need flexibly.
>
> Myself, I'm using Fedora, just out of preference for its system management
> tools. Pybombs works on that as well.
>
> So much for what I'd recommend in platforms.
>
> Regarding getting stuff done fast: Well... you're a DSP person, so you'll
> possibly agree it's about finding the right balance between math (because,
> well, if you can't describe your signals and systems, you might not get as
> far), system design (the classical "let's assume these receivers are all
> synchronized" vs real world as well as things like knowing when you want to
> decimate), and some accumulation of experience by just trying, especially
> when the latter can be pretty quick.
>
> That's why, though many GNU Radio and UHD users don't like overly
> graphical tools to do their development, often a very GNU Radio
> Companion-centric approach is a good idea, not only because it's quick, but
> mostly because it's self-documenting, the generated source code is still
> readable (and runs without any speed degradation) and it's easy to document
> and communicate (and, having a shoddy memory myself, easy to re-understand)
> what you did just this morning if you actually have a flow graph that looks
> like a directed graph.
>
> You're not alone with your problem of "OK, I've got a USRP, and some
> software frameworks, but what now?"; but especially for those who haven't
> been doing SDR for a long time, the realization that just connecting a USRP
> source to a Qt GUI Waterfall sink does something *useful* is a nice
> thing, and they get to develop their SDR applications relatively rapidly,
> as they have instant access to a relatively nice library of blocks ?
> whether you want an FFT of arbitrary size, a single interpolating low pass
> FIR, or a whole decimating polyphase filterbank. There's timing recovery
> and equalizers, Schmitt triggers and whatnot.
>
> So: starting with the GNU Radio companion is definitely a thing worth
> doing. You can definitely go pretty far with it, and its ability to
> structure things (by putting "subgraphs" into hierarchical blocks, for
> example) doesn't even imply that the complexity of your system will become
> at one point de facto impossible to handle.
>
> If your demands for a specific block outgrow what can be done by combining
> the functionality provided, but you know the DSP behind what you want to
> do, it's actually not that hard to write your own GNU Radio block in C++ or
> Python. As a matter of fact, GNU Radio has a "daughter project", the VOLK
> (Vector-Optimized Library of Kernels) project, which just contains just C
> (and occasionally, a bit of different machine-specific
> assembler/intrinsics) implementations of typical DSP basics ? think of the
> dot product, magnitude squared, trigonometrics, endianness swaps,
> interleavers, those kinds of things, so pretty often you start of by
> writing a GNU Radio block and then figure out that you just need to
> pair-wise multiply a series of complexes, and just go and use the
> appropriate VOLK kernel, and get an instant speedup of up to "pretty much",
> depending on what hardware you're running on.
>
> So: Really, get your hands dirty. A Ubuntu installation should not take
> long, and getting, and using pybombs, to get a running GNU Radio
> experimental setup should also be a matter of minutes (on a fast
> workstation, considering that by default, GNU Radio and UHD are built from
> source, and the rest as far as possible is installed from your Ubuntu's
> package repositories automatically). The Guided Tutorials might not be
> overly demanding from you in terms of DSP, but they are a pretty quick way
> to get started.
>
> Have fun,
>
> Marcus
>
>
>
>
> On 28.05.2016 16:57, Mark Napier via USRP-users wrote:
>
> Hello,
>
> I'm an experienced DSP/ASIC guy but a newbie to gnuradio. I've had a
> USRP1 for years now but anytime I've wanted to do anything real with it
> I've be stymied by software stack.
>
> So now I'm working at a company where we are digging into SDR and I have
> my hands on a lot of Ettus hardware. The software stack is still a
> problem. On my own I've tried to get a working build environment up on my
> macbook pro and have given up on that for now. My current effort is trying
> to use pybombs to get a VMWare image of Ubuntu 16.04 working and the guys
> at Ettus have been helping me. At work we are trying to do something
> similar with Windows 10.
>
> Well after all this I have a more basic question for the experienced
> developers here. What is your recipe? What OS (version specific), what
> exact tools, how do you get your build environment up and running quickly
> so that you can do something useful?
>
> Thanks in advance,
>
> Mark Napier
>
>
>
> _______________________________________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160530/9b28ad36/attachment-0001.html>
------------------------------
Message: 11
Date: Mon, 30 May 2016 00:56:32 -0700
From: Derek Kozel <[email protected]>
To: Haile Berhe <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Changing center frequency automatically
Message-ID:
<CAA+K=tsngjcnjgcyzdwdgfwb9xhakt+gknxqi0ivhcj8kr6...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Haile,
Those frequencies are too far apart to transmit simultaneously on a single
N200. You could synchronize three N200s and have one on each of the carrier
frequencies. If you do not need to transmit at all three frequencies at
exactly the same time, but instead hop between then then that may be
possible with a single N200.
Can you describe more about your application?
Regards,
Derek
On Sat, May 28, 2016 at 6:11 AM, Haile Berhe via USRP-users <
[email protected]> wrote:
> Hello,
> I have been making researches using USRP and GNU radio for a couple of
> months now. Today, I have a reached a point where I have no clue how to do
> it. I want to change the center frequency of USRP N200 and so that I can
> transmit in multiple frequencies simultaneously. There are some suggestions
> from some USRP users on the net but none of them happen to be helpful.
> Here is the problem in short:
> I want to transmit some a signal in the frequency ranges of 200MHz, 500MHz
> and 1.3GHz for certain purpose. I could not sum all these frequencies
> (using ADD block) and transmit them on a single center frequency as they
> are far away from each other. Any suggestions, please?
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160530/2ea9d668/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 69, Issue 30
******************************************
