usrp-users@lists.ettus.com
Discussion and technical support related to USRP, UHD, RFNoC
View all threadsRe: [USRP-users] USRP-users Digest, Vol 108, Issue 18
Hi, everyone.
I am doing the estimation angle of arrival by using USRP.
The problem I want to fix is the initial phase offset of each dboards.
From now on, I have searched some knowledge about this issue. But I can not
implement the concept.
those concept I got are below:
- Some kinds of dboard’s initial phase offset can remain constant after
re-tune by timed command (code)
http://files.ettus.com/manual/page_sync.html 2
http://files.ettus.com/manual/page_sync.html
- I saw some AOA finding hardware set using another usrp or dboard to
transmit a reference signal into the USRPs which are receivers connected
to antenna array elements.
https://decibel.ni.com/content/docs/DOC-25716 1
https://decibel.ni.com/content/docs/DOC-25716
My simple hardware set is below:
Two usrp N200 (with UBX).
An octoclock to provide the reference signal.
/---/
Theoretically, I would to send and to receive the same signal, I would get
same
waveform (phase). But I get a different offset and I find the offset is not
constant.
Summary of the problems:
I do not know where and how to add those ‘timed commands’ which
taught in the USRP Hardware Driver and USRP Manual.
(I saw someone said that I can do nothing and the initial offset of UBX
will remain constant after retuning. But the result tell me it’s not
true.)
2.
Can anybody provide or teach me the code of phase calibration by
using another USRP?
I really do not understand how to set the gnuradio blocks to complete
these work.
Any example could provide to me or anyone can help me?
Thank you very much for any help.
Simona
Il giorno mar 20 ago 2019 alle ore 17:26 usrp-users-request@lists.ettus.com
ha scritto:
Send USRP-users mailing list submissions to
usrp-users@lists.ettus.com
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
usrp-users-request@lists.ettus.com
You can reach the person managing the list at
usrp-users-owner@lists.ettus.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. B205 GPIO & UHD Python API (Louis Brown)
2. Re: Incorrect RX time_spec values with X300, TwinRX, and
v3.14.1.0 (Neel Pandeya)
3. Re: Incorrect RX time_spec values with X300, TwinRX, and
v3.14.1.0 (Jason Roehm)
4. Re: Incorrect RX time_spec values with X300, TwinRX, and
v3.14.1.0 (Jason Roehm)
5. Re: Incorrect RX time_spec values with X300, TwinRX, and
v3.14.1.0 (Neel Pandeya)
6. Re: Incorrect RX time_spec values with X300, TwinRX, and
v3.14.1.0 (Jason Roehm)
Message: 1
Date: Mon, 19 Aug 2019 11:22:38 -0500
From: Louis Brown rfengr00@me.com
To: usrp-users@lists.ettus.com
Subject: [USRP-users] B205 GPIO & UHD Python API
Message-ID: 353FEC09-C798-47A9-B0F2-77CB3CA98F0F@me.com
Content-Type: text/plain; charset=us-ascii
Are there any examples of accessing B205 GPIO via UHD Python API? I need
to control some hardware via SPI and can bit-bang it if needed.
Thanks,
Lou
Message: 2
Date: Mon, 19 Aug 2019 11:34:28 -0500
From: Neel Pandeya neel.pandeya@ettus.com
To: Jason Roehm jasonr@3db-labs.com
Cc: usrp-users usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Incorrect RX time_spec values with X300,
TwinRX, and v3.14.1.0
Message-ID:
<
CACaXmv-XwDKP8ok_325K_hahwWUAuesQJddD8-CkoNrJY7GqfQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Jason:
I also would have expected UHD 3.14.1.0 to have resolved this issue.
Would you be able to send me a stand-alone program that I can use to
reproduce this problem?
Also, I'm curious, do you have a GPSDO installed in your X300?
--Neel Pandeya
On Sun, 18 Aug 2019 at 13:19, Jason Roehm via USRP-users <
usrp-users@lists.ettus.com> wrote:
On 8/16/19 10:32 PM, Marcus D. Leech via USRP-users wrote:
On 08/16/2019 04:54 PM, Jason Roehm via USRP-users wrote:
I have a software application that interfaces to an X300 with a
TwinRX daughterboard installed. We recently upgraded our UHD version
to v3.14.1.0 in our application. Since then, we've observed that the
time_spec values on consecutive blocks of data received from the unit
(i.e. from two sequential calls to rx_streamer::recv()) are not
consistent with one another. The timecodes reported by the unit seem
to be moving forward at twice real time.
As an example, assume that I have the X300 configured for a sample
rate of 100 MSPS, and that I'm getting 1000 samples per call to
recv() (these are just round numbers to simplify the discussion). I'm
seeing metadata from consecutive recv() calls that look like this:
Block 1:
- time_spec.get_whole_secs(): 0
- time_spec.get_frac_secs(): 0
- 1000 samples @ 100 MHz = 10 usec of data
Block 2:
- time_spec.get_whole_secs(): 0
- time_spec.get_frac_secs(): 0.000020 (where I would have expected
0.000010 instead) - 1000 samples @ 100 MHz = 10 usec of data
... and so on.
If you watch the stream of timestamps received from the device, it
looks like time is passing at twice the appropriate rate. I noticed
this recent commit that seemed could be related:
If I revert that commit, then the timekeeping on the TwinRX channel
works properly again. However, that isn't a fix that I can work with;
I also use this hardware in a configuration where the X300 has a
TwinRX and LFRX daughterboard installed simultaneously. Without the
above commit, then I am unable to stream data from the LFRX; the
rx_streamer never returns any data for that channel. I previously
reported that problem
(
http://ettus.80997.x6.nabble.com/USRP-users-X300-with-TwinRX-and-LFRX-under-UHD-v3-14-td12749.html
)
and never got an answer, but the above commit silently fixed it in
v3.14.1.0.
How can I get correct timekeeping with the X300/TwinRX, while
maintaining my ability to stream from a TwinRX and LFRX
simultaneously?
Jason
I THINK this is fixed in commit:
f712d477b97e2ee7cca56d5afcf199f00959eb85
That commit is already included in v3.14.1.0 (and this code was later
amended by commit 4eb12b031f9cad3df3e294db466bd26dee6b78e1, see
So, I don't think that is a fix for this problem.
Jason
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com