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
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
