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

[Collins, Richard]

Hey Sean,

Thanks for the heads up. I was just looking through the pdu_to_tagged_stream block for debugging. I noticed the comment about blocking, and wondered if a dedicated message handler would be a better option than overloading "calculate_output_stream_length".

Thanks for the info about the tsb_tag_name... I was wondering if I should use the PDU to Tagged Stream block before going into the USRP, and it seems a common option to take.  Using the Tag Debug block after the PDU to Tagged Stream block, I see that tx_sob, tx_time, and tx_eob pass through. I'll test ASAP to see if the USRP Sink listens to these tags (now that it should see them). If not, I'll try setting the tsb_tag_name to packet_len (which I guess causes the usrp sink to ignore tx_sob, tx_eob, etc.).

Thanks again,

  - Rich

On Wed, Nov 16, 2016 at 11:23 AM, Sean Nowlan <address@hidden> wrote:

I think you will have to write a custom block that is similar to the pdu_to_tagged_stream block, but doesn't inherit from tagged_stream_block to avoid the limitation on the number of samples that can be handled. Here's how I'd do it, but keep in mind I haven't tried this and you may get into trouble doing blocking waits within the work method.

* Copy pdu_to_tagged_stream in an OOT project.

* Inherit from source_block instead of tagged_stream_block.

* Move the stuff that's in "calculate_output_stream_length" into the top of the work method body. It looks like this will do a blocking wait with a timeout to see if there is a PDU available on the queue. If not, it should return 0 items. Once a PDU is found, it stashes the PDU's metadata, data vector, and length.

* At the seciton of the work method that copies tags, I suggest keeping that code since it will copy your PDU length. The downstream USRP sink should be configured with a tsb_tag_name argument matching the 'packet_len' field in your PDU's metadata.

* At the bottom of the work method, write as many items of the data vector to the output as noutput_items allows, and then decrement the number of remaining items to write. Keep an index or pointer into your current buffer and increment that too. After one or more work calls you should have written the entire buffer to the output and you can go back to looking for PDU packets on the input port.

Hope this helps.

Sean

You'd have to add a message handler that stashes 

work 

On Thu, Nov 10, 2016 at 9:07 PM, Collins, Richard <address@hiddencom> wrote:

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

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio