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: Can you make a flow graph with only RFNoC blocks?
(Hunter DeJarnette)
2. Re: monitor with E310/312 (Philip Balister)
3. Re: Frequency Hopping Transmitter (Richard Bell)
4. Fwd: Angle of Arrival Measurements (Michael Duckett)
5. Re: USRP through Python (Richard Bell)
6. Re: Fwd: Angle of Arrival Measurements (Alexander Levedahl)
7. E310 (RFNoC not PC host) (Ignazio Finazzi)
8. Re: E310 (RFNoC not PC host) (Marcus M?ller)
9. Re: Fwd: Angle of Arrival Measurements (Derek Kozel)
10. Re: E310 (RFNoC not PC host) (Ignazio Finazzi)
11. Re: Fwd: Angle of Arrival Measurements (Michael Duckett)
12. Re: Fwd: Angle of Arrival Measurements (Marcus M?ller)
13. Re: [Discuss-gnuradio] error msg of hardware not supporting
the requested RX frequency (Derek Kozel)
14. Re: FW: Fw: rfnoc-radio-redo 3f8c97e Modelsim DE 10.4C
simulation fails on noc_block_moving_avg_tb (Jonathon Pendlum)
15. Re: Fwd: Angle of Arrival Measurements (Marcus D. Leech)
16. building an E310 RFNoC FPGA image with HLS ([email protected])
17. Re: USRP through Python (Martin Braun)
18. Re: E310 (RFNoC not PC host) (Martin Braun)
19. Style Guide for referencing USRP or Ettus (Richard Bell)
20. IEEE 802.11 Transmitter in X310s (Abhinav Jadon)
21. Re: E310 GPSDO clock reference (Marcus D. Leech)
22. Re: E310 GPSDO clock reference (Derek Kozel)
23. Re: [Discuss-gnuradio] error msg of hardware not supporting
the requested RX frequency (Derek Kozel)
24. Re: E310 (RFNoC not PC host) (Matt Ettus)
----------------------------------------------------------------------
Message: 1
Date: Fri, 8 Apr 2016 12:11:50 -0400
From: Hunter DeJarnette <[email protected]>
To: Martin Braun <[email protected]>, [email protected],
[email protected]
Subject: Re: [USRP-users] Can you make a flow graph with only RFNoC
blocks?
Message-ID:
<CAAs=ssphrfd-wwseythj6rqh65tv+kl05aihcft4massuuo...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/47e7a191/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 8 Apr 2016 09:37:47 -0700
From: Philip Balister <[email protected]>
To: john liu <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] monitor with E310/312
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
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
>
------------------------------
Message: 3
Date: Fri, 8 Apr 2016 09:40:06 -0700
From: Richard Bell <[email protected]>
To: Tilla <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Frequency Hopping Transmitter
Message-ID:
<CAMMoi3txpPdcyiGHQq9hz2L7Z20=ccfpacxoeah6xcwuzov...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Alright thanks for the feedback, I appreciate it. (The kHz was a typo
indeed, I meant Hz.)
Rich
On Thu, Apr 7, 2016 at 6:20 PM, Tilla <[email protected]> wrote:
> I have seen freq hop times consistently sub millisecond through the C++
> interface, often as fast as 850 u-seconds for a full retune, not just a dsp
> tune.
>
>
>
> This seems pretty consistent with your 1250Hz (assuming kHz is a typo).
>
>
>
> I didn?t run for extended period of time hopping very quickly, so I cant
> comment on the sustainment part of your observation.
>
>
>
> We have run a ?slowly? hopping application for single digit hours without
> issue?
>
>
>
> *From:* USRP-users [mailto:[email protected]] *On Behalf
> Of *Richard Bell via USRP-users
> *Sent:* Thursday, April 7, 2016 7:17 PM
> *To:* [email protected]
> *Subject:* [USRP-users] Frequency Hopping Transmitter
>
>
>
> I was hoping for some feedback on the attached python script which
> implements a frequency hopping transmitter using a USRP (N210 with WBX DB
> in my case). The script allows you to enter a dwell time, which is how long
> the radio sits at each frequency, and then hops to a random frequency
> within a user specified range of frequencies.
>
> The point of this script is to quantitatively estimate the fastest hopping
> speed a USRP can handle. To do this, I used the Python time module and
> time.clock() on a Ubuntu 14.04 LTS intel corei7 computer to measure the
> time between hops. If the time between hops was greater then the dwell
> time, the script declares that the hop rate is not supported.
>
> Part of the measurement does include waiting for the LO to lock, to make
> the measurement fair. The transmitted signal is just a constant at
> baseband, which produces a pure sine at passband, or a tone. So you will
> just see tones on a spec analyzer as the script runs. I didn't care to get
> more complicated with the baseband signal because I'm interested in the
> fastest hop rate only.
>
> What I would welcome, is any glaring issues I've overlooked in my
> implementation to make this measurement. I can't claim that this script is
> the most efficient way of getting the USRP to hop, it's only my stab at it.
> If anyone would recommend a different technique to improve the hop rate, I
> would love to hear about it.
>
> My findings using this script are that the USRPN210+WBX consistently
> support hop rates of 200 Hz. Faster then this, and eventually you get a hop
> that misses a deadline within a few seconds of starting the script. I've
> gotten single hops to occur within the specified dwell time as fast as 1250
> kHz, but this cannot be sustained. Eventually at these rates, a hop
> deadline is missed.
>
> Look forward to hearing any pointers or guidance that can be offered.
>
> v/,r
>
> Rich
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/9dca6cbe/attachment-0001.html>
------------------------------
Message: 4
Date: Fri, 8 Apr 2016 12:51:02 -0400
From: Michael Duckett <[email protected]>
To: [email protected]
Subject: [USRP-users] Fwd: Angle of Arrival Measurements
Message-ID:
<CAL8gsQQiNpnD1mfx-NjSnozL2jOib1n=yle-pcxxh7ppi9f...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
We are trying to measure the angle of arrival of FM using USRP B210. We
have run into some problems with the measurements and hence we are writing
this email. It would be nice if we can get some inputs from you on how to
fix this issue. We have used two methods for computing the phase
difference. We have used the first one most of the time. However, we are
posting both the methods here for you to have a look.
I have attached method 1 (phase_difference_probe.grc for probing and
phase_difference_view.grc which provides a nice GUI to look at) and method
2 (complex_method.grc). Method 1 is based on the following "paper":
http://www.egr.msu.edu/classes/ece480/capstone/spring14/group02/docs/Application%20Note%20-%20Phase%20George%20Godby%20Team%202.pdf
We use these flow graphs and run them in another script which probes the
"top_block" to get 500 samples which are then averaged to produce one data
point.
We also attach a diagram (AoA_Figure.pdf) which shows a basic idea of how
the antennas and transmitter are setup and what the Angle of Arrival (AoA)
is, when it comes to our measurements.
We tried our code in two different situations. In our first test, our
transmitter was another B210 and we were in an open field. The frequency we
tried ranged from 200 MHz to 1.0 GHz and then 3 GHz and 4 GHz. Our Phase
difference and consequently our AoA measurement were not too far off, when
the antenna array was facing the transmitter (i.e. at an expected AoA of 0
degs). As we moved closer towards an AoA of +- 90 the accuracy of the
measurement fell off. But the consistency of the 500 samples was still
pretty good (we were getting a standard deviation under 0.10 radians).
For our second test, we tried to get the AoA from FM radio towers. We got
about 800-1000m away from a popular radio station tower and pointed the
antenna array at the tower (expecting an AoA of around 0 degs). But we got
measurements which were way off. We did this for a couple of different
spots but the measurements were all over the place (the standard deviation
for individual data points were pretty good but the measurement for the 0
deg position at one spot was different for another spot around the tower).
We did manege to get angle measurements at one point when we were about 800
meters from the tower. The expected angle was 0 but we got 60 - 70 degrees
as the measured angle. We also tried at other places, one was about 800 m
from the tower and the other about 1200m. But both these places were
problematic.
It would be nice to get your inputs on the flow graphs. What are your
thoughts about the flow graph? Do you see any glaring problems with the
flow graph or with the set up? If you have any more questions about the
setup then feel free to ask.
Most of the information about the setup that we are using are in the
attached grc files. Thanks a lot for all your time.
Sincerely,
Michael Duckett
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/93e95f36/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: phase_difference_probe.grc
Type: application/octet-stream
Size: 45305 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/93e95f36/attachment-0003.grc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: phase_difference_view.grc
Type: application/octet-stream
Size: 56845 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/93e95f36/attachment-0004.grc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: complex_method.grc
Type: application/octet-stream
Size: 30088 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/93e95f36/attachment-0005.grc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AoA_Figure.pdf
Type: application/pdf
Size: 8387 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/93e95f36/attachment-0001.pdf>
------------------------------
Message: 5
Date: Fri, 8 Apr 2016 10:06:46 -0700
From: Richard Bell <[email protected]>
To: Martin Braun <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP through Python
Message-ID:
<CAMMoi3twaoyEL6G6B8JjiAWiGX2ApM=lz6wo_1fmmthk8ie...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I have no issue that Python doesn't handle. It was a general question in
case I do run into this situation.
Thanks,
Rich
On Thu, Apr 7, 2016 at 6:12 PM, Martin Braun via USRP-users <
[email protected]> wrote:
> Well, usually the USRP blocks expose all you need. What are you trying
> to do?
>
> M
>
> On 04/07/2016 03:02 PM, Richard Bell via USRP-users wrote:
> > Is the design flow typically something like this then:
> >
> > 1) Use python for USRP control if the function calls are exposed,
> otherwise
> > 2) Write a C++ block that you can call in Python that does the desired
> > control/monitoring
> >
> > Rich
> >
> > On Thu, Apr 7, 2016 at 11:01 AM, Marcus M?ller
> > <[email protected] <mailto:[email protected]>> wrote:
> >
> > multi_usrp is a UHD class, that the usrp_sink and _source use
> > *internally*; you can't use it standalone in GNU Radio, and that's
> > why there's no GNU Radio benefit from swigging it.
> > However, the usrp_sink and _source blocks wrap most of the relevant
> > methods, though under different names (set_gain[1] instead of
> > set_rx_gain or set_tx_gain, because if modifying a usrp_sink or
> > usrp_source, it's clear whether you want to modify TX or RX).
> >
> > Best regards,
> > Marcus
> >
> > [1]
> https://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__source.html
> >
> > On 07.04.2016 19:44, Dave NotTelling via USRP-users wrote:
> >> Martin,
> >>
> >> Is there a specific reason why the multi_usrp class isn't
> >> exposed to Python?
> >>
> >> -Dave
> >>
> >> On Thu, Apr 7, 2016 at 1:13 PM, Martin Braun via USRP-users
> >> <<mailto:[email protected]>[email protected]
> >> <mailto:[email protected]>> wrote:
> >>
> >> To clarify,
> >>
> >> multi_usrp is not swigged, only the GNU Radio blocks. So the UHD
> >> reference manual does not apply to Python-land.
> >>
> >> Cheers,
> >> M
> >>
> >> On 04/06/2016 02:27 PM, Richard Bell via USRP-users wrote:
> >> > Ah thank you! That python API is what I couldn't find, I
> >> kept getting
> >> > stuck on the C++ API.
> >> >
> >> > Things are working now.
> >> >
> >> > Rich
> >> >
> >> > On Wed, Apr 6, 2016 at 2:09 PM, James Humphries
> >> > <[email protected] <mailto:[email protected]>
> >> <mailto:[email protected]
> >> <mailto:[email protected]>>> wrote:
> >> >
> >> > Hi Rich,
> >> >
> >> > It looks like you have instantiated a USRP sink, which
> >> is for TX
> >> > only. You will need to add a USRP source if you want to
> >> RX as well.
> >> >
> >> > See the GNU Radio Python API here for a list of all the
> >> functions
> >> > and methods:
> >> >
> >> > http://gnuradio.org/doc/sphinx/#uhd-blocks
> >> >
> >> > -Trip
> >> >
> >> > On Wed, Apr 6, 2016 at 3:47 PM, Richard Bell via
> USRP-users
> >> > <[email protected] <mailto:
> [email protected]>
> >> <mailto:[email protected]
> >> <mailto:[email protected]>>> wrote:
> >> >
> >> > Hi all,
> >> >
> >> > After instantiating a usrp object in Python, which I
> >> will call
> >> > usrp here, I'm attempting to call
> >> > usrp.get_rx_sensor("lo_locked") and
> >> usrp.get_rx_freq(), but I
> >> > get the following error:
> >> >
> >> > AttributeError: 'usrp_sink_sptr' object has no
> attribute
> >> > 'get_rx_freq'
> >> >
> >> > I can call usrp.set_center_freq(target_freq) just
> >> fine. How do I
> >> > gain access to the full set of usrp methods through
> >> Python? Is
> >> > there example code that demonstrates some of this?
> >> I've looked
> >> > through the freq_hopping.py and
> >> usrp_spectrum_sense.py scripts
> >> > extensively. They don't use much more then
> >> set_center_freq().
> >> >
> >> > Thanks,
> >> > Rich
> >> >
> >> > _______________________________________________
> >> > USRP-users mailing list
> >> > [email protected]
> >> <mailto:[email protected]>
> >> <mailto:[email protected]
> >> <mailto:[email protected]>>
> >> >
> >>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > 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] <mailto:[email protected]>
> >>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> 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] <mailto:[email protected]>
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected]
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/5d1c8ea2/attachment-0001.html>
------------------------------
Message: 6
Date: Fri, 8 Apr 2016 13:28:48 -0400
From: Alexander Levedahl <[email protected]>
To: Michael Duckett <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Fwd: Angle of Arrival Measurements
Message-ID:
<CA+z+orhZF0k8p2pD-geY74DFOzMa+f2d7Y9c_8MCkinncJC=p...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I do not have the ability to look at files right now so sorry if I am
asking questions that are answered in the files.
If you stand in one spot and rotate, is the error consistent? I.e., if you
are pointing the array right at it, it shows the AOA as 60-70. If you
change to pointing 30 degrees, does the AOA change to 90-100?
Are the results consistent across restarting the B210? Depending on the
answer to these questions, it may simply be a calibration problem. I.e.,
when you turn it on there needs to be a calibration step.
Finally, how many antennas are you using 2 or are you using multiple
B210s? Is your antenna spaced appropriately for the operating frequency?
On Fri, Apr 8, 2016 at 12:51 PM, Michael Duckett via USRP-users <
[email protected]> wrote:
> Hello,
>
> We are trying to measure the angle of arrival of FM using USRP B210. We
> have run into some problems with the measurements and hence we are writing
> this email. It would be nice if we can get some inputs from you on how to
> fix this issue. We have used two methods for computing the phase
> difference. We have used the first one most of the time. However, we are
> posting both the methods here for you to have a look.
>
> I have attached method 1 (phase_difference_probe.grc for probing and
> phase_difference_view.grc which provides a nice GUI to look at) and method
> 2 (complex_method.grc). Method 1 is based on the following "paper":
>
>
>
> http://www.egr.msu.edu/classes/ece480/capstone/spring14/group02/docs/Application%20Note%20-%20Phase%20George%20Godby%20Team%202.pdf
>
>
> We use these flow graphs and run them in another script which probes the
> "top_block" to get 500 samples which are then averaged to produce one data
> point.
>
> We also attach a diagram (AoA_Figure.pdf) which shows a basic idea of how
> the antennas and transmitter are setup and what the Angle of Arrival (AoA)
> is, when it comes to our measurements.
>
> We tried our code in two different situations. In our first test, our
> transmitter was another B210 and we were in an open field. The frequency we
> tried ranged from 200 MHz to 1.0 GHz and then 3 GHz and 4 GHz. Our Phase
> difference and consequently our AoA measurement were not too far off, when
> the antenna array was facing the transmitter (i.e. at an expected AoA of 0
> degs). As we moved closer towards an AoA of +- 90 the accuracy of the
> measurement fell off. But the consistency of the 500 samples was still
> pretty good (we were getting a standard deviation under 0.10 radians).
>
> For our second test, we tried to get the AoA from FM radio towers. We got
> about 800-1000m away from a popular radio station tower and pointed the
> antenna array at the tower (expecting an AoA of around 0 degs). But we got
> measurements which were way off. We did this for a couple of different
> spots but the measurements were all over the place (the standard deviation
> for individual data points were pretty good but the measurement for the 0
> deg position at one spot was different for another spot around the tower).
> We did manege to get angle measurements at one point when we were about 800
> meters from the tower. The expected angle was 0 but we got 60 - 70 degrees
> as the measured angle. We also tried at other places, one was about 800 m
> from the tower and the other about 1200m. But both these places were
> problematic.
>
> It would be nice to get your inputs on the flow graphs. What are your
> thoughts about the flow graph? Do you see any glaring problems with the
> flow graph or with the set up? If you have any more questions about the
> setup then feel free to ask.
>
> Most of the information about the setup that we are using are in the
> attached grc files. Thanks a lot for all your time.
>
> Sincerely,
> Michael Duckett
>
>
> _______________________________________________
> 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/20160408/9db8c76a/attachment-0001.html>
------------------------------
Message: 7
Date: Fri, 8 Apr 2016 17:32:33 +0000 (UTC)
From: Ignazio Finazzi <[email protected]>
To: [email protected]
Subject: [USRP-users] E310 (RFNoC not PC host)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi all!!
I'm new on USRPs. I used GNURadio and GRC and i developed some programs with
a RTL-SDR. Few weeks ago, we decided to buy an USRP E310 devide to develop
our project and board it in an UAV.
After read all E310 posts and the User Manual i understood that the better
way to use USRP Embedded devices is to develop programs inside the Zynq 7000
series FPGA and the within ARM as the host.
My question is: Is it possible to use RFNoC toolkit in the ARM? If it
possible, how? If not, how can i develop programs within the FPGA without
VHDL or Verilog?
Thanks so much
------------------------------
Message: 8
Date: Fri, 8 Apr 2016 19:57:46 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] E310 (RFNoC not PC host)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Ignazio,
RFNoC is an FPGA architecture, so no, you cannot use it "on the ARM",
but can use the ARM to talk to your FPGA carrying such an RFNoC-based
DSP design.
Assuming you want to use GNU Radio:
That runs well, and comes with the gr-uhd module that talks to all our
USRP devices, whether you're using an RFNoC FPGA image or a non-RFNoC one.
If you want to use RFNoC, though, you will need UHD (the host-side
driver) from its rfnoc-devel branch, and you'll need gr-ettus, which is
another GNU Radio module, that supports connecting on-FPGA signal
processing blocks "as if" they were normal GNU Radio blocks.
These all are integrated in our RFNoC-enabled SD card images; you can
build one of those yourself.
Now, you ask:
> If not, how can i develop programs within the FPGA without VHDL or
Verilog?
I'm afraid that in its current state, this is not really possible. You
will need at least basic Verilog proficiency.
Best regards,
Marcus
On 08.04.2016 19:32, Ignazio Finazzi via USRP-users wrote:
> Hi all!!
>
> I'm new on USRPs. I used GNURadio and GRC and i developed some programs with
> a RTL-SDR. Few weeks ago, we decided to buy an USRP E310 devide to develop
> our project and board it in an UAV.
>
> After read all E310 posts and the User Manual i understood that the better
> way to use USRP Embedded devices is to develop programs inside the Zynq 7000
> series FPGA and the within ARM as the host.
>
> My question is: Is it possible to use RFNoC toolkit in the ARM? If it
> possible, how? If not, how can i develop programs within the FPGA without
> VHDL or Verilog?
>
> Thanks so much
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 9
Date: Fri, 8 Apr 2016 11:19:31 -0700
From: Derek Kozel <[email protected]>
To: Alexander Levedahl <[email protected]>
Cc: Michael Duckett <[email protected]>, usrp-users
<[email protected]>
Subject: Re: [USRP-users] Fwd: Angle of Arrival Measurements
Message-ID:
<CAA+K=tv_3df1yvgw2vjforfkh+p18vyuvea+mtqqhma89fz...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Michael,
In addition to Alexander's good thoughts, are you monitoring the time
domain signal levels to ensure that the receive gain is set appropriately?
I see a QT GUI Sink (you may consider using the QT Frequency Sink), but it
would be worth while looking at a QT Time Sink as well to see if you are
clipping.
Regards,
Derek
On Fri, Apr 8, 2016 at 10:28 AM, Alexander Levedahl via USRP-users <
[email protected]> wrote:
> I do not have the ability to look at files right now so sorry if I am
> asking questions that are answered in the files.
>
> If you stand in one spot and rotate, is the error consistent? I.e., if
> you are pointing the array right at it, it shows the AOA as 60-70. If you
> change to pointing 30 degrees, does the AOA change to 90-100?
> Are the results consistent across restarting the B210? Depending on the
> answer to these questions, it may simply be a calibration problem. I.e.,
> when you turn it on there needs to be a calibration step.
>
> Finally, how many antennas are you using 2 or are you using multiple
> B210s? Is your antenna spaced appropriately for the operating frequency?
>
>
> On Fri, Apr 8, 2016 at 12:51 PM, Michael Duckett via USRP-users <
> [email protected]> wrote:
>
>> Hello,
>>
>> We are trying to measure the angle of arrival of FM using USRP B210. We
>> have run into some problems with the measurements and hence we are writing
>> this email. It would be nice if we can get some inputs from you on how to
>> fix this issue. We have used two methods for computing the phase
>> difference. We have used the first one most of the time. However, we are
>> posting both the methods here for you to have a look.
>>
>> I have attached method 1 (phase_difference_probe.grc for probing and
>> phase_difference_view.grc which provides a nice GUI to look at) and method
>> 2 (complex_method.grc). Method 1 is based on the following "paper":
>>
>>
>>
>> http://www.egr.msu.edu/classes/ece480/capstone/spring14/group02/docs/Application%20Note%20-%20Phase%20George%20Godby%20Team%202.pdf
>>
>>
>> We use these flow graphs and run them in another script which probes the
>> "top_block" to get 500 samples which are then averaged to produce one data
>> point.
>>
>> We also attach a diagram (AoA_Figure.pdf) which shows a basic idea of how
>> the antennas and transmitter are setup and what the Angle of Arrival (AoA)
>> is, when it comes to our measurements.
>>
>> We tried our code in two different situations. In our first test, our
>> transmitter was another B210 and we were in an open field. The frequency we
>> tried ranged from 200 MHz to 1.0 GHz and then 3 GHz and 4 GHz. Our Phase
>> difference and consequently our AoA measurement were not too far off, when
>> the antenna array was facing the transmitter (i.e. at an expected AoA of 0
>> degs). As we moved closer towards an AoA of +- 90 the accuracy of the
>> measurement fell off. But the consistency of the 500 samples was still
>> pretty good (we were getting a standard deviation under 0.10 radians).
>>
>> For our second test, we tried to get the AoA from FM radio towers. We got
>> about 800-1000m away from a popular radio station tower and pointed the
>> antenna array at the tower (expecting an AoA of around 0 degs). But we got
>> measurements which were way off. We did this for a couple of different
>> spots but the measurements were all over the place (the standard deviation
>> for individual data points were pretty good but the measurement for the 0
>> deg position at one spot was different for another spot around the tower).
>> We did manege to get angle measurements at one point when we were about 800
>> meters from the tower. The expected angle was 0 but we got 60 - 70 degrees
>> as the measured angle. We also tried at other places, one was about 800 m
>> from the tower and the other about 1200m. But both these places were
>> problematic.
>>
>> It would be nice to get your inputs on the flow graphs. What are your
>> thoughts about the flow graph? Do you see any glaring problems with the
>> flow graph or with the set up? If you have any more questions about the
>> setup then feel free to ask.
>>
>> Most of the information about the setup that we are using are in the
>> attached grc files. Thanks a lot for all your time.
>>
>> Sincerely,
>> Michael Duckett
>>
>>
>> _______________________________________________
>> 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/20160408/ee08ae83/attachment-0001.html>
------------------------------
Message: 10
Date: Fri, 8 Apr 2016 18:21:27 +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=utf-8
Marcus M?ller via USRP-users <usrp-users@...> writes:
>
> Hi Ignazio,
>
> RFNoC is an FPGA architecture, so no, you cannot use it "on the ARM",
> but can use the ARM to talk to your FPGA carrying such an RFNoC-based
> DSP design.
>
> Assuming you want to use GNU Radio:
> That runs well, and comes with the gr-uhd module that talks to all our
> USRP devices, whether you're using an RFNoC FPGA image or a non-RFNoC one.
> If you want to use RFNoC, though, you will need UHD (the host-side
> driver) from its rfnoc-devel branch, and you'll need gr-ettus, which is
> another GNU Radio module, that supports connecting on-FPGA signal
> processing blocks "as if" they were normal GNU Radio blocks.
> These all are integrated in our RFNoC-enabled SD card images; you can
> build one of those yourself.
>
> Now, you ask:
>
> > If not, how can i develop programs within the FPGA without VHDL or
> Verilog?
>
> I'm afraid that in its current state, this is not really possible. You
> will need at least basic Verilog proficiency.
>
> Best regards,
> Marcus
> On 08.04.2016 19:32, Ignazio Finazzi via USRP-users wrote:
> > Hi all!!
> >
> > I'm new on USRPs. I used GNURadio and GRC and i developed some programs with
> > a RTL-SDR. Few weeks ago, we decided to buy an USRP E310 devide to develop
> > our project and board it in an UAV.
> >
> > After read all E310 posts and the User Manual i understood that the better
> > way to use USRP Embedded devices is to develop programs inside the Zynq 7000
> > series FPGA and the within ARM as the host.
> >
> > My question is: Is it possible to use RFNoC toolkit in the ARM? If it
> > possible, how? If not, how can i develop programs within the FPGA without
> > VHDL or Verilog?
> >
> > Thanks so much
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users@...
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
Thanks Marcus for your fast answer.
Well, i understood that RFNoC is an FPGA architecture. I try to say that, i
want to process the signal on the FPGA and transmit the processed signal to
the ARM, finally send the data processed to a ground station which do the
graphic process.
I had flashed the SD card with the release 4 e3xx demo image
(http://files.ettus.com/e3xx_images/e3xx-release-4/ettus-e3xx-sg3/). After
that i started a SSH connection (X terminal enabled) and launched GRC but i
didn't find any RFNoC block in the GRC installed in the ARM.
One more question, the SDK OECORE (OE cross-compiler build environment) must
installed on the embedded linux on the ARM or on my PC? SDK OECORE tool is
different that RFNoC toolkit i think...which is the difference?
Thanks so much
------------------------------
Message: 11
Date: Fri, 8 Apr 2016 15:15:31 -0400
From: Michael Duckett <[email protected]>
To: Derek Kozel <[email protected]>
Cc: Alexander Levedahl <[email protected]>, usrp-users
<[email protected]>
Subject: Re: [USRP-users] Fwd: Angle of Arrival Measurements
Message-ID:
<cal8gsqt3so7tbhity_fhr9tu_q5cy+gvs2uxamnw-dg0mt9...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
We are using two antennas on the same B210 and the distance between them is
7cm (the distance between the two "TX/RX" ports). We understand that this
affects the measured phase difference and the further calculation for the
AOA. For future tests we may try to widen the distance between the two
antennas to half the wavelength (I think that would be around 1.3 to 1.7 m
for FM radio station frequencies).
This distance between the two antennas brings us to the first question.
Because the distance between the antennas was small compared to half the
wavelength of the frequency, the range of valid phase differences was
shrunk, too. Most of the time when we were measuring we got phase
differences which were out of range of the valid region. In one spot close
to the tower, we positioned our antenna array at the 0 degree orientation
and phase difference values which corresponded to 60-70 degrees. In
another spot with the same orientation, we got phase difference values
which were out of range. So when we rotated the antenna array, it was
difficult to compared the AOA because most of the time that calculation
wasn't possible. But we can see noticeable changes in the phase difference
when rotating the array. But there doesn't seem to be an easily
decipherable pattern to the error.
We haven't been monitoring the time domain signal levels. We can try that
next time, as well.
On Fri, Apr 8, 2016 at 2:19 PM, Derek Kozel <[email protected]> wrote:
> Hello Michael,
>
> In addition to Alexander's good thoughts, are you monitoring the time
> domain signal levels to ensure that the receive gain is set appropriately?
> I see a QT GUI Sink (you may consider using the QT Frequency Sink), but it
> would be worth while looking at a QT Time Sink as well to see if you are
> clipping.
>
> Regards,
> Derek
>
>
> On Fri, Apr 8, 2016 at 10:28 AM, Alexander Levedahl via USRP-users <
> [email protected]> wrote:
>
>> I do not have the ability to look at files right now so sorry if I am
>> asking questions that are answered in the files.
>>
>> If you stand in one spot and rotate, is the error consistent? I.e., if
>> you are pointing the array right at it, it shows the AOA as 60-70. If you
>> change to pointing 30 degrees, does the AOA change to 90-100?
>> Are the results consistent across restarting the B210? Depending on the
>> answer to these questions, it may simply be a calibration problem. I.e.,
>> when you turn it on there needs to be a calibration step.
>>
>> Finally, how many antennas are you using 2 or are you using multiple
>> B210s? Is your antenna spaced appropriately for the operating frequency?
>>
>>
>> On Fri, Apr 8, 2016 at 12:51 PM, Michael Duckett via USRP-users <
>> [email protected]> wrote:
>>
>>> Hello,
>>>
>>> We are trying to measure the angle of arrival of FM using USRP B210. We
>>> have run into some problems with the measurements and hence we are writing
>>> this email. It would be nice if we can get some inputs from you on how to
>>> fix this issue. We have used two methods for computing the phase
>>> difference. We have used the first one most of the time. However, we are
>>> posting both the methods here for you to have a look.
>>>
>>> I have attached method 1 (phase_difference_probe.grc for probing and
>>> phase_difference_view.grc which provides a nice GUI to look at) and method
>>> 2 (complex_method.grc). Method 1 is based on the following "paper":
>>>
>>>
>>>
>>> http://www.egr.msu.edu/classes/ece480/capstone/spring14/group02/docs/Application%20Note%20-%20Phase%20George%20Godby%20Team%202.pdf
>>>
>>>
>>> We use these flow graphs and run them in another script which probes the
>>> "top_block" to get 500 samples which are then averaged to produce one data
>>> point.
>>>
>>> We also attach a diagram (AoA_Figure.pdf) which shows a basic idea of
>>> how the antennas and transmitter are setup and what the Angle of Arrival
>>> (AoA) is, when it comes to our measurements.
>>>
>>> We tried our code in two different situations. In our first test, our
>>> transmitter was another B210 and we were in an open field. The frequency we
>>> tried ranged from 200 MHz to 1.0 GHz and then 3 GHz and 4 GHz. Our Phase
>>> difference and consequently our AoA measurement were not too far off, when
>>> the antenna array was facing the transmitter (i.e. at an expected AoA of 0
>>> degs). As we moved closer towards an AoA of +- 90 the accuracy of the
>>> measurement fell off. But the consistency of the 500 samples was still
>>> pretty good (we were getting a standard deviation under 0.10 radians).
>>>
>>> For our second test, we tried to get the AoA from FM radio towers. We
>>> got about 800-1000m away from a popular radio station tower and pointed the
>>> antenna array at the tower (expecting an AoA of around 0 degs). But we got
>>> measurements which were way off. We did this for a couple of different
>>> spots but the measurements were all over the place (the standard deviation
>>> for individual data points were pretty good but the measurement for the 0
>>> deg position at one spot was different for another spot around the tower).
>>> We did manege to get angle measurements at one point when we were about 800
>>> meters from the tower. The expected angle was 0 but we got 60 - 70 degrees
>>> as the measured angle. We also tried at other places, one was about 800 m
>>> from the tower and the other about 1200m. But both these places were
>>> problematic.
>>>
>>> It would be nice to get your inputs on the flow graphs. What are your
>>> thoughts about the flow graph? Do you see any glaring problems with the
>>> flow graph or with the set up? If you have any more questions about the
>>> setup then feel free to ask.
>>>
>>> Most of the information about the setup that we are using are in the
>>> attached grc files. Thanks a lot for all your time.
>>>
>>> Sincerely,
>>> Michael Duckett
>>>
>>>
>>> _______________________________________________
>>> 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/20160408/a369dfab/attachment-0001.html>
------------------------------
Message: 12
Date: Fri, 8 Apr 2016 22:21:29 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Fwd: Angle of Arrival Measurements
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Michael,
I'd really try with larger distance first ? at ca $\frac{1}{40}\lambda$
distance, it's likely your two antennas don't work as two independent
free-space-to-50-Ohm impedance converters, but as coupling elements of
one larger antenna, unless they are extremely directive themselves (what
antenna type are you using?); the phase center of that is kind of hard
to make out, as reflections on the connectors and non-perfect 50Ohm
matching on both the antenna and USRP side might influence it heavily.
It's a good sign you're seeing angle changes when rotating the array;
that means that you're on a good track. Do you do any higher order
tracking before or after converting the phase offset to an angle?
So, I'm currently having a look at your flow graphs; they look sound to
me; especially the complex method (Which pretty much is equivalent to
picking one frequency bin from the FFT, if you add a sharp bandpass
filter, so that you only see one frequency) looks efficient. In fact,
seeing both approaches in one place reminded me of OFDM radar, where one
actually takes advantage of the time/frequency structure of the signal,
and, more elementarily, the fact that a shift in time domain is a
modulation with an offset frequency in frequency domain. Maybe [1] is a
bit of a fun read to you; for the angle of arrival problem (which for
your approaches is really but a time offset problem), things boil down to:
If $x$ and $y$ are the same signal, but $y(t)=x(t-\tau)$ is delayed by
$\tau$, then their Fourier transforms $X$ and $Y$ are also the same but
for the latter $Y=e^{-j2\pi\tau f} X$ being the first modulated by a
complex sinusoid. Estimating that sinusoid's frequency gives you the
timing offset; you can get the "pure" tone by just dividing $\frac YX$.
Looking at the discrete signal case, note that the frequency resolution
you can get depends on the DFT you're doing ? i.e. longer
observation/larger DFT has a very positive effect on accuracy!
I'd really love to see multiple approaches at AoA being implemented,
that will definitely be an interesting use case for both SDR in general,
the USRP B210, and GNU Radio; I don't remember fully, but I think the
cel-kit account on github has a gr-specest repo, where you can find a
few examples of parametric spectrum estimators; amongst these MUSIC, an
algorithm actually originating in the world of direction detection,
applied to frequency estimation. It should be pretty straightforward to
adapt the algorithm to spatial problems ? basically, you'd replace the
estimated signal autocovariance matrix by a antenna cross-correlation
matrix.
Best regards,
Marcus
[1] Braun, Martin. /Ofdm radar algorithms in mobile communication
networks/. Diss. Karlsruhe, Karlsruher Institut f?r Technologie (KIT),
Diss., 2014, 2014.
http://d-nb.info/104838490X/34
On 08.04.2016 21:15, Michael Duckett via USRP-users wrote:
> We are using two antennas on the same B210 and the distance between
> them is 7cm (the distance between the two "TX/RX" ports). We
> understand that this affects the measured phase difference and the
> further calculation for the AOA. For future tests we may try to widen
> the distance between the two antennas to half the wavelength (I think
> that would be around 1.3 to 1.7 m for FM radio station frequencies).
>
> This distance between the two antennas brings us to the first
> question. Because the distance between the antennas was small compared
> to half the wavelength of the frequency, the range of valid phase
> differences was shrunk, too. Most of the time when we were measuring
> we got phase differences which were out of range of the valid region.
> In one spot close to the tower, we positioned our antenna array at the
> 0 degree orientation and phase difference values which corresponded
> to 60-70 degrees. In another spot with the same orientation, we got
> phase difference values which were out of range. So when we rotated
> the antenna array, it was difficult to compared the AOA because most
> of the time that calculation wasn't possible. But we can see
> noticeable changes in the phase difference when rotating the array.
> But there doesn't seem to be an easily decipherable pattern to the error.
>
> We haven't been monitoring the time domain signal levels. We can try
> that next time, as well.
>
> On Fri, Apr 8, 2016 at 2:19 PM, Derek Kozel <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hello Michael,
>
> In addition to Alexander's good thoughts, are you monitoring the
> time domain signal levels to ensure that the receive gain is set
> appropriately? I see a QT GUI Sink (you may consider using the QT
> Frequency Sink), but it would be worth while looking at a QT Time
> Sink as well to see if you are clipping.
>
> Regards,
> Derek
>
>
> On Fri, Apr 8, 2016 at 10:28 AM, Alexander Levedahl via USRP-users
> <[email protected] <mailto:[email protected]>>
> wrote:
>
> I do not have the ability to look at files right now so sorry
> if I am asking questions that are answered in the files.
>
> If you stand in one spot and rotate, is the error consistent?
> I.e., if you are pointing the array right at it, it shows the
> AOA as 60-70. If you change to pointing 30 degrees, does the
> AOA change to 90-100?
> Are the results consistent across restarting the B210?
> Depending on the answer to these questions, it may simply be a
> calibration problem. I.e., when you turn it on there needs to
> be a calibration step.
>
> Finally, how many antennas are you using 2 or are you using
> multiple B210s? Is your antenna spaced appropriately for the
> operating frequency?
>
>
> On Fri, Apr 8, 2016 at 12:51 PM, Michael Duckett via
> USRP-users <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hello,
>
> We are trying to measure the angle of arrival of FM using
> USRP B210. We have run into some problems with the
> measurements and hence we are writing this email. It would
> be nice if we can get some inputs from you on how to fix
> this issue. We have used two methods for computing the
> phase difference. We have used the first one most of the
> time. However, we are posting both the methods here for
> you to have a look.
>
> I have attached method 1 (phase_difference_probe.grc for
> probing and phase_difference_view.grc which provides a
> nice GUI to look at) and method 2 (complex_method.grc).
> Method 1 is based on the following "paper":
>
>
>
> http://www.egr.msu.edu/classes/ece480/capstone/spring14/group02/docs/Application%20Note%20-%20Phase%20George%20Godby%20Team%202.pdf
>
>
> We use these flow graphs and run them in another script
> which probes the "top_block" to get 500 samples which are
> then averaged to produce one data point.
>
> We also attach a diagram (AoA_Figure.pdf) which shows a
> basic idea of how the antennas and transmitter are setup
> and what the Angle of Arrival (AoA) is, when it comes to
> our measurements.
>
> We tried our code in two different situations. In our
> first test, our transmitter was another B210 and we were
> in an open field. The frequency we tried ranged from 200
> MHz to 1.0 GHz and then 3 GHz and 4 GHz. Our Phase
> difference and consequently our AoA measurement were not
> too far off, when the antenna array was facing the
> transmitter (i.e. at an expected AoA of 0 degs). As we
> moved closer towards an AoA of +- 90 the accuracy of the
> measurement fell off. But the consistency of the 500
> samples was still pretty good (we were getting a standard
> deviation under 0.10 radians).
>
> For our second test, we tried to get the AoA from FM radio
> towers. We got about 800-1000m away from a popular radio
> station tower and pointed the antenna array at the tower
> (expecting an AoA of around 0 degs). But we got
> measurements which were way off. We did this for a couple
> of different spots but the measurements were all over the
> place (the standard deviation for individual data points
> were pretty good but the measurement for the 0 deg
> position at one spot was different for another spot around
> the tower). We did manege to get angle measurements at one
> point when we were about 800 meters from the tower. The
> expected angle was 0 but we got 60 - 70 degrees as the
> measured angle. We also tried at other places, one was
> about 800 m from the tower and the other about 1200m. But
> both these places were problematic.
>
> It would be nice to get your inputs on the flow graphs.
> What are your thoughts about the flow graph? Do you see
> any glaring problems with the flow graph or with the set
> up? If you have any more questions about the setup then
> feel free to ask.
>
> Most of the information about the setup that we are using
> are in the attached grc files. Thanks a lot for all your time.
>
> Sincerely,
> Michael Duckett
>
>
> _______________________________________________
> 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] <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/20160408/faa6bba1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-2.png
Type: image/png
Size: 751 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/faa6bba1/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-9.png
Type: image/png
Size: 567 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/faa6bba1/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-8.png
Type: image/png
Size: 590 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/faa6bba1/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-7.png
Type: image/png
Size: 1170 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/faa6bba1/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-6.png
Type: image/png
Size: 526 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/faa6bba1/attachment-0013.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-5.png
Type: image/png
Size: 598 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/faa6bba1/attachment-0014.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-4.png
Type: image/png
Size: 583 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/faa6bba1/attachment-0015.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-3.png
Type: image/png
Size: 1158 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/faa6bba1/attachment-0016.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tblatex-10.png
Type: image/png
Size: 657 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/faa6bba1/attachment-0017.png>
------------------------------
Message: 13
Date: Fri, 8 Apr 2016 13:56:39 -0700
From: Derek Kozel <[email protected]>
To: Vinit Shah <[email protected]>
Cc: "[email protected]" <[email protected]>,
GNURadio Discussion List <[email protected]>
Subject: Re: [USRP-users] [Discuss-gnuradio] error msg of hardware not
supporting the requested RX frequency
Message-ID:
<CAA+K=tuRbWtpwAx922UXG_R=2wrqyilbgxkujk_6bueqgqa...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Vinit,
This question is much more about UHD so I'm adding the usrp-users mailing
list [1].
There is no USRP daughterboard which goes to 250 GHz so I assume you mean
250 MHz which would point towards the BasicRx daughterboard. This
daughterboard has no mixer and so the N200 will use aliasing to receive
non-baseband signals. The N200's ADC runs at 100 MSPS, but Gigabit Ethernet
isn't able to transport that much data so it is always decimated by some
factor. This means that a target frequency of 97.9 MHz (A good choice for a
first test) is in a higher Nyquist band. What you're seeing is correct
behaviour.
UHD 3.5.5 is very old and I'd recommend removing the current version and
install a newer release. I would guess that you are on Ubuntu 14.04 and
installed it using apt. If you are very unfamiliar with Linux and don't
have anyone locally who you could get some assistance from it's worth
considering using the GNU Radio Live Environment [2] which can be written
to a USB drive and booted from. This comes with up to date versions of GNU
Radio and UHD, as well as a variety of additional SDR related packages.
You can also look at PyBOMBS[3] or the build-gnuradio [4] script, either of
which will install the latest UHD and GNU Radio.
Regards,
Derek
[1] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[2] https://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD
[3] https://github.com/gnuradio/pybombs/
[4]
https://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGRFromSource#Using-the-build-gnuradio-script
On Fri, Apr 8, 2016 at 1:12 PM, Vinit Shah <[email protected]> wrote:
> Dear all,
> I am a beginner in Linux and So far I have successfully installed gnuradio
> and hardware dependencies.
> The very basic program which is just connecting usrp source with WX gui
> fft sink is not working correctly.
> I am getting following error messaege
>
> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.005.005-0-unknown
>
> Using Volk machine: sse4_2_64_orc
> -- Opening a USRP2/N-Series device...
> -- Current recv frame size: 1472 bytes
> -- Current send frame size: 1472 bytes
>
> UHD Warning:
> Unable to set the thread priority. Performance may be negatively
> affected.
> Please see the general application notes in the manual for
> instructions.
> EnvironmentError: OSError: error in pthread_setschedparam
>
> UHD Warning:
> The hardware does not support the requested RX frequency:
> Target frequency: 97.900000 MHz
> Actual frequency: -2.100000 MHz
>
> >>> Done
>
> My daughter board has range up to 250 Gigs... but I do not know why even
> with 10 M sampling frequency my system is aliasing ??
> This is a common problem I found on internet but no effective solution so
> far, I think.
> Any help would be highly appreciated.
> I request you please explain explicitly because I am novice in this field(
> with linux), and if possible with example..??
>
> Thank you very much in advance
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/9bdca473/attachment-0001.html>
------------------------------
Message: 14
Date: Fri, 8 Apr 2016 14:05:41 -0700
From: Jonathon Pendlum <[email protected]>
To: "Swanson, Craig" <[email protected]>
Cc: "Myers, David" <[email protected]>, "Brothers, Timothy"
<[email protected]>, "Hunter, Bill B."
<[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] FW: Fw: rfnoc-radio-redo 3f8c97e Modelsim DE
10.4C simulation fails on noc_block_moving_avg_tb
Message-ID:
<CAGdo0uRS6EWkMAv5kj5ZtV7P0HAHXMyzx=x_x-yajbv32t4...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Craig,
I have a large number of fixes for the various test benches that will be
pushed in the next few days.
Jonathon
On Fri, Apr 8, 2016 at 6:01 AM, Swanson, Craig <
[email protected]> wrote:
> Jonathon,
>
> I sent you the log file about ten days ago with why the rfnoc-radio-redo
> fails on your off the shelf vanilla noc_block_moving_avg module. Any
> update on why this is failing?
>
>
>
> 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
>
> http://www.gtri.gatech.edu
>
>
>
> *From:* Swanson, Craig
> *Sent:* Tuesday, March 29, 2016 7:49 AM
> *To:* Jonathon Pendlum <[email protected]>
>
> *Subject:* Re: Fw: rfnoc-radio-redo 3f8c97e Modelsim DE 10.4C simulation
> fails on noc_block_moving_avg_tb
>
>
>
> ?Jonathon,
>
> See the attached.
>
> Craig
>
>
>
> *Craig F. Swanson*
>
> *Research Engineer II*
>
> *Information and Communications Laboratory*
>
> *Communications, Systems, and Spectrum Division*
>
> *Georgia Tech Research Institute*
>
>
> *Room 560 250 14th St NW*
>
> *Atlanta, GA 30318*
>
> *Cell: 770.298.9156 <770.298.9156>*
>
> http://www.gtri.gatech.edu
> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
>
>
> ------------------------------
>
> *From:* Jonathon Pendlum <[email protected]>
> *Sent:* Monday, March 28, 2016 1:31 PM
> *To:* Swanson, Craig
> *Subject:* Re: Fw: rfnoc-radio-redo 3f8c97e Modelsim DE 10.4C simulation
> fails on noc_block_moving_avg_tb
>
>
>
> What kind of warning messages?
>
>
>
>
>
> Jonathon
>
>
>
> On Mon, Mar 28, 2016 at 10:04 AM, Swanson, Craig <
> [email protected]> wrote:
>
> Jonathon,
>
> Thanks.
>
> In the rfnoc-radio-redo I ran make on noc_block_moving_avg in the top/e300
> and lib/rfnoc and got lots of nasty looking warning messages that I don?t
> think I ever saw in rfnoc-devel. My guess is that the radio redo is still
> very immature in the synthesis and simulation.
>
>
>
> 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
>
> http://www.gtri.gatech.edu
>
>
>
> *From:* Jonathon Pendlum [mailto:[email protected]]
> *Sent:* Monday, March 28, 2016 12:53 PM
> *To:* Swanson, Craig <[email protected]>
> *Subject:* Re: Fw: rfnoc-radio-redo 3f8c97e Modelsim DE 10.4C simulation
> fails on noc_block_moving_avg_tb
>
>
>
> Synthesis works. I will be pushing in the next day or so with fixes for
> the test benches.
>
>
>
> On Fri, Mar 25, 2016 at 11:33 AM, Swanson, Craig <
> [email protected]> wrote:
>
> ?Jonathon,
>
> Are there any testbenches that work? I need to create a Receiver
> testbench that is based off of a working testbench.
>
> Does the synthesis part work if I run "make E310_RFNOC"?
>
>
>
> Craig
>
>
>
> *Craig F. Swanson*
>
> *Research Engineer II*
>
> *Information and Communications Laboratory*
>
> *Communications, Systems, and Spectrum Division*
>
> *Georgia Tech Research Institute*
>
>
> *Room 560 250 14th St NW*
>
> *Atlanta, GA 30318*
>
> *Cell: 770.298.9156 <770.298.9156>*
>
> http://www.gtri.gatech.edu
> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
>
>
> ------------------------------
>
> *From:* Jonathon Pendlum <[email protected]>
> *Sent:* Friday, March 25, 2016 2:05 PM
> *To:* Swanson, Craig
> *Subject:* Re: Fw: rfnoc-radio-redo 3f8c97e Modelsim DE 10.4C simulation
> fails on noc_block_moving_avg_tb
>
>
>
> Several of the test benches are very likely to be broken since I made some
> big test bench infrastructure improvements but didn't update all the test
> benches. I plan on doing that soon, but for the next few days they will be
> broken.
>
>
>
> On Fri, Mar 25, 2016 at 9:10 AM, Swanson, Craig <
> [email protected]> wrote:
>
> Jonathon,
>
> I was wrong about needing to add into
> usrp3/tools/scripts/viv_sim_project.tcl
>
> set_property default_lib work [current_project]?
>
> right before "launch_simulation".
>
> I reloaded rfnoc-radio-redo and it wasn't necessary.
>
>
>
> But I am still getting the error shown below in Modelsim.
>
>
>
> Craig
>
>
>
>
>
> *Craig F. Swanson*
>
> *Research Engineer II*
>
> *Information and Communications Laboratory*
>
> *Communications, Systems, and Spectrum Division*
>
> *Georgia Tech Research Institute*
>
>
> *Room 560 250 14th St NW*
>
> *Atlanta, GA 30318*
>
> *Cell: 770.298.9156 <770.298.9156>*
>
> http://www.gtri.gatech.edu
> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
>
>
> ------------------------------
>
> *From:* Swanson, Craig
> *Sent:* Friday, March 25, 2016 11:43 AM
> *To:* Jonathon Pendlum
> *Cc:* [email protected]
> *Subject:* rfnoc-radio-redo 3f8c97e Modelsim DE 10.4C simulation fails on
> noc_block_moving_avg_tb
>
>
>
> Jonathon,
>
> I moved to the rfnoc-radio-redo branch 3f8c97e and so far I am pleased
> with how Modelsim DE 10.4c (a 32-bit executable) is responding. When I
> used the rfnoc-devel branch, I could never run "make vsim". I always had
> to run "make vsim GUI=1", and then call up modelsim from vivado. Maybe it
> has to do with Vivado 2015.4 fixing the issue with
>
> set_param project.enableUnifiedSimulation 0
>
> which I believe is no longer needed.
>
> I did have to go into usrp3/tools/scripts/viv_sim_project.tcl and add
>
> set_property default_lib work [current_project]?
>
> right before "launch_simulation".
>
>
>
> But I am getting this error in Modelsim:
>
>
>
> # do {noc_block_moving_avg_tb_simulate.do}
>
> # vsim -voptargs=""+acc"" -t 1ps -c -L unisims_ver -L unimacro_ver -L
> secureip -L work -L fifo_generator_v13_0_1 -L xil_defaultlib -L
> xbip_utils_v3_0_5 -L axi_utils_v2_0_1 -L xbip_pipe_v3_0_1 -L
> xbip_dsp48_wrapper_v3_0_4 -L xbip_dsp48_addsub_v3_0_1 -L
> xbip_bram18k_v3_0_1 -L mult_gen_v12_0_10 -L floating_point_v7_0_11 -L
> xbip_dsp48_mult_v3_0_1 -L xbip_dsp48_multadd_v3_0_1 -L div_gen_v5_1_9 -lib
> work work.noc_block_moving_avg_tb work.glbl
>
> # Start time: 11:30:41 on Mar 25,2016
>
> # ** Error: (vsim-3170) Could not find
> '/home/craig/uhd/fpga-src/usrp3/lib/rfnoc/noc_block_moving_avg_tb/modelsim_proj/modelsim_proj.sim/sim_1/behav/msim/work.noc_block_moving_avg_tb'.
>
> # Error loading design
>
> # Error: Error loading design
>
> # Pausing macro execution
>
> # MACRO ./noc_block_moving_avg_tb_simulate.do PAUSED at line 9
>
>
>
> Any ideas?
>
>
>
> Craig
>
>
>
>
>
>
>
> *Craig F. Swanson*
>
> *Research Engineer II*
>
> *Information and Communications Laboratory*
>
> *Communications, Systems, and Spectrum Division*
>
> *Georgia Tech Research Institute*
>
>
> *Room 560 250 14th St NW*
>
> *Atlanta, GA 30318*
>
> *Cell: 770.298.9156 <770.298.9156>*
>
> http://www.gtri.gatech.edu
> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/235cb47e/attachment-0001.html>
------------------------------
Message: 15
Date: Fri, 08 Apr 2016 17:16:36 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Fwd: Angle of Arrival Measurements
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 04/08/2016 04:21 PM, Marcus M?ller via USRP-users wrote:
> Hi Michael,
>
>
>
> So, I'm currently having a look at your flow graphs; they look sound
> to me; especially the complex method (Which pretty much is equivalent
> to picking one frequency bin from the FFT, if you add a sharp bandpass
> filter, so that you only see one frequency) looks efficient. In fact,
> seeing both approaches in one place reminded me of OFDM radar, where
> one actually takes advantage of the
I use the complex-conjugate method in astronomical interferometry, which
is related to AoA, at least in an incidental sense--the emergence
of fringes is due to change in phase due to change in arrival angle
relative to the baseline between the antenna.
I also just use it for measuring and/or looking-for phase-drift between
two sources that should be phase-coherent.
> time/frequency structure of the signal, and, more elementarily, the
> fact that a shift in time domain is a modulation with an offset
> frequency in frequency domain. Maybe [1] is a bit of a fun read to
> you; for the angle of arrival problem (which for your approaches is
> really but a time offset problem), things boil down to:
> If $x$ and $y$ are the same signal, but $y(t)=x(t-\tau)$ is delayed by
> $\tau$, then their Fourier transforms $X$ and $Y$ are also the same
> but for the latter $Y=e^{-j2\pi\tau f} X$ being the first modulated by
> a complex sinusoid. Estimating that sinusoid's frequency gives you the
> timing offset; you can get the "pure" tone by just dividing $\frac
> YX$. Looking at the discrete signal case, note that the frequency
> resolution you can get depends on the DFT you're doing ? i.e. longer
> observation/larger DFT has a very positive effect on accuracy!
>
> I'd really love to see multiple approaches at AoA being implemented,
> that will definitely be an interesting use case for both SDR in
> general, the USRP B210, and GNU Radio; I don't remember fully, but I
> think the cel-kit account on github has a gr-specest repo, where you
> can find a few examples of parametric spectrum estimators; amongst
> these MUSIC, an algorithm actually originating in the world of
> direction detection, applied to frequency estimation. It should be
> pretty straightforward to adapt the algorithm to spatial problems ?
> basically, you'd replace the estimated signal autocovariance matrix by
> a antenna cross-correlation matrix.
>
> Best regards,
> Marcus
>
> [1] Braun, Martin. /Ofdm radar algorithms in mobile communication
> networks/. Diss. Karlsruhe, Karlsruher Institut f?r Technologie (KIT),
> Diss., 2014, 2014.
> http://d-nb.info/104838490X/34
> On 08.04.2016 21:15, Michael Duckett via USRP-users wrote:
>> We are using two antennas on the same B210 and the distance between
>> them is 7cm (the distance between the two "TX/RX" ports). We
>> understand that this affects the measured phase difference and the
>> further calculation for the AOA. For future tests we may try to widen
>> the distance between the two antennas to half the wavelength (I think
>> that would be around 1.3 to 1.7 m for FM radio station frequencies).
>>
>> This distance between the two antennas brings us to the first
>> question. Because the distance between the antennas was small
>> compared to half the wavelength of the frequency, the range of valid
>> phase differences was shrunk, too. Most of the time when we were
>> measuring we got phase differences which were out of range of the
>> valid region. In one spot close to the tower, we positioned our
>> antenna array at the 0 degree orientation and phase difference
>> values which corresponded to 60-70 degrees. In another spot with the
>> same orientation, we got phase difference values which were out of
>> range. So when we rotated the antenna array, it was difficult to
>> compared the AOA because most of the time that calculation wasn't
>> possible. But we can see noticeable changes in the phase difference
>> when rotating the array. But there doesn't seem to be an easily
>> decipherable pattern to the error.
>>
>> We haven't been monitoring the time domain signal levels. We can try
>> that next time, as well.
>>
>> On Fri, Apr 8, 2016 at 2:19 PM, Derek Kozel <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Hello Michael,
>>
>> In addition to Alexander's good thoughts, are you monitoring the
>> time domain signal levels to ensure that the receive gain is set
>> appropriately? I see a QT GUI Sink (you may consider using the QT
>> Frequency Sink), but it would be worth while looking at a QT Time
>> Sink as well to see if you are clipping.
>>
>> Regards,
>> Derek
>>
>>
>> On Fri, Apr 8, 2016 at 10:28 AM, Alexander Levedahl via
>> USRP-users <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> I do not have the ability to look at files right now so sorry
>> if I am asking questions that are answered in the files.
>>
>> If you stand in one spot and rotate, is the error
>> consistent? I.e., if you are pointing the array right at it,
>> it shows the AOA as 60-70. If you change to pointing 30
>> degrees, does the AOA change to 90-100?
>> Are the results consistent across restarting the B210?
>> Depending on the answer to these questions, it may simply be
>> a calibration problem. I.e., when you turn it on there needs
>> to be a calibration step.
>>
>> Finally, how many antennas are you using 2 or are you using
>> multiple B210s? Is your antenna spaced appropriately for the
>> operating frequency?
>>
>>
>> On Fri, Apr 8, 2016 at 12:51 PM, Michael Duckett via
>> USRP-users <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Hello,
>>
>> We are trying to measure the angle of arrival of FM using
>> USRP B210. We have run into some problems with the
>> measurements and hence we are writing this email. It
>> would be nice if we can get some inputs from you on how
>> to fix this issue. We have used two methods for computing
>> the phase difference. We have used the first one most of
>> the time. However, we are posting both the methods here
>> for you to have a look.
>>
>> I have attached method 1 (phase_difference_probe.grc for
>> probing and phase_difference_view.grc which provides a
>> nice GUI to look at) and method 2 (complex_method.grc).
>> Method 1 is based on the following "paper":
>>
>>
>>
>> http://www.egr.msu.edu/classes/ece480/capstone/spring14/group02/docs/Application%20Note%20-%20Phase%20George%20Godby%20Team%202.pdf
>>
>>
>> We use these flow graphs and run them in another script
>> which probes the "top_block" to get 500 samples which are
>> then averaged to produce one data point.
>>
>> We also attach a diagram (AoA_Figure.pdf) which shows a
>> basic idea of how the antennas and transmitter are setup
>> and what the Angle of Arrival (AoA) is, when it comes to
>> our measurements.
>>
>> We tried our code in two different situations. In our
>> first test, our transmitter was another B210 and we were
>> in an open field. The frequency we tried ranged from 200
>> MHz to 1.0 GHz and then 3 GHz and 4 GHz. Our Phase
>> difference and consequently our AoA measurement were not
>> too far off, when the antenna array was facing the
>> transmitter (i.e. at an expected AoA of 0 degs). As we
>> moved closer towards an AoA of +- 90 the accuracy of the
>> measurement fell off. But the consistency of the 500
>> samples was still pretty good (we were getting a standard
>> deviation under 0.10 radians).
>>
>> For our second test, we tried to get the AoA from FM
>> radio towers. We got about 800-1000m away from a popular
>> radio station tower and pointed the antenna array at the
>> tower (expecting an AoA of around 0 degs). But we got
>> measurements which were way off. We did this for a couple
>> of different spots but the measurements were all over the
>> place (the standard deviation for individual data points
>> were pretty good but the measurement for the 0 deg
>> position at one spot was different for another spot
>> around the tower). We did manege to get angle
>> measurements at one point when we were about 800 meters
>> from the tower. The expected angle was 0 but we got 60 -
>> 70 degrees as the measured angle. We also tried at other
>> places, one was about 800 m from the tower and the other
>> about 1200m. But both these places were problematic.
>>
>> It would be nice to get your inputs on the flow graphs.
>> What are your thoughts about the flow graph? Do you see
>> any glaring problems with the flow graph or with the set
>> up? If you have any more questions about the setup then
>> feel free to ask.
>>
>> Most of the information about the setup that we are using
>> are in the attached grc files. Thanks a lot for all your
>> time.
>>
>> Sincerely,
>> Michael Duckett
>>
>>
>> _______________________________________________
>> 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] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/1bdf919f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 567 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/1bdf919f/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 590 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/1bdf919f/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1170 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/1bdf919f/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 526 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/1bdf919f/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 598 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/1bdf919f/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 583 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/1bdf919f/attachment-0013.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1158 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/1bdf919f/attachment-0014.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 657 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/1bdf919f/attachment-0015.png>
------------------------------
Message: 16
Date: Fri, 08 Apr 2016 15:45:15 -0400
From: [email protected]
To: [email protected]
Subject: [USRP-users] building an E310 RFNoC FPGA image with HLS
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes";
format="flowed"
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
------------------------------
Message: 17
Date: Fri, 8 Apr 2016 14:37:26 -0700
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: Re: [USRP-users] USRP through Python
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Oh OK. In general, you should be able to do everything through the GNU
Radio stuff, and if you can't, then we should probably amend gr-uhd. So
please tell us if you ever do run into such an issue.
Cheers,
Martin
On 04/08/2016 10:06 AM, Richard Bell wrote:
> I have no issue that Python doesn't handle. It was a general question in
> case I do run into this situation.
>
> Thanks,
> Rich
>
> On Thu, Apr 7, 2016 at 6:12 PM, Martin Braun via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> Well, usually the USRP blocks expose all you need. What are you trying
> to do?
>
> M
>
> On 04/07/2016 03:02 PM, Richard Bell via USRP-users wrote:
> > Is the design flow typically something like this then:
> >
> > 1) Use python for USRP control if the function calls are exposed,
> otherwise
> > 2) Write a C++ block that you can call in Python that does the desired
> > control/monitoring
> >
> > Rich
> >
> > On Thu, Apr 7, 2016 at 11:01 AM, Marcus M?ller
> > <[email protected] <mailto:[email protected]>
> <mailto:[email protected]
> <mailto:[email protected]>>> wrote:
> >
> > multi_usrp is a UHD class, that the usrp_sink and _source use
> > *internally*; you can't use it standalone in GNU Radio, and that's
> > why there's no GNU Radio benefit from swigging it.
> > However, the usrp_sink and _source blocks wrap most of the relevant
> > methods, though under different names (set_gain[1] instead of
> > set_rx_gain or set_tx_gain, because if modifying a usrp_sink or
> > usrp_source, it's clear whether you want to modify TX or RX).
> >
> > Best regards,
> > Marcus
> >
> > [1]
> https://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__source.html
> >
> > On 07.04.2016 19:44, Dave NotTelling via USRP-users wrote:
> >> Martin,
> >>
> >> Is there a specific reason why the multi_usrp class isn't
> >> exposed to Python?
> >>
> >> -Dave
> >>
> >> On Thu, Apr 7, 2016 at 1:13 PM, Martin Braun via USRP-users
> >> <<mailto:[email protected]
> <mailto:[email protected]>>[email protected]
> <mailto:[email protected]>
> >> <mailto:[email protected]
> <mailto:[email protected]>>> wrote:
> >>
> >> To clarify,
> >>
> >> multi_usrp is not swigged, only the GNU Radio blocks. So the
> UHD
> >> reference manual does not apply to Python-land.
> >>
> >> Cheers,
> >> M
> >>
> >> On 04/06/2016 02:27 PM, Richard Bell via USRP-users wrote:
> >> > Ah thank you! That python API is what I couldn't find, I
> >> kept getting
> >> > stuck on the C++ API.
> >> >
> >> > Things are working now.
> >> >
> >> > Rich
> >> >
> >> > On Wed, Apr 6, 2016 at 2:09 PM, James Humphries
> >> > <[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> >> <mailto:[email protected]
> <mailto:[email protected]>
> >> <mailto:[email protected]
> <mailto:[email protected]>>>> wrote:
> >> >
> >> > Hi Rich,
> >> >
> >> > It looks like you have instantiated a USRP sink, which
> >> is for TX
> >> > only. You will need to add a USRP source if you want to
> >> RX as well.
> >> >
> >> > See the GNU Radio Python API here for a list of all the
> >> functions
> >> > and methods:
> >> >
> >> > http://gnuradio.org/doc/sphinx/#uhd-blocks
> >> >
> >> > -Trip
> >> >
> >> > On Wed, Apr 6, 2016 at 3:47 PM, Richard Bell via
> USRP-users
> >> > <[email protected]
> <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> >> <mailto:[email protected]
> <mailto:[email protected]>
> >> <mailto:[email protected]
> <mailto:[email protected]>>>> wrote:
> >> >
> >> > Hi all,
> >> >
> >> > After instantiating a usrp object in Python,
> which I
> >> will call
> >> > usrp here, I'm attempting to call
> >> > usrp.get_rx_sensor("lo_locked") and
> >> usrp.get_rx_freq(), but I
> >> > get the following error:
> >> >
> >> > AttributeError: 'usrp_sink_sptr' object has no
> attribute
> >> > 'get_rx_freq'
> >> >
> >> > I can call usrp.set_center_freq(target_freq) just
> >> fine. How do I
> >> > gain access to the full set of usrp methods through
> >> Python? Is
> >> > there example code that demonstrates some of this?
> >> I've looked
> >> > through the freq_hopping.py and
> >> usrp_spectrum_sense.py scripts
> >> > extensively. They don't use much more then
> >> set_center_freq().
> >> >
> >> > Thanks,
> >> > Rich
> >> >
> >> > _______________________________________________
> >> > USRP-users mailing list
> >> > [email protected]
> <mailto:[email protected]>
> >> <mailto:[email protected]
> <mailto:[email protected]>>
> >> <mailto:[email protected]
> <mailto:[email protected]>
> >> <mailto:[email protected]
> <mailto:[email protected]>>>
> >> >
> >>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > USRP-users mailing list
> >> > [email protected]
> <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> >> >
> >>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >> >
> >>
> >>
> >> _______________________________________________
> >> USRP-users mailing list
> >> [email protected]
> <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> >>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> USRP-users mailing list
> >> [email protected]
> <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> >>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
> >
> >
> > _______________________________________________
> > 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] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
------------------------------
Message: 18
Date: Fri, 8 Apr 2016 14:38:18 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] E310 (RFNoC not PC host)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Ignazio,
yes, that's what RFNoC is designed to do. You will need to cross-compile
RFNoC for your E310 to use it.
Cheers,
Martin
On 04/08/2016 11:21 AM, Ignazio Finazzi via USRP-users wrote:
> Marcus M?ller via USRP-users <usrp-users@...> writes:
>
>>
>> Hi Ignazio,
>>
>> RFNoC is an FPGA architecture, so no, you cannot use it "on the ARM",
>> but can use the ARM to talk to your FPGA carrying such an RFNoC-based
>> DSP design.
>>
>> Assuming you want to use GNU Radio:
>> That runs well, and comes with the gr-uhd module that talks to all our
>> USRP devices, whether you're using an RFNoC FPGA image or a non-RFNoC one.
>> If you want to use RFNoC, though, you will need UHD (the host-side
>> driver) from its rfnoc-devel branch, and you'll need gr-ettus, which is
>> another GNU Radio module, that supports connecting on-FPGA signal
>> processing blocks "as if" they were normal GNU Radio blocks.
>> These all are integrated in our RFNoC-enabled SD card images; you can
>> build one of those yourself.
>>
>> Now, you ask:
>>
>>> If not, how can i develop programs within the FPGA without VHDL or
>> Verilog?
>>
>> I'm afraid that in its current state, this is not really possible. You
>> will need at least basic Verilog proficiency.
>>
>> Best regards,
>> Marcus
>> On 08.04.2016 19:32, Ignazio Finazzi via USRP-users wrote:
>>> Hi all!!
>>>
>>> I'm new on USRPs. I used GNURadio and GRC and i developed some programs with
>>> a RTL-SDR. Few weeks ago, we decided to buy an USRP E310 devide to develop
>>> our project and board it in an UAV.
>>>
>>> After read all E310 posts and the User Manual i understood that the better
>>> way to use USRP Embedded devices is to develop programs inside the Zynq 7000
>>> series FPGA and the within ARM as the host.
>>>
>>> My question is: Is it possible to use RFNoC toolkit in the ARM? If it
>>> possible, how? If not, how can i develop programs within the FPGA without
>>> VHDL or Verilog?
>>>
>>> Thanks so much
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users@...
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
> Thanks Marcus for your fast answer.
>
> Well, i understood that RFNoC is an FPGA architecture. I try to say that, i
> want to process the signal on the FPGA and transmit the processed signal to
> the ARM, finally send the data processed to a ground station which do the
> graphic process.
>
> I had flashed the SD card with the release 4 e3xx demo image
> (http://files.ettus.com/e3xx_images/e3xx-release-4/ettus-e3xx-sg3/). After
> that i started a SSH connection (X terminal enabled) and launched GRC but i
> didn't find any RFNoC block in the GRC installed in the ARM.
>
> One more question, the SDK OECORE (OE cross-compiler build environment) must
> installed on the embedded linux on the ARM or on my PC? SDK OECORE tool is
> different that RFNoC toolkit i think...which is the difference?
>
> Thanks so much
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 19
Date: Fri, 8 Apr 2016 15:10:13 -0700
From: Richard Bell <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Style Guide for referencing USRP or Ettus
Message-ID:
<CAMMoi3u=mreY4=Oiy=wfkkezsgskuj4asj9eps75i6wugvf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/52d546dc/attachment-0001.html>
------------------------------
Message: 20
Date: Sat, 9 Apr 2016 03:59:56 +0530
From: Abhinav Jadon <[email protected]>
To: "[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: [USRP-users] IEEE 802.11 Transmitter in X310s
Message-ID:
<caax7w7k8skmwdqcsmly9ytsoe_kjgkz4ap38zhbzqb4cnfr...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
My setup consists of two X310s - one transmitter and one receiver -
connected with SMA cable.
The receiver code has been independently tested by capturing the AP packets.
The transmitter code was tested in a software loopback with the receiver.
The gains on both sides were adjusted such that there was no clipping.
attenuator (-10db) were used to connect the two USRPs over SMA link.
The transmitter transmits the packet but at the receiver end, these packets
are not successfully decoded. A deeper look reveals that for a high
correlation value (0.8) , packets are being detected by the packet
detection mechanism but the signal field is decoded wrongly in all the
packets detected. . Since unit testing of every block was successful, it
was my hypothesis that the source of error lies on the transmitter-hardware
side.
I began scraping thorough the mail archives and got hold of this :
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-September/015576.html
This thread details on the problem related to burst transmissions in X310.
Apparently, the successive bursts are not same - the end of first burst is
appended to the second burst.
I don't have the hardware to verify the claim, but assuming that it is
correct. It still doesn't explain the wrong decoding of the signal field.
What am I missing ?
Abhinav PS Jadon
2012122
Electronics and Communication Engineering Undergraduate
IIIT - Delhi
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160409/8908aa37/attachment-0001.html>
------------------------------
Message: 21
Date: Fri, 08 Apr 2016 18:45:14 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] E310 GPSDO clock reference
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
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
------------------------------
Message: 22
Date: Fri, 8 Apr 2016 16:38:43 -0700
From: Derek Kozel <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] E310 GPSDO clock reference
Message-ID:
<CAA+K=tsvfknhrt254t2qb3kit_rxos9cmmofjo-4xr4vvgy...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/58382a67/attachment-0001.html>
------------------------------
Message: 23
Date: Fri, 8 Apr 2016 20:40:16 -0700
From: Derek Kozel <[email protected]>
To: Vinit Shah <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] [Discuss-gnuradio] error msg of hardware not
supporting the requested RX frequency
Message-ID:
<CAA+K=tudvdzky51qbidqbpat-irvrftduys3xwpndbvxgev...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Vinit,
Lets keep the mailing list in the loop so others can benefit as well. The
BasicRX uses undersampling along with a Digital Down Converter in the FPGA
to select a section of spectrum to observe.
https://en.wikipedia.org/wiki/Undersampling
What sort of antenna are you using? The BasicRX doesn't have any amplifier
either so a signal must be sufficiently strong to be received. The received
signal from the SMA is converted to a differential signal by a balun and
then run to the ADCs on the N200's motherboard. Do you have access to a
signal or function generator? The input power to drive the ADC to full
scale is +10 dBm, or a 2Vpp signal centred on 0V. If you have access to one
of these or another low power transmitter which works below 250 MHz you
could try that. I'd keep the maximum input power a bit below the +10 dBm
just to avoid any possibility of damage.
I'd need to test it myself to produce real numbers, but signals above
-100dBm I'd expect to be visibly detectable with enough averaging on the
FFT.
Regards,
Derek
On Fri, Apr 8, 2016 at 6:10 PM, Vinit Shah <[email protected]> wrote:
> Pardon.. daughterboard range is 250 Mhz..
> When I am trying to run that simple FM receiver program, I get very very
> weak signal..-100 dB which is nothing but the noise floor I guess. And I do
> not know what the problem would be if this error message is harmless..
>
> Also, I am little confused, if daughter board does not have mixer then How
> is it going to downsample and convert it into IF range.. ??
>
> On Fri, Apr 8, 2016 at 1:56 PM, Derek Kozel <[email protected]> wrote:
>
>> Hello Vinit,
>>
>> This question is much more about UHD so I'm adding the usrp-users mailing
>> list [1].
>>
>> There is no USRP daughterboard which goes to 250 GHz so I assume you mean
>> 250 MHz which would point towards the BasicRx daughterboard. This
>> daughterboard has no mixer and so the N200 will use aliasing to receive
>> non-baseband signals. The N200's ADC runs at 100 MSPS, but Gigabit Ethernet
>> isn't able to transport that much data so it is always decimated by some
>> factor. This means that a target frequency of 97.9 MHz (A good choice for a
>> first test) is in a higher Nyquist band. What you're seeing is correct
>> behaviour.
>>
>>
>> UHD 3.5.5 is very old and I'd recommend removing the current version and
>> install a newer release. I would guess that you are on Ubuntu 14.04 and
>> installed it using apt. If you are very unfamiliar with Linux and don't
>> have anyone locally who you could get some assistance from it's worth
>> considering using the GNU Radio Live Environment [2] which can be written
>> to a USB drive and booted from. This comes with up to date versions of GNU
>> Radio and UHD, as well as a variety of additional SDR related packages.
>>
>> You can also look at PyBOMBS[3] or the build-gnuradio [4] script, either
>> of which will install the latest UHD and GNU Radio.
>>
>> Regards,
>> Derek
>>
>> [1] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> [2] https://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD
>> [3] https://github.com/gnuradio/pybombs/
>> [4]
>> https://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGRFromSource#Using-the-build-gnuradio-script
>>
>> On Fri, Apr 8, 2016 at 1:12 PM, Vinit Shah <[email protected]> wrote:
>>
>>> Dear all,
>>> I am a beginner in Linux and So far I have successfully installed
>>> gnuradio and hardware dependencies.
>>> The very basic program which is just connecting usrp source with WX gui
>>> fft sink is not working correctly.
>>> I am getting following error messaege
>>>
>>> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.005.005-0-unknown
>>>
>>> Using Volk machine: sse4_2_64_orc
>>> -- Opening a USRP2/N-Series device...
>>> -- Current recv frame size: 1472 bytes
>>> -- Current send frame size: 1472 bytes
>>>
>>> UHD Warning:
>>> Unable to set the thread priority. Performance may be negatively
>>> affected.
>>> Please see the general application notes in the manual for
>>> instructions.
>>> EnvironmentError: OSError: error in pthread_setschedparam
>>>
>>> UHD Warning:
>>> The hardware does not support the requested RX frequency:
>>> Target frequency: 97.900000 MHz
>>> Actual frequency: -2.100000 MHz
>>>
>>> >>> Done
>>>
>>> My daughter board has range up to 250 Gigs... but I do not know why even
>>> with 10 M sampling frequency my system is aliasing ??
>>> This is a common problem I found on internet but no effective solution
>>> so far, I think.
>>> Any help would be highly appreciated.
>>> I request you please explain explicitly because I am novice in this
>>> field( with linux), and if possible with example..??
>>>
>>> Thank you very much in advance
>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> [email protected]
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160408/81d99118/attachment-0001.html>
------------------------------
Message: 24
Date: Sat, 9 Apr 2016 12:38:17 +0300
From: Matt Ettus <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] E310 (RFNoC not PC host)
Message-ID:
<CAN=1kn9agj8hqo5fbtkjxq-q1mkddzh95xvd9tsw0ud68p5...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Fri, Apr 8, 2016 at 8:57 PM, Marcus M?ller <[email protected]>
wrote:
> > If not, how can i develop programs within the FPGA without VHDL or
> Verilog?
>
> I'm afraid that in its current state, this is not really possible. You
> will need at least basic Verilog proficiency.
>
> Best regards,
> Marcus
>
>
Actually, you can use Vivado HLS to create blocks with C instead of
Verilog/VHDL. See the add_sub block in the rfnoc directory.
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160409/eb08ae22/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 9
*****************************************
