Gr-uhd: rx_freq tag and lo_locked

Detlef_R · March 31, 2015, 9:55pm

Hi all,

I’ve been working on a flowgraph that controls sweeping a USRP by
retuning and then dumping samples until catching the sample tagged with
rx_freq of the correct value.

I was confused as to why I was still getting mountains of garbage
samples (several hundred thousand at 10MS/s) after catching the rx_freq
tag, until today I put “assert(usrp->get_sensor(“lo_locked”).to_bool())”
after the block that identifies the correct rx_freq tag, and it popped
immediately.

I’m wondering about the prudence of saying a sample is “at a certain
frequency” before the LO has had a chance to settle.

I also realize that gr-uhd folks are trying to make the message
interface more robust, and the rx_freq tag is an awesome idea, but what
I really want to know is what is the first USABLE sample at my requested
freq. If I still have to carry around a usrp_source pointer so that I
can check the LO state, then the tags output by the usrp_source lose a
lot of appeal.

Any chance of making rx_freq tag “the first usable sample”, or is there
a good reason for the way it works that I haven’t considered?

-Doug

AndersonS_Douglas_J · March 31, 2015, 10:17pm

Hi Doug,

the rationale behind that is that these tags correspond to the stream
metadata coming from the USRP, which tell the host when the tuning
operation has taken place. Now, you’re right, it’s a problem to think
you’re tuned although your LO still hasn’t settled, but since tunes
could also be digital-path only, using the “earliest” time seems
correct.

By the way, you might also want to try a different approach, based on
timed commands: you can set a time for things like tune requests, thus
making sure that the tuning happens at the exact point in time you want
it to (and not influenced by the latency and load of your general
purpose PC). You can then simply “take” the right samples without caring
about tags at all, because you know when these should occur (i.e. which
numbers these should have).

Greetings,
Marcus

PS: try turning off the DC offset correction, if you’re on the N210, for
fast-tuning applications. You’ll have a bigger DC offset, but less
“swinging” after each tune.
PS2: I don’t know whether your overall frequency range allows this, but
as long as you tune within your USRP/daughterboards physical bandwidth,
you might just tune digitally and avoid LO retuning:
http://files.ettus.com/manual/page_general.html#general_tuning_process

AndersonS_Douglas_J · March 31, 2015, 11:26pm

Marcus,

That makes sense, I hadn’t thought of the DSP tuning issue, though I
think it would be infinitely more useful to make the stream tagging
logic aware of LO/DSP tuning and tag the first usable block in either
case. Slightly more involved than I assumed though.

I was actually going to ask this on the Ettus list later but since you
brought up DC offset: is there a technical reason that there is no
uhd_rx_dc_offset cal script? Is is because the LO can be offset so it’s
considered unnecessary or would a cal script not work as well for the RX
side as it does the TX side for some reason? I read through the
tx_dc_offset cal script last week and was curious…

-Doug

From: discuss-gnuradio-bounces+danderson=removed_email_address@domain.invalid
[discuss-gnuradio-bounces+danderson=removed_email_address@domain.invalid] on behalf
of Marcus M. [[email protected]]
Sent: Tuesday, March 31, 2015 2:15 PM
To: [email protected]
Subject: Re: [Discuss-gnuradio] gr-uhd: rx_freq tag and lo_locked

Hi Doug,

the rationale behind that is that these tags correspond to the stream
metadata coming from the USRP, which tell the host when the tuning
operation has taken place. Now, you’re right, it’s a problem to think
you’re tuned although your LO still hasn’t settled, but since tunes
could also be digital-path only, using the “earliest” time seems
correct.

By the way, you might also want to try a different approach, based on
timed commands: you can set a time for things like tune requests, thus
making sure that the tuning happens at the exact point in time you want
it to (and not influenced by the latency and load of your general
purpose PC). You can then simply “take” the right samples without caring
about tags at all, because you know when these should occur (i.e. which
numbers these should have).

Greetings,
Marcus

PS: try turning off the DC offset correction, if you’re on the N210, for
fast-tuning applications. You’ll have a bigger DC offset, but less
“swinging” after each tune.
PS2: I don’t know whether your overall frequency range allows this, but
as long as you tune within your USRP/daughterboards physical bandwidth,
you might just tune digitally and avoid LO retuning:
http://files.ettus.com/manual/page_general.html#general_tuning_process
On 03/31/2015 09:54 PM, Anderson, Douglas J. wrote:
Hi all,

I’ve been working on a flowgraph that controls sweeping a USRP by
retuning and then dumping samples until catching the sample tagged with
rx_freq of the correct value.

I was confused as to why I was still getting mountains of garbage
samples (several hundred thousand at 10MS/s) after catching the rx_freq
tag, until today I put “assert(usrp->get_sensor(“lo_locked”).to_bool())”
after the block that identifies the correct rx_freq tag, and it popped
immediately.

I’m wondering about the prudence of saying a sample is “at a certain
frequency” before the LO has had a chance to settle.

I also realize that gr-uhd folks are trying to make the message
interface more robust, and the rx_freq tag is an awesome idea, but what
I really want to know is what is the first USABLE sample at my requested
freq. If I still have to carry around a usrp_source pointer so that I
can check the LO state, then the tags output by the usrp_source lose a
lot of appeal.

Any chance of making rx_freq tag “the first usable sample”, or is there
a good reason for the way it works that I haven’t considered?

-Doug

AndersonS_Douglas_J · March 31, 2015, 11:33pm

I must admit I don’t know the exact reason, but the thing about the
remaining DC offset is generally that it depends on many factors,
including temperature, so it’s very hard to calibrate once forever,
whereas things like IQ imbalance tend to behave alike on both I and Q,
so that temperature dependency is not as bad.

AndersonS_Douglas_J · March 31, 2015, 11:51pm

Hmm, okay. Even the spectrum analyzers we use in the field currently
need to run cal scripts periodically to account for temp changes and
drift, so not being able to calibrate “once forever” isn’t a big deal at
all.

I’ll have to do a more thorough reading of the tx cal script and then
I’ll bring further questions about this over to the Ettus list.

Thanks, Marcus.

-Doug

From: discuss-gnuradio-bounces+danderson=removed_email_address@domain.invalid
[discuss-gnuradio-bounces+danderson=removed_email_address@domain.invalid] on behalf
of Marcus M. [[email protected]]
Sent: Tuesday, March 31, 2015 3:31 PM
To: [email protected]
Subject: Re: [Discuss-gnuradio] gr-uhd: rx_freq tag and lo_locked

I must admit I don’t know the exact reason, but the thing about the
remaining DC offset is generally that it depends on many factors,
including temperature, so it’s very hard to calibrate once forever,
whereas things like IQ imbalance tend to behave alike on both I and Q,
so that temperature dependency is not as bad.

On 03/31/2015 11:25 PM, Anderson, Douglas J. wrote:
Marcus,

That makes sense, I hadn’t thought of the DSP tuning issue, though I
think it would be infinitely more useful to make the stream tagging
logic aware of LO/DSP tuning and tag the first usable block in either
case. Slightly more involved than I assumed though.

I was actually going to ask this on the Ettus list later but since you
brought up DC offset: is there a technical reason that there is no
uhd_rx_dc_offset cal script? Is is because the LO can be offset so it’s
considered unnecessary or would a cal script not work as well for the RX
side as it does the TX side for some reason? I read through the
tx_dc_offset cal script last week and was curious…

-Doug

From:
discuss-gnuradio-bounces+danderson=removed_email_address@domain.invalidmailto:discuss-gnuradio-bounces+danderson=removed_email_address@domain.invalid
[discuss-gnuradio-bounces+danderson=removed_email_address@domain.invalidmailto:discuss-gnuradio-bounces+danderson=removed_email_address@domain.invalid]
on behalf of Marcus M.
[[email protected]mailto:[email protected]]
Sent: Tuesday, March 31, 2015 2:15 PM
To: [email protected]mailto:[email protected]
Subject: Re: [Discuss-gnuradio] gr-uhd: rx_freq tag and lo_locked

Hi Doug,

the rationale behind that is that these tags correspond to the stream
metadata coming from the USRP, which tell the host when the tuning
operation has taken place. Now, you’re right, it’s a problem to think
you’re tuned although your LO still hasn’t settled, but since tunes
could also be digital-path only, using the “earliest” time seems
correct.

By the way, you might also want to try a different approach, based on
timed commands: you can set a time for things like tune requests, thus
making sure that the tuning happens at the exact point in time you want
it to (and not influenced by the latency and load of your general
purpose PC). You can then simply “take” the right samples without caring
about tags at all, because you know when these should occur (i.e. which
numbers these should have).

Greetings,
Marcus

PS: try turning off the DC offset correction, if you’re on the N210, for
fast-tuning applications. You’ll have a bigger DC offset, but less
“swinging” after each tune.
PS2: I don’t know whether your overall frequency range allows this, but
as long as you tune within your USRP/daughterboards physical bandwidth,
you might just tune digitally and avoid LO retuning:
http://files.ettus.com/manual/page_general.html#general_tuning_process
On 03/31/2015 09:54 PM, Anderson, Douglas J. wrote:
Hi all,

I’ve been working on a flowgraph that controls sweeping a USRP by
retuning and then dumping samples until catching the sample tagged with
rx_freq of the correct value.

I was confused as to why I was still getting mountains of garbage
samples (several hundred thousand at 10MS/s) after catching the rx_freq
tag, until today I put “assert(usrp->get_sensor(“lo_locked”).to_bool())”
after the block that identifies the correct rx_freq tag, and it popped
immediately.

I’m wondering about the prudence of saying a sample is “at a certain
frequency” before the LO has had a chance to settle.

I also realize that gr-uhd folks are trying to make the message
interface more robust, and the rx_freq tag is an awesome idea, but what
I really want to know is what is the first USABLE sample at my requested
freq. If I still have to carry around a usrp_source pointer so that I
can check the LO state, then the tags output by the usrp_source lose a
lot of appeal.

Any chance of making rx_freq tag “the first usable sample”, or is there
a good reason for the way it works that I haven’t considered?

-Doug

Discuss-gnuradio mailing list
[email protected]mailto:[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

AndersonS_Douglas_J · April 1, 2015, 7:51pm

Martin,

I think we could have the same effect with a much simpler solution:

What about adding an lo_locked metadata tag to the stream of samples?

You could send lo_locked value=False on the last sample before LO
unlocks, and lo_locked value=True for first sample after LO locks. That
should be (?) simple to implement and would be equally as useful.

Otherwise, determining the first usable sample, as you said, “depends on
pretty much everything”, and that’s a lot to push down on the end user.

-Doug

From: discuss-gnuradio-bounces+danderson=removed_email_address@domain.invalid
[discuss-gnuradio-bounces+danderson=removed_email_address@domain.invalid] on behalf
of Martin B. [[email protected]]
Sent: Wednesday, April 01, 2015 11:30 AM
To: [email protected]
Subject: Re: [Discuss-gnuradio] gr-uhd: rx_freq tag and lo_locked

On 31.03.2015 14:25, Anderson, Douglas J. wrote:

Marcus,

That makes sense, I hadn’t thought of the DSP tuning issue, though I
think it would be infinitely more useful to make the stream tagging
logic aware of LO/DSP tuning and tag the first usable block in either
case. Slightly more involved than I assumed though.

That is correct. It depends on pretty much everything, at the very least
which exact device + d’board combo you’re using.

Cheers,
M

Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

AndersonS_Douglas_J · April 1, 2015, 7:32pm

On 31.03.2015 14:25, Anderson, Douglas J. wrote:

Marcus,

That makes sense, I hadn’t thought of the DSP tuning issue, though I
think it would be infinitely more useful to make the stream tagging
logic aware of LO/DSP tuning and tag the first usable block in either
case. Slightly more involved than I assumed though.

That is correct. It depends on pretty much everything, at the very least
which exact device + d’board combo you’re using.

Cheers,
M

AndersonS_Douglas_J · April 1, 2015, 8:37pm

Hi Doug,

What about adding an lo_locked metadata tag to the stream of samples?

You could send lo_locked value=False on the last sample before LO unlocks, and
lo_locked value=True for first sample after LO locks. That should be (?) simple to
implement and would be equally as useful.
The problem is that the architecture doesn’t really allow this. You have
to imagine it like this:
There’s two (ok, more than that, but basically) two things going through
the RX-side Motherboard/daughterboard connector:

Analog complex baseband, which gets converted to digital samples at
the physical sampling rate by the motherboard’s ADC (typically 100+
MS/s), and
serial control lines.

Both the sample bit lines from the ADC as well as the serial control
lines end up in the FPGA. Now, UHD has a fast track on which it pushes
all the samples around, through the various DSP stages, and through your
Gigabit interface (on N2x0, for example). That’s possible because
samples are just that - samples. No back and forth communication, just
FIFOs in one direction and an on-FPGA bus that configures the whole
thing and makes sure things such as timed commands are executed on time.

The daughterboards do all the analog magic – using programmable gain
amplifiers, programmable LO synthesizers, attenuators etc.
To control these, the control lines are there. These basically are just
“extended” serial ports of your PC. UHD knows how, for example, to
configure a specific LO synthesizer to give you the desired frequency,
and it just instructs the USRP to do so (“Write this over your serial
control port #0”, “Read the thing you get when asking for register 0x0F
on port #1”, these kind of things). These transfers are a lot slower,
though they can be initiated at a given time (thanks to timed commands,
again), than the sample clock.

Now, when you ask UHD “what is the lo_locked sensor value?”, UHD
translates that to an read instruction to the LO synthesizer, and
translates the answer it gets from the USRP back to something like
true/false. Typically, these requests take quite some time. Also, your
chip has no way of guessing early whether the LO is locked or not – it
observes stability, and the speed it can detect whether the LO is locked
must be inverse to the quality of that observation.

Thus, getting the answer from the synthesizer chip would typically
longer than justifiable here – you’d end up throwing away less samples
if you did not poll the chip for that info and just threw away a fixed
amount of samples after every rx_freq tag. Also, polling the sensor
might get in the way of “normal” operation, because it’d occupy the
serial line.

Greetings,
Marcus

AndersonS_Douglas_J · April 1, 2015, 8:51pm

Excellent information, I will stick to dumping n samples after receiving
rx_freq.

Thank you!
-Doug

From: discuss-gnuradio-bounces+danderson=removed_email_address@domain.invalid
[discuss-gnuradio-bounces+danderson=removed_email_address@domain.invalid] on behalf
of Marcus M. [[email protected]]
Sent: Wednesday, April 01, 2015 12:34 PM
To: [email protected]
Subject: Re: [Discuss-gnuradio] gr-uhd: rx_freq tag and lo_locked

Hi Doug,

What about adding an lo_locked metadata tag to the stream of samples?

You could send lo_locked value=False on the last sample before LO unlocks, and
lo_locked value=True for first sample after LO locks. That should be (?) simple to
implement and would be equally as useful.
The problem is that the architecture doesn’t really allow this. You have
to imagine it like this:
There’s two (ok, more than that, but basically) two things going through
the RX-side Motherboard/daughterboard connector:

Analog complex baseband, which gets converted to digital samples at
the physical sampling rate by the motherboard’s ADC (typically 100+
MS/s), and
serial control lines.

Both the sample bit lines from the ADC as well as the serial control
lines end up in the FPGA. Now, UHD has a fast track on which it pushes
all the samples around, through the various DSP stages, and through your
Gigabit interface (on N2x0, for example). That’s possible because
samples are just that - samples. No back and forth communication, just
FIFOs in one direction and an on-FPGA bus that configures the whole
thing and makes sure things such as timed commands are executed on time.

The daughterboards do all the analog magic – using programmable gain
amplifiers, programmable LO synthesizers, attenuators etc.
To control these, the control lines are there. These basically are just
“extended” serial ports of your PC. UHD knows how, for example, to
configure a specific LO synthesizer to give you the desired frequency,
and it just instructs the USRP to do so (“Write this over your serial
control port #0”, “Read the thing you get when asking for register 0x0F
on port #1”, these kind of things). These transfers are a lot slower,
though they can be initiated at a given time (thanks to timed commands,
again), than the sample clock.

Now, when you ask UHD “what is the lo_locked sensor value?”, UHD
translates that to an read instruction to the LO synthesizer, and
translates the answer it gets from the USRP back to something like
true/false. Typically, these requests take quite some time. Also, your
chip has no way of guessing early whether the LO is locked or not – it
observes stability, and the speed it can detect whether the LO is locked
must be inverse to the quality of that observation.

Thus, getting the answer from the synthesizer chip would typically
longer than justifiable here – you’d end up throwing away less samples
if you did not poll the chip for that info and just threw away a fixed
amount of samples after every rx_freq tag. Also, polling the sensor
might get in the way of “normal” operation, because it’d occupy the
serial line.

Greetings,
Marcus

On 04/01/2015 07:49 PM, Anderson, Douglas J. wrote:

-Doug

That makes sense, I hadn’t thought of the DSP tuning issue, though I

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

AndersonS_Douglas_J · April 1, 2015, 11:32pm

On 01.04.2015 10:49, Anderson, Douglas J. wrote:

Martin,

I think we could have the same effect with a much simpler solution:

What about adding an lo_locked metadata tag to the stream of
samples?

This would require the FPGA to automatically send some kind of
notification that the LO has locked (our packet format doesn’t have such
a field), and the USRP sink to parse async messages or something like
that for every sample (at least, every sample after an rx_freq tag).
This would mean both architectural changes and added processing load.

My assertion ‘depends on everything’ also was a bit pessimistic. Tune
time depends on certain parameters, such as devices used (mboard/dboard)
and some DSP settings; possibly even temperature and other analogs. For
a given setup, it won’t change massively during operation.

So you’re right that we’re pushing this to the user, but without a
really tight coupling between the app and the analog front-end (and I
consider USB or Ethernet not fall into this category), there’s not a
simple solution – unless you count measuring the delay between the
first sample with the rx_freq tag and the end of the transition, and
then statically adding another tag after X many samples, which I don’t
think you were asking for.

Cheers,
M