# GR-UHD features incoming **URL:** \ **Category:** GNU Radio\ **Created:** [May 6, 2015, 7:36pm UTC](https://www.ruby-forum.com/t/gr-uhd-features-incoming/241862 "2015-05-06T19:36:07Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![Detlef\_R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/58f4c7/32.png) [@Detlef\_R](https://www.ruby-forum.com/u/Detlef_R)\ **Post date:** [May 6, 2015, 7:36pm UTC](https://www.ruby-forum.com/t/gr-uhd-features-incoming/241862/1 "2015-05-06T19:36:07Z")
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](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 ---
**Author:** ![pytlik](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/779978/32.png) [@pytlik](https://www.ruby-forum.com/u/pytlik)\ **Post date:** [May 6, 2015, 11:06pm UTC](https://www.ruby-forum.com/t/gr-uhd-features-incoming/241862/2 "2015-05-06T23:06:26Z")
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? > **[USRP Hardware Driver and Device Manual: uhd::usrp::multi\_usrp Class Reference](https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a7beb49c1a04a81b3e7569db482453746)** > > \#include \ 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](http://gnuradio.4.n7.nabble.com/GR-UHD-features-incoming-tp53611p53616.html) Sent from the GnuRadio mailing list archive at [Nabble.com](http://Nabble.com). ---
**Author:** ![pytlik](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/779978/32.png) [@pytlik](https://www.ruby-forum.com/u/pytlik)\ **Post date:** [June 24, 2015, 12:03pm UTC](https://www.ruby-forum.com/t/gr-uhd-features-incoming/241862/3 "2015-06-24T12:03:36Z")
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: ---
**Author:** ![pytlik](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/779978/32.png) [@pytlik](https://www.ruby-forum.com/u/pytlik)\ **Post date:** [June 24, 2015, 6:15pm UTC](https://www.ruby-forum.com/t/gr-uhd-features-incoming/241862/4 "2015-06-24T18:15:11Z")
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 ---
**Author:** ![pytlik](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/779978/32.png) [@pytlik](https://www.ruby-forum.com/u/pytlik)\ **Post date:** [June 24, 2015, 1:34pm UTC](https://www.ruby-forum.com/t/gr-uhd-features-incoming/241862/5 "2015-06-24T13:34:09Z")
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: ---
**Author:** ![pytlik](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/779978/32.png) [@pytlik](https://www.ruby-forum.com/u/pytlik)\ **Post date:** [June 24, 2015, 8:57pm UTC](https://www.ruby-forum.com/t/gr-uhd-features-incoming/241862/6 "2015-06-24T20:57:02Z")
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: ---
**Author:** ![pytlik](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/779978/32.png) [@pytlik](https://www.ruby-forum.com/u/pytlik)\ **Post date:** [June 24, 2015, 9:43pm UTC](https://www.ruby-forum.com/t/gr-uhd-features-incoming/241862/7 "2015-06-24T21:43:13Z")
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 🙂 M ---
**Author:** ![pytlik](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/779978/32.png) [@pytlik](https://www.ruby-forum.com/u/pytlik)\ **Post date:** [June 24, 2015, 7:51pm UTC](https://www.ruby-forum.com/t/gr-uhd-features-incoming/241862/8 "2015-06-24T19:51:00Z")
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: ---
**Author:** ![pytlik](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/779978/32.png) [@pytlik](https://www.ruby-forum.com/u/pytlik)\ **Post date:** [June 24, 2015, 10:22pm UTC](https://www.ruby-forum.com/t/gr-uhd-features-incoming/241862/9 "2015-06-24T22:22:56Z")
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: