Re: GNU Radio Companion N310 GPIO Sink/Source block

2022-06-28 Thread Marcus D. Leech
On 2022-06-28 19:56, U L wrote: Joshua, Generally Fabien is right. To exercise the full feature set of the GPIO you would likely need an OOT block. However, if only limited performance and features are needed then you might get away with using the Python embedded block or Python snippet in GR

Re: GNU Radio Companion N310 GPIO Sink/Source block

2022-06-28 Thread U L
Joshua, Generally Fabien is right. To exercise the full feature set of the GPIO you would likely need an OOT block. However, if only limited performance and features are needed then you might get away with using the Python embedded block or Python snippet in GRC to implement something quick and ea

Re: GNU Radio Companion N310 GPIO Sink/Source block

2022-06-28 Thread Fabien PELLET
Hi Joshua, I'm also using GPIO on LFTX and LFRX on a N210 and I can tell you that you will not find source or sink that deal with that IO as far as I know. The only way to use them is to write an OOT that uses the UHD methods. Best regards, Fabien, F4CTZ White, Joshua J a écrit >(Cr

Re: GNU Radio Companion N310 GPIO Sink/Source block

2022-06-28 Thread U L
Joshua, I have not personally used the N3XX devices, but I did recently successfully manipulate the GPIO on a N210 w/ LFXX daughtercards. The relevant UHD manual section for you I think is https://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_fpgio (but also see the X310 section at https://file

GNU Radio Companion N310 GPIO Sink/Source block

2022-06-28 Thread White, Joshua J
(Cross-posted on usrp-users and discuss-gnuradio) For anyone who's familiar with using the USRP3 (specifically the N310) with GNU Radio: I'm trying to create a flowgraph in gnu radio companion that incorporates reading a value from one pin on the front panel GPIO of the N310 and writing a value

RE: Re: Number of samples processed in the work function

2022-06-28 Thread Jim Melton
We recently confirmed that set_min_noutput_items() has absolutely no effect on processing. The set_output_multiple() is the right way to do what you want. It is appropriate because of the conditions you described: * packets contain a fixed number of samples. * you are reading a socket, and not d

Re: Number of samples processed in the work function

2022-06-28 Thread Marcus Müller
Also a very good solution, but requires that you always get exactly 1024 items, not sometimes 1024, and in some cases 100, or 1023. On 28.06.22 19:13, WarMonkey wrote: I think "processing more samples" should be prohibited because the length of each buffer is limited. Use "set_output_multiple()

Re: Number of samples processed in the work function

2022-06-28 Thread Marcus Müller
Hi Daniel On 28.06.22 18:44, Perkins, Daniel (US) wrote: * processing more samples is not recommended Not only not recommended, it's strictly forbidden, and breaks GNU Radio. You get only as much output buffer as you get noutput_items. You produce more, you're overwriting parts of previous

Re: Number of samples processed in the work function

2022-06-28 Thread WarMonkey
I think "processing more samples" should be prohibited because the length of each buffer is limited. Use "set_output_multiple()" function to keep noutput_items equal to N*output_multiple (N is a positive integer). https://www.gnuradio.org/doc/doxygen/classgr_1_1block.html#a63d67fd758b70c6f2d7b7d4ed

Number of samples processed in the work function

2022-06-28 Thread Perkins, Daniel (US)
I have written a source block that reads an IQ data stream from a socket. It is my understanding that: * the work function should attempt to process the number of samples as determined by the noutput_items variable * processing fewer samples is acceptable * processing more samples is