On 03/08/2021 01:22 PM, Xiang Ma wrote:
I have tried to first use GNURadio to write a program in GRC. And
implement my code referring to the generated top_block.py
The following code works
```
from gnuradio import uhd
def u_source(self):
self.source = uhd.usrp_source(
device_addr=self.usrp_address_source,
stream_args=uhd.stream_args(
cpu_format="fc32",
channels=range(1),
),
)
self.source.set_samp_rate(self.adc_rate)
self.source.set_center_freq(self.freq, 0)
self.source.set_gain(self.rx_gain, 0)
self.source.set_antenna("RX2", 0)
self.source.set_auto_dc_offset(False, 0) # Uncomment this line for
SBX daughterboard
self.source.set_center_freq(self.freq, 1)
self.source.set_gain(self.rx_gain, 1)
self.source.set_antenna("RX2", 1)
self.source.set_auto_dc_offset(False, 1)
```
And when I change the channels=range(2),
Add a new line as the file sink of channel 2, it doesn't work. It
doesn't crash, just stuck.
self.connect((self.source, 1), self.file_sink_source)
I don't understand. I thought the two channels might be independent
since they work on two daughterboards.
I try to use gdb to debug the code. But the information is hard to
understand. It shows multiple threads.
The fact that you feel the need to *edit* the *generated* code from GRC
means that you have an insufficient understanding of
GRC, and making random, unguided-by-deep-knowledge changes to the
*generated* code is almost never called for unless you're
doing something "special" and you have the expertise to make those
changes.
Go back to GRC, simply create a usrp_source object with two channels, a
single motherboard, and a subdev spec of "A:0 B:0", with
RX2 for the antenna selector, and you'll have two streams that you
can deal with independently. One can go to a file sink, the
other can go to a different file sink, or other bits of DSP chain.
I'll note that on balance, this is more of a discuss-gnuradio question
than a usrp-users question, I'd recommend cross-posting any
further missives in this thread.
Doing this "two channels from the same device" thing is not that exotic
or unusual, so I suspect that your approach of post-editing
the generated code from GRC is where your problems are, and I'd avoid
it. The GRC file should be considered the "source code", and
you make all your edits to that, using the GRC tooling. Just as in
compiled languages, there's very few legitimate reasons for
"editing the object code".
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
