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