I pulled down the master branch of UHD about 2 months ago.
My version is 3.15.0.HEAD-0-gaea0e2de.
On Mon, Jun 15, 2020, 4:54 PM Marcus D. Leech
wrote:
> On 06/15/2020 06:51 PM, Aaron Smith wrote:
>
> Yes, transmissions within the same session are consistent. If I destroy
> the MultiUSRP object
On 06/15/2020 06:51 PM, Aaron Smith wrote:
Yes, transmissions within the same session are consistent. If I
destroy the MultiUSRP object and recreate it (restart my transmit
script), the timing will change. If I repeat hundreds of transmissions
without restarting the timing is stable to the expe
Yes, transmissions within the same session are consistent. If I destroy the
MultiUSRP object and recreate it (restart my transmit script), the timing
will change. If I repeat hundreds of transmissions without restarting the
timing is stable to the expected accuracy of my TOA measurements.
On Mon,
On 06/15/2020 06:45 PM, Aaron Smith wrote:
I am using a master clock rate of 48 MHz and a sample rate of 8 MHz.
When do you notice the timing inconsistency? For example, if you do a
number of timed transmits during the same session, are they
self-consistent? Where "session" is defined as "th
I am using a master clock rate of 48 MHz and a sample rate of 8 MHz.
On Mon, Jun 15, 2020, 4:41 PM Marcus D. Leech
wrote:
> On 06/15/2020 03:42 PM, Aaron Smith wrote:
> > I am using the python api.
> >
> > usrp = uhd.usrp.MultiUSRP()
> >
> > # Set gain, clock rate, sample rate etc...
> >
> > usr
On 06/15/2020 03:42 PM, Aaron Smith wrote:
I am using the python api.
usrp = uhd.usrp.MultiUSRP()
# Set gain, clock rate, sample rate etc...
usrp.set_clock_source('external')
usrp.set_time_source('external')
ts_reset = uhd.types.TimeSpec(0.0)
usrp.set_time_next_pps(ts_reset)
time.sleep(1.0)
l
On 06/15/2020 01:35 PM, Aaron Smith wrote:
Looking back over the thread, I thought there might be some confusion
about what I am trying to accomplish.
My goal is to get a radio (and only 1 radio) to transmit at a
specified time. I don't care what the front end transmit delay of the
radio is,
Looking back over the thread, I thought there might be some confusion about
what I am trying to accomplish.
My goal is to get a radio (and only 1 radio) to transmit at a specified
time. I don't care what the front end transmit delay of the radio is, I
just want it to be consistent so I can calibra
I think I need more information on what you’re doing.
Are you starting a timed transmit sequence on both B200 and seeing a timing
difference between the two?
More details on your exact setup will help us all help you.
Sent from my iPhone
> On Jun 15, 2020, at 1:09 PM, Aaron Smith wrote:
>
I was able to test the B210 today and I confirmed that it also has a random
delay that is related to 1/master_clock_rate.
Marcus, I wonder if I misunderstood your email, because I thought it would
work.
I am only transmitting with one channel. Do I have to utilize the other
channel in some way to
On 06/12/2020 10:07 PM, Aaron Smith via USRP-users wrote:
Robin - with your insight I see that other users have addressed this
on this mailing list. In this thread:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-June/057080.html
the user reports that the B210 does not have this
Robin - with your insight I see that other users have addressed this on
this mailing list. In this thread:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-June/057080.html
the user reports that the B210 does not have this problem, even though it
uses the same AD9361. Perhaps I will
On 06/12/2020 09:35 PM, Robin Coxe via USRP-users wrote:
The phase ambiguity is introduced by the divide-by-2 in the PLLs of
the Analog Devices AD9361 RF integrated transceiver on the B200.
These dividers randomly introduce a 0-degree or 180-degree phase
shift when they come up.
In *additi
The phase ambiguity is introduced by the divide-by-2 in the PLLs of the
Analog Devices AD9361 RF integrated transceiver on the B200. These
dividers randomly introduce a 0-degree or 180-degree phase shift when they
come up.
On Fri, Jun 12, 2020 at 4:08 PM Aaron Smith via USRP-users <
usrp-users
All of the devices share a 10 MHz reference that is generated from the same
source as the 1 PPS.
When you say it's a phase ambiguity, are you suggesting that it's a problem
with the 10Hz reference or something inherent in the radio hardware that I
will have to deal with? Or is there a software fix
The change in time of arrival with B200s is due to phase ambiguity. Do you
have a 10MHz reference shared between your devices as well?
Don't know why N210 has that off-by-one timestamp. I'm guessing that
there's an extra flop in the logic for the PPS timing chain somewhere -- as
in, the clock star
Hello all,
I have two separate, but related, questions.
I am trying to trigger an RF transmission every second, and I am receiving
the transmission with a receiver that has very precise time stamps. I am
driving the receiver with the same 1 PPS source as the B200 and N210. For
my simple test, I w
17 matches
Mail list logo
