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: Where can I find the latest OFDM support materials
(Swanson, Craig)
2. Re: E310 (RFNoC not PC host) (Ignazio Finazzi)
3. Re: Where can I find the latest OFDM support materials
(Marcus M?ller)
4. Re: Unable to create Vivado projekt or to build clean repo
(Jonathon Pendlum)
5. Re: building an E310 RFNoC FPGA image with HLS (Jonathon Pendlum)
6. Re: Trigger Tx on FPGA (Jonathon Pendlum)
7. Re: Can you make a flow graph with only RFNoC blocks?
(Jonathon Pendlum)
8. Re: Trigger Tx on FPGA (Zhihong Luo)
9. Re: USRP x310 " ddr3_32bit: Code generation aborted:
Unconfigured MIG instance" (Ryan Marlow)
10. Re: monitor with E310/312 (john liu)
11. Re: Errors when building X310_RFNOC_HGS in X300 for
rfnoc-ofdm branch (Jonathon Pendlum)
12. Re: Style Guide for referencing USRP or Ettus (Matt Ettus)
13. Re: E310 GPSDO clock reference (Claudio Cicconetti)
14. Can I get arbitrary sampling rate with X300+UBX? (Vladimir)
15. How to know if a radio is currently in use? (Claudio Cicconetti)
16. Re: Can I get arbitrary sampling rate with X300+UBX?
([email protected])
17. Re: E310 GPSDO clock reference ([email protected])
----------------------------------------------------------------------
Message: 1
Date: Sun, 10 Apr 2016 16:02:52 +0000
From: "Swanson, Craig" <[email protected]>
To: Dave NotTelling <[email protected]>
Cc: Martin Braun <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Where can I find the latest OFDM support
materials
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Dave,
Thanks for the heads up. This led me to reading about Bastian'?s AGC paper and
running it on an FPGA which I am assuming is RFNoC. Do you know how we can get
the FPGA code?
Thanks,
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
________________________________
From: Dave NotTelling <[email protected]>
Sent: Tuesday, March 22, 2016 8:44 AM
To: Swanson, Craig
Cc: Martin Braun; [email protected]
Subject: Re: [USRP-users] Where can I find the latest OFDM support materials
Craig,
Check out https://github.com/bastibl/gr-ieee802-11.
-Dave
On Mon, Mar 21, 2016 at 7:57 PM, Swanson, Craig via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Martin,
Where can I get your latest gnuradio code for the transmitter and receiver for
OFDM? I am aware of the rfnoc-ofdm git in fpga, but I wanted to start out with
the flowgraph UHD code that doesn't use RFNoC.
Is there a repository for presentations, tutorials, and flowgraphs?
Thanks,
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th Street NW
Atlanta, GA 30318
Cell: 770-298-9156<tel:770-298-9156>
http://www.gtri.gatech.edu
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[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/20160410/bafd0362/attachment-0001.html>
------------------------------
Message: 2
Date: Sun, 10 Apr 2016 18:17:12 +0000 (UTC)
From: Ignazio Finazzi <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] E310 (RFNoC not PC host)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Philip Balister via USRP-users <usrp-users@...> writes:
>
> This message is misleading in the E310 case.
>
> For an E310 in network mode, what is important is the versions of uhd
> must match. release-4 has uhd-3.9.2 installed, so you must use uhd-3.9.2
> on the PC also.
>
> Philip
Thanks for your reply, Philip.
Yes i have the 3.9.2 version (lastest) installed on my host PC.
------------------------------
Message: 3
Date: Sun, 10 Apr 2016 20:53:48 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Where can I find the latest OFDM support
materials
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
No, that was done on a N210, which is a second generation device and
predates RFNoC (and can't be supported by RFNoC).
Best regards,
Marcus
On 10.04.2016 18:02, Swanson, Craig via USRP-users wrote:
>
> Dave,
>
> Thanks for the heads up. This led me to reading about Bastian'?s AGC
> paper and running it on an FPGA which I am assuming is RFNoC. Do you
> know how we can get the FPGA code?
>
>
> Thanks,
>
> Craig
>
>
> *Craig F. Swanson*
> */Research Engineer II
> /*
> */Information and Communications Laboratory/*
> */Communications, Systems, and Spectrum Division/*
> /Georgia Tech Research Institute/
> /Room 560
> 250 14th St NW
> /
> /Atlanta, GA 30318/
> /Cell: 770.298.9156/
> http://www.gtri.gatech.edu
> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
>
> ------------------------------------------------------------------------
> *From:* Dave NotTelling <[email protected]>
> *Sent:* Tuesday, March 22, 2016 8:44 AM
> *To:* Swanson, Craig
> *Cc:* Martin Braun; [email protected]
> *Subject:* Re: [USRP-users] Where can I find the latest OFDM support
> materials
>
> Craig,
>
> Check out https://github.com/bastibl/gr-ieee802-11.
>
> -Dave
>
> On Mon, Mar 21, 2016 at 7:57 PM, Swanson, Craig via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> Martin,
>
> Where can I get your latest gnuradio code for the transmitter and
> receiver for OFDM? I am aware of the rfnoc-ofdm git in fpga, but
> I wanted to start out with the flowgraph UHD code that doesn?t use
> RFNoC.
>
> Is there a repository for presentations, tutorials, and flowgraphs?
>
>
>
> Thanks,
>
> Craig
>
>
>
> *Craig F. Swanson*
>
> *Research Engineer II*
>
> *Information and Communications Laboratory*
>
> *Communications, Systems, and Spectrum Division*
>
> Georgia Tech Research Institute
>
> Room 560
>
> 250 14^th Street NW
>
> Atlanta, GA 30318
>
> Cell: 770-298-9156 <tel:770-298-9156>
>
> http://www.gtri.gatech.edu
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160410/b745d4f1/attachment-0001.html>
------------------------------
Message: 4
Date: Sun, 10 Apr 2016 12:52:24 -0700
From: Jonathon Pendlum <[email protected]>
To: Patrick Berger <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Unable to create Vivado projekt or to build
clean repo
Message-ID:
<CAGdo0uT=r+8hzdxyomybu84fgrsbjad5sznspshkmdaqkl1...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Patrick,
What branch are you on? rfnoc-devel or rfnoc-ofdm? Did you run source
setupenv.sh in the usrp3/top/x300/ directory? What is it output?
Jonathon
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160410/bff28bcf/attachment-0001.html>
------------------------------
Message: 5
Date: Sun, 10 Apr 2016 13:00:40 -0700
From: Jonathon Pendlum <[email protected]>
To: [email protected]
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] building an E310 RFNoC FPGA image with HLS
Message-ID:
<CAGdo0uQX-uMhYE9sXxuyfEsfn=yzcvb6upn5ampypkq-y2t...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi An Qi,
To build an image using HLS, you need to include a block that uses HLS and
then run 'make E310_RFNOC_HLS'. To try it out, we have an example block
that can use HLS, noc_block_addsub (usrp3/lib/rfnoc/noc_block_addsub.v). To
build an image with that block in it for the E310, you would would add
noc_block_addsub (with parameter USE_HLS set to 1) to
rfnoc_ce_auto_inst_e310.v and then run 'make E310_RFNOC_HLS'. If you want
to use HLS in your own blocks, you can add your C/C++ code in the directory
/usrp3/lib/hls using addsub_hls as an example.
Jonathon
On Fri, Apr 8, 2016 at 12:45 PM, An Qi Zhang via USRP-users <
[email protected]> wrote:
> Hello,
>
> I was building the RFNoC FPGA image for the E310 and noticed there was an
> option to build the FPGA image using Vivado HLS. I was wondering if you had
> a complete set of instructions for building a custom FPGA image using the
> E310_RFNOC_HLS option.
>
> Thanks,
> An Qi
>
>
>
>
> _______________________________________________
> 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/20160410/58b09768/attachment-0001.html>
------------------------------
Message: 6
Date: Sun, 10 Apr 2016 13:09:53 -0700
From: Jonathon Pendlum <[email protected]>
To: Zhihong Luo <[email protected]>
Cc: Martin Braun <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Trigger Tx on FPGA
Message-ID:
<cagdo0usrop1gtkejv30zaj3cbprzjzi+kahgw+b_mhgu7sg...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Zhihong,
No need for a split stream. You would set INPUT_PORTS=2 and OUTPUT_PORTS=1
on noc_shell and connect two AXI Wrapper instances to noc_shell for the two
input block ports. Only one of the AXI wrapper's output (str_src) will be
connected noc_shell and you'll need to manually setup the header
(s_axis_data_tuser) since you cannot use SIMPLE_MODE in this configuration.
To hold off TX, just don't send any data to the AXI wrapper module until
you trigger on RX. Or if you want the lowest latency possible, send the TX
waveform minus one sample and when you trigger, send the final sample (with
tlast asserted).
Jonathon
On Wed, Apr 6, 2016 at 2:15 PM, Zhihong Luo <[email protected]> wrote:
> Hi Jonathon,
>
> I have a look at the two examples involving multiple ports:
> *noc_block_addsub.v,
> **noc_block_split_stream.v*. They have the same format, deframer ->
> split_stream_fifo -> framer. Can I instead use split_stream_fifo at first,
> then separate axi_wrappers, for the hope that the axi_wrapper can take care
> of the possible timing issues for me?
>
> Thanks,
> Zhihong
>
> On Wed, Apr 6, 2016 at 4:19 PM, Zhihong Luo <[email protected]> wrote:
>
>> Jonathon,
>>
>> Thanks for the reply. It looks much cleaner in a flow-graph :)
>>
>> I wonder whether this is the right way to make a multiple input/output
>> port block: set the input/output port number in the noc_shell, then create
>> one axi_wrapper for each port. Do I need to use blocks like the
>> split_stream_fifo.v used?
>>
>> To hold off sending the TX, I can change the eob bit in the
>> s_axis_data_tuser, right?
>>
>> Thanks a lot,
>> Zhihong
>>
>>
>>
>> On Wed, Apr 6, 2016 at 3:37 PM, Jonathon Pendlum <
>> [email protected]> wrote:
>>
>>> Hi Zhihong,
>>>
>>> Make your "trigger" block have two input ports, one from the host and
>>> one from Radio RX. Have your block consume the Radio RX data and hold off
>>> sending the TX waveform samples from the host until your trigger condition
>>> is satisfied. Your flowgraph would look something like this:
>>>
>>> Host --> Trigger block --> Radio TX
>>> ^----------- Radio RX
>>>
>>>
>>>
>>> Jonathon
>>>
>>> On Wed, Apr 6, 2016 at 12:17 PM, Zhihong Luo via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> Hi Martin,
>>>>
>>>> Thanks a lot for the advice, I am looking into it. I think what really
>>>> confuses me is how to "trigger" it from a different block. As I said, I
>>>> built a block on the RX chain for detection, how can I send the trigger
>>>> signal to the TX side (either radio.v or a TX RFNoC block)?
>>>>
>>>> Once I get this communication work, I can control the state by changing
>>>> the eob ( 1 for stop, 0 for start), is it right?
>>>>
>>>> Thanks,
>>>> Zhihong
>>>>
>>>> On Wed, Apr 6, 2016 at 12:51 PM, Martin Braun via USRP-users <
>>>> [email protected]> wrote:
>>>>
>>>>> For an example, you can have a look at the fosphor block, which uses
>>>>> EOB
>>>>> to keep track of state.
>>>>>
>>>>> Cheers,
>>>>> Martin
>>>>>
>>>>> On 04/05/2016 11:27 AM, Zhihong Luo wrote:
>>>>> > Hi Martin,
>>>>> >
>>>>> > Thanks a lot for the reply!
>>>>> >
>>>>> > Can you be more specific on how to do this on fpga? I don't know how
>>>>> to
>>>>> > control radio from a custom RFNoC block. For eob, do you mean eob in
>>>>> the
>>>>> > new_tx_control.v? I am confused by what eob, eop, odd stand for.
>>>>> >
>>>>> > Thanks,
>>>>> > Zhihong
>>>>> >
>>>>> > 2016?4?5?????Martin Braun via USRP-users
>>>>> > <[email protected] <mailto:[email protected]>> ???
>>>>> >
>>>>> > You can simply not output anything until your trigger condition
>>>>> is met,
>>>>> > or you could assert eob on your trigger.
>>>>> >
>>>>> > Cheers,
>>>>> > Martin
>>>>> >
>>>>> > On 04/02/2016 01:27 PM, Zhihong Luo via USRP-users wrote:
>>>>> > > Hi all,
>>>>> > >
>>>>> > > I try to implement a RFNoC detection block in RX, which should
>>>>> trigger
>>>>> > > TX when it observes a certain pattern of the received signal.
>>>>> Is
>>>>> > there a
>>>>> > > way to do this on FPGA? Because if I do this on PC, it seems
>>>>> very
>>>>> > > difficult to control the timing of the Tx. Thanks a lot for
>>>>> any help.
>>>>> > >
>>>>> > > Thanks,
>>>>> > > Zhihong
>>>>> > >
>>>>> > >
>>>>> > > _______________________________________________
>>>>> > > USRP-users mailing list
>>>>> > > [email protected] <javascript:;>
>>>>> > >
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>> > >
>>>>> >
>>>>> >
>>>>> > _______________________________________________
>>>>> > USRP-users mailing list
>>>>> > [email protected] <javascript:;>
>>>>> >
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>> >
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> [email protected]
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160410/2eba6249/attachment-0001.html>
------------------------------
Message: 7
Date: Sun, 10 Apr 2016 13:35:33 -0700
From: Jonathon Pendlum <[email protected]>
To: Hunter DeJarnette <[email protected]>
Cc: Martin Braun <[email protected]>,
"[email protected]" <[email protected]>, Ian
Buckley
<[email protected]>
Subject: Re: [USRP-users] Can you make a flow graph with only RFNoC
blocks?
Message-ID:
<cagdo0uqks_ybntge1xmufnz27+x0mgz5ykyoss1tbpyzpo8...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Hunter,
One option is to use a Keep One in N block to ensure the data coming back
to the host is at a low rate to prevent overflows.
Jonathon
On Fri, Apr 8, 2016 at 9:11 AM, Hunter DeJarnette via USRP-users <
[email protected]> wrote:
> I'm interested in making the changes Ian suggested, by connecting the DDC
> to the DUC in order to send sample directly from RX to TX without going
> through the host. I'm wondering if I made this change and then routed
> dummy samples into the host so that the radio turned on, wouldn't it 'lose'
> samples since the host can't keep up with the FPGA, and therefore cause the
> radio to turn on and off? How can I make sure that the RX and TX remain on
> in this configuration?
>
> Ians comments were here:
>
>
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-May/013840.html
>
> On Wed, Apr 6, 2016 at 12:47 PM, Martin Braun via USRP-users <
> [email protected]> wrote:
>
>> Just wanted to confirm this is still accurate. We'll keep you updated
>> here!
>>
>> Cheers,
>> Martin
>>
>> On 04/05/2016 02:55 PM, Sylvain Munaut via USRP-users wrote:
>> > Hi,
>> >
>> >
>> >> Is there a way that I can route samples from rx to tx without going to
>> the
>> >> host using RFNoC?
>> >
>> > Not at the moment.
>> >
>> > Search the archive, it's been discussed several times.
>> >
>> > It's meant to be supported and is being worked on, but it's currently
>> > not working.
>> >
>> > Cheers,
>> >
>> > Sylvain
>> >
>> > _______________________________________________
>> > USRP-users mailing list
>> > [email protected]
>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> >
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160410/7d2f2daf/attachment-0001.html>
------------------------------
Message: 8
Date: Mon, 11 Apr 2016 04:39:34 +0800
From: Zhihong Luo <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: Martin Braun <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Trigger Tx on FPGA
Message-ID:
<CAH4wXLopStkynk7_TXRhy7OJzn=y97rzqfo+uex7xwgfnoc...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Jonathon,
Thanks a lot for the reply! Yes, I'll use two axi_wrappers for this, so
that I don't need to write deframer, fifo and framer, etc by myself.
"To hold off TX, just don't send any data to the AXI wrapper module until
you trigger on RX". To do this, do you mean deassert the
s_axis_data_tvalid? I am sorry but I did not get the lowest latency
method. Can you explain a little more?
Thanks,
Zhihong
On Mon, Apr 11, 2016 at 4:09 AM, Jonathon Pendlum <
[email protected]> wrote:
> Hi Zhihong,
>
> No need for a split stream. You would set INPUT_PORTS=2 and OUTPUT_PORTS=1
> on noc_shell and connect two AXI Wrapper instances to noc_shell for the two
> input block ports. Only one of the AXI wrapper's output (str_src) will be
> connected noc_shell and you'll need to manually setup the header
> (s_axis_data_tuser) since you cannot use SIMPLE_MODE in this configuration.
>
> To hold off TX, just don't send any data to the AXI wrapper module until
> you trigger on RX. Or if you want the lowest latency possible, send the TX
> waveform minus one sample and when you trigger, send the final sample (with
> tlast asserted).
>
>
>
> Jonathon
>
> On Wed, Apr 6, 2016 at 2:15 PM, Zhihong Luo <[email protected]> wrote:
>
>> Hi Jonathon,
>>
>> I have a look at the two examples involving multiple ports:
>> *noc_block_addsub.v,
>> **noc_block_split_stream.v*. They have the same format, deframer ->
>> split_stream_fifo -> framer. Can I instead use split_stream_fifo at first,
>> then separate axi_wrappers, for the hope that the axi_wrapper can take care
>> of the possible timing issues for me?
>>
>> Thanks,
>> Zhihong
>>
>> On Wed, Apr 6, 2016 at 4:19 PM, Zhihong Luo <[email protected]> wrote:
>>
>>> Jonathon,
>>>
>>> Thanks for the reply. It looks much cleaner in a flow-graph :)
>>>
>>> I wonder whether this is the right way to make a multiple input/output
>>> port block: set the input/output port number in the noc_shell, then create
>>> one axi_wrapper for each port. Do I need to use blocks like the
>>> split_stream_fifo.v used?
>>>
>>> To hold off sending the TX, I can change the eob bit in the
>>> s_axis_data_tuser, right?
>>>
>>> Thanks a lot,
>>> Zhihong
>>>
>>>
>>>
>>> On Wed, Apr 6, 2016 at 3:37 PM, Jonathon Pendlum <
>>> [email protected]> wrote:
>>>
>>>> Hi Zhihong,
>>>>
>>>> Make your "trigger" block have two input ports, one from the host and
>>>> one from Radio RX. Have your block consume the Radio RX data and hold off
>>>> sending the TX waveform samples from the host until your trigger condition
>>>> is satisfied. Your flowgraph would look something like this:
>>>>
>>>> Host --> Trigger block --> Radio TX
>>>> ^----------- Radio RX
>>>>
>>>>
>>>>
>>>> Jonathon
>>>>
>>>> On Wed, Apr 6, 2016 at 12:17 PM, Zhihong Luo via USRP-users <
>>>> [email protected]> wrote:
>>>>
>>>>> Hi Martin,
>>>>>
>>>>> Thanks a lot for the advice, I am looking into it. I think what really
>>>>> confuses me is how to "trigger" it from a different block. As I said, I
>>>>> built a block on the RX chain for detection, how can I send the trigger
>>>>> signal to the TX side (either radio.v or a TX RFNoC block)?
>>>>>
>>>>> Once I get this communication work, I can control the state by
>>>>> changing the eob ( 1 for stop, 0 for start), is it right?
>>>>>
>>>>> Thanks,
>>>>> Zhihong
>>>>>
>>>>> On Wed, Apr 6, 2016 at 12:51 PM, Martin Braun via USRP-users <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> For an example, you can have a look at the fosphor block, which uses
>>>>>> EOB
>>>>>> to keep track of state.
>>>>>>
>>>>>> Cheers,
>>>>>> Martin
>>>>>>
>>>>>> On 04/05/2016 11:27 AM, Zhihong Luo wrote:
>>>>>> > Hi Martin,
>>>>>> >
>>>>>> > Thanks a lot for the reply!
>>>>>> >
>>>>>> > Can you be more specific on how to do this on fpga? I don't know
>>>>>> how to
>>>>>> > control radio from a custom RFNoC block. For eob, do you mean eob
>>>>>> in the
>>>>>> > new_tx_control.v? I am confused by what eob, eop, odd stand for.
>>>>>> >
>>>>>> > Thanks,
>>>>>> > Zhihong
>>>>>> >
>>>>>> > 2016?4?5?????Martin Braun via USRP-users
>>>>>> > <[email protected] <mailto:[email protected]>>
>>>>>> ???
>>>>>> >
>>>>>> > You can simply not output anything until your trigger condition
>>>>>> is met,
>>>>>> > or you could assert eob on your trigger.
>>>>>> >
>>>>>> > Cheers,
>>>>>> > Martin
>>>>>> >
>>>>>> > On 04/02/2016 01:27 PM, Zhihong Luo via USRP-users wrote:
>>>>>> > > Hi all,
>>>>>> > >
>>>>>> > > I try to implement a RFNoC detection block in RX, which
>>>>>> should trigger
>>>>>> > > TX when it observes a certain pattern of the received signal.
>>>>>> Is
>>>>>> > there a
>>>>>> > > way to do this on FPGA? Because if I do this on PC, it seems
>>>>>> very
>>>>>> > > difficult to control the timing of the Tx. Thanks a lot for
>>>>>> any help.
>>>>>> > >
>>>>>> > > Thanks,
>>>>>> > > Zhihong
>>>>>> > >
>>>>>> > >
>>>>>> > > _______________________________________________
>>>>>> > > USRP-users mailing list
>>>>>> > > [email protected] <javascript:;>
>>>>>> > >
>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>> > >
>>>>>> >
>>>>>> >
>>>>>> > _______________________________________________
>>>>>> > USRP-users mailing list
>>>>>> > [email protected] <javascript:;>
>>>>>> >
>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>> >
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> USRP-users mailing list
>>>>>> [email protected]
>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> [email protected]
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160411/ec7707ca/attachment-0001.html>
------------------------------
Message: 9
Date: Sun, 10 Apr 2016 17:11:50 -0400
From: Ryan Marlow <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP x310 " ddr3_32bit: Code generation
aborted: Unconfigured MIG instance"
Message-ID:
<CADVE_uxtFeXG=oq5vdkkwo-skhaaifp-e+8m6qnve80fu3r...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hey All,
I believe I resolved the issue. I suppose the IP versions in Vivado 15.4
for the ddr3_32bit core is incompatible with the configuration provided in
the repo. I switched to the recommended 2015.2 version and the error did
not occur.
Best,
Ryan Marlow
On Fri, Apr 8, 2016 at 2:58 AM, Ryan Marlow <[email protected]> wrote:
> Hello all,
> I am trying to build an image for the usrp x310 in vivado 2015.4.
> While building the ddr3_32bit IP for the project, I get a read out like
> this:
>
>
>
> ========================================================
>
> BUILDER: Building IP ddr3_32bit
>
> ========================================================
>
> BUILDER: Staging IP in build directory...
>
> Reserving IP location:
>> /home/rynmrlw/pybombs-prefix/src/uhd/fpga-src/fpga/usrp3/top/x300/build-ip/xc7k410tffg900-2/ddr3_32bit
>
> BUILDER: Retargeting IP to part xc7k410tffg900-2...
>
> BUILDER: Building IP...
>
>
>> ****** Vivado v2015.4 (64-bit)
>
> **** SW Build 1412921 on Wed Nov 18 09:44:32 MST 2015
>
> **** IP Build 1412160 on Tue Nov 17 13:47:24 MST 2015
>
> ** Copyright 1986-2015 Xilinx, Inc. All Rights Reserved.
>
>
>> source
>> /home/rynmrlw/pybombs-prefix/src/uhd/fpga-src/fpga/usrp3/top/../tools/scripts/viv_generate_ip.tcl
>
> # set xci_file $::env(XCI_FILE) ;
>
> # set part_name $::env(PART_NAME) ;
>
> # set gen_example_proj $::env(GEN_EXAMPLE) ;
>
> # set synth_ip $::env(SYNTH_IP) ;
>
> # set ip_name [file rootname [file tail $xci_file]] ;
>
> # file delete -force "$xci_file.out"
>
> # create_project -part $part_name -in_memory -ip
>
> # set_property target_simulator XSim [current_project]
>
> # add_files -norecurse -force $xci_file
>
> INFO: [IP_Flow 19-234] Refreshing IP repositories
>
> INFO: [IP_Flow 19-1704] No user IP repositories specified
>
> INFO: [IP_Flow 19-2313] Loaded Vivado IP repository
>> '/opt/Xilinx/Vivado/2015.4/data/ip'.
>
> # reset_target all [get_files $xci_file]
>
> # puts "BUILDER: Generating IP Target..."
>
> BUILDER: Generating IP Target...
>
> # generate_target all [get_files $xci_file]
>
> INFO: [IP_Flow 19-1686] Generating 'Instantiation Template' target for IP
>> 'ddr3_32bit'...
>
> *ERROR: [xilinx.com:ip:mig_7series:2.4-0] ddr3_32bit: Code generation
>> aborted: Unconfigured MIG instance*
>
> *CRITICAL WARNING: [IP_Flow 19-1747] Failed to deliver file
>> '/opt/Xilinx/Vivado/2015.4/data/ip/xilinx/mig_7series_v2_4/xit/instantiation_template.xit':
>> *
>
> *ERROR: [IP_Flow 19-167] Failed to deliver one or more file(s).*
>
> *ERROR: [IP_Flow 19-3505] IP Generation error: Failed to generate IP
>> 'ddr3_32bit'. Failed to generate 'Verilog Instantiation Template' outputs: *
>
> *ERROR: [IP_Flow 19-98] Generation of the IP CORE failed.*
>
> Failed to generate IP 'ddr3_32bit'. Failed to generate 'Verilog
>> Instantiation Template' outputs:
>
> INFO: [Common 17-206] Exiting Vivado at Fri Apr 8 02:41:13 2016...
>
> Releasing IP location:
>> /home/rynmrlw/pybombs-prefix/src/uhd/fpga-src/fpga/usrp3/top/x300/build-ip/xc7k410tffg900-2/ddr3_32bit
>
> make[1]: ***
>> [/home/rynmrlw/pybombs-prefix/src/uhd/fpga-src/fpga/usrp3/top/x300/build-ip/xc7k410tffg900-2/ddr3_32bit/ddr3_32bit.xci.out]
>> Error 1
>
> make[1]: Leaving directory
>> `/home/rynmrlw/pybombs-prefix/src/uhd/fpga-src/fpga/usrp3/top/x300'
>
> make: *** [X310_RFNOC_HGS] Error 2
>
>
> I've upgraded the IP using the upgrade_ip.sh script in the ip folder. Is
> there a specific version of Vivado (and IP) that I should be using? My
> current vivado configurations are also included in this print out.
> Best,
> Ryan Marlow
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160410/29fc0a65/attachment-0001.html>
------------------------------
Message: 10
Date: Mon, 11 Apr 2016 09:07:37 +0800
From: john liu <[email protected]>
To: Philip Balister <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] monitor with E310/312
Message-ID:
<caf6nntjmkmk5kxv5pw+qemuyavbtw2hxj75ouii-umo6vow...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi ,Philip
Thank you for your help.
Best regards
John
On Sat, Apr 9, 2016 at 12:37 AM, Philip Balister <[email protected]> wrote:
> On 04/08/2016 01:29 AM, john liu via USRP-users wrote:
> > Dear all,
> > Can we use E312/E312 with a LCD monitor?The interface is USB or
> > others?And where can we find the hard driver?
> > thank you for your reply.
> > best regards
>
> gnuradio-demo-image works with this panel:
>
> https://www.mimomonitors.com/products/mimo-um-760r-7-display
>
> The driver is the udlfb driver.
>
> Philip
>
> > John
> >
> >
> >
> > _______________________________________________
> > 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/20160411/285ae04b/attachment-0001.html>
------------------------------
Message: 11
Date: Sun, 10 Apr 2016 18:25:10 -0700
From: Jonathon Pendlum <[email protected]>
To: "Swanson, Craig" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Errors when building X310_RFNOC_HGS in X300
for rfnoc-ofdm branch
Message-ID:
<cagdo0ut_6ueycshnl2wtz17ty-qku14z9ebiyw2js+8mwiv...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Craig,
I pushed a fix for this, try it out and let me know if you run into any
other issues.
Jonathon
On Sat, Apr 9, 2016 at 12:09 PM, Swanson, Craig <
[email protected]> wrote:
> Jonathon,
>
> Here are my errors when I executed the following:
> ~/uhd/rfnoc-ofdm/usrp3/top/x300 (rfnoc-devel)$ make X310_RFNOC_HGS
>
> ?
>
>
>
> ERROR: [Synth 8-439] module 'divide_int16_int32' not found
> [/home/craig/uhd/rfnoc-ofdm/usrp3/lib/rfnoc/complex_invert.v:94]
> ERROR: [Synth 8-285] failed synthesizing module 'complex_invert'
> [/home/craig/uhd/rfnoc-ofdm/usrp3/lib/rfnoc/complex_invert.v:10]
> ERROR: [Synth 8-285] failed synthesizing module 'one_tap_equalizer'
> [/home/craig/uhd/rfnoc-ofdm/usrp3/lib/rfnoc/one_tap_equalizer.v:5]
> ERROR: [Synth 8-285] failed synthesizing module 'noc_block_eq'
> [/home/craig/uhd/rfnoc-ofdm/usrp3/lib/rfnoc/noc_block_eq.v:5]
> ERROR: [Synth 8-285] failed synthesizing module 'x300_core'
> [/home/craig/uhd/rfnoc-ofdm/usrp3/top/x300/x300_core.v:2]
> INFO: [Synth 8-4472] Detected and applied attribute dont_touch =
> 32'b00000000000000000000000000000000
> [/home/craig/uhd/rfnoc-ofdm/usrp3/top/x300/x300.v:1367]
> ERROR: [Synth 8-285] failed synthesizing module 'x300'
> [/home/craig/uhd/rfnoc-ofdm/usrp3/top/x300/x300.v:18]
>
>
>
>
> *Craig F. Swanson*
>
> *Research Engineer II *
> *Information and Communications Laboratory*
> *Communications, Systems, and Spectrum Division*
> *Georgia Tech Research Institute*
>
>
> *Room 560 250 14th St NW *
> *Atlanta, GA 30318*
> *Cell: 770.298.9156 <770.298.9156>*
> http://www.gtri.gatech.edu
> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160410/e7914694/attachment-0001.html>
------------------------------
Message: 12
Date: Mon, 11 Apr 2016 12:53:31 +0300
From: Matt Ettus <[email protected]>
To: Richard Bell <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Style Guide for referencing USRP or Ettus
Message-ID:
<CAN=1kn8j=dkrnokhsdvn4um7nnojg0csao65ks7puczem3a...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks for asking. We don't have anything in particular, so I would just
list company name and our website if there are no other guidelines from the
publisher.
Matt
On Sat, Apr 9, 2016 at 1:10 AM, Richard Bell via USRP-users <
[email protected]> wrote:
> I'm writing a paper in which I would like to reference Ettus Research or
> the USRP. I found a style guide for referencing GNU Radio, but I don't see
> anything for the USRP. Do you guys have a template or example of how you'd
> like to be referenced?
>
> Rich
>
> _______________________________________________
> 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/20160411/41c80c15/attachment-0001.html>
------------------------------
Message: 13
Date: Mon, 11 Apr 2016 12:58:34 +0200
From: Claudio Cicconetti <[email protected]>
To: [email protected], [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] E310 GPSDO clock reference
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Dear Derek, Marcus,
I ran the experiments as you suggested.
Specifically, in the E310 I used the GPSDO as time source and then
generated a constant signal while measuring from another (validated)
device the frequency drift with respect to the nominal expected
frequency. The centre frequency used is 1.2 GHz. The results were
repeatable, with negligible result differences from a run to any another
one.
I collected about 5 minutes of traces. The raw data is available at the
following URL (column 1: time in ms; column 2: frequency drift in Hz):
https://dl.dropboxusercontent.com/u/3247031/freq_drift_trace.txt
In the pictures at the following URL I have plotted, respectively, the
drift at start-up (first 10 s) and while the system is in a steady state
(for instance, in seconds from 60 to 70):
https://dl.dropboxusercontent.com/u/3247031/freq_drift_startup.png
https://dl.dropboxusercontent.com/u/3247031/freq_drift_steadystate.png
The good news is that the drift converges after a few seconds.
The bad news is that there are still non-negligible oscillations, in the
order of a few tens of Hz.
In my application these oscillations may cause issues. In fact, I was
relying on the internal GPSDO to yield a much more stable clock,
comparable with what I get on a series N or X device.
Is this the best I can ever get from my E310 or would it be possible to
have improvements with a change to the UHD library of E310 FPGA?
Best regards,
Claudio
On 04/09/2016 01:38 AM, Derek Kozel via USRP-users wrote:
> Hi Claudio,
>
> The E310 can be locked to an external 1PPS or can use it's internal GPS
> receiver with an external antenna to discipline it's reference. It cannot
> use an external 10 MHz reference in the same way as other USRPs.
>
> Marcus' questions are the ones I would have asked next to determine many
> parts per million drift are you seeing. Can you capture a longer duration,
> both starting from t=0 when you set the time source to the gpsdo or 1PPS on
> the external SYNC, and where t=0 is more than a minute after the ref_locked
> sensor returns true?
>
> Thanks,
> Derek
>
> On Fri, Apr 8, 2016 at 3:45 PM, Marcus D. Leech via USRP-users <
> [email protected]> wrote:
>
>> On 04/08/2016 03:35 AM, Claudio Cicconetti via USRP-users wrote:
>>
>>> Dear Derek,
>>> Even with the PPS synchronization, the frequency stability I get is very
>>> poor. You can find in the graph at the URL below the frequency drift
>>> measured over a time window of 30 seconds:
>>>
>>> https://dl.dropboxusercontent.com/u/3247031/e310_freq.png
>>>
>>> In the E310 manual I found the following statement: "Unlike most USRP
>>> devices, the E310 does not have independent reference clock and time
>>> source inputs."
>>>
>>> Does this mean it is not possible to lock the internal clock to an
>>> external / gpsdo reference?
>>>
>>> If this is the case I would like to know it ASAP because for me this
>>> means aborting the current project with E310 and find an alternative
>>> solution.
>>>
>>> Best regards,
>>> Claudio
>>>
>> Claudio:
>>
>> I've raised this with engineering, and hopefully someone will pipe up in
>> the next couple of days on this subject, or sooner.
>>
>> So it looks like the amplitude of corrections is about 120Hz, but at what
>> center frequency? Just to calibrate things.
>>
>> How long did you let the 1PPS run with your program before taking
>> measurements? The servo on the E310 can be fairly slow to converge
>> with a 1PPS input.
>>
>>
>>
>>
>>> On 04/08/2016 12:07 AM, Derek Kozel wrote:
>>>
>>>> Hello Claudio,
>>>>
>>>> I have to apologize, I have just been corrected by a coworker that the
>>>> clock API behavior is accurate . While it is technically possible to
>>>> feed a
>>>> DC coupled 10 MHz signal to the Sync connector, it was never designed to
>>>> function this way and will not work with many normal 10 MHz sources. The
>>>> Manual and code are correct and state that the SYNC input is for a 1PPS
>>>> (LVCMOS or 5V) signal.
>>>> http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_hw_sync
>>>>
>>>> The two correct ways to discipline the E310's internal reference are as
>>>> follows:
>>>>
>>>> With a 1PPS signal being fed into SYNC:
>>>>
>>>> tx_waveforms --freq 1592.5e6 --rate 1e6 --pps external
>>>> or in your own code
>>>> usrp->set_time_source("external")
>>>>
>>>>
>>>> With a GPS antenna attached to GPS:
>>>>
>>>> tx_waveforms --freq 1592.5e6 --rate 1e6 --pps gpsdo
>>>> or in your own code
>>>> usrp->set_time_source("gpsdo")
>>>>
>>>>
>>>> http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a57a5580ba06d7d6a037c9ef64f1ea361
>>>>
>>>> Either of these options will discipline the internal reference and much
>>>> improve your frequency alignment with other devices disciplined by the
>>>> same
>>>> source.
>>>>
>>>> I hope this is clear and helps. Please let me know if one of these
>>>> methods
>>>> works and if you have any other questions.
>>>>
>>>> Regards,
>>>> Derek
>>>>
>>>>
>>>> On Wed, Apr 6, 2016 at 11:00 AM, Derek Kozel <[email protected]>
>>>> wrote:
>>>>
>>>> Hello Claudio,
>>>>>
>>>>> I'm sorry, I've just opened a bug for this. Please use the --pps flag
>>>>> instead for now. The E310 will accept either a 1PPS signal or 10 MHz
>>>>> reference to the rf connector but for the moment the time
>>>>> synchronization
>>>>> call must be used for both. I'll get this fixed.
>>>>>
>>>>> With 10 MHz reference or 1PPS signal being fed in
>>>>> /usr/lib/uhd/examples/tx_waveforms --freq 1592.5e6 --rate 1e6 --pps
>>>>> external
>>>>>
>>>>> With a GPS antenna attached
>>>>> /usr/lib/uhd/examples/tx_waveforms --freq 1592.5e6 --rate 1e6 --pps
>>>>> gpsdo
>>>>>
>>>>> Regards,
>>>>> Derek
>>>>>
>>>>> On Wed, Apr 6, 2016 at 1:08 AM, Claudio Cicconetti <
>>>>> [email protected]> wrote:
>>>>>
>>>>> Dear Derek,
>>>>>> Thank you for your response.
>>>>>>
>>>>>> However, this does not solve the issue: when invoking tx_waveforms
>>>>>> using
>>>>>> any value different from 'internal' for parameter '--ref' I get:
>>>>>>
>>>>>> "Error: ValueError: Clock source option not supported: $REF. The only
>>>>>> value supported is "internal". To discipline the internal oscillator,
>>>>>> set the appropriate time source"
>>>>>>
>>>>>> (where $REF is one of external, mimo, gpsdo)
>>>>>>
>>>>>> An example of command invokation with output is included at the bottom.
>>>>>>
>>>>>> Further advice on how to solve the issue would be greatly appreciated.
>>>>>>
>>>>>> Best regards,
>>>>>> Claudio
>>>>>>
>>>>>> On 04/05/2016 07:43 PM, Derek Kozel wrote:
>>>>>>
>>>>>>> Hello Claudio,
>>>>>>>
>>>>>>> The E310 is only using the external reference for the duration of
>>>>>>> query_gpsdo_sensors. You must also run tx_waveforms with "--ref
>>>>>>>
>>>>>> external"
>>>>>>
>>>>>>> for TX waveforms to use the reference. USRPs are designed to be
>>>>>>>
>>>>>> stateless
>>>>>>
>>>>>>> between sessions so it is always in a known state. Please let us know
>>>>>>> if
>>>>>>> this solves your problem.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> https://github.com/EttusResearch/uhd/blob/master/host/examples/tx_waveforms.cpp#L69
>>>>>>
>>>>>>> Regards,
>>>>>>> Derek
>>>>>>>
>>>>>>> On Tue, Apr 5, 2016 at 1:49 AM, Claudio Cicconetti via USRP-users <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>> Dear all,
>>>>>>>> I cannot lock properly an E310 to the GPSDO 10 MHz reference.
>>>>>>>>
>>>>>>>> I tried with stable releases 3 and 4 and also with a home-compiled
>>>>>>>>
>>>>>>> rel-4
>>>>>>
>>>>>>> from git. The result is always the same:
>>>>>>>>
>>>>>>>> 1. the E310 acquires lock from GPS (as indicated by
>>>>>>>>
>>>>>>> query_gpsdo_sensors)
>>>>>>
>>>>>>> 2. I transmit a beacon (using tx_waveforms)
>>>>>>>> 3. on the receiver (see below) a get a drift between 1 kHz and 2 kHz
>>>>>>>>
>>>>>>>> Note: as "receiver" I used i) an Agilent spectrum analyzer with high
>>>>>>>> internal clock accuracy; ii) an USRP N210 with external 10 MHz clock
>>>>>>>> reference coming from a (properly locked) professional GPS receiver;
>>>>>>>> iii) another USRP N210 equipped with a (properly locked) internal
>>>>>>>>
>>>>>>> GPSDO.
>>>>>>
>>>>>>> Needless to say: i, ii, and iii are perfectly frequency-consistent to
>>>>>>>> one another.
>>>>>>>>
>>>>>>>> Any idea of what I could have messed?
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Claudio
>>>>>>>>
>>>>>>>> --
>>>>>>>> Claudio Cicconetti, PhD
>>>>>>>> Software Engineer - MBI S.r.l. - Pisa, Italy
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> USRP-users mailing list
>>>>>>>> [email protected]
>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>>
>>>>>>>> ---------------------------------------------------
>>>>>>
>>>>>> Running:
>>>>>>
>>>>>> /usr/lib/uhd/examples/tx_waveforms --freq 1592.5e6 --rate 1e6
>>>>>> --ref=gpsdo
>>>>>>
>>>>>> I get:
>>>>>>
>>>>>> linux; GNU C++ version 4.9.2; Boost_105700; UHD_003.009.002-0-unknown
>>>>>>
>>>>>>
>>>>>> Creating the usrp device with: ...
>>>>>> -- Loading FPGA image: /usr/share/uhd/images/usrp_e310_fpga.bit... done
>>>>>> -- Detecting internal GPSDO .... found
>>>>>> -- Initializing core control...
>>>>>> -- Performing register loopback test... pass
>>>>>> -- Performing register loopback test... pass
>>>>>> -- Performing register loopback test... pass
>>>>>> -- Performing CODEC loopback test... pass
>>>>>> -- Performing CODEC loopback test... pass
>>>>>> -- Setting time source to internal
>>>>>> -- Asking for clock rate 16 MHz
>>>>>> -- Actually got clock rate 16 MHz
>>>>>> -- Performing timer loopback test... pass
>>>>>> -- Performing timer loopback test... pass
>>>>>> -- Loading FPGA image: /usr/share/uhd/images/usrp_e3xx_fpga_idle.bit...
>>>>>> done
>>>>>> Error: ValueError: Clock source option not supported: gpsdo. The only
>>>>>> value supported is "internal". To discipline the internal oscillator,
>>>>>> set the appropriate time source.
>>>>>>
>>>>>>
>>>>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 14
Date: Mon, 11 Apr 2016 15:04:36 +0300
From: Vladimir <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] Can I get arbitrary sampling rate with X300+UBX?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hello,
Is it possible by any means to get the sampling rate fine tuned in X300 (eg 1
Hz resolution at 20 Msps point)? Is there any input point where we can provide
some reference freq or directly Fs from an external source? Or, may be some
custom FPGA version implementing arbitrary resampling or reprogramming dsp to
the exact freq?
If there is no ready solution yet, what would be the best (easiest) way to
implement it by our own means?
Vladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160411/f4e7327e/attachment-0001.html>
------------------------------
Message: 15
Date: Mon, 11 Apr 2016 15:50:39 +0200
From: Claudio Cicconetti <[email protected]>
To: [email protected]
Subject: [USRP-users] How to know if a radio is currently in use?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Dear all,
What is the official way to test from the command-line (or API) if an
Ettus device is currently being used by another application on the same
host?
In the past I used to issue a uhd_find_devices command, which would
return an empty list if the radio was in use, but it seems recent
versions broke this opportunity with some device types.
Even worse, if I try to use the radio while another application is
already using it, the original application receives a TIMEOUT error and
terminates abruptly.
Based on my tests:
- N210, UHD 3.8.5: broken
- N210, UHD 3.9.2: broken
- E310, UHD 3.9.2: broken
- B210: UHD 3.9.2: works as expected
- X300, UHD 3.9.2: works as expected
Any ideas or suggestions?
Best regards,
Claudio
--
Claudio Cicconetti, PhD
Software Engineer - MBI S.r.l. - Pisa, Italy
------------------------------
Message: 16
Date: Mon, 11 Apr 2016 10:54:20 -0400
From: [email protected]
To: Vladimir <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Can I get arbitrary sampling rate with
X300+UBX?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
The standard DSP chain in the X3xx family only allows sample rates that
are an integer fraction of the master clock rate (200MHhz,
by default).
If you want to re-sample with such fine resolution, you'll have to do it
in host-side software, or do an implementation of a fractional resampler
in the FPGA.
On 2016-04-11 08:04, Vladimir via USRP-users wrote:
> Hello,
>
> Is it possible by any means to get the sampling rate fine tuned in X300 (eg 1
> Hz resolution at 20 Msps point)? Is there any input point where we can
> provide some reference freq or directly Fs from an external source? Or, may
> be some custom FPGA version implementing arbitrary resampling or
> reprogramming dsp to the exact freq?
>
> If there is no ready solution yet, what would be the best (easiest) way to
> implement it by our own means?
>
> Vladimir
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1]
Links:
------
[1] 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/20160411/3baa8ae1/attachment-0001.html>
------------------------------
Message: 17
Date: Mon, 11 Apr 2016 11:18:26 -0400
From: [email protected]
To: Claudio Cicconetti <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: [USRP-users] E310 GPSDO clock reference
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
My understanding is that the DPLL in the FPGA that is used to convert
the 1PPS from the on-board clock module to a synchronized master clock
is going to be revised to provide improved synchronization. I don't have
any idea about when that might happen.
Looks like your steady-state stability is on the order of 10PPB
currently. I'm not sure what magnitude of improvement is envisioned.
On 2016-04-11 06:58, Claudio Cicconetti wrote:
> Dear Derek, Marcus,
> I ran the experiments as you suggested.
>
> Specifically, in the E310 I used the GPSDO as time source and then
> generated a constant signal while measuring from another (validated)
> device the frequency drift with respect to the nominal expected
> frequency. The centre frequency used is 1.2 GHz. The results were
> repeatable, with negligible result differences from a run to any another
> one.
>
> I collected about 5 minutes of traces. The raw data is available at the
> following URL (column 1: time in ms; column 2: frequency drift in Hz):
>
> https://dl.dropboxusercontent.com/u/3247031/freq_drift_trace.txt [1]
>
> In the pictures at the following URL I have plotted, respectively, the
> drift at start-up (first 10 s) and while the system is in a steady state
> (for instance, in seconds from 60 to 70):
>
> https://dl.dropboxusercontent.com/u/3247031/freq_drift_startup.png [2]
>
> https://dl.dropboxusercontent.com/u/3247031/freq_drift_steadystate.png [3]
>
> The good news is that the drift converges after a few seconds.
>
> The bad news is that there are still non-negligible oscillations, in the
> order of a few tens of Hz.
>
> In my application these oscillations may cause issues. In fact, I was
> relying on the internal GPSDO to yield a much more stable clock,
> comparable with what I get on a series N or X device.
>
> Is this the best I can ever get from my E310 or would it be possible to
> have improvements with a change to the UHD library of E310 FPGA?
>
> Best regards,
> Claudio
>
> On 04/09/2016 01:38 AM, Derek Kozel via USRP-users wrote:
> Hi Claudio, The E310 can be locked to an external 1PPS or can use it's
> internal GPS receiver with an external antenna to discipline it's reference.
> It cannot use an external 10 MHz reference in the same way as other USRPs.
> Marcus' questions are the ones I would have asked next to determine many
> parts per million drift are you seeing. Can you capture a longer duration,
> both starting from t=0 when you set the time source to the gpsdo or 1PPS on
> the external SYNC, and where t=0 is more than a minute after the ref_locked
> sensor returns true? Thanks, Derek On Fri, Apr 8, 2016 at 3:45 PM, Marcus D.
> Leech via USRP-users < [email protected]> wrote: On 04/08/2016 03:35
> AM, Claudio Cicconetti via USRP-users wrote: Dear Derek, Even with the PPS
> synchronization, the frequency stability I get is very poor. You can find in
> the graph at the URL below the frequency drift measured over a time window of
> 30 seconds: https://dl.dropboxusercontent.com/u/3247031/e310_freq.png [4] In
> the E310
manual I found the following statement: "Unlike most USRP devices, the E310
does not have independent reference clock and time source inputs." Does this
mean it is not possible to lock the internal clock to an external / gpsdo
reference? If this is the case I would like to know it ASAP because for me this
means aborting the current project with E310 and find an alternative solution.
Best regards, Claudio Claudio: I've raised this with engineering, and hopefully
someone will pipe up in the next couple of days on this subject, or sooner. So
it looks like the amplitude of corrections is about 120Hz, but at what center
frequency? Just to calibrate things. How long did you let the 1PPS run with
your program before taking measurements? The servo on the E310 can be fairly
slow to converge with a 1PPS input. On 04/08/2016 12:07 AM, Derek Kozel wrote:
Hello Claudio, I have to apologize, I have just been corrected by a coworker
that the clock API behavior is accurate . While it is technically
possible to feed a DC coupled 10 MHz signal to the Sync connector, it was never
designed to function this way and will not work with many normal 10 MHz
sources. The Manual and code are correct and state that the SYNC input is for a
1PPS (LVCMOS or 5V) signal.
http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_hw_sync [5] The two
correct ways to discipline the E310's internal reference are as follows: With a
1PPS signal being fed into SYNC: tx_waveforms --freq 1592.5e6 --rate 1e6 --pps
external or in your own code usrp->set_time_source("external") With a GPS
antenna attached to GPS: tx_waveforms --freq 1592.5e6 --rate 1e6 --pps gpsdo or
in your own code usrp->set_time_source("gpsdo")
http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a57a5580ba06d7d6a037c9ef64f1ea361
[6] Either of these options will discipline the internal reference and much
improve your frequency alignment with other devices disciplined by the same
source. I hope this is clear and helps. Please
let me know if one of these methods works and if you have any other questions.
Regards, Derek On Wed, Apr 6, 2016 at 11:00 AM, Derek Kozel
<[email protected]> wrote: Hello Claudio, I'm sorry, I've just opened a bug
for this. Please use the --pps flag instead for now. The E310 will accept
either a 1PPS signal or 10 MHz reference to the rf connector but for the moment
the time synchronization call must be used for both. I'll get this fixed. With
10 MHz reference or 1PPS signal being fed in /usr/lib/uhd/examples/tx_waveforms
--freq 1592.5e6 --rate 1e6 --pps external With a GPS antenna attached
/usr/lib/uhd/examples/tx_waveforms --freq 1592.5e6 --rate 1e6 --pps gpsdo
Regards, Derek On Wed, Apr 6, 2016 at 1:08 AM, Claudio Cicconetti <
[email protected]> wrote: Dear Derek, Thank you for your response.
However, this does not solve the issue: when invoking tx_waveforms using any
value different from 'internal' for parameter '--ref' I get: "Error:
ValueError: Clock source option not
supported: $REF. The only value supported is "internal". To discipline the
internal oscillator, set the appropriate time source" (where $REF is one of
external, mimo, gpsdo) An example of command invokation with output is included
at the bottom. Further advice on how to solve the issue would be greatly
appreciated. Best regards, Claudio On 04/05/2016 07:43 PM, Derek Kozel wrote:
Hello Claudio, The E310 is only using the external reference for the duration
of query_gpsdo_sensors. You must also run tx_waveforms with "--ref external"
for TX waveforms to use the reference. USRPs are designed to be stateless
between sessions so it is always in a known state. Please let us know if this
solves your problem.
https://github.com/EttusResearch/uhd/blob/master/host/examples/tx_waveforms.cpp#L69
[7] Regards, Derek On Tue, Apr 5, 2016 at 1:49 AM, Claudio Cicconetti via
USRP-users < [email protected]> wrote: Dear all, I cannot lock
properly an E310 to the GPSDO 10 MHz reference. I tried
with stable releases 3 and 4 and also with a home-compiled rel-4
> from git. The result is always the same:
>
>> 1. the E310 acquires lock from GPS (as indicated by
> query_gpsdo_sensors)
> 2. I transmit a beacon (using tx_waveforms)
>
>> 3. on the receiver (see below) a get a drift between 1 kHz and 2 kHz Note:
>> as "receiver" I used i) an Agilent spectrum analyzer with high internal
>> clock accuracy; ii) an USRP N210 with external 10 MHz clock reference coming
>> from a (properly locked) professional GPS receiver; iii) another USRP N210
>> equipped with a (properly locked) internal
> GPSDO.
> Needless to say: i, ii, and iii are perfectly frequency-consistent to
>
>> one another. Any idea of what I could have messed? Best regards, Claudio --
>> Claudio Cicconetti, PhD Software Engineer - MBI S.r.l. - Pisa, Italy
>> _______________________________________________ USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [8]
>> ---------------------------------------------------
Running: /usr/lib/uhd/examples/tx_waveforms --freq 1592.5e6 --rate 1e6
--ref=gpsdo I get: linux; GNU C++ version 4.9.2; Boost_105700;
UHD_003.009.002-0-unknown Creating the usrp device with: ... -- Loading
FPGA image: /usr/share/uhd/images/usrp_e310_fpga.bit... done --
Detecting internal GPSDO .... found -- Initializing core control... --
Performing register loopback test... pass -- Performing register
loopback test... pass -- Performing register loopback test... pass --
Performing CODEC loopback test... pass -- Performing CODEC loopback
test... pass -- Setting time source to internal -- Asking for clock rate
16 MHz -- Actually got clock rate 16 MHz -- Performing timer loopback
test... pass -- Performing timer loopback test... pass -- Loading FPGA
image: /usr/share/uhd/images/usrp_e3xx_fpga_idle.bit... done Error:
ValueError: Clock source option not supported: gpsdo. The only value
supported is "internal". To discipline the internal oscillator, set the
appropriate time source. _______________________________________________
USRP-users mailing list [email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [8]
_______________________________________________ USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [8]
_______________________________________________ USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [8]
Links:
------
[1] https://dl.dropboxusercontent.com/u/3247031/freq_drift_trace.txt
[2] https://dl.dropboxusercontent.com/u/3247031/freq_drift_startup.png
[3]
https://dl.dropboxusercontent.com/u/3247031/freq_drift_steadystate.png
[4] https://dl.dropboxusercontent.com/u/3247031/e310_freq.png
[5] http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_hw_sync
[6]
http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a57a5580ba06d7d6a037c9ef64f1ea361
[7]
https://github.com/EttusResearch/uhd/blob/master/host/examples/tx_waveforms.cpp#L69
[8] 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/20160411/7a594b67/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 68, Issue 11
******************************************
