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
