|
From: | Dobler, Anton |
Subject: | AW: USRP, GPIO toggling and Gnuradio |
Date: | Fri, 10 Sep 2021 15:54:50 +0000 |
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?
BR,
Anton Von: Discuss-gnuradio <discuss-gnuradio-bounces+anton.dobler=unibw.de@gnu.org> im Auftrag von Marcus D. Leech <patchvonbraun@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:
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? |
[Prev in Thread] | Current Thread | [Next in Thread] |