Hello Mike,
2/
Maybe what Ron Economos suggested is the right way for you
('set_output_multiple'). I think you cannot change that on-the-fly (please
correct me if I am wrong), but maybe that still works for you.
3/
The latter thought ("because the UHD: USRP sink samp rate is set to a rate that
it can 'handle'") is probably correct.
In a hardware source/sink block (like the "UHD" blocks), sampling rate defines
the actual processing rate (sample acquisition / sample transmission) of the
block. The block will try its best to run at the defined rate.
All other blocks, except "Throttle" block, do not care about the configured
sampling rate and just compute the incoming/outgoing data as fast as they can.
They may still ask you to input the sampling rate, but that is just used for
computation purposes (usually to allow you to use Hertz on other arguments,
because you will have to deal with Radians or normalized frequencies otherwise).
"Throttle" block is an exceptional case, which is used to intentionally slow
down the execution speed for simulation purposes (and must not be used when
hardware blocks are present). It intentionally slows down the execution of the
slowgraph, to match the processing rate with the actual time.
So, rate_now and rate_ave will _not_ be consistent with your defined sampling
rate (..or maybe, by pure luck), when your blocks are not keeping up or when
hardware sources/sinks and Throttle blocks are not present in your flowgraph.
The rate that you should be seeing is the maximum rate that GNU Radio can
sustain (ignoring the overheads introduced by the UHD blocks), if you have
deleted the UHD blocks. If it still does, then maybe it is by pure luck, or
maybe some other blocks are throttling the speed of the flowgraph somehow
(which shouldn't really happen).
Regards,
Kyeong Su Shin
________________________________
보낸 사람: Michael Bassi <mba...@srcaus.com>
보낸 날짜: 2019년 11월 25일 월요일 오후 2:20
받는 사람: Kyeong Su Shin <kss...@postech.ac.kr>; Discuss Gnuradio
<discuss-gnuradio@gnu.org>
제목: Re: Custom OOT Block Running on USRP + General GNU Radio Questions.
Thank you, Kyeong
I really appreciate your reply.
1/
Does anyone have experience using these functions?
would any help with 2/?
2/
Thank you. It looks like the work function input array "output_items" is a
numpy array.
I was therefore able to eliminate the for loop.
I am also now return = 0 if the output buffer isn't long enough. My waveform
PRI now appears to be consistent upon visual inspection.
out = output_items[0]
if not len(out) < self.num_samples_pri:
out[:self.num_samples_pw] = 1.0
out[self.num_samples_pw:] = 0.0
num_out = self.num_samples_pri
else:
num_out = 0
return num_out
This may just be a quick fix though. My PRI may be longer than expected in some
cases, and I should be doing like you suggest by keeping some internal array.
Does anyone know how to implement this properly? Assuming it is necessary?
3/
With the python code improvements, I am still getting under-runs at the same
sample rate of 1e6.
However, after reducing the samp rate by a factor of 10 (to 1e5 samp/sec). I am
no longer getting under-run...
Would this be because my code is now working with smaller arrays and therefore
runs faster?
Or because the UHD: USRP sink samp rate is set to a rate that it can 'handle'?
I still have a shaky understanding of what sampling rate means here.
I have attached Probe Rate -> Message Debug blocks to the output of my custom
block, as you suggested. rate_now and rate_ave appear to be consistent with my
defined sampling rate. Is there a specific test you do with these blocks? what
do you look for?
I have the C++ implementation ready to go, though still having troubles running
my custom blocks from the USRP (see 5/)
RFNoC is just plain intimidating.
4/
Thanks I will check out other custom blocks.
5/
Yes, hopefully someone can help!
Thanks again,
Mike
________________________________
From: Kyeong Su Shin <kss...@postech.ac.kr>
Sent: 25 November 2019 13:44
To: Michael Bassi <mba...@srcaus.com>; Discuss Gnuradio
<discuss-gnuradio@gnu.org>
Subject: Re: Custom OOT Block Running on USRP + General GNU Radio Questions.
Hello Mike,
I never used USRP E3xx series boards, so I coud be off on some points, but:
1: Yes, you are correct. If I recall correctly, it uses a ring buffer-like
structure. Length of the output buffer is basically amount of data points that
you can safely write to the buffer at the moment, and therefore variable.
There are a few functions that can affect the buffer size. See:
https://www.gnuradio.org/doc/doxygen/classgr_1_1block.html (assumes C++,
though).
2:
If your output buffer is too small, just keep your unwritten data in a some
internal array (self.something) and write to the output buffer during the next
round or wait (and do not write to the buffer) until the buffer grows large
enough (maybe there are better ways to do this - can anyone help?).
By the way, I believe you are using Python to write OOT blocks. Python OOT
blocks can be extremely slow, especially if you are using for and if statements
and/or running it on an low-power ARM board. Use Python tricks to minimise the
number of for and if statments (use something like "a[0:2] = [1] * 2 "). It is
just like writing a Matlab/Octave simulation.
3:
"Sampling Rate" in the GNU Radio blocks, except in some hardware sources/sinks
(including "UHD: USRP sink") and the "Throttle" block (which is for simulation
purposes), is just a concept. It does not actually affect the processing speed
of the code, and is there to solely make your calculations easier (by allowing
you to think in Hertz, instead of in Radians). Actual processing speed is
defined by the sampling rate of the hardware sources/sink blocks in your flow
graph (the "UHD: USRP Sink" block, in this case), and all other blocks will
just try to generate as many samples as they can, regardless of their
configured sampling rates.
So, if your codes can generate samples fast enough, and if you do not have
conflicting settings (more than two instances of hardware sources/sinks , or
"Throttle" blocks, with conflicting sampling rates), you should not see any
underruns.
I think your codes are indeed running too slow, especially since the processing
power of E313 is very limited. To verify this, replace your "UHD: USRP Sink"
with a "Null Sink" block and attach "Probe Rate" -> "Message Debug" to your
code (I've never done this on a E313, but I think it should still work). It
will show you the maximum throughput of your flowgraph. If this is indeed the
case, you must try optimising your codes, or re-write them in C++ (Or even
better, see if you can push things to RFNoC).
4:
It depends (there are some cases where you can write fast Python blocks), but
yes, C++ blocks are usually _way_ faster, and you are better off with C++
blocks, especially if you are dealing with low-power ARM chips. Poorly written
C++ blocks can still run very slowly, so please read OOT blocks that other
people wrote before moving on ( http://cgran.hopto.org/ ).
RFNoC is also an option for USRP E3xx / X3xx series boards. The Cortex-A9 CPUs
in your USRP E313 have very limited computational power, so you may HAVE to use
RFNoC. That requires some HDL experiences, however (FPGA development required).
5: (maybe someone else can answer this?)
Regards,
Kyeong Su Shin
________________________________
보낸 사람: Michael Bassi <mba...@srcaus.com> 대신 Discuss-gnuradio
<discuss-gnuradio-bounces+ksshin=postech.ac...@gnu.org>
보낸 날짜: 2019년 11월 25일 월요일 오전 9:32
받는 사람: Discuss Gnuradio <discuss-gnuradio@gnu.org>
제목: Custom OOT Block Running on USRP + General GNU Radio Questions.
Hi guys,
Firstly, I feel obliged to explain that I'm a young engineer relatively new to
Linux, SDR, GNU radio and USRP, and currently overwhelmed with the task
assigned to me! Many thanks in advance to any help provided. First time posting
to the
I have written a custom OOT block for GNU Radio that reads in information from
a file (in this case, pulse width (PW), and pulse repetition interval (PRI)),
and outputs a corresponding waveform with matching characteristics. I am
attempting to run this from a USRP E312 device. It is currently partially
working, and I have several questions:
1/ In the work function, an output array is provided as follows "out =
output_items[0]". The length of this array seems to be maxed at 8192, however
some times it's much less. Is this because the scheduler doesn't always have
enough resources to do the send the full 8192 - I found this statement GNU
website somewhere, is it related to this 'phenomenon'?
/* By default, GNU Radio runs a scheduler that attempts to optimize throughput.
Using a dynamic scheduler, blocks in a flowgraph pass chunks of items from
sources to sinks.The sizes of these chunks will vary depending on the speed of
processing. For each block, the number of items it can process is dependent on
how much space it has in its output buffer(s) and how many items are available
on the input buffer(s). */
Could someone please explain the output_items object to me?
2/ This is how i'm setting the output, out array within my custom block work
function:
self.num_samples_pri = int(self.sample_rate * float(self.pri))
self.num_samples_pw = int(self.sample_rate * float(self.pw))
for i in range(self.num_samples_pri):
if i < len(out):
if i < self.num_samples_pw:
out[i] = 1
else:
out[i] = 0
If the out array length is < num_samples_pw, my waveform is cut short, and I
get uneven spacing between some of the waveform pulses.
My question is, how do I deal with this issue? I have tried to appending more
elements to out array, but they seem to be ignored.
3/ I have built a GRC project with my custom block as source, and UHD: USRP
sink block as output so that I can run my project soley on the USRP device with
no connection to the PC.
When I run the compiled file on my USRP device, I am getting continuous
under-run errors. I know that under-run occurs when a block is not receiving
enough samples. In my case, the sample rate used in my code matches that
entered in the UHD USRP sink block. D
Is the underrun occurring because my USRP device isn't running my custom code
fast enough?
How do I deal with this?
4/ Should I be using custom blocks written in C++ instead of python, when the
intent is to run on the USRP device. I have heard that C++ is faster.
5/ I was able to run my custom PYTHON block from the USRP by copying the
gr-custom_block folder to the device, and building using cmake, etc. however
the C++ implementation of my custom block was not recognized.
AttributeError: 'module' object has no attribute 'readfilesource_cpp'
I got some advice on stack overflow about setting up a cross compilation
tool-chain, and recommended Ettus procedures to follow AN-311 and AN-315.
However, It was a struggle.
I would love some more advice on this!
Cheers,
Mike
