AW: USRP, GPIO toggling and Gnuradio

[Dobler, Anton]

PS: To clarify the 20us: 

If I do not use a sleep function in that OOT block and run the flowgraph, I measure a switching time of the GPIOs of 20us no matter which sample rate I use.... I

f I use a sleep function the toggling period really depends on the corresponding flowgraph's complexity. 

Using a very simple flowgraph consisting out of a signal generator and that GPIO block I get 5kHz rect signal properly shown on a oscilloscope. 

Using the more complex flowgraph to extract package rate from a received signal I am far out of scope of the desired toggling period... 

---

Von: Dobler, Anton
Gesendet: Freitag, 10. September 2021 17:54
An: Marcus D. Leech; discuss-gnuradio@gnu.org
Betreff: AW: USRP, GPIO toggling and Gnuradio

 

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.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:

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?