rfnoc_block_impl: check for existing block_port stream_arg before overriding

[ejk43]

Current implementation of rfnoc_block_impl:start() will enforce the block_port stream_arg of unaligned streamers is always set to the channel of the gnuradio flowgraph; this approach prohibits use of channel 1 without also using channel 0.

I'm simply running a check now to see if a specialized block_port per channel is provided to the stream args. If so, do NOT override based on the flowgraph port.

[ejk43]

On further digging, I've found some troubling updates for this PR... First, note the channel selection DOES work if the only RFNoC block before the PS domain is the Radio block.

But, there's two problems/limitations:

1. The stream_args input to the rfnoc block constructor should not have any "channels" value, otherwise the block_port will get overwritten in the rfnoc_block_impl constructor here: https://github.com/EttusResearch/gr-ettus/blob/master/lib/rfnoc_block_impl.cc#L173

2. More troubling, it appears the issue_stream_cmd functionality in UHD propagates through source_block_ctrls by calling each MATCHING channel. So for example, if I want to use a DDC after the rfnoc_radio, I need to also specify "block_port0=1" in the DDC stream_arg. This is annoying, but OK, since DDCs often have two channels. But what if my RFNoC block only has one input/output port? I need to experiment here, but maybe it's now impossible to specify channel 1?

Thoughts/input? Any ideas to resolve? I'd love to get to a place where I can specify a specific channel on the RFNoC radio GRC block (similar to the multi-usrp device spec), and then I can use downstream RFNoC blocks as usual.

[ejk43]

Updated this PR by adding hooks to implement the port/channel mapping feature provided by the UHD PR here: EttusResearch/uhd#164

When tested on an E310, I was able to use a command-line parameter to specify which channel to use for receive and transmitting with a flowgraph like this:

One concern in particular: the gr-ettus I originally edited was a bit behind master, and it looks like there's now MANY places in the uhd_rfnoc_radio.xml GRC definition that conflate the number of channels with the actual channel index used. Many of these checks are applied during flowgraph generation rather than at run time, which would become a significant concern if we're trying to specify the channel programmatically. For example, antenna selection of the alternate channel would likely break since it only applies to channel 0 unless we have specified num_channels > 1. I have not attempted to iron out all the channel indexing issues in uhd_rfnoc_radio.xml, but thought I'd mention this as a concern for this PR and for the overall support of properly selecting which channel to use.

[mbr0wn]

We'll need a fresh approach to this, since we're not merging the port mapping in UHD, either.