[Discuss-gnuradio] PDUs in GNU Radio for UHD USRP Sink

[Collins, Richard]

Hello,

I'm having trouble figuring out how to correctly send PDUs to the UHD USRP Sink. It's my understanding (mostly from [1] and [2]) that you can send a PDU with

• a dictionary car containing "tx_sob" set to PMT_T, (and maybe "tx_time" formatted according to notes in [2] or in the source code), and
  
• a uniform vector cdr containing complex32 samples to send.

What I've done is make a block that accepts a stream of samples tagged by a previous block (using stream tags), and saves them off to a std::vector between the start and end tags. This part works as expected. Once this vector (or "pkt_buffer") is full, other samples are ignored and the transmission half of the code in this custom block is able to run. It uses usrp->get_time_now() to check to see if some time has elapsed, and if so, carves up the internal "pkt_buffer" vector into PDUs of the desired size (e.g. a max of 512 samples long), and sends them out of the registered message port. Externally, this port is connected to the "command" port of the UHD USRP Sink block.

I know these messages have a max size (I think of 4k samples), and it seems to work best (e.g. without the flowgraph freezing freezing, or uhd_usrp_source block taking up too much CPU of one core) when the size is smaller (e.g. 512 samples).

What happens though, as seen through captured samples from another SDR, is the USRP will output nothing for a while (a little longer than the expected length in time of my whole "packet" or set of PDUs). Then the USRP will output what looks just like a carrier signal for the rest of the time before the next burst of PDUs (I'm assuming from the Null Source feeding into the UHD USRP Sink block's streaming "in" port, which must be connected to something in GNU Radio).

As a small side note, I don't get an error output except for a single U per packet... it seems if I send too many PDUs (i.e. more than the first, second to last, and the last), I'll get a "U" after a whole set of PDUs is sent. I don't think that's a problem though.

I've checked the output of this block with the message debug block, and it seems that the correct samples are sent in the expected order.

An example of what I'm trying to do (in C++) can be found here: http://pastebin.com/uyNTkFmU

Documentation Used:
  [1] - http://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__sink.html

  [2] - http://gnuradio.org/doc/doxygen/page_uhd.html#uhd_command_syntax_cmds
  [3] - http://gnuradio.org/doc/doxygen/page_pmt.html
  [4] - http://gnuradio.org/doc/doxygen/page_msg_passing.html

Examples found:

  [5] - https://github.com/bastibl/gr-foo/blob/master/lib/packet_pad_impl.cc helped, but he's using stream tags, not Asynchronous Message passing

  [6] - some examples in uhd/host/examples/ and gnuradio/gr-uhd/examples/c++/ but mostly for testing uhd function calls to get/set gps time.

It's been suggested a couple times to use asynchronous message passing instead of tagged streams when I've asked over the past year or so, and I see why from an old post from Tim O'Shea's blog that shows the differences in performance. I just don't know how to use his eventstream or other underlying gr-vt blocks, and would like to rely on as few OOT modules as possible. I've found a few examples where tagged streams are used, but not any with PDUs.

I've made a block almost a year ago (my first one, actually) which used PDUs in Python, but I found that I ended up using a PDU to Tagged Stream block before the UHD USRP Sink. That was ok for that instance; but now I've got to send a relatively large set (>4k) of samples at a specific time.

Any help or guidance is appreciated! Hopefully I'm just missing something small or obvious.

Thanks,

Richard Collins