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: change the master clock rate on X310 (Michael West)
   2. Re: Setting up RFNOC development environment & running
      gr-ettus/rfnoc examples (Eddie Fung)
   3. Re: Understanding Data Packet Protocol in FPGA (Derek Kozel)
   4. Re: Setting up RFNOC development environment & running
      gr-ettus/rfnoc examples (Jonathon Pendlum)
   5. Can not get data from rfnoc block (john liu)
   6. Difference between timestamps (Vladica Sark)
   7. Re: AD9361 medium access method (Brais Ares)
   8. Re: Can not get data from rfnoc block (Nicolas Cuervo)
   9. B210 C-API dual channel (?????? 1)
  10. Accessing FPGA image in Vivado (Philipp Rudnik)
  11. Re: B210 C-API dual channel (mle...@ripnet.com)
  12. Re: Accessing FPGA image in Vivado (Marcus M?ller)
  13. Re: Accessing FPGA image in Vivado (Marcus M?ller)


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

Message: 1
Date: Wed, 30 Nov 2016 12:41:52 -0800
From: Michael West <michael.w...@ettus.com>
To: Paolo Palana <p.pal...@itsystems.it>
Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] change the master clock rate on X310
Message-ID:
        <CAM4xKrprBxxmH7njkJDc9KN=peuw-ioqsjyqmrvfcuxhn8n...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi Paolo,

The issue is the ADC.  To operate under 80 MHz, it needs to be put in low
speed mode.  See the datasheet for the ADS62P48 here:
http://www.ti.com/lit/ds/symlink/ads62p48.pdf

Regards,
Michael

On Wed, Nov 30, 2016 at 2:57 AM, Paolo Palana via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Good morning to all the mailing list.
>
> In two projects of mine I need in one case a 128 Mhz sample rate, why in
> the other 64Mhz (decimation is not an option in this stage).
> As far as I can understand looking at the schematics and looking through
> the code,
> the ADC clocks (I'm not interest in DACs) are provided from the output 8
> and 9 of the lmk04816 chip.
> The setup of this component is performed in the x300_clock_ctrl.cpp file.
>
> I was able, reading x300_clock_ctrl.cpp and the lmk04816 datasheet,  to
> obtain the 128 Mhz I desired.
> I tested it and it works. With this setup the variable master_clock_div
> is 20.
>
> Now I thought "Well I need 64Mhz? Just set the master_clock_div to 40".
> I made my calculations and on the paper... that is so.
> The problem is that with master_clock_div=40 I got the following error:
>
> Error: RuntimeError: ADC Calibration Clock in FPGA failed to lock to
> internal source.
>
> Reading again the lmk04816 datasheet I discovered a difference within
> the two divide values. Namely the former (master_clock_div=20) cause the
> chip
> to operate in normal mode, while the latter (master_clock_div=40) cause
> the chip to operate in extended mode. As far as I can understand the
> extended mode require some "precaution" during the setup and I think
> this could be the source of my problem.
>
> What I would ask is:
> 1) is my guess correct?
> 2) how can I setup the chip in extended mode?
>
> Thank you for your attention.
>
>
> _______________________________________________
> 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/20161130/4decdbfa/attachment-0001.html>

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

Message: 2
Date: Wed, 30 Nov 2016 17:46:23 -0500
From: Eddie Fung <ef...@appcomsci.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Setting up RFNOC development environment &
        running gr-ettus/rfnoc examples
Message-ID: <011e00be-01b3-2a61-e5bc-0ee14d5aa...@appcomsci.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

Jonathan,

Thanks for the clarification. Based upon your suggestion, I did the 
following:

----------------Begin Transcript--------------------------------------

$ ./make.py -d x310 -r X310_RFNOC_HG -m 10 --fill-with-fifos ddc 
axi_dma_fifo fft axi_fifo_loopback fosphor window

[programmed X310 fpga via usb/jtag]

$ uhd_usrp_probe


[... text deleted ...]
-- [RFNOC] ------- Block Setup -----------
-- Setting up NoC-Shell Control for port #0 (SID: 00:00>02:30)...OK
-- Port 48: Found NoC-Block with ID F1F0D00000000000.
-- Reading XML file: ..../rfnoc/share/uhd/rfnoc/blocks/dma_fifo.xml
-- Setting up NoC-Shell Control for port #1 (SID: 00:01>02:31)...OK
-- [RFNoC Factory] block_ctrl_base::make()
-- Reading XML file: ..../rfnoc/share/uhd/rfnoc/blocks/dma_fifo.xml
-- [RFNoC Factory] Using controller key 'DmaFIFO' and block name 'DmaFIFO'
-- block_ctrl_base()
-- Reading XML file: ..../rfnoc/share/uhd/rfnoc/blocks/dma_fifo.xml
-- Found valid blockdef
-- NOC ID: 0xF1F0D00000000000  Block ID: 0/DmaFIFO_0

[... text deleted ...]

-- [RFNOC] ------- Block Setup -----------
-- Setting up NoC-Shell Control for port #0 (SID: 00:02>02:40)...OK
-- Port 64: Found NoC-Block with ID 12AD100000000001.
-- Reading XML file: ..../rfnoc/share/uhd/rfnoc/blocks/radio_x300.xml
-- Setting up NoC-Shell Control for port #1 (SID: 00:03>02:41)...OK
-- [RFNoC Factory] block_ctrl_base::make()
-- Reading XML file: ..../rfnoc/share/uhd/rfnoc/blocks/radio_x300.xml
-- [RFNoC Factory] Using controller key 'X300Radio' and block name 'Radio'
-- block_ctrl_base()
-- Reading XML file: ..../rfnoc/share/uhd/rfnoc/blocks/radio_x300.xml
-- Found valid blockdef
-- NOC ID: 0x12AD100000000001  Block ID: 0/Radio_0

[... text deleted ...]

-- [RFNOC] ------- Block Setup -----------
-- Setting up NoC-Shell Control for port #0 (SID: 00:04>02:50)...OK
-- Port 80: Found NoC-Block with ID 12AD100000000001.
-- Reading XML file: ..../rfnoc/share/uhd/rfnoc/blocks/radio_x300.xml
-- Setting up NoC-Shell Control for port #1 (SID: 00:05>02:51)...OK
-- [RFNoC Factory] block_ctrl_base::make()
-- Reading XML file: ..../rfnoc/share/uhd/rfnoc/blocks/radio_x300.xml
-- [RFNoC Factory] Using controller key 'X300Radio' and block name 'Radio'
-- block_ctrl_base()
-- Reading XML file: ..../rfnoc/share/uhd/rfnoc/blocks/radio_x300.xml
-- Found valid blockdef
-- NOC ID: 0x12AD100000000001  Block ID: 0/Radio_1

[... text deleted ...]

-- [RFNOC] ------- Block Setup -----------
-- Setting up NoC-Shell Control for port #0 (SID: 00:06>02:60)...OK
-- Port 96: Found NoC-Block with ID DDC0000000000000.
-- Reading XML file: ..../rfnoc/share/uhd/rfnoc/blocks/ddc.xml
-- Setting up NoC-Shell Control for port #1 (SID: 00:07>02:61)...OK
-- [RFNoC Factory] block_ctrl_base::make()
-- Reading XML file: ..../rfnoc/share/uhd/rfnoc/blocks/ddc.xml
-- [RFNoC Factory] Using controller key 'DDC' and block name 'DDC'
-- block_ctrl_base()
-- Reading XML file: ..../rfnoc/share/uhd/rfnoc/blocks/ddc.xml
-- Found valid blockdef
-- NOC ID: 0xDDC0000000000000  Block ID: 0/DDC_0

[... text deleted ...]

-- [RFNOC] ------- Block Setup -----------
-- Setting up NoC-Shell Control for port #0 (SID: 00:08>02:70)...OK
Error: EnvironmentError: IOError: Block ctrl (CE_04_Port_70) no response 
packet - AssertionError: bool(buff)
   in uint64_t ctrl_iface_impl::wait_for_ack(bool)
   at ..../rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:205

----------------End Transcript--------------------------------------
At this point, I am just trying to add in standard blocks that are 
already provided.
I deleted some of output from 'uhd_usrp_probe' for brevity but can 
include it
if it would help with isolating the problem.

Any suggestions on where to look for the problem?

Thanks,
Eddie


On 11/29/2016 01:50 PM, Jonathon Pendlum wrote:
> Hi Eddie,
>
> You'll need to generate a FPGA image with the RFNoC blocks you want. 
> There is information on how to do this in the knowledge base: 
> https://kb.ettus.com/RFNoC_Getting_Started_Guides. Also, soon I will 
> be updating the image package with an image that has various RFNoC 
> blocks in it.
>
>
>
> Jonathon
>
> On Mon, Nov 28, 2016 at 12:41 PM, Eddie Fung via USRP-users 
> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote:
>
>     I am trying to set up and baseline a development environment for
>     RFNOC by testing it using the examples under gr-ettus and
>     am running into an error. I have set up my environment by
>     following the instructions given at
>     https://kb.ettus.com/Getting_Started_with_RFNoC_Development
>     <https://kb.ettus.com/Getting_Started_with_RFNoC_Development>.
>
>     The following is an abbreviated transcript of what I did:
>     ---------------Begin
>     
> Transcript---------------------------------------------------------------------------------------------------------------
>     $ sudo pip install git+https://github.com/gnuradio/pybombs.git
>     <https://github.com/gnuradio/pybombs.git>
>     $ pybombs recipes add gr-recipes
>     git+https://github.com/gnuradio/gr-recipes.git
>     <https://github.com/gnuradio/gr-recipes.git>
>     $ pybombs recipes add ettus
>     git+https://github.com/EttusResearch/ettus-pybombs.git
>     <https://github.com/EttusResearch/ettus-pybombs.git>
>     $ pybombs prefix init ./rfnoc -R rfnoc -a rfnoc
>     $ cd ./rfnoc
>     $ . ./setup_env.sh
>     $ uhd_images_downloader
>     Images destination:      ..../rfnoc/share/uhd/images
>     Downloading images from:
>     
> http://files.ettus.com/binaries/images/uhd-images_003.010.000.000-36-g967897e0.zip
>     
> <http://files.ettus.com/binaries/images/uhd-images_003.010.000.000-36-g967897e0.zip>
>     Downloading images to:
>     /tmp/tmpuCXKMR/uhd-images_003.010.000.000-36-g967897e0.zip
>     $ uhd_images_loader --args="type=x300,addr=192.168.20.2"
>     $ uhd_usrp_probe
>     [text deleted for brevity]
>     |   |     _____________________________________________________
>     |   |    /
>     |   |   |       RFNoC blocks on this device:
>     |   |   |
>     |   |   |   * DmaFIFO_0
>     |   |   |   * Radio_0
>     |   |   |   * Radio_1
>     |   |   |   * DDC_0
>     |   |   |   * DDC_1
>     |   |   |   * DUC_0
>     |   |   |   * DUC_1
>
>     $ ./rfnoc/src/gr-ettus/examples/rfnoc/rfnoc_dma_fifo.py
>     [text deleted for brevity]
>     RuntimeError: Cannot find a block for ID: FIFO
>     -----------------End
>     
> Transcript-------------------------------------------------------------------------------------------------------------
>
>     Based upon the output of the 'uhd_usrp_probe', I'm not surprised
>     by the runtime error messsage.
>     So my questions are as follows:
>     1. Did I miss any steps in setting up my environment that would
>     have made the example run?
>     2. Is there a specific FPGA image I could have downloaded that
>     would have worked with the gr-ettus examples?
>     3. (And most importantly), Are there build instructions for an
>     RFNOC FPGA image that would have worked for the gr-ettus examples?
>
>     Thanks,
>     Eddie
>
>     _______________________________________________
>     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
>     <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/20161130/d5709200/attachment-0001.html>

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

Message: 3
Date: Wed, 30 Nov 2016 16:01:04 -0800
From: Derek Kozel <derek.ko...@ettus.com>
To: Steven Nicholas Alfano <sna2...@columbia.edu>,
        "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Understanding Data Packet Protocol in FPGA
Message-ID:
        <CAA+K=tvHPeT7S0M6WK9=u8bcdd-e6fj4tnzvn-5lx5dtfus...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hello Steven,

I am using Wireshark 2.0.2 on Ubuntu 16.04. I don't have any recent
experience with Ubuntu 14.04. However I don't think that reinstalling your
OS is necessary, or likely to be very helpful. You said that you
encountered an error when starting Wireshark related to the ZPU dissector,
what is that error. Also, you should not be running Wireshark as root. I
wonder if that is why you are not detecting the plugins, Wireshark may not
be looking in your user's plugin directory.

If we can't get past the error then you can try purging the existing
wireshark install(s) and your plugin directory. Then try building an
installing Wireshark 2.0.2 from source, then rebuilding the dissectors.

I've added back in the usrp-users list. Lets keep that included so that
others can step in if they have had relevant experience installing the
dissectors.

Regards,
Derek

On Wed, Nov 30, 2016 at 7:47 AM, Steven Nicholas Alfano <
sna2...@columbia.edu> wrote:

> Hi Derek,
>
> Sorry if you are still on break, but we are still wondering what version
> of WireShark you recommend us using to get the dissector working on Ubuntu
> 14.04.
>
> Thanks,
> Steven
>
> On Mon, Nov 28, 2016 at 11:52 AM, Steven Nicholas Alfano <
> sna2...@columbia.edu> wrote:
>
>> Hi Derek,
>>
>> In an effort to get the Dissectors working with Wireshark, we will be
>> reinstalling our OS and starting from scratch. We are using Ubuntu 14.04.
>> What version of WireShark do you recommend we use to get everything working
>> properly?
>>
>> Thanks,
>> Steven
>>
>> On Wed, Nov 23, 2016 at 7:57 PM, Derek Kozel <derek.ko...@ettus.com>
>> wrote:
>>
>>> Hi Steven,
>>>
>>> No problem. I will be out of the office as well for Thanksgiving. If you
>>> keep the usrp-users list included on emails the support team can jump in
>>> and help when I am not around.
>>>
>>> Regards,
>>> Derek
>>>
>>> On Wed, Nov 23, 2016 at 4:55 PM, Steven Nicholas Alfano <
>>> sna2...@columbia.edu> wrote:
>>>
>>>> Hi Derek,
>>>>
>>>> With the holiday here I won't be able to check on this for a few days,
>>>> but appreciate your continued support. As far as permissions go Wireshark
>>>> is run with sudo command so that shouldn't be the issue.
>>>>
>>>> On Nov 23, 2016 7:23 PM, "Derek Kozel" <derek.ko...@ettus.com> wrote:
>>>>
>>>>> Hello Steven,
>>>>>
>>>>> You can check the enabled protocols by opening Wireshark and viewing
>>>>> the Analyze > Enabled Protocols menu. Search for UHD and two protocols
>>>>> (CHDR UHD and UHD) should be listed.
>>>>>
>>>>> On my system I have two .so files in ~/.wireshark/plugins
>>>>>
>>>>> [dkozel@er-dk-merlot build] ls -l ~/.wireshark/plugins/
>>>>> total 40
>>>>> -rw-r--r-- 1 dkozel dkozel 21096 Nov 23 16:21 chdr-plugin.so
>>>>> -rw-r--r-- 1 dkozel dkozel 14800 Aug 24 12:18 zpu-plugin.so
>>>>>
>>>>> Possibly you ran make install with sudo permissions? That would mean
>>>>> that Wireshark would be unable to read the files.
>>>>>
>>>>> Regards,
>>>>> Derek
>>>>>
>>>>> On Wed, Nov 23, 2016 at 3:10 PM, Steven Nicholas Alfano <
>>>>> sna2...@columbia.edu> wrote:
>>>>>
>>>>>> I am actually not able to see the plugins in Wireshark. I tried
>>>>>> moving the plugins from the build directory to the Wireshark plugin
>>>>>> directory to no avail. I receive an error upon starting Wireshark in
>>>>>> relation to the zpu dissector similar to the errors I posted earlier.
>>>>>>
>>>>>> Any thoughts?
>>>>>>
>>>>>> On Nov 23, 2016 5:53 PM, "Steven Nicholas Alfano" <
>>>>>> sna2...@columbia.edu> wrote:
>>>>>>
>>>>>>> Derek,
>>>>>>>
>>>>>>> I was able to get the dissector to build by uninstalling everything
>>>>>>> Wireshark and starting over from scratch. This may seem like a silly
>>>>>>> question, but what needs to be done to enable the dissector in Wireshark
>>>>>>> now that it has been built. Currently have the usrp connected via USB 
>>>>>>> and
>>>>>>> seeing the same screen as before when running the tx_waveform.
>>>>>>>
>>>>>>> On Nov 23, 2016 5:01 PM, "Derek Kozel" <derek.ko...@ettus.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> That error is caused by the dissector not supporting Wireshark 2.
>>>>>>>> We updated the dissectors several months ago. Can you please try 
>>>>>>>> building
>>>>>>>> the dissectors from a recent commit? They are independent from the 
>>>>>>>> main UHD
>>>>>>>> version so you do not have to update your UHD install.
>>>>>>>>
>>>>>>>> https://github.com/EttusResearch/uhd/tree/master/tools/dissectors
>>>>>>>>
>>>>>>>> Here is the most specific commit that added support. Any recent
>>>>>>>> maint or master commit will work, including the 3.10.1.0 release tag.
>>>>>>>> https://github.com/EttusResearch/uhd/commit/fe7fe8b6ceb21da3
>>>>>>>> e3636b955f2248b511a6d146
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Derek
>>>>>>>>
>>>>>>>> On Wed, Nov 23, 2016 at 1:46 PM, Steven Nicholas Alfano <
>>>>>>>> sna2...@columbia.edu> wrote:
>>>>>>>>
>>>>>>>>> Derek,
>>>>>>>>>
>>>>>>>>> I am using Ubuntu 14.04 with Wireshark 2.2.2
>>>>>>>>>
>>>>>>>>> I get the following error multiple times when attempting to
>>>>>>>>> install the dissector. I am following the instructions on the link you
>>>>>>>>> shared.
>>>>>>>>>
>>>>>>>>> ~/uhd/tools/dissectors/packet-chdr.c:206:13: error: too many
>>>>>>>>> arguments to function ?tvb_get_string?
>>>>>>>>>              bytes = tvb_get_string(wmem_packet_scope(), tvb, 0,
>>>>>>>>> 4);
>>>>>>>>>
>>>>>>>>> Steven
>>>>>>>>>
>>>>>>>>> On Wed, Nov 23, 2016 at 4:28 PM, Derek Kozel <
>>>>>>>>> derek.ko...@ettus.com> wrote:
>>>>>>>>>
>>>>>>>>>> Sorry, I didn't see my previous message and assumed it had not
>>>>>>>>>> sent. Have you done the install steps and made sure the dependency 
>>>>>>>>>> was
>>>>>>>>>> satisfied?
>>>>>>>>>> https://github.com/EttusResearch/uhd/tree/master/tools/dissectors
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Nov 23, 2016 at 1:26 PM, Derek Kozel <
>>>>>>>>>> derek.ko...@ettus.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Steven,
>>>>>>>>>>>
>>>>>>>>>>> If you post how you are installing the dissector and the error
>>>>>>>>>>> message maybe we can help. Also what Wireshark version are you 
>>>>>>>>>>> using?
>>>>>>>>>>>
>>>>>>>>>>> Getting the dissector working is going to be the best way of
>>>>>>>>>>> understanding the data format.
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Derek
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Nov 23, 2016 at 12:15 PM, Steven Nicholas Alfano <
>>>>>>>>>>> sna2...@columbia.edu> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Derek,
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for getting back to me. Previously I tried to install
>>>>>>>>>>>> the dissector, but it failed. I tried again just now to the same 
>>>>>>>>>>>> result.
>>>>>>>>>>>> Will continue to search for a work around, but any other 
>>>>>>>>>>>> information would
>>>>>>>>>>>> be valuable.
>>>>>>>>>>>>
>>>>>>>>>>>> Steven
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Nov 23, 2016 at 2:05 PM, Derek Kozel <
>>>>>>>>>>>> derek.ko...@ettus.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hello Steven,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Do you have the Wireshark dissectors for CHDR and the ZPU
>>>>>>>>>>>>> installed? They are included in the source and will decode the 
>>>>>>>>>>>>> various
>>>>>>>>>>>>> fields.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Derek
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Nov 23, 2016 at 9:21 AM, Steven Nicholas Alfano via
>>>>>>>>>>>>> USRP-users <usrp-users@lists.ettus.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am trying to get a better understanding of how the data
>>>>>>>>>>>>>> packet protocols are handled in the FPGA, specifically in 
>>>>>>>>>>>>>> reference to the
>>>>>>>>>>>>>> information provided here: http://files.ettus.com/manual/
>>>>>>>>>>>>>> page_rtp.html
>>>>>>>>>>>>>> I am using a B205mini with the default Ettus software
>>>>>>>>>>>>>> commands; specifically my question is in reference to the 
>>>>>>>>>>>>>> functions found
>>>>>>>>>>>>>> in tx_waveforms.cpp.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am sending the following command to the USRP and monitoring
>>>>>>>>>>>>>> the communication using WireShark:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   sudo ./tx_waveforms --rate 1e6 --freq 900e6 --wave-type
>>>>>>>>>>>>>>> CONST
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What's confusing me is that every data packet outside the
>>>>>>>>>>>>>> very first packet sent has the packet type defined as "Command 
>>>>>>>>>>>>>> Response:
>>>>>>>>>>>>>> Error"
>>>>>>>>>>>>>> The packet also reads that a Fractional Timestamp should be
>>>>>>>>>>>>>> included, but after the first 64-bits the constant data stream 
>>>>>>>>>>>>>> begins.
>>>>>>>>>>>>>> Additionally it appears that the total packet length is
>>>>>>>>>>>>>> defined with the most significant byte appearing after the least
>>>>>>>>>>>>>> significant byte.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> An example of the first 64-bits seen looks like
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 11111000 00011111 00001011 00000000 01010000 00000000
>>>>>>>>>>>>>>> 00000000 00000000
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> F9 1F 0B 00 60 00 00 00
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is what the terminal prints out during elaboration of
>>>>>>>>>>>>>> the above command:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Setting TX Rate: 1.000000 Msps...
>>>>>>>>>>>>>>> -- Asking for clock rate 32.000000 MHz...
>>>>>>>>>>>>>>> -- Actually got clock rate 32.000000 MHz.
>>>>>>>>>>>>>>> -- Performing timer loopback test... pass
>>>>>>>>>>>>>>> Actual TX Rate: 1.000000 Msps...
>>>>>>>>>>>>>>> Setting TX Freq: 900.000000 MHz...
>>>>>>>>>>>>>>> Actual TX Freq: 900.000000 MHz...
>>>>>>>>>>>>>>> Setting device timestamp to 0...
>>>>>>>>>>>>>>> Checking TX: LO: locked ...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Does anyone have any insight into this protocol or have
>>>>>>>>>>>>>> something like a USRP FPGA Design Diagram that would make 
>>>>>>>>>>>>>> understanding the
>>>>>>>>>>>>>> data packet control simpler?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thank you for any assistance,
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Steven Alfano
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Master's in Electrical Engineering
>>>>>>>>>>>>>> Columbia University
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> USRP-users mailing list
>>>>>>>>>>>>>> USRP-users@lists.ettus.com
>>>>>>>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ett
>>>>>>>>>>>>>> us.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Steven Alfano
>>>>>>>>>>>>
>>>>>>>>>>>> Master's in Electrical Engineering
>>>>>>>>>>>> Columbia University
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Steven Alfano
>>>>>>>>>
>>>>>>>>> Master's in Electrical Engineering
>>>>>>>>> Columbia University
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>
>>
>>
>> --
>> Steven Alfano
>>
>> Master's in Electrical Engineering
>> Columbia University
>>
>
>
>
> --
> Steven Alfano
>
> Master's in Electrical Engineering
> Columbia University
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161130/e45780ed/attachment-0001.html>

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

Message: 4
Date: Wed, 30 Nov 2016 18:03:43 -0600
From: Jonathon Pendlum <jonathon.pend...@ettus.com>
To: Eddie Fung <ef...@appcomsci.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Setting up RFNOC development environment &
        running gr-ettus/rfnoc examples
Message-ID:
        <CAGdo0uR18v=s5wrhsk5phpys8e6xpntpe2us1b7hn_3t89y...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi Eddie,

Remove "axi_dma_fifo" from your list of blocks. There is already one in the
X310 image by default and that is a special block that requires manual
instantiation.



Jonathon

On Wed, Nov 30, 2016 at 4:46 PM, Eddie Fung via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Jonathan,
>
> Thanks for the clarification. Based upon your suggestion, I did the
> following:
>
> ----------------Begin Transcript--------------------------------------
>
> $ ./make.py -d x310 -r X310_RFNOC_HG -m 10 --fill-with-fifos ddc
> axi_dma_fifo fft axi_fifo_loopback fosphor window
>
> [programmed X310 fpga via usb/jtag]
>
> $ uhd_usrp_probe
>
> [... text deleted ...]
> -- [RFNOC] ------- Block Setup -----------
> -- Setting up NoC-Shell Control for port #0 (SID: 00:00>02:30)...OK
> -- Port 48: Found NoC-Block with ID F1F0D00000000000.
> -- Reading XML file: ..../rfnoc/share/uhd/rfnoc/blocks/dma_fifo.xml
> -- Setting up NoC-Shell Control for port #1 (SID: 00:01>02:31)...OK
> -- [RFNoC Factory] block_ctrl_base::make()
> -- Reading XML file: ..../rfnoc/share/uhd/rfnoc/blocks/dma_fifo.xml
> -- [RFNoC Factory] Using controller key 'DmaFIFO' and block name 'DmaFIFO'
> -- block_ctrl_base()
> -- Reading XML file: ..../rfnoc/share/uhd/rfnoc/blocks/dma_fifo.xml
> -- Found valid blockdef
> -- NOC ID: 0xF1F0D00000000000  Block ID: 0/DmaFIFO_0
>
> [... text deleted ...]
>
> -- [RFNOC] ------- Block Setup -----------
> -- Setting up NoC-Shell Control for port #0 (SID: 00:02>02:40)...OK
> -- Port 64: Found NoC-Block with ID 12AD100000000001.
> -- Reading XML file: ..../rfnoc/share/uhd/rfnoc/blocks/radio_x300.xml
> -- Setting up NoC-Shell Control for port #1 (SID: 00:03>02:41)...OK
> -- [RFNoC Factory] block_ctrl_base::make()
> -- Reading XML file: ..../rfnoc/share/uhd/rfnoc/blocks/radio_x300.xml
> -- [RFNoC Factory] Using controller key 'X300Radio' and block name 'Radio'
> -- block_ctrl_base()
> -- Reading XML file: ..../rfnoc/share/uhd/rfnoc/blocks/radio_x300.xml
> -- Found valid blockdef
> -- NOC ID: 0x12AD100000000001  Block ID: 0/Radio_0
>
> [... text deleted ...]
>
> -- [RFNOC] ------- Block Setup -----------
> -- Setting up NoC-Shell Control for port #0 (SID: 00:04>02:50)...OK
> -- Port 80: Found NoC-Block with ID 12AD100000000001.
> -- Reading XML file: ..../rfnoc/share/uhd/rfnoc/blocks/radio_x300.xml
> -- Setting up NoC-Shell Control for port #1 (SID: 00:05>02:51)...OK
> -- [RFNoC Factory] block_ctrl_base::make()
> -- Reading XML file: ..../rfnoc/share/uhd/rfnoc/blocks/radio_x300.xml
> -- [RFNoC Factory] Using controller key 'X300Radio' and block name 'Radio'
> -- block_ctrl_base()
> -- Reading XML file: ..../rfnoc/share/uhd/rfnoc/blocks/radio_x300.xml
> -- Found valid blockdef
> -- NOC ID: 0x12AD100000000001  Block ID: 0/Radio_1
>
> [... text deleted ...]
>
> -- [RFNOC] ------- Block Setup -----------
> -- Setting up NoC-Shell Control for port #0 (SID: 00:06>02:60)...OK
> -- Port 96: Found NoC-Block with ID DDC0000000000000.
> -- Reading XML file: ..../rfnoc/share/uhd/rfnoc/blocks/ddc.xml
> -- Setting up NoC-Shell Control for port #1 (SID: 00:07>02:61)...OK
> -- [RFNoC Factory] block_ctrl_base::make()
> -- Reading XML file: ..../rfnoc/share/uhd/rfnoc/blocks/ddc.xml
> -- [RFNoC Factory] Using controller key 'DDC' and block name 'DDC'
> -- block_ctrl_base()
> -- Reading XML file: ..../rfnoc/share/uhd/rfnoc/blocks/ddc.xml
> -- Found valid blockdef
> -- NOC ID: 0xDDC0000000000000  Block ID: 0/DDC_0
>
> [... text deleted ...]
>
> -- [RFNOC] ------- Block Setup -----------
> -- Setting up NoC-Shell Control for port #0 (SID: 00:08>02:70)...OK
> Error: EnvironmentError: IOError: Block ctrl (CE_04_Port_70) no response
> packet - AssertionError: bool(buff)
>   in uint64_t ctrl_iface_impl::wait_for_ack(bool)
>   at ..../rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:205
>
> ----------------End Transcript--------------------------------------
> At this point, I am just trying to add in standard blocks that are already
> provided.
> I deleted some of output from 'uhd_usrp_probe' for brevity but can include
> it
> if it would help with isolating the problem.
>
> Any suggestions on where to look for the problem?
>
> Thanks,
> Eddie
>
>
> On 11/29/2016 01:50 PM, Jonathon Pendlum wrote:
>
> Hi Eddie,
>
> You'll need to generate a FPGA image with the RFNoC blocks you want. There
> is information on how to do this in the knowledge base:
> https://kb.ettus.com/RFNoC_Getting_Started_Guides. Also, soon I will be
> updating the image package with an image that has various RFNoC blocks in
> it.
>
>
>
> Jonathon
>
> On Mon, Nov 28, 2016 at 12:41 PM, Eddie Fung via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> I am trying to set up and baseline a development environment for RFNOC by
>> testing it using the examples under gr-ettus and
>> am running into an error. I have set up my environment by following the
>> instructions given at
>> https://kb.ettus.com/Getting_Started_with_RFNoC_Development.
>>
>> The following is an abbreviated transcript of what I did:
>> ---------------Begin Transcript--------------------
>> ------------------------------------------------------------
>> -------------------------------
>> $ sudo pip install git+https://github.com/gnuradio/pybombs.git
>> $ pybombs recipes add gr-recipes git+https://github.com/gnuradi
>> o/gr-recipes.git
>> $ pybombs recipes add ettus git+https://github.com/EttusRe
>> search/ettus-pybombs.git
>> $ pybombs prefix init ./rfnoc -R rfnoc -a rfnoc
>> $ cd ./rfnoc
>> $ . ./setup_env.sh
>> $ uhd_images_downloader
>> Images destination:      ..../rfnoc/share/uhd/images
>> Downloading images from: http://files.ettus.com/binarie
>> s/images/uhd-images_003.010.000.000-36-g967897e0.zip
>> Downloading images to: /tmp/tmpuCXKMR/uhd-images_003.
>> 010.000.000-36-g967897e0.zip
>> $ uhd_images_loader --args="type=x300,addr=192.168.20.2"
>> $ uhd_usrp_probe
>> [text deleted for brevity]
>> |   |     _____________________________________________________
>> |   |    /
>> |   |   |       RFNoC blocks on this device:
>> |   |   |
>> |   |   |   * DmaFIFO_0
>> |   |   |   * Radio_0
>> |   |   |   * Radio_1
>> |   |   |   * DDC_0
>> |   |   |   * DDC_1
>> |   |   |   * DUC_0
>> |   |   |   * DUC_1
>>
>> $ ./rfnoc/src/gr-ettus/examples/rfnoc/rfnoc_dma_fifo.py
>> [text deleted for brevity]
>> RuntimeError: Cannot find a block for ID: FIFO
>> -----------------End Transcript--------------------
>> ------------------------------------------------------------
>> -----------------------------
>>
>> Based upon the output of the 'uhd_usrp_probe', I'm not surprised by the
>> runtime error messsage.
>> So my questions are as follows:
>> 1. Did I miss any steps in setting up my environment that would have made
>> the example run?
>> 2. Is there a specific FPGA image I could have downloaded that would have
>> worked with the gr-ettus examples?
>> 3. (And most importantly), Are there build instructions for an RFNOC FPGA
>> image that would have worked for the gr-ettus examples?
>>
>> Thanks,
>> Eddie
>>
>> _______________________________________________
>> 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/20161130/c5ac1d58/attachment-0001.html>

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

Message: 5
Date: Thu, 1 Dec 2016 17:06:22 +0800
From: john liu <johncorad1...@gmail.com>
To: Lihua Ren <anything...@163.com>,    "USRP-users@lists.ettus.com"
        <usrp-users@lists.ettus.com>
Subject: [USRP-users] Can not get data from rfnoc block
Message-ID:
        <caf6nntkocnsz2ecaz-y6ccf9rtarhmwyoocpafzyfev8jyq...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi all,
We develop a custom rfnoc block.Then we used file source ??rfnoc
block??file sink.
But we couldn't get data.The data size was 0 byte from file sink.
Run uhd_usrp_probe,we could find our rfnoc block,which is also appear in
gnuradio-companion.

best regards
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161201/d9fa297d/attachment-0001.html>

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

Message: 6
Date: Thu, 1 Dec 2016 12:08:22 +0100
From: Vladica Sark <vladicas...@gmail.com>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] Difference between timestamps
Message-ID: <188ffa56-6e71-58ef-b23f-5bd081f18...@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi,

I am issuing a STREAM_MODE_NUM_SAMPS_AND_DONE command in order to get 
number of samples.
I set the time when the samples should be taken.

Later, when I receive the samples, the time in the metadata differs for 
a few samples compared to the time set. It is different on different 
radios.

For example on N210 the sampling starts 3 samples later, and on 
B205mini, 7 samples later.

I am wondering if this is so by design, or I am doing something wrong?

BR,
Vladica



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

Message: 7
Date: Thu, 1 Dec 2016 13:03:19 +0100
From: Brais Ares <ba...@gradiant.org>
To: Ian Buckley <i...@ionconcepts.com>
Cc: Michael West <michael.w...@ettus.com>,      usrp-users
        <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] AD9361 medium access method
Message-ID:
        <CAJcStAhZ56tJqEmS=fw-3Q5k2dz1MKZTJ75JjY=u2gvndfb...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Thank you, Ian and Michael,

Useful explanation, all is crystal clear now.

Cheers,
Leroy.

2016-11-28 22:31 GMT+01:00 Ian Buckley <i...@ionconcepts.com>:

> Leroy,
> Just to add a little more useful background info. The functionality
> associated with TXNRX and ENABLE w.r.t transitioning the AD9361's state
> machine between modes is duplicated in the SPI register set. The advantage
> to using the dedicated pins is absolutely unambiguous timing (Often most
> applicable to TDD style apps). If you use SPI to do the same thing a small
> amount of time ambiguity is introduced due to the formation and
> transmission of the SPI transaction, however that ambiguity is introduced
> only in state machine transitions, not sample timing as Michael already
> indicted.
>
> In a similar vein there are also 12 additional "GPIO" style pins on AD9361
> that can be programmed for out of band control/status functionality that
> duplicates SPI functionality.
>
> -Ian
>
>
> On Mon, Nov 28, 2016 at 12:08 PM, Michael West via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi Leroy,
>>
>> Samples are constantly being sent and received from/to the AD9361.  There
>> are modules in the FPGA to control the sample streams.  For RX, the control
>> module either drops the samples or packetizes and sends them to the host
>> depending on what the user requests.  For TX, the control module either
>> sends the user's samples or an idle value (there is a register for idle
>> sample value that defaults to zero).  Those modules also generate signals
>> to indicate when they are streaming to enable/disable frontend components
>> so noise is eliminated when not streaming.
>>
>> Regards,
>> Michael
>>
>> On Wed, Nov 23, 2016 at 12:05 AM, Brais Ares <ba...@gradiant.org> wrote:
>>
>>> Useful reference, thank you Michael.
>>>
>>> Just below that line I can see also ENABLE is held high. Then how
>>> exactly are the internals of uhd working when using something like 
>>> "*stream_cmd.time_spec
>>> = uhd::time_spec_t(seconds_in_future);*"?:
>>>
>>>    - Are all received samples being written to DDR through DMA and then
>>>    somehow the kernel driver selects and returns the ones the userspace
>>>    program asked for? (this would mean that reciprocally, when no 
>>> transmission
>>>    have been programmed from user space, FPGA stills reading samples from 
>>> DDR
>>>    and transmitting them, but those samples being zeros),
>>>    - or is there any block within the FPGA letting the data go through
>>>    DMA only when receptions/transmissions are required (with exact timing)?
>>>
>>> Regards,
>>> Leroy.
>>>
>>> 2016-11-22 21:41 GMT+01:00 Michael West <michael.w...@ettus.com>:
>>>
>>>> Hi Leroy,
>>>>
>>>> The AD9361 is used in FDD mode.  The TXNRX value is held high (
>>>> https://github.com/EttusResearch/fpga/blob/master/usrp3/top
>>>> /e300/e310.v#L509).
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>> On Tue, Nov 22, 2016 at 3:39 AM, Brais Ares via USRP-users <
>>>> usrp-users@lists.ettus.com> wrote:
>>>>
>>>>> Hello everyone,
>>>>>
>>>>> I have a really simply question I couldn't find an answer to.
>>>>>
>>>>> I've seen Ad9361 has three methods to access the channel: TDD, FDD and
>>>>> FDD-independent mode. I'm just wondering which one is being used in USRP
>>>>> E310 when using *timed calls* (like the ones in the
>>>>> *rx_timed_samples.cpp* example)*. *At first I thought it'd be TDD,
>>>>> but the more I read, the more I think it's actually FDD-independent mode.
>>>>>
>>>>> And who's being in charge of controlling the TXNRX and ENABLE pins in*
>>>>> real time*, a HDL core within the FPGA whose 'triggers' have been
>>>>> configured from SW?
>>>>>
>>>>> Cheers,
>>>>> Leroy.
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>
>>
>


-- 

*Brais Ares*
*Research Engineer*
*Advanced Communications Area*

Phone: (0034) 986 120 430* Ext. 3012*
www.gradiant.org* / *uavs.gradiant.org


Take care of the environment: Try not to print this email.

*The information contained in this email message may be confidential
information, and may also be the subject of legal professional privilege.
If you are not the intended recipient, any use, interference with,
disclosure or copying of this material is unauthorised and prohibited.
Please inform us immediately and destroy the email. Thank you for your
cooperation. *
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161201/f77ef820/attachment-0001.html>

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

Message: 8
Date: Thu, 1 Dec 2016 13:46:39 +0100
From: Nicolas Cuervo <nicolas.cue...@ettus.com>
To: john liu <johncorad1...@gmail.com>
Cc: Lihua Ren <anything...@163.com>,    "USRP-users@lists.ettus.com"
        <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Can not get data from rfnoc block
Message-ID:
        <caoupcviyxou40-xyo7yjnsaurwmxftr6d097z21umsjsk97...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hello John,

This is a rather broad question and with this information there is not much
that we can do to identify your issue. If we assume that the problem is in
your HDL code, have you run a testbench for your code before programming it
into the device to check if your HDL code is, indeed, putting elements at
the output? If it does put elements at your output, are the values for this
output what you expect? This is a simulation step that can help you
identify problems at an early stage of your design.

If the testbench shows that the block is behaving as you expect, then you'd
have to revise the connections of your block to the AXI wrapper within your
block code, or even to the AXI crossbar in the instantiation file. If after
checking the connections everything still seems to be just fine, my next
recommendation would be to debug your design using chipscope. Now, if you
are applying more block controlling by adding more logic in the host (i.e.
applying more processing by the means of cpp), then you'd have to debug
that too.

If the block appears with usrp_probe and shows up on GNURadio is a sign
that the set up is done correctly (API is being correctly identified,
linking is done and the code compiles), but doesn't guarantee that the
block is going to output your desired signal.

Cheers,
- Nicolas


On Thu, Dec 1, 2016 at 10:06 AM, john liu via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
> We develop a custom rfnoc block.Then we used file source ??rfnoc
> block??file sink.
> But we couldn't get data.The data size was 0 byte from file sink.
> Run uhd_usrp_probe,we could find our rfnoc block,which is also appear in
> gnuradio-companion.
>
> best regards
> John
>
> _______________________________________________
> 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/20161201/c1a05f5f/attachment-0001.html>

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

Message: 9
Date: Thu, 1 Dec 2016 17:07:01 +0300
From: ?????? 1 <andrew4...@rambler.ru>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] B210 C-API dual channel
Message-ID: <1480601221.717742.1095.46...@mail.rambler.ru>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

Hi

Thanks for all the answers.

Thanks to them, I have simplified the program and correct the problem.

I used MinGW compiler from qt for windows and param full_secs in
uhd_usrp_set_time_now was defined as 32 bit

When I redefined as a 64-bit all became OK.

Do I understand that needed use set_time_unknown_pps() instead of set_time_now()
?

And I do not quite understand the meaning of timeout parameter in
uhd_rx_streamer_recv especially for the continuous

stream from device.

Regards,

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

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

Message: 10
Date: Thu, 1 Dec 2016 17:19:10 +0100
From: Philipp Rudnik <rup2pr...@gmail.com>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Accessing FPGA image in Vivado
Message-ID:
        <cadk_vqejprldsa1s6ji-ckivvjksenof0nq_0n+31vf_tgs...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi everybody!

For a part of my bachelors thesis I've been trying to get access to the
Front Panel GPIO Port on my NI USRP-2953R (X310) to be able to address an
array antenna.
Since pushing patterns via UHD was too slow my idea was to edit the FPGA
image by adding a modul, that runs through the address patterns as soon as
an rx stream is detected.
Since I'm quite new to the FPGA programming thing I wanted to build the
initial FPGA image first. I tried two things, first i imported the fpga
source, ip and constaints from the github.com/ettusresearch repository to
my Vivado (Version 2015.4) project. In another project I tried importing
the RFNoC tutorial to Vivado (found in a presentation by Ettus Research
8/26/2015), I followed the steps in the tutorial.

Both tries failed. The first implementation complained about having too
many user io's for this FPGA (673 instead of max. 500). In the second case
the sythetisation failed because of missing moduls.

Correct me if I'm wrong, but I thought in the fpga repository are all files
necessary to rebuild the image with Vivado (and if wanted edit them).

It would be great if somebody could help me out with that!

additional information: I'm working on a Windows 7 machine with Vivado
2015.4 and the FPGA is a Kintex 7 xc7k410tffg900-2.

Best regards
Philipp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161201/f94b4e1d/attachment-0001.html>

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

Message: 11
Date: Thu, 01 Dec 2016 11:20:10 -0500
From: mle...@ripnet.com
To: ?????? 1 <andrew4...@rambler.ru>
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] B210 C-API dual channel
Message-ID: <7c015cc7281d28e417569d7144a69...@ripnet.com>
Content-Type: text/plain; charset="utf-8"

set_time_unknown_pps() is "safer" on B210 because each channel (unless
this has changed) has its own clock, and it also has an internal PPS
generator.  If you use set_time_now(), then in fact, the clocks on the
two sides will have slightly different times. 

The timeout allows non-blocking behavior in a single-threaded app.  It
will also mean that if the USRP stops sending data, you'll know about it
within <timeout> seconds. 

On 2016-12-01 09:07, ?????? 1 via USRP-users wrote:

> Hi 
> 
> Thanks for all the answers. 
> 
> Thanks to them, I have simplified the program and correct the problem. 
> 
> I used MinGW compiler from qt for windows and param FULL_SECS in 
> UHD_USRP_SET_TIME_NOW was defined as 32 bit 
> 
> When I redefined as a 64-bit all became OK. 
> 
> Do I understand that needed use SET_TIME_UNKNOWN_PPS() instead of 
> SET_TIME_NOW() ? 
> 
> And I do not quite understand the meaning of TIMEOUT parameter in 
> UHD_RX_STREAMER_RECV especially for the continuous 
> 
> stream from device. 
> 
> Regards, 
> 
> Andrew. 
> _______________________________________________
> 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/20161201/0af38734/attachment-0001.html>

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

Message: 12
Date: Thu, 1 Dec 2016 17:38:18 +0100
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Accessing FPGA image in Vivado
Message-ID: <2bd983d0-c805-e43d-4741-f715765bb...@ettus.com>
Content-Type: text/plain; charset="windows-1252"

Hi Philip,

the FPGA image is really meant to be built using the UHD build system
(which more or less generates a Xilinx Vivado project on the fly). So,
I'd discourage you from going your first route, and the second seems
right, to me.

I'm not really able to tell you what went wrong in the second case ? but
please follow

http://files.ettus.com/manual/md_usrp3_build_instructions.html

(under "Build Instructions ? Xilinx Vivado only") and tell us where
exactly that happened.

"Missing modules" isn't totally clear ? it might mean you didn't set up
all paths necessary to make Vivado find the sources, or you might have a
license problem and aren't allowed to use some of the IP cores that are
part of the X3xx design.

Best regards,

Marcus


On 12/01/2016 05:19 PM, Philipp Rudnik via USRP-users wrote:
> Hi everybody!
>
> For a part of my bachelors thesis I've been trying to get access to
> the Front Panel GPIO Port on my NI USRP-2953R (X310) to be able to
> address an array antenna.
> Since pushing patterns via UHD was too slow my idea was to edit the
> FPGA image by adding a modul, that runs through the address patterns
> as soon as an rx stream is detected.
> Since I'm quite new to the FPGA programming thing I wanted to build
> the initial FPGA image first. I tried two things, first i imported the
> fpga source, ip and constaints from the github.com/ettusresearch
> <http://github.com/ettusresearch> repository to my Vivado (Version
> 2015.4) project. In another project I tried importing the RFNoC
> tutorial to Vivado (found in a presentation by Ettus Research
> 8/26/2015), I followed the steps in the tutorial.
>
> Both tries failed. The first implementation complained about having
> too many user io's for this FPGA (673 instead of max. 500). In the
> second case the sythetisation failed because of missing moduls.
>
> Correct me if I'm wrong, but I thought in the fpga repository are all
> files necessary to rebuild the image with Vivado (and if wanted edit
> them).
>
> It would be great if somebody could help me out with that!
>
> additional information: I'm working on a Windows 7 machine with Vivado
> 2015.4 and the FPGA is a Kintex 7 xc7k410tffg900-2.
>
> Best regards
> Philipp
>
>
> _______________________________________________
> 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/20161201/416026aa/attachment-0001.html>

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

Message: 13
Date: Thu, 1 Dec 2016 17:38:25 +0100
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Accessing FPGA image in Vivado
Message-ID: <fbd055ab-28b6-5554-2828-48bd80dfa...@ettus.com>
Content-Type: text/plain; charset="windows-1252"

Hi Philip,

the FPGA image is really meant to be built using the UHD build system
(which more or less generates a Xilinx Vivado project on the fly). So,
I'd discourage you from going your first route, and the second seems
right, to me.

I'm not really able to tell you what went wrong in the second case ? but
please follow

http://files.ettus.com/manual/md_usrp3_build_instructions.html

(under "Build Instructions ? Xilinx Vivado only") and tell us where
exactly that happened, including log files.

"Missing modules" isn't totally clear ? it might mean you didn't set up
all paths necessary to make Vivado find the sources, or you might have a
license problem and aren't allowed to use some of the IP cores that are
part of the X3xx design.

Best regards,

Marcus


On 12/01/2016 05:19 PM, Philipp Rudnik via USRP-users wrote:
> Hi everybody!
>
> For a part of my bachelors thesis I've been trying to get access to
> the Front Panel GPIO Port on my NI USRP-2953R (X310) to be able to
> address an array antenna.
> Since pushing patterns via UHD was too slow my idea was to edit the
> FPGA image by adding a modul, that runs through the address patterns
> as soon as an rx stream is detected.
> Since I'm quite new to the FPGA programming thing I wanted to build
> the initial FPGA image first. I tried two things, first i imported the
> fpga source, ip and constaints from the github.com/ettusresearch
> <http://github.com/ettusresearch> repository to my Vivado (Version
> 2015.4) project. In another project I tried importing the RFNoC
> tutorial to Vivado (found in a presentation by Ettus Research
> 8/26/2015), I followed the steps in the tutorial.
>
> Both tries failed. The first implementation complained about having
> too many user io's for this FPGA (673 instead of max. 500). In the
> second case the sythetisation failed because of missing moduls.
>
> Correct me if I'm wrong, but I thought in the fpga repository are all
> files necessary to rebuild the image with Vivado (and if wanted edit
> them).
>
> It would be great if somebody could help me out with that!
>
> additional information: I'm working on a Windows 7 machine with Vivado
> 2015.4 and the FPGA is a Kintex 7 xc7k410tffg900-2.
>
> Best regards
> Philipp
>
>
> _______________________________________________
> 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/20161201/56721b00/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 76, Issue 1
*****************************************

Reply via email to