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
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
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
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()
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
(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
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
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
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
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
10 matches
Mail list logo
