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. USRP B210 does not synchronize internal clock to ClockTamer
      (George Vardakis)
   2. Re: Custom RFNoC block connection through UHD API and
      accessing front panel GPIO (Jean Michel Cioranesco (jm))


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

Message: 1
Date: Mon, 12 Jun 2017 14:38:37 +0300
From: George Vardakis <[email protected]>
To: [email protected]
Subject: [USRP-users] USRP B210 does not synchronize internal clock to
        ClockTamer
Message-ID:
        <caghzxvnseighi06rtmrazqg8pujbmrkec+wgtss_usidwfu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hello all,

I have two USRP B210 devices and a ClockTamer. For my MIMO application, i
need the frequencies of the receiving streams of the two USRPs to match
perfectly. I connect the ClockTamer to the devices, and set the output
frequency of the clocktamer at 10MHz. To test whether it works properly, i
transmit a sine wave from another device, and receive from my two USRPs.
What i observe when i set the output frequency of the tamer, is that while
at the first USRP the frequency of the received signal shifts (sign that
the internal clock becomes in sync with the external), the signal received
by the other USRP does not have the same behavior. In fact it does not
shift at all.The result is that the the frequencies of the receiving
streams of the different USRPs have a small offset. If i set the output
frequency of the clocktamer to 10MHz + 1 Hz, or +2 Hz, then the signal of
the first USRP shifts a bit and i can make it match the other USRP's
signal, but i do not think that is acqurate. In a few words, the problem is
that it seems that the one USRP obeys the external clock, while the other
does not. In both USRP source blocks i have set the "Clock source" option
to external and left the "Time source" option at Default. I have tested the
sma cables of the ClockTamer and they seem fine. I also checked that the
clocktamer outputs that i use. work. Does anyone have any idea what might
be wrong? Maybe a hardware issue?

Thank you for your time!


George Vardakis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170612/4dd7edc3/attachment-0001.html>

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

Message: 2
Date: Mon, 12 Jun 2017 14:55:30 +0000
From: "Jean Michel Cioranesco (jm)" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Custom RFNoC block connection through UHD
        API and accessing front panel GPIO
Message-ID: <737E55BBE338284C9440EEDF7BAAC22F579D5F@lhreml507-mbb>
Content-Type: text/plain; charset="utf-8"

Hi Jonathon,

Thank you for your answers. I have some additional questions if I may.

1.       Regarding the example code to connect RFNoC blocks using UHD API, you 
mentioned it is straight forward. Could you please provide this reference code 
or point it even if there is no tutorial for it, it would be very useful.

2.       For connecting the GPIO to a custom RFNoC block, I will follow your 
first option. I am modifying the custom core interface, but then 
rfnoc_ce_auto_inst_x310.v which instantiate the custom core gets overwritten by 
gen_rfnoc_inst.py when I run compilation. What would be the proper way of 
dealing with this automatically generated file to add extra I/Os. May be I 
could bypass the gen_rfnoc_inst.py script and use a locally modified file? Is 
there an easy way of doing this?

Many thanks for your help and patience

jm

Hi,

Now I am encountering some difficulties in the next steps and I hope you guys 
can help me.
I am unsure how I could connect the usrp block on the receiver side. I was 
thinking to use the following script (but I could not successfully verify it is 
connected on the datapath):
./rfnoc_rx_to_file --radio-id 0 --block-id customblock
Is this how you guys are connecting your custom blocks? Do you have a tutorial 
or other information that would help me connect the block successfully?
I would like to use the UHD API directly to make the connection in RFNoC if 
possible.

That will work and is a good example to follow on how to build your own RFNoC 
UHD apps. We do not have a pure UHD API tutorial on how to connect blocks yet, 
although the example code is very straightforward.

My second question relates to the RTL design of the custom block. I would like 
to connect an output of my custom core directly to one of the frontpanel GPIO 
pin.
Is there any example out there on how to do that or other useful information?

The GPIO is connected to the radio core, so you have two options: 1) Modify the 
RTL to connect one of the GPIO pins to your block instead of the radio core or 
2) Send a command packet to the radio core to set the GPIO.

My third and final question is  about the UHD version compability of the API, I 
am now working under UHD_4.0.0.rfnoc-0-unknown to develop the custom FPGA 
image. Will the software I will develop to connect the RFNoC blocks be portable 
to UHD version 3.10.1.1?

While behind the scenes UHD is using RFNoC in 3.10+, we will not enable full 
RFNoC support in UHD until the 4.0 release.

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

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

Subject: Digest Footer

_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


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

End of USRP-users Digest, Vol 82, Issue 12
******************************************

Reply via email to