Send USRP-users mailing list submissions to
        [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
        [email protected]

You can reach the person managing the list at
        [email protected]

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


Today's Topics:

   1. Re: Trigger Signal (Julian Arnold)
   2. Receiving multiple signals using a single RX port (Snehasish Kar)
   3. Re: Receiving multiple signals using a single RX port
      (Evert Verduin)
   4. RFNOC + GPIO (Christophe ALEXANDRE)
   5. Re: Sync of two b205mini (?????? ????)
   6. Re: Sync of two b205mini (Marcus D. Leech)
   7. NEWSDR // Tufts University // Thr-Fri June 1-2 (Neel Pandeya)
   8. Re: RFNOC + GPIO (Michael West)
   9. UBX160 and TrinRx on one X310 (liu Jong)
  10. Re: RFNOC + GPIO (Christophe ALEXANDRE)
  11. Re: UBX160 and TrinRx on one X310 (Derek Kozel)
  12. Re: UBX160 and TrinRx on one X310 (liu Jong)
  13. GRC + RFNoC + Radio Loopback (Christophe ALEXANDRE)
  14. Re: GRC + RFNoC + Radio Loopback (Jonathon Pendlum)


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

Message: 1
Date: Mon, 22 May 2017 18:14:39 +0200
From: Julian Arnold <[email protected]>
To: [email protected], [email protected]
Subject: Re: [USRP-users] Trigger Signal
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8

Hey Mareike,

have you considered using the GPIO API for this task [1]?
I think using the GPIOs as a trigger source is more adequate than using
the PPS input as the PPS should be used for time synchronization between
multiple devices. (However, one could probably abuse it as a trigger)

Cheers,

[1] https://files.ettus.com/manual/page_gpio_api.html

On 05/22/2017 04:50 PM, hetzel--- via USRP-users wrote:
> Hi!
>
> I want to build a trigger signal for my USRP X310 using UHD version
> 3.10.1.1. I want to send a pulse to the USRP and after receiving this
> pulse my device should start/stop streaming or something similar.
>
> I found that I can use the PPS TRIG IN port and send a trigger signal.
> Therefore I have to set the PPS to external:
> pps = "external"   (Is this the right way to do so?)
> Afterwards the idea is to use timed commands and to start a long time
> from now. But with the next received PPS pulse, I set the clock to the
> same time. I started with a slightly changed tx_waveforms C++ file. I
> would use these additions to the code:
>
> usrp->set_time_now(0.0); //somewhere in the beginning
> usrp->set_command_time(uhd::time_spec_t(1e6));
>
> md.has_time_spec = true;
> md.time_spec = uhd::time_spec_t(1e6); // I am not sure if this is needed
>
> usrp->set_time_next_pps(uhd::time_spec_t(1e6)); // and this directly
> before I want to start streaming
>
> usrp->clear_command_time(); // in the end
>
>
>
> If I run this program my USRP seems to wait for a PPS signal but it
> does not react to those I send using a Function Generator. So how does
> a PPS input pulse has to look like? It says that it should have max 5V
> but how long should it be?
>
> So I have to stop the program. But if I want to re-run it there occurs
> a problem and I cannot run any other program until I power cycle the
> device. I get the following output to the console:
>
>
> Win32; Microsoft Visual C++ version 14.0; Boost_105900;
> UHD_003.010.001.001-rele
> ase
>
>
> Creating the usrp device with: ...
> -- X300 initialization sequence...
> -- Determining maximum frame size... 8000 bytes.
> -- Setup basic communication...
> -- Loading values from EEPROM...
> -- Setup RF frontend clocking...
> -- Radio 1x clock:200
> -- Creating WSA UDP transport for 192.168.40.2:49153
> -- Creating WSA UDP transport for 192.168.40.2:49153
> -- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1304.3MB/s)
> -- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1304.9MB/s)
> -- Creating WSA UDP transport for 192.168.40.2:49153
> Error: EnvironmentError: IOError: Block ctrl (CE_01_Port_40) no
> response packet
> - AssertionError: bool(buff)
>   in unsigned __int64 __cdecl ctrl_iface_impl::wait_for_ack(const bool)
>   at
> C:\cygwin64\home\jenkins\worker\Package_Windows_x64_14\work\uhd\host\lib\rf
> noc\ctrl_iface.cpp:205
>
>
> Do you have any idea why this happens?
>
> I use Visual Studio 2015 on Windows 7.
>
> Best regards,
> Mareike Hetzel
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

-- 
Julian Arnold, M.Sc.

Institute for Networked Systems
RWTH Aachen University

Kackertstrasse 9
52072 Aachen
Germany




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

Message: 2
Date: Mon, 22 May 2017 16:34:30 +0000
From: Snehasish Kar <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Receiving multiple signals using a single RX
        port
Message-ID:
        
<pn1pr01mb0368b4c786054f92b20cb7e888...@pn1pr01mb0368.indprd01.prod.outlook.com>
        
Content-Type: text/plain; charset="us-ascii"

Hello 

I wanted to know if it is possible to receive multiple signals using a single 
rx board. E.g. I want to receive both GSM downlink and uplink using the same 
port. Please let me know, how to do it.

BR
Snehasish 


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

Message: 3
Date: Mon, 22 May 2017 18:57:21 +0200
From: Evert Verduin <[email protected]>
To: Snehasish Kar <[email protected]>,     Snehasish Kar via
        USRP-users <[email protected]>,        
"[email protected]"
        <[email protected]>
Subject: Re: [USRP-users] Receiving multiple signals using a single RX
        port
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"

The Gsm duplex distance is 45 MHz.
If you Have enough IQ bandwidth, this should be NO issue. But, in the 
contruary, you are sampling loads of unwanted data.

Furthermore, signal Dynamics can be An issue.
IT is not rare that downlink is 80dB stronger then the uplink. Intermodulation 
can occur easily. Gsm downlink bands are often very crowded and used rf Powers 
are high. You need a hell of a system to keep that amount of signals intermod 
free with a high dynamic range. ( Since you want to receive signals around 
-100dBm as well )

In principle, yes it can be done. Practically you will have dynamic signal 
issues.

Evert





Snehasish Kar via USRP-users <[email protected]> schreef op 22 mei 
2017 18:34:30 CEST:
>Hello 
>
>I wanted to know if it is possible to receive multiple signals using a
>single rx board. E.g. I want to receive both GSM downlink and uplink
>using the same port. Please let me know, how to do it.
>
>BR
>Snehasish 
>_______________________________________________
>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/20170522/fbf73f89/attachment-0001.html>

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

Message: 4
Date: Mon, 22 May 2017 19:53:47 +0200
From: Christophe ALEXANDRE <[email protected]>
To: [email protected]
Subject: [USRP-users] RFNOC + GPIO
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed

Hi,

i'm using an X310. Is there any way to use
the external GPIOs inside an RFNOC block ?

  
  regards.

  Christophe ALEXANDRE
  
  





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

Message: 5
Date: Mon, 22 May 2017 21:01:26 +0300
From: ?????? ???? <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Sync of two b205mini
Message-ID:
        <CABh6qSTk8Mt=fwg+j4fjonckzyivs3k4u_1hjtolu2me4n1...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Thank you for answers.
I hope they were informative not only for me)

What i want: i playing with transceiving and receiving signals. If one
device emit signal and another receive this - all o'k. But now i playing
with channel hopping and i don't know where problem is: on emitter or
receiver side, or on both. b205mini - looks like it's bad choice. As a
temporary solution can i use some like this:
http://www.ebay.com/itm/10MHZ-Output-Sine-Wave-GPS-Displined-Clock-GPSDO-GPS-Antenna-Power-Supply-wr-/162347890705
and share to several devices with:
https://www.pasternack.com/50-ohm-sma-sp8t-pin-diode-switch-500-mhz-to-18-ghz-pe7168-p.aspx

2017-05-22 2:08 GMT+03:00 Marcus D. Leech <[email protected]>:

> On 05/21/2017 05:36 PM, ?????? ???? wrote:
>
> Marcus,
> thank you for resopnse.
>
>
> Sorry about non-informative questions. This is becouse i'm not enough
> understand what i doing.
> But i still have some dumb/interest questions:
>
> 1 Is it possible to send pps and/or 10MHz signal from host to devices? eg.
> using host as external source?
> [image: ?????????? ??????????? 2]
>
> Where would the 1PPS/10Mhz *come from* inside the host?  That's not a
> particularly standard feature.
>
> 2 Or use TR/X port as output of pps/ref reference to connect to ref port
> on another device, then use their TR/X port as output of pps/ref source to
> transmit to third device, etc.
> [image: ?????????? ??????????? 1]
> 3 Or using one of devices as "master", then via host connection share
> pps/ref signal to all another devices?
> [image: ?????????? ??????????? 3]
>
> No, these aren't viable either.  The TX/RX port is for transmitting
> signals out of the device, not for carrying a refclock, although if you
> could tune the output
>   down as low as 10MHz, you could use it as a 10Mhz reference.  But that
> isn't possible.
>
> 4 Or any software solutions for completely synchronize time and/or phase?
> eg. compute cross correlation on maded records as "post factum", or even in
> realtime.
>
> You can synchronize *time* by feeding in a common reference signal (either
> 10Mhz or 1PPS).   Such a signal is easy to generate with low-cost
>   GPSDOs, or even the octoclock-G from Ettus.
>
>
> However, the main issue is that the B205mini isn't really designed for
> mutual phase-coherence across multiple devices -- both due to the way the
>   reference "servo" works in the FPGA, and the fact that the AD9361 isn't
> configured for phase-offset sync
>
> Thank you in advance,
>
> Anik
>
>
>
> 2017-05-21 20:46 GMT+03:00 Marcus D. Leech via USRP-users <
> [email protected]>:
>
>> On 05/21/2017 06:13 AM, ?????? ???? via USRP-users wrote:
>>
>>> Hi,
>>> sorry about my horrible English.
>>>
>>> How can i synchronize my two b205mini divices? Now i cannot have any
>>> external clock/time references, but trying to do this via just uhd driver
>>> https://pastebin.com/6PNxtARp
>>> It is possible at all? Or im doing some wrong. -it's more possible)
>>>
>>> Thank you in advance,
>>>
>>> Anik
>>>
>>> Without a shared external reference, it would be very difficult,
>> depending on what you mean by "synchronize", and at what timescales.
>>
>>
>>
>>
>> _______________________________________________
>> 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/20170522/39debde1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 8197 bytes
Desc: not available
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170522/39debde1/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 10280 bytes
Desc: not available
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170522/39debde1/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 8129 bytes
Desc: not available
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170522/39debde1/attachment-0005.png>

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

Message: 6
Date: Mon, 22 May 2017 14:58:56 -0400
From: "Marcus D. Leech" <[email protected]>
To: ?????? ???? <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Sync of two b205mini
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

On 05/22/2017 02:01 PM, ?????? ???? wrote:
> Thank you for answers.
> I hope they were informative not only for me)
>
> What i want: i playing with transceiving and receiving signals. If one 
> device emit signal and another receive this - all o'k. But now i 
> playing with channel hopping and i don't know where problem is: on 
> emitter or receiver side, or on both. b205mini - looks like it's bad 
> choice. As a temporary solution can i use some like this:
> http://www.ebay.com/itm/10MHZ-Output-Sine-Wave-GPS-Displined-Clock-GPSDO-GPS-Antenna-Power-Supply-wr-/162347890705
That would be fine.

> and share to several devices with:
> https://www.pasternack.com/50-ohm-sma-sp8t-pin-diode-switch-500-mhz-to-18-ghz-pe7168-p.aspx
That is a 8-to-1   *SWITCH*, not a 10Mhz distribution amplifier.

The Ettus Octoclock or Octoclock-G (with built-in GPSDO) would give you 
an integrated solution.


>
> 2017-05-22 2:08 GMT+03:00 Marcus D. Leech <[email protected] 
> <mailto:[email protected]>>:
>
>     On 05/21/2017 05:36 PM, ?????? ???? wrote:
>>     Marcus,
>>     thank you for resopnse.
>>
>>
>>     Sorry about non-informative questions. This is becouse i'm not
>>     enough understand what i doing.
>>     But i still have some dumb/interest questions:
>>
>>     1 Is it possible to send pps and/or 10MHz signal from host to
>>     devices? eg. using host as external source?
>>     ?????????? ??????????? 2
>     Where would the 1PPS/10Mhz *come from* inside the host?  That's
>     not a particularly standard feature.
>
>>     2 Or use TR/X port as output of pps/ref reference to connect to
>>     ref port on another device, then use their TR/X port as output of
>>     pps/ref source to transmit to third device, etc.
>>     ?????????? ??????????? 1
>>     3 Or using one of devices as "master", then via host connection
>>     share pps/ref signal to all another devices?
>>     ?????????? ??????????? 3
>     No, these aren't viable either.  The TX/RX port is for
>     transmitting signals out of the device, not for carrying a
>     refclock, although if you could tune the output
>       down as low as 10MHz, you could use it as a 10Mhz reference. 
>     But that isn't possible.
>
>>     4 Or any software solutions for completely synchronize time
>>     and/or phase? eg. compute cross correlation on maded records as
>>     "post factum", or even in realtime.
>>
>     You can synchronize *time* by feeding in a common reference signal
>     (either 10Mhz or 1PPS).   Such a signal is easy to generate with
>     low-cost
>       GPSDOs, or even the octoclock-G from Ettus.
>
>
>     However, the main issue is that the B205mini isn't really designed
>     for mutual phase-coherence across multiple devices -- both due to
>     the way the
>       reference "servo" works in the FPGA, and the fact that the
>     AD9361 isn't configured for phase-offset sync
>
>>     Thank you in advance,
>>
>>     Anik
>>
>>
>>
>>     2017-05-21 20:46 GMT+03:00 Marcus D. Leech via USRP-users
>>     <[email protected] <mailto:[email protected]>>:
>>
>>         On 05/21/2017 06:13 AM, ?????? ???? via USRP-users wrote:
>>
>>             Hi,
>>             sorry about my horrible English.
>>
>>             How can i synchronize my two b205mini divices? Now i
>>             cannot have any external clock/time references, but
>>             trying to do this via just uhd driver
>>             https://pastebin.com/6PNxtARp
>>             It is possible at all? Or im doing some wrong. -it's more
>>             possible)
>>
>>             Thank you in advance,
>>
>>             Anik
>>
>>         Without a shared external reference, it would be very
>>         difficult, depending on what you mean by "synchronize", and
>>         at what timescales.
>>
>>
>>
>>
>>         _______________________________________________
>>         USRP-users mailing list
>>         [email protected] <mailto:[email protected]>
>>         http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>         <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170522/ee665fad/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 8129 bytes
Desc: not available
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170522/ee665fad/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 10280 bytes
Desc: not available
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170522/ee665fad/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 8197 bytes
Desc: not available
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170522/ee665fad/attachment-0005.png>

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

Message: 7
Date: Mon, 22 May 2017 12:47:47 -0700
From: Neel Pandeya <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] NEWSDR // Tufts University // Thr-Fri June 1-2
Message-ID:
        <cacaxmv8hpbf+lf0gidhh3py8lsthubkyfv5h0ohke7gu3tu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

*********************************************************************
                        CALL-FOR-PARTICIPATION

*********************************************************************
                            NEWSDR 2017

              New England Workshop on Software Defined Radio

                           Seventh-Annual

                          Evening Workshops
                           Thursday June 1
                           17:30 to 21:00

                          Day-Long Symposium
                           Friday June 2
                           08:00 to 16:00

                          Tufts University
                          Medford, MA, USA

                      http://www.sdr-boston.org/

                         Free Pre-Registration
                Pre-registration deadline is Friday May 26

                 Poster Submissions and Pre-Registrations
                       Accepted Until Friday May 26

*********************************************************************
                     INVITATION TO PARTICIPATE

You are cordially invited to the 2017 New England Workshop on
Software Defined Radio (NEWSDR 2017), which is the seventh installment
of an annual series of symposium and workshop events organized by
the Boston SDR User Group (SDR-Boston).

This year, NEWSDR will be held at Tufts University, and consists of
a day-long symposium on Friday, as well as several hands-on technical
workshops the evening before on Thursday. You are welcome to attend
either or both events, which are entirely free when pre-registering.

Attendance is typically about 100 people, and attendees are evenly
split between academia and industry.

*********************************************************************
                         EVENING WORKSHOPS

                          THURSDAY JUNE 1
                           17:00 to 21:00

                          Tufts University
                       Medford, Massachusetts

                              AGENDA

16:00 ? 17:30  Setup session for the Workshop Events (optional)

17:30 ? 21:00  Workshop Events

Two hands-on technical workshops are being offered in parallel:

* "SDR Using USRP E310 and Simulink"
  by MathWorks

* "FPGA Programming on the USRP with the RFNoC Framework"
  by Ettus Research

MathWorks and Ettus Research will each run a workshop on the evening
before the main event. Workshops are technical, practical, hands-on
activities in a group setting. Specific topics and further details
about the workshops is listed below. Attendance is free, but
pre-registration is required. Free pizza and soda will be provided.

*********************************************************************
                         DAY-LONG SYMPOSIUM

                           FRIDAY JUNE 2
                           08:00 to 16:00

                        Breed Memorial Hall
                         Tufts University
                        51 Winthrop Street
                       Medford, Massachusetts

                              AGENDA

07:30 to 08:00  Coffee and Light Refreshments

08:00 to 08:15  Welcome and Introduction

08:15 to 09:40  Sponsor Overview Presentations (20 minutes each)

09:40 to 10:15  Elevator-Pitch Oral Presentations
                of Poster Presenters (2 minutes each)

10:15 to 10:45  Coffee, Attendee Networking, Poster Sessions,
                Sponsor Exhibits, and Demos

10:45 to 11:45  Industry Tutorial Presentation by MediaTek:
                "Prototyping Next Generation Wireless Devices"

11:45 to 13:00  Lunch and Attendee Networking

13:00 to 14:00  Keynote Presentation by Professor Dennis Roberson

14:00 to 14:30  Coffee, Attendee Networking, Poster Sessions,
                Sponsor Exhibits, and Demos

14:30 to 15:30  Industry Tutorial Presentation by Analog Devices:
                "ADALM-PLUTO SDR Prototyping with Matlab"

15:30 to 16:00  Closing Remarks, Best Poster Award, Announcements

Keynote Speaker:
  * Professor Dennis Roberson, Illinois Institute of Technology

Technical Poster Presentations:
  *  Covering the recent work in SDR and cognitive radio technology
  *  Poster presentations are now being solicited
  *  See link at the bottom of this email to submit your abstract

Corporate Sponsors:
  *  Analog Devices
  *  Ettus Research
  *  MathWorks
  *  MediaTek Wireless

The symposium features plenary speakers, technical poster
presentation sessions, hardware and software demonstrations from the
event sponsors, and workshops from the event sponsors, all focusing
on recent work in SDR and cognitive radio technology. Free breakfast,
lunch, and coffee will be provided. Attendance is free, but advance
registration is required.

The symposium provides an excellent networking opportunity and a
terrific venue to exchange thoughts and ideas with other people
working in the SDR space.

*********************************************************************
                       WORKSHOP DESCRIPTION

                   SDR with E310 using Simulink
                            MathWorks

This tutorial focuses on demonstrating modeling SDR-based designs in
MATLAB and Simulink, and configuring and deploying on the USRP E310.
Topics presented will include modeling communication systems using
Simulink, implementing radio I/O with E310 and Simulink, and
prototyping deployment with real-time data via HW/SW co-design.

Prior knowledge of programming Xilinx Zynq SoCs with MATLAB and
Simulink, and knowledge of communications systems and hardware design
are prerequisites.

Outline:

Model Communication system using Simulink:
* Model and simulate RF signal chain and communication algorithms.
* Overview of Software Defined Radio concepts and workflows.
* Simulate a communication system that includes a transmitter,
  AD9361 transceiver, channel, and receiver (RF test environment).

Implement Radio I/O with E310 SDR and Simulink:
* Verify the operation of baseband transceiver algorithm using real
  data streamed from the AD9361 into MATLAB and Simulink.
* Overview of System objects and hardware platforms.
* Perform baseband processing in MATLAB and Simulink on received
  signal.
* Verify algorithm performance for real data versus simulated data.

Hardware-Software Co-Design for Software:
* Split and deploy Tx/Rx algorithms to PL and PS.
* Overview of Zynq HW/SW co-design workflow.
* Implement transmitter and receiver on PL/PS using HW/SW co-design
  workflow.
* Download generated code to the ARM & FPGA, and tune system
  parameters in real-time operation via Simulink.

*********************************************************************
                       WORKSHOP DESCRIPTION

        FPGA Programming on the USRP with the RFNoC Framework
                           Ettus Research

Ettus Research's RFNoC (RF Network-on-Chip) software is meant
to decrease the development time for experienced FPGA engineers
seeking to integrate IP into the USRP signal processing chain.
RFNoC is the architecture for USRP devices that use Xilinx 7-series
FPGAs (E310, E312, X300, X310). RFNoC is built around a packetized
network infrastructure in the FPGA that handles the transport of
control and sample data between the host CPU and the radio. Users
target their custom algorithms to the FPGA in the form of
Computation Engines (CE), which are processing blocks that attach to
this network. CEs act as independent nodes on the network that can
receive and transmit data to any other node (e.g., another CE, the
radio block, or the host CPU). Users can create modular,
FPGA-accelerated SDR applications by chaining CEs into a flow graph.
RFNoC is supported in UHD and GNU Radio. In this workshop, we will
present an interactive hands-on tutorial on RFNoC, including a
discussion on its design and capabilities, demonstrations of several
existing examples, and a walk-through on implementing a user-defined
CE and integrating the CE into GNU Radio.

Prerequisites:

* Attendees are expected to bring their own laptops to the workshop.
The laptop should have a minimum of 4 GB memory, 60 GB of free disk
space, one Ethernet port available, and one USB 3.0 port available.

* Attendees are expected to install VirtualBox 5.1.22 or newer.

All necessary USRP hardware will be provided in the workshop.
Attendees do not need to bring any USRP hardware.

*********************************************************************
                           REGISTRATION

  *  Pre-register for the Symposium, or for the Workshop, or both

  *  Pre-registration is required, but is completely free

  *  Pre-registration takes less than 5 minutes

  *  Pre-registration includes free meals at the event

  *  Parking available

  *  You must pre-register online

  *  Attendance, meals, parking are all limited, so please
     pre-register online as soon as possible to secure your spot

  *  Pre-registration deadline is Friday May 26

  *  See link at the bottom of this announcement to pre-register online

*********************************************************************
                               LINKS

                     Attendee Pre-registration:
                       https://goo.gl/Oy99HU

                     Poster Abstract Submission:
                       https://goo.gl/pJohKn

*********************************************************************
                      ADDITIONAL INFORMATION

             More information, and the event schedule,
            for this event can be found at our website:

                    http://www.sdr-boston.org/

*********************************************************************
                                EOF
*********************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170522/7a5b71df/attachment-0001.html>

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

Message: 8
Date: Mon, 22 May 2017 18:06:27 -0700
From: Michael West <[email protected]>
To: Christophe ALEXANDRE <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNOC + GPIO
Message-ID:
        <cam4xkrrbnfhel7st3rnp9bnvdp0rl_odb1hhappgvynncl8...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi Christophe,

Yes.  The external GPIO is controlled by the radio block, so the custom
RFNoC block would just have to generate the appropriate control packet to
the radio and handle the ACK packet coming back.  There will be some random
amount of latency with that approach.  If you need deterministic timing of
the GPIO signals, you can supply a timestamp in the packet from your custom
block, use timed commands from the host, or simply rewire the GPIO signals
directly to the custom block.

Regards,
Michael

On Mon, May 22, 2017 at 10:53 AM, Christophe ALEXANDRE via USRP-users <
[email protected]> wrote:

> Hi,
>
> i'm using an X310. Is there any way to use
> the external GPIOs inside an RFNOC block ?
>
>   regards.
>
>  Christophe ALEXANDRE
>
>
>
> _______________________________________________
> 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/20170522/23f9e033/attachment-0001.html>

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

Message: 9
Date: Tue, 23 May 2017 09:39:02 +0800
From: liu Jong <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] UBX160 and TrinRx on one X310
Message-ID:
        <CAEui2n3bNu2vwsYa=g+qm1cgjqe29q_huvsc_5goirjrure...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Dear all,
Can we use UBX160 and TrinRx on one X310 and achieve 3 RX and 1 TX?

thank you.

best regards
Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170523/911e3fad/attachment-0001.html>

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

Message: 10
Date: Tue, 23 May 2017 08:38:41 +0200
From: Christophe ALEXANDRE <[email protected]>
To: Michael West <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNOC + GPIO
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

thank you for your quick answer.

do you have any figure about the random latency ?

is there any documentation/example somewhere about :

1) generating the appropriate control packet

2) rewiring the GPIO signals directly to the custom block

  
  regards.


  Christophe ALEXANDRE
  

Le 23/05/2017 ? 03:06, Michael West a ?crit :
> Hi Christophe,
>
> Yes.  The external GPIO is controlled by the radio block, so the 
> custom RFNoC block would just have to generate the appropriate control 
> packet to the radio and handle the ACK packet coming back.  There will 
> be some random amount of latency with that approach.  If you need 
> deterministic timing of the GPIO signals, you can supply a timestamp 
> in the packet from your custom block, use timed commands from the 
> host, or simply rewire the GPIO signals directly to the custom block.
>
> Regards,
> Michael
>
> On Mon, May 22, 2017 at 10:53 AM, Christophe ALEXANDRE via USRP-users 
> <[email protected] <mailto:[email protected]>> wrote:
>
>     Hi,
>
>     i'm using an X310. Is there any way to use
>     the external GPIOs inside an RFNOC block ?
>
>       regards.
>
>      Christophe ALEXANDRE
>
>
>
>     _______________________________________________
>     USRP-users mailing list
>     [email protected] <mailto:[email protected]>
>     http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>     <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>
>

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

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

Message: 11
Date: Tue, 23 May 2017 08:39:11 +0100
From: Derek Kozel <[email protected]>
To: liu Jong <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] UBX160 and TrinRx on one X310
Message-ID:
        <CAA+K=ttcnd4_bwyilxn0coqzgygbsop3dix4tng4zfdikft...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hello Jon,

Currently it is not possible to receive three time aligned sample streams
in that configuration. You can use the TwinRX or the UBX separately. We
hope to change that in the future but do not have a time estimate for
adding that feature.

Regards,
Derek

On Tue, May 23, 2017 at 2:39 AM, liu Jong via USRP-users <
[email protected]> wrote:

> Dear all,
> Can we use UBX160 and TrinRx on one X310 and achieve 3 RX and 1 TX?
>
> thank you.
>
> best regards
> Jon
>
> _______________________________________________
> 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/20170523/8d45726b/attachment-0001.html>

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

Message: 12
Date: Tue, 23 May 2017 16:04:04 +0800
From: liu Jong <[email protected]>
To: Derek Kozel <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] UBX160 and TrinRx on one X310
Message-ID:
        <CAEui2n2C+hP2ynp3hDFAe-b=6q61qbnoaocpbue4yxuortx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Derek,
thank you.

2017-05-23 15:39 GMT+08:00 Derek Kozel <[email protected]>:

> Hello Jon,
>
> Currently it is not possible to receive three time aligned sample streams
> in that configuration. You can use the TwinRX or the UBX separately. We
> hope to change that in the future but do not have a time estimate for
> adding that feature.
>
> Regards,
> Derek
>
> On Tue, May 23, 2017 at 2:39 AM, liu Jong via USRP-users <
> [email protected]> wrote:
>
>> Dear all,
>> Can we use UBX160 and TrinRx on one X310 and achieve 3 RX and 1 TX?
>>
>> thank you.
>>
>> best regards
>> Jon
>>
>> _______________________________________________
>> 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/20170523/6712d1d3/attachment-0001.html>

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

Message: 13
Date: Tue, 23 May 2017 11:40:04 +0200
From: Christophe ALEXANDRE <[email protected]>
To: [email protected]
Subject: [USRP-users] GRC + RFNoC + Radio Loopback
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"

Hi,

i'm using an X310 with 2 BasicRx and 2 BasicTx and a fresh install of RFNoC.

i'm trying to understand how i can use RFNoC with gnuradio companion
and how i can mix gnuradio software blocks and RFNoC blocks.

With the help of Ettus documentations, i think i understand the idea
except in one case, when i try to use both Rx and Tx radio blocks (and i 
can't
see any examples in ~rfnoc/src/gr-ettus/examples/rfnoc).

My first test is a simple loopback :




when i run this flowgraph, there is no errors, but nothing happens
and the rf0 and rf1 leds are off. There is no signal copy
from rf1:Rx2 to rf0:Tx.

if i understand clearly the problem explained here :

https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/

this is a timestamp problem on the Tx side. I've tried to follow the 
proposed solution
(Step 2: Enable Streamer), but without success.

But if the flowgraph go back to the host doing nothing (add a 0 
constant), it works
(i suppose that gnuradio creates the necessary timestamps for the Tx side) :




Leds are on and the input signal is going from rf1:Rx2 to rf0:Tx.


Is there any better way to solve this problem ?

  
  regards.


  Christophe ALEXANDRE
  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170523/8c6a9a54/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mhchgkcieefppgkn.png
Type: image/png
Size: 48211 bytes
Desc: not available
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170523/8c6a9a54/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oblcnkeooilafnfm.png
Type: image/png
Size: 51473 bytes
Desc: not available
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170523/8c6a9a54/attachment-0003.png>

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

Message: 14
Date: Tue, 23 May 2017 10:41:56 -0400
From: Jonathon Pendlum <[email protected]>
To: Christophe ALEXANDRE <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] GRC + RFNoC + Radio Loopback
Message-ID:
        <cagdo0utvfubmoywamsrnqe0kzmwzwfvb7e9yhgxhszdophm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi Christophe,

Out of the box, all RFNoC flowgraphs require at least one connection back
to the host. This is a limitation of UHD that we plan on fixing. That is
also why your second flowgraph worked. We are having some discussions on
making a block to allow loopback, but I can't give you any dates when that
will be done. If you want to give it a try yourself, one possibility would
be to make a custom rfnoc block with 2 inputs / 1 output. One of the inputs
would be from the rx radio, the other a "dummy" connection from the host.
The output would connect to the tx radio. The block would also need to
adjust vita time or just strip it off the header.



Jonathon

On Tue, May 23, 2017 at 5:40 AM, Christophe ALEXANDRE via USRP-users <
[email protected]> wrote:

> Hi,
>
> i'm using an X310 with 2 BasicRx and 2 BasicTx and a fresh install of
> RFNoC.
>
> i'm trying to understand how i can use RFNoC with gnuradio companion
> and how i can mix gnuradio software blocks and RFNoC blocks.
>
> With the help of Ettus documentations, i think i understand the idea
> except in one case, when i try to use both Rx and Tx radio blocks (and i
> can't
> see any examples in ~rfnoc/src/gr-ettus/examples/rfnoc).
>
> My first test is a simple loopback :
>
>
>
>
> when i run this flowgraph, there is no errors, but nothing happens
> and the rf0 and rf1 leds are off. There is no signal copy
> from rf1:Rx2 to rf0:Tx.
>
> if i understand clearly the problem explained here :
>
> https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/
>
> this is a timestamp problem on the Tx side. I've tried to follow the
> proposed solution
> (Step 2: Enable Streamer), but without success.
>
> But if the flowgraph go back to the host doing nothing (add a 0 constant),
> it works
> (i suppose that gnuradio creates the necessary timestamps for the Tx side)
> :
>
>
>
>
> Leds are on and the input signal is going from rf1:Rx2 to rf0:Tx.
>
>
> Is there any better way to solve this problem ?
>
>
>  regards.
>
>
>  Christophe ALEXANDRE
>
>
>
>
> _______________________________________________
> 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/20170523/d1a4c04c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mhchgkcieefppgkn.png
Type: image/png
Size: 48211 bytes
Desc: not available
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170523/d1a4c04c/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oblcnkeooilafnfm.png
Type: image/png
Size: 51473 bytes
Desc: not available
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170523/d1a4c04c/attachment-0003.png>

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

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 81, Issue 23
******************************************

Reply via email to