GR-UHD features incoming

Hi,

you might have noticed some movement on the gr-uhd component recently.
Here’s a quick update what’s happening:

Least importantly, there was some refactoring to reduce the amount of
duplicated code between usrp_sink and usrp_source. It’s very unlikely
this will affect anyone, unless you have custom patches to these blocks.
This was merely a requisite for being able to do further changes.

The big change for the moment is the enhanced message interface. With
more blocks using messages for commands (not just data), we’re trying to
standardize how blocks receive messages. If you build the manual
yourself, you’ll see the changes added in
https://github.com/mbr0wn/gnuradio/commit/72e0c237e06e5214eb2706bd4ac732cef068161c
to document how we’d like these command interfaces to look like.

UHD already had it’s own, home-grown message command interface. With
this change, it has been adapted to comply with how command messages
should look like.
At the same time, a lot of new commands were added. You can now change
gain, antenna, DSP frequency, LO offset, command times, analog bandwidth
(where applicable) and sampling rate through messages.

This offers tons of cool new options. Imagine you have a blind OFDM
receiver, which first estimates the OFDM parameters (center frequency,
bandwidth, sampling rate) before attempting to blind-demodulate. You can
have a downstream block change all of these parameters[1] in a kind of
control loop[2] until they match, then demodulate – all from the same
flow graph, just using GNU Radio blocks.

The flipside of this new swath of options is that I haven’t tested it
very thoroughly. There’s just way too much to test, and I’d rather have
it out there sooner than later. Of course, all the new commands are
understood and acted upon, and most importantly, nothing that
previously worked was changed in functionality and/or API
. So, all
these changes are backward-compatible.

These changes have just entered our ever-full PR FIFO, so it’s not yet
in master. If you’re interested in checking it out before that, see
here:

https://github.com/mbr0wn/gnuradio/tree/uhd/message_updates

There’s some more changes in the pipeline, but I’m happy to get feedback
on this stage.

Have fun,
Martin

[1] To change the sampling rate arbitrarily, you’ll need an AD9361-based
device, e.g. the B210
[2] In a true control loop, you have precise control over the feedback
delay, which you don’t have with async messages. However, some of these
values create tags when changed, so at least you get precise timing
information feedback

Martin,

Thanks for this. While your at it…could you add a field in GRC UHD
source block to enable/disable the DC RX offset correction, as well as a
message to control it?

http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a7beb49c1a04a81b3e7569db482453746

It actually works in the GRC Osmocom source block, but I’d rather stick
with
UHD source block. With the messaging, it could be dynamically turned
off.

Thanks,
Lou

Martin B.-2 wrote

Hi,

you might have noticed some movement on the gr-uhd component recently.
Here’s a quick update what’s happening:


View this message in context:
http://gnuradio.4.n7.nabble.com/GR-UHD-features-incoming-tp53611p53616.html
Sent from the GnuRadio mailing list archive at Nabble.com.

Hi Martin,

I’m trying to make use of the new message interface. I’m able to set
center frequency and other parameters with use of it which is great as
now I’m able to make for example a application that scans spectrum
without stopping the flowgraph.

However I expected that after USRP switch frequency because it received
a command a new stream tag would be added to the signal at the moment of
switching (like it happens when for example central frequency is
switched with use of gui widgets). No tag is added though. Is this
intended behaviour?

Best Regards,
Piotr K.

W dniu 06.05.2015 o 19:35, Martin B. pisze:

Piotr,

not intentional – this was indeed an oversight. I’ll add an issue.
However, it’s not trivial to change; when doing message-based retuning,
there’s no clear way of knowing which sample to tag.

M

Hi all,

After reading the code of usrp_source_impl I’ve found out that there are
separate methods for tune requests invoked from gui and by message
interface.

For gui:
::uhd::tune_result_t
usrp_source_impl::set_center_freq(const ::uhd::tune_request_t
tune_request,
size_t chan)
{

_tag_now = true;

}

For messages:
SET_CENTER_FREQ_FROM_INTERNALS(usrp_source_impl, set_rx_freq);

The second one doesn’t set _tag_now - therefore no tags are added.
Everything suggests that this behaviour is intentional.
But what is the rationale? Without this tag I’ll have to keep track of
frequency changes that are made and add tags myself as they are needed
to trigger events downstream.

Would it be possible to leave for the user to decide if he wants to
receive tags or not?

Best Regards,
Piotr K.

W dniu 24.06.2015 o 12:01, Piotr K. pisze:

Hi Martin,

I’m thinking of some solution to make stream tags more usable in
combination with message interface. My first thought is that maybe
stream tag should be added to the stream whenever something (other than
timestamp) changes in _metadata received from uhd device?


Piotr

W dniu 24.06.2015 o 19:50, Piotr K. pisze:

On 24.06.2015 11:55, Piotr K. wrote:

Hi Martin,

I’m thinking of some solution to make stream tags more usable in
combination with message interface. My first thought is that maybe
stream tag should be added to the stream whenever something (other than
timestamp) changes in _metadata received from uhd device?

The RX metadata only includes timestamp and EOB (apart from error
codes), so I’m not sure what exactly you would want to make a tag.

That said, I’m all for making tags more useful and adding more
information. And I’m even more happy about code contributions than I am
about suggestions :slight_smile:

M

Hi Martin,

When the command carried by message is executed immediately after
reception by USRP the situation seems to be similar to tune request
invoked by the user through gui. Or is there something that I
overlooked?

Things get more complicated when command has “time” in the future at
which it should be executed. I don’t see easy way to identify uhd
metadata that is result of execution of given command so it could be
turned into a stream tag.

Best Regards,
Piotr

W dniu 24.06.2015 o 18:14, Martin B. pisze:

Haha,

Another genius plan ruined by hard reality. I forgot what is inside uhd
metadata and assumed that current frequency is taken from there. The
good thing is that learned that it will be easier to generate the tags
myself in some block than to require from usrp source to do the magic.

Regarding the code contribution - if I figure out how to do generate
tags resulting from execution of a command I will send the code for
review.

Best Regards,
Piotr K.

W dniu 24.06.2015 o 21:41, Martin B. pisze:

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs