Hello again, Wanted to send some more results in case anyone is following...
I narrowed the problem down to a few lines in gr-ettus's rfnoc_block_impl that specifically overrides the block_port for each channel; the "block_port" stream_args in device->get_rx_stream(stream_args) function was coerced to equal the port of the gnuradio flowgraph. (See code here: https://github.com/EttusResearch/gr-ettus/blob/814a7de651cd4c5595ff66a0326e0f2927d2baef/lib/rfnoc_block_impl.cc#L334 ) I have a suggested change on on a PR that's available on my fork of gr-ettus: https://github.com/ejk43/gr-ettus/tree/ejk/rfnoc-port-edit Essentially this fix will NOT override any block_portX stream args you specify in the stream args. So we should be able to do this to target channel 1 of the E300: (note the Stream args where block_port0=1) [image: Inline image 1] That does the trick for me. Hope this helps! EJ On Mon, Sep 25, 2017 at 9:38 AM, EJ Kreinar <ejkrei...@gmail.com> wrote: > Hi all, > > On further inspection, I've had no more luck using python RFNoC to record > on channel 1 (channel B)... > > Sadly, manually editing the stream args in the rfnoc radio did not appear > to have any effect (see below). And, editing the "connect" in python > command still errors out as per Test 3 of my original email. > > self.uhd_rfnoc_streamer_radio_0 = ettus.rfnoc_radio( > self.device3, > uhd.stream_args( # Tx Stream Args > cpu_format="fc32", > otw_format="sc16", > args="block_port=1", > ), > uhd.stream_args( # Rx Stream Args > cpu_format="fc32", > otw_format="sc16", > args="block_port=1", > ), > 0, -1 > ) > > It appears that the rfnoc_rx_to_file takes a far more manual approach to > running the application, rather than using gnuradio-- the rfnoc_rx_to_file > creates the rfnoc graph and then calls the recv function in a loop, and > does not use GR to link up to a file sink, as in the python flowgraph. > > Any other ideas? I'm currently leaning towards the conclusion that > switching the receive channel is simply not currently supported with Rfnoc > + Gnuradio. Agreed?? > > EJ > > On Mon, Sep 25, 2017 at 9:11 AM, EJ Kreinar <ejkrei...@gmail.com> wrote: > >> Thanks Tom, Quick update here... >> >> I've found a set of options that will control the E300 receive channel >> using rfnoc software: >> >> rfnoc_rx_to_file --freq <frequency> --rate <sample rate> --ant TX/RX >> --radio-chan 0 >> rfnoc_rx_to_file --freq <frequency> --rate <sample rate> --ant RX2 >> --radio-chan 0 >> rfnoc_rx_to_file --freq <frequency> --rate <sample rate> --ant TX/RX >> --radio-chan 1 >> rfnoc_rx_to_file --freq <frequency> --rate <sample rate> --ant RX2 >> --radio-chan 1 >> >> >> Tracking where/how rfnoc_rx_to_file sets the appropriate channel, it >> appears that it simply sets the "block_port" streamer args: >> >> streamer_args["block_port"] = str(boost::format("%d") % >> radio_chan); >> >> >> Or, alternatively, if there's a block inserted via the command line, then >> the correct port is connected in the rx_graph: >> >> rx_graph->connect(radio_ctrl_id, radio_chan, >> blk_ctrl->get_block_id(), uhd::rfnoc::ANY_PORT); >> >> Interestingly, this seems to suggest an approach closest to my "test 3" >> earlier. I'll look for how this can tie into python rfnoc software now... >> >> >> EJ >> >> >> On Thu, Sep 21, 2017 at 4:24 PM, Tom Bereknyei <t...@dds.mil> wrote: >> >>> EJ, >>> >>> I went through that same sequence of attempts and never got a solution >>> other than using TX/RX and RX2 on the same A channel. >>> >>> On Thu, Sep 21, 2017 at 14:05 EJ Kreinar via USRP-users < >>> usrp-users@lists.ettus.com> wrote: >>> >>>> Hi all, >>>> >>>> I'm trying to specify exactly which channel to record from an RFNoC >>>> flowgraph on the E310, but I cant seem to get this to work.... >>>> >>>> Typically, in non-RFNoC applications, or in the "legacy_compat" mode, >>>> you can use the following options: >>>> >>>> uhd_rx_cfile -r <sample rate> -f <frequency> -A TX/RX --spec=A:A >>>> recording.c32 >>>> uhd_rx_cfile -r <sample rate> -f <frequency> -A RX2 --spec=A:A >>>> recording.c32 >>>> uhd_rx_cfile -r <sample rate> -f <frequency> -A TX/RX --spec=A:B >>>> recording.c32 >>>> uhd_rx_cfile -r <sample rate> -f <frequency> -A RX2 --spec=A:B >>>> recording.c32 >>>> >>>> And each option, in turn, records data from a different receive port on >>>> the E310. >>>> >>>> >>>> But, I cant figure out the correct combination to get the rfnoc_radio >>>> software to support recording on channel B. A few things I've tried: >>>> >>>> 1. Changing the rfnoc_radio dropdown to "Radio Select = B". This errors >>>> like this: >>>> >>>> Traceback (most recent call last): >>>> File "/home/root/test_rx.py", line 138, in <module> >>>> main() >>>> File "/home/root/test_rx.py", line 127, in main >>>> tb = top_block_cls(args=options.args, freq=options.freq, >>>> gain=options.gain, rate=options.rate) >>>> File "/home/root/test_rx.py", line 52, in __init__ >>>> 1, -1 >>>> File "/usr/lib/python2.7/site-packages/ettus/ettus_swig.py", line >>>> 1980, in make >>>> return _ettus_swig.rfnoc_radio_make(*args, **kwargs) >>>> RuntimeError: Cannot find a block for ID: Radio_1 >>>> -- Loading FPGA image: /boot/system_top.bit... done >>>> >>>> >>>> 2. Adding a FIFO to the FPGA on the second channel, and "dropping" the >>>> samples from the first channel. >>>> [image: Inline image 1] >>>> >>>> But this fails like so: >>>> >>>> -- [0/FIFO_0] source_node_ctrl::set_rx_streamer() 0 -> 1 >>>> -- [0/Radio_0] radio_ctrl_impl::set_rx_streamer() 1 -> 1 >>>> -- [0/Radio_0] e3xx_radio_ctrl_impl::_update_enables() >>>> -- [0/Radio_0] e3xx_radio_ctrl_impl::_update_gpio_state() >>>> -- [Device3] updating RX streamer to RX Terminator 0 >>>> -- New tick_rate == 250000 New samp_rate == 250000 New scaling == >>>> 3.05185e-05 >>>> -- [0/FIFO_0] source_block_ctrl_base::issue_stream_cmd() >>>> -- [0/Radio_0] radio_ctrl_impl::issue_stream_cmd() 0 a >>>> -- [0/Radio_0] radio_ctrl_impl::issue_stream_cmd() called on inactive >>>> channel. Skipping. >>>> timeout on chan 0 >>>> timeout on chan 0 >>>> >>>> And no data is recorded. >>>> >>>> 3. I also tried (foolishly) manually editing the generated python to >>>> connect the File Sink to port 1 of the rfnoc_radio, rather than port 0. >>>> >>>> I used this flowgraph: >>>> [image: Inline image 3] >>>> And then I manually changed the following lines: >>>> >>>> self.connect((self.uhd_rfnoc_streamer_radio_0, 0), >>>> (self.blocks_file_sink_0_0, 0)) >>>> =becomes==> >>>> self.connect((self.uhd_rfnoc_streamer_radio_0, 1), >>>> (self.blocks_file_sink_0_0, 0)) >>>> >>>> I was hopeful that port 1 actually existed and was initialized >>>> correctly in UHD, but alas, port 1 clearly does not exist for me to attach >>>> the file sink to: >>>> >>>> Traceback (most recent call last): >>>> File "/home/root/test_rx.py", line 138, in <module> >>>> main() >>>> File "/home/root/test_rx.py", line 128, in main >>>> tb.start() >>>> File "/usr/lib/python2.7/site-packages/gnuradio/gr/top_block.py", >>>> line 109, in start >>>> top_block_start_unlocked(self._impl, max_noutput_items) >>>> File "/usr/lib/python2.7/site-packages/gnuradio/gr/runtime_swig.py", >>>> line 3671, in top_block_start_unlocked >>>> return _runtime_swig.top_block_start_unlocked(*args, **kwargs) >>>> RuntimeError: rfnoc_radio(1): missing connection from output port 0 >>>> -- Loading FPGA image: /boot/system_top.bit... done >>>> >>>> >>>> I cant seem to figure this out.. Any suggestions?? Am I missing >>>> something obvious, or is RFNoC missing this support? >>>> >>>> (by the way, I am admittedly still behind on my UHD version. So perhaps >>>> there's updates that resolve this issue recently?) >>>> >>>> Thanks! >>>> EJ >>>> _______________________________________________ >>>> USRP-users mailing list >>>> USRP-users@lists.ettus.com >>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>>> >>> -- >>> Maj Tom Bereknyei >>> Defense Digital Service >>> t...@dds.mil >>> (571) 225-1630 >>> >> >> >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
