I am extracting the package rate of a receive signal using a rather complex GRC
flowgraph, i.e. I am detecting the preamble of a receive signal and generate a
clock from here. This clock signal period is within the range of 100us - 1ms.
As I wrote in my first message, the work function with the sleep timer works
for simple flowgraphs using a sampling rate of up to 10kHz. After that the
toggling period stays more or less the same, I guess this is because of the
rescheduling time limit as Jeff Long already stated.
However, I am wondering, why the block needs a sleep function at all, since the
threshold_ff_impl.cc, whose work function is almost the same as the one I use,
does not need that and still has the proper sampling...
I read about the ATR functionality and that there are three fast-path methods
for a USRP device (uhd::tx_streamer::send(), uhd::rx_streamer::recv(), and
uhd::tx_streamer::recv_async_msg()).
Do you think wiring the GPIOs to the ATR functionality and toggling them by
switching tx_stream on/off would be a better solution?
As a second idea, I was wondering if using a input vector to the block of a
certain size (e.g. 1000 items) would be a better approach than using the
noutputitems, which I think have been only two items (still need to run the
perf counters...)? I guess the scheduler runs the work function of each block
completely, doen't it??
Thank you for your help!
BR,
Anton
________________________________
Von: Discuss-gnuradio <discuss-gnuradio-bounces+anton.dobler=unibw...@gnu.org>
im Auftrag von Marcus D. Leech <patchvonbr...@gmail.com>
Gesendet: Freitag, 10. September 2021 17:36
An: discuss-gnuradio@gnu.org
Betreff: Re: USRP, GPIO toggling and Gnuradio
On 2021-09-10 10:18 a.m., Dobler, Anton wrote:
Dear all,
I am currently trying to write an OOT block to switch a GPIO pin high or low
depending on the input signal. So far it has worked with the configuration of
the pins and I can also switch the pins according to the input signal in a
relatively simple flowgraph consisting of a signal generator that produces a
square wave signal.
The block's work function looks like this:
int GPIO_IO_impl::work(int noutput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)
{
const float *in_signal = (const float *) input_items[0];
for(int i=0; i < noutput_items; i++) {
if(in_signal[i] >= d_threshold)
{
_dev->set_gpio_attr(gpio, std::string("OUT"), "HIGH",
0xffffffff)
}
if(in_signal[i] < d_threshold)
{
_dev->set_gpio_attr(gpio, std::string("OUT"), "LOW", 0xffffff);
}
boost::this_thread::sleep_for(boost::chrono::nanoseconds((unsigned long
long)d_samp_period));
}
return noutput_items;
}
The sleep function is important in that without it, regardless of the sampling
rate of the square wave signal, the pin is switched with a period of 20us. If I
use the sleep function, the whole thing works better, but only up to a sampling
rate of about 20kHz. I have read a little bit about the function of the
scheduler in GNURadio, but I did not find a solution.
Starting from the standing approach, I have tried using both Timed Commands and
Boost Signals, with the result that the pins are switched completely
asynchronously. Since I don't really know what to do at this point, I wanted to
ask if any of you had experience with this kind of OOT block in GNURadio.
?
Best regards,
Anton
Could you clarify--you WANT the pins to be switched at a very high rate--that
is you expect your input signal to be switching between thresholds with a
period smaller than 20us?
