Re: [Discuss-gnuradio] Maximum input items consumed on each input stream
Hi Laura,
the buffer sizes are determined at flow graph startup based on the
involved block's io signature, output multiples, alignment
requirements, minimum and maximum buffer sizes, and the page size
(which practically everywhere is 4kB).
I think you're expecting the amount of items your block is presented
with to be deterministic: it's simply not.
It's a thing that depends on the temporal execution of the signal
processing flowgraph at run time. Thus, your work (or general_work)
must always make sure it works within the boundaries of how many
samples are supplied in that specific call, and how much output space
is available at that point.
I think
https://www.gnuradio.org/blog/2017-01-05-buffers/
might be of interest to you.
Best regards,
Marcus
On Thu, 2019-08-29 at 14:27 -0700, Laura Arjona wrote:
> Thank you very much Michael.
>
> What are the I/O buffer sizes?
>
> * My block is a general block
> * In my forecast: ninput_items_required[0] = noutput_items;
> * In the general_work: const gr_complex *in = (const gr_complex *)
> input_items[0];
> float *out = (float *)
> output_items[0];
>
> /*
> * The private constructor
> */
> decoder_impl::frame_decoder_impl(int sample_rate,std::vector
> output_sizes)
> : gr::block("decoder",
> gr::io_signature::make(1, 1, sizeof(gr_complex)),
> gr::io_signature::makev(2, 2, output_sizes)),
> s_rate(sample_rate)
> {
>
>
>
>
> On Thu, Aug 29, 2019 at 5:41 AM Michael Dickens <
> michael.dick...@ettus.com> wrote:
> > Hi Laura - In the "work" or "general_work" method, there are
> > arguments that contain the information you're looking for. These
> > arguments are set depending on what type of block you're creating
> > (source, sink, sync, tagged_stream, whatever), are influenced by
> > what the "forecast()" method returns, and are constrained by the
> > I/O buffer sizes. Sorry to be a little vague, but the answer is
> > that the value of the variable "consumed" in your description is
> > context dependent. Hope this is useful! - MLD
> >
> > On Wed, Aug 28, 2019 at 2:53 PM Laura Arjona
> > wrote:
> > > Hello GNURadio community,
> > >
> > > Does anyone know what is the maximum number of input items that
> > > an Out Of Tree block can consume on each input stream?
> > >
> > > consume_each(consumed) --> what is the maximum value that the
> > > variable consumed can take?
> > >
> > > Thank you very much.
> > >
> > >
> > > --
> > > Laura Arjona
> > > Washington Research Foundation Innovation Postdoctoral Fellow in
> > > Neuroengineering
> > >
> > > Paul G. Allen School of Computer Science & Engineering
> > > 185 E Stevens Way NE
> > > University of Washington
> > > Seattle, WA 98195-2350
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
> > --
> > Michael Dickens, Mac OS X Programmer
> >
> > Ettus Research Technical Support
> >
> > Email: supp...@ettus.com
> >
> > Web: http://www.ettus.com
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Maximum input items consumed on each input stream
Laura et al,
consume_each <= ninput_items.
If you need a larger buffer than you consume you can abuse the
scheduler slightly by set_relative_rate(1, some_min_input_items), this
is done in the stream to vector blocks for example. I do this in a
visualization sink where I need to produce FFTs with a certain
overlap.
// We need at least this number of points to do our job
m_input_length = std::max(m_consume_each, m_fft_size);
// This is probably abusing the scheduler quite a bit
set_relative_rate(1, m_input_length);
Interesting to see you work in neuroengineering. I'm an
anesthesiologist and very interested these applications of gnuradio.
--Albin
On Fri, Aug 30, 2019 at 11:44 AM Marcus Müller wrote:
>
> Hi Laura,
>
> the buffer sizes are determined at flow graph startup based on the
> involved block's io signature, output multiples, alignment
> requirements, minimum and maximum buffer sizes, and the page size
> (which practically everywhere is 4kB).
>
> I think you're expecting the amount of items your block is presented
> with to be deterministic: it's simply not.
>
> It's a thing that depends on the temporal execution of the signal
> processing flowgraph at run time. Thus, your work (or general_work)
> must always make sure it works within the boundaries of how many
> samples are supplied in that specific call, and how much output space
> is available at that point.
>
> I think
>
> https://www.gnuradio.org/blog/2017-01-05-buffers/
>
> might be of interest to you.
>
> Best regards,
> Marcus
>
> On Thu, 2019-08-29 at 14:27 -0700, Laura Arjona wrote:
> > Thank you very much Michael.
> >
> > What are the I/O buffer sizes?
> >
> > * My block is a general block
> > * In my forecast: ninput_items_required[0] = noutput_items;
> > * In the general_work: const gr_complex *in = (const gr_complex *)
> > input_items[0];
> > float *out = (float *)
> > output_items[0];
> >
> > /*
> > * The private constructor
> > */
> > decoder_impl::frame_decoder_impl(int sample_rate,std::vector
> > output_sizes)
> > : gr::block("decoder",
> > gr::io_signature::make(1, 1, sizeof(gr_complex)),
> > gr::io_signature::makev(2, 2, output_sizes)),
> > s_rate(sample_rate)
> > {
> >
> >
> >
> >
> > On Thu, Aug 29, 2019 at 5:41 AM Michael Dickens <
> > michael.dick...@ettus.com> wrote:
> > > Hi Laura - In the "work" or "general_work" method, there are
> > > arguments that contain the information you're looking for. These
> > > arguments are set depending on what type of block you're creating
> > > (source, sink, sync, tagged_stream, whatever), are influenced by
> > > what the "forecast()" method returns, and are constrained by the
> > > I/O buffer sizes. Sorry to be a little vague, but the answer is
> > > that the value of the variable "consumed" in your description is
> > > context dependent. Hope this is useful! - MLD
> > >
> > > On Wed, Aug 28, 2019 at 2:53 PM Laura Arjona
> > > wrote:
> > > > Hello GNURadio community,
> > > >
> > > > Does anyone know what is the maximum number of input items that
> > > > an Out Of Tree block can consume on each input stream?
> > > >
> > > > consume_each(consumed) --> what is the maximum value that the
> > > > variable consumed can take?
> > > >
> > > > Thank you very much.
> > > >
> > > >
> > > > --
> > > > Laura Arjona
> > > > Washington Research Foundation Innovation Postdoctoral Fellow in
> > > > Neuroengineering
> > > >
> > > > Paul G. Allen School of Computer Science & Engineering
> > > > 185 E Stevens Way NE
> > > > University of Washington
> > > > Seattle, WA 98195-2350
> > > > ___
> > > > Discuss-gnuradio mailing list
> > > > Discuss-gnuradio@gnu.org
> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > >
> > >
> > > --
> > > Michael Dickens, Mac OS X Programmer
> > >
> > > Ettus Research Technical Support
> > >
> > > Email: supp...@ettus.com
> > >
> > > Web: http://www.ettus.com
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Maximum input items consumed on each input stream
Just to put a number on this question, the DVB-T2 transmitter uses up to 16 Megabyte buffers between blocks. I'm not sure what the absolute maximum is, but 16 Megabytes should cover most applications. The DVB-T2 blocks use set_output_multiple() in conjunction with forecast() to allocate these large buffers. Ron On 8/28/19 11:46, Laura Arjona wrote: Hello GNURadio community, Does anyone know what is the maximum number of input items that an Out Of Tree block can consume on each input stream? consume_each(consumed) --> what is the maximum value that the variable consumed can take? Thank you very much. -- *Laura Arjona* Washington Research Foundation Innovation Postdoctoral Fellow in Neuroengineering *Paul G. Allen School of Computer Science & Engineering* 185 E Stevens Way NE University of Washington Seattle, WA 98195-2350 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Maximum input items consumed on each input stream
Hi Laura - All of what's written already is basically correct. I'll add on
minor tweak: "ninput_items" and "noutput_items", which are 2 of the
arguments to the "work" or "general_work" method, define the maximum number
of input and/or output items available to use or requested to produce; see
the comments in the header for this method: <
https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/include/gnuradio/block.h#L168
>. Which of these variables is used depends on the actual block type as
already noted: source, sink, sync, tagged_stream, etc ... for example for
a source block -- one that does have inputs -- "ninput_items" is not used;
for a sink block "noutput_items" is not used. For general blocks,
"ninput_items" is as noted in the header: "number of input items available
on each input stream", and "noutput_items" is "number of output items to
write on each output stream" ... but note that both of these are maximums.
The values of these variables generally varies during runtime -- or rather,
it is not guaranteed that they will constant -- so, you can't do something
like "always produce 100 items", because there might not be enough output
buffer space. Hence you have to rely on the values of these variables to
determine how to do "work", and needs to keep track of the number of items
consumed during work (and then consume just that number). Hopefully this
and the other replies provide enough information for you to figure out how
to proceed. Cheers! - MLD
ps> It is -very- cool to have a neuroengineer and anesthesiologist using GR!
On Fri, Aug 30, 2019 at 6:27 AM Albin Stigö wrote:
> Laura et al,
>
> consume_each <= ninput_items.
>
> If you need a larger buffer than you consume you can abuse the
> scheduler slightly by set_relative_rate(1, some_min_input_items), this
> is done in the stream to vector blocks for example. I do this in a
> visualization sink where I need to produce FFTs with a certain
> overlap.
>
> // We need at least this number of points to do our job
> m_input_length = std::max(m_consume_each, m_fft_size);
> // This is probably abusing the scheduler quite a bit
> set_relative_rate(1, m_input_length);
>
> Interesting to see you work in neuroengineering. I'm an
> anesthesiologist and very interested these applications of gnuradio.
>
>
> --Albin
>
> On Fri, Aug 30, 2019 at 11:44 AM Marcus Müller
> wrote:
> >
> > Hi Laura,
> >
> > the buffer sizes are determined at flow graph startup based on the
> > involved block's io signature, output multiples, alignment
> > requirements, minimum and maximum buffer sizes, and the page size
> > (which practically everywhere is 4kB).
> >
> > I think you're expecting the amount of items your block is presented
> > with to be deterministic: it's simply not.
> >
> > It's a thing that depends on the temporal execution of the signal
> > processing flowgraph at run time. Thus, your work (or general_work)
> > must always make sure it works within the boundaries of how many
> > samples are supplied in that specific call, and how much output space
> > is available at that point.
> >
> > I think
> >
> > https://www.gnuradio.org/blog/2017-01-05-buffers/
> >
> > might be of interest to you.
> >
> > Best regards,
> > Marcus
> >
> > On Thu, 2019-08-29 at 14:27 -0700, Laura Arjona wrote:
> > > Thank you very much Michael.
> > >
> > > What are the I/O buffer sizes?
> > >
> > > * My block is a general block
> > > * In my forecast: ninput_items_required[0] = noutput_items;
> > > * In the general_work: const gr_complex *in = (const gr_complex *)
> > > input_items[0];
> > > float *out = (float *)
> > > output_items[0];
> > >
> > > /*
> > > * The private constructor
> > > */
> > > decoder_impl::frame_decoder_impl(int sample_rate,std::vector
> > > output_sizes)
> > > : gr::block("decoder",
> > > gr::io_signature::make(1, 1, sizeof(gr_complex)),
> > > gr::io_signature::makev(2, 2, output_sizes)),
> > > s_rate(sample_rate)
> > > {
> > >
> > >
> > >
> > >
> > > On Thu, Aug 29, 2019 at 5:41 AM Michael Dickens <
> > > michael.dick...@ettus.com> wrote:
> > > > Hi Laura - In the "work" or "general_work" method, there are
> > > > arguments that contain the information you're looking for. These
> > > > arguments are set depending on what type of block you're creating
> > > > (source, sink, sync, tagged_stream, whatever), are influenced by
> > > > what the "forecast()" method returns, and are constrained by the
> > > > I/O buffer sizes. Sorry to be a little vague, but the answer is
> > > > that the value of the variable "consumed" in your description is
> > > > context dependent. Hope this is useful! - MLD
> > > >
> > > > On Wed, Aug 28, 2019 at 2:53 PM Laura Arjona
> > > > wrote:
> > > > > Hello GNURadio community,
> > > > >
> > > > > Does anyone know what is the maximum number of input items that
> > > > > an Out Of Tree block can consume on each input stream?
>
Re: [Discuss-gnuradio] Maximum input items consumed on each input stream
Hi Ron, just because I think this might be interesting to people dealing with really high rates: The maximum size is typically limited by the size of mmap'able memory that you can allocate; that depends on the circular buffer factory used: For the posix shared memory thing, I don't think anything is stopping you from using "memory space size" order amounts of buffer. For anonymous file-backed mmap'ed buffers, I'd expect that we haven't addressed the possibility of using more than 32 bit addresses, so somewhere around 2 GB you'd find your upper limit. Best regards, Marcus On Fri, 2019-08-30 at 06:20 -0700, Ron Economos wrote: > Just to put a number on this question, the DVB-T2 transmitter uses up to 16 > Megabyte buffers between blocks. I'm not sure what the absolute maximum is, > but 16 Megabytes should cover most applications. > The DVB-T2 blocks use set_output_multiple() in conjunction with forecast() to > allocate these large buffers. > Ron > On 8/28/19 11:46, Laura Arjona wrote: > > Hello GNURadio community, > > > > Does anyone know what is the maximum number of input items that an Out Of > > Tree block can consume on each input stream? > > > > consume_each(consumed) --> what is the maximum value that the variable > > consumed can take? > > > > Thank you very much. > > > > > > -- > > Laura Arjona > > Washington Research Foundation Innovation Postdoctoral Fellow in > > Neuroengineering > > > > Paul G. Allen School of Computer Science & Engineering > > 185 E Stevens Way NE > > University of Washington > > Seattle, WA 98195-2350 > > > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio smime.p7s Description: S/MIME cryptographic signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Phase Align two RFNoC Radio Blocks in GRC
Hello together, I am trying to transmit one complex cosine from both TX - Antenna of my USRP-x310 with two UBX-160 Daugtherboards. I am transmitting a cosine with the frequency of 100 kHz and the center frequency of my RFNoC Radio Blocks is 2.45 GHz. So basically I see a peak at 2.45 Ghz + 100 kHz at my spectrum analyzer (plus the lo leakage at 2.45 GHz). Additionally I receive the spectrum on another x310. In the following link you can see my flowgraph in GRC: https://ibb.co/7W6mTKf As you can see i have two multiply blocks to change the phase of the complex cosines, the value of the multiply blocks are > pow(math.e, 1j*phi*(math.pi/180)) and > pow(math.e, 1j*psi*(math.pi/180)). I can change phi and psi with a qt gui range slider. Default value ist multiplication by 1. My goal with this setup was to check the MIMO capabilities of the USRP x310. I calculated the Phase offset both transmitted waves should have at the antenna of my spectrum analyzer. With my multiplication blocks I created different phase offsets, thus causing destructive interference at the receiving end (peak at analyzer is the smallest at this phase). However most of the time when I start different runs of my flowgraph (or when I power cycle the device) I always have to set a different phase offset to see the destructive interference. To me it seems pretty random which phase offset both transmitting path get even though i don't understand why. In another thread I read that maybe timed tuning will work for me but I did not quite understand what that improves in particular nor who I use it in my GRC generated python file. (Using the RFnoC Radio Blocks does not make it easier by the way.) This is the link: http://ettus.80997.x6.nabble.com/USRP-users-use-a-usrp-x310-as-MIMO-transmitter-daughterboard-synchronization-tt11642.html Any ideas, suggestions and explanations on how to phase align the transmit path of my (single) USRP x310 would be greatly appreciated! (I posted to the USRP List too, but I think maybe it's more of a python code fix and not HDL where you guys are better in..) Best regards Felix P.S: One last point if that helps: When I use the same setup with the USRP sink block with two inputs the phase seems to be locked and does not change with each new start of the flowgraph, even though i did not use timed commands there. When I try to use the RFNoC Radio Block with two inputs it does not work at all. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Expensive file write operation
Also note that a total of 40 MS/s, even at 16sc, is still 160 MB/s in data; it's not guaranteed that a consumer SSD would sustain that rate for arbitrarily long. Average write rates these days most definitely suffice, but don't underestimate the effect filesystem bookkeeping and imperfect buffer handling on OS side. Best regards, Marcus On Fri, 2019-08-30 at 19:56 +0200, sumit kumar wrote: > Hi Nate, > Ok I understood your point. Thanks for the Freq hint :) , I missed that in > hurry. > Regards > Sumit > > On Fri, 30 Aug 2019 at 19:50, Nate Temple wrote: > > Hi Sumit, > > > > The change for the output type doesn't address the limits of the transport. > > The output change however does cut the rate of data you're storing to disk > > in half, which can be useful if you have longer recordings or if your SSD > > is the bottle neck. > > > > This Akitio adapter box paired with a Mellanox card is a setup we have > > tested for TB3 to 10Gb: > > > > https://www.newegg.com/akitio-model-t3pb-t3dis-aktu/p/N82E16814988001 > > https://store.mellanox.com/products/mellanox-mcx4121a-acat-connectx-4-lx-en-network-interface-card-25gbe-dual-port-sfp28-pcie3-0-x8-rohs-r6.html > > > > I have not personally used this QNAP product, but others have reported it > > works fine (you'd want the one with the SFP port) > > > > https://www.qnap.com/en-us/product/qna-tb-10gbe > > > > > > One other observation on your flowgraph, you do not have the Ch1 Center > > Freq set correctly, it is currently set as 0. > > > > > > Regards, > > Nate Temple > > > > > > On Fri, Aug 30, 2019 at 10:42 AM sumit kumar wrote: > > > Hi Nate, > > > Thanks. > > > My understanding about this was wrong :D I will order one adapter. > > > Meanwhile, I tried your suggestion, it is still giving overruns. > > > I have attached the screenshots of my config, can you please verify. > > > > > > > > > > > > > > > > > > On Fri, 30 Aug 2019 at 19:12, Nate Temple wrote: > > > > Hi Sumit, > > > > > > > > Are you using a 1Gb transport to the X310? > > > > > > > > The max data rate a 1Gb link can handle is ~25 MS/s @ sc16 OTW. With > > > > the two channels at 20 MS/s you're over this limit and would need to > > > > use 10Gb. If your laptop has a TB3/USB-C port, there are several TB3 to > > > > 10Gb adapters available. > > > > > > > > > > > > Another observation -- if you switch the output type of the UHD Source > > > > block to be Complex int16 and then set your file sinks to have the data > > > > type Ints, you will cut the data rate in half that is being written to > > > > disk (complex 16bit Ints vs complex 32 bit floats). > > > > > > > > Regards, > > > > Nate Temple > > > > > > > > > > > > On Fri, Aug 30, 2019 at 9:59 AM sumit kumar wrote: > > > > > Hi, > > > > > I am trying to capture RF data thru X310 from 2 channels and writing > > > > > them to file using GNU Radio. But when I use a sampling rate of 20 > > > > > MHz, packets start dropping badly. > > > > > > > > > > I have a very decent Laptop i7 8th Gen, SSD, 16 gb RAM. I also > > > > > observed the CPU performance, it does not look stressed at all. I > > > > > mean, none of the cores were reaching anywhere near to even 50%. > > > > > Am I doing something wrong? For 10MHz sampling rate it is good, no > > > > > overruns. > > > > > I have attached my flowgraph, and the cpu performance screenshot. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards > > > > > -- > > > > > Sumit Kumar > > > > > > > > > > > > > > > ___ > > > > > Discuss-gnuradio mailing list > > > > > Discuss-gnuradio@gnu.org > > > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > > > > > -- > > > Sumit Kumar > > > > > > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio smime.p7s Description: S/MIME cryptographic signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Maximum input items consumed on each input stream
Thank you very much Marcus, Michael, Abin, and Ron, really appreciate your responses. To give some context, I just started designing a prototype reader to implement a custom protocol for backscatter neural implants; very excited to build my platform with GNU-radio :) After reading all the information from your responses and links provided, I still have a problem with my implementation. According to the buffer sizes that you mentioned, I should not have this problem, but I think I am missing something. I may need to re-design my system/flow-graph, but I would like to get a last advice/help, if possible. Thanks in advance! *I want my block Decoder to consume_each(>8900) but I get overflows "D" messages. See details below* I have 2 general out of tree blocks: Gate and Decoder. They both have*:* *ninput_items_required[0] = noutput_items;* *const gr_complex *in = (const gr_complex *) input_items[0];* * gr_complex *out = (gr_complex *) output_items[0]; * The flow-graph looks like *uhd_source -> fir_filter_ccc -> Gate -> Decoder -> other blocks. (Using a USRP N210 + SBX)* The idea is that I want the block *Decoder* to only process the input samples when I have received *k* samples. Let's set k=~8900 So, at the *Decoder* block general_work(), I set *consume_each(0) *until *ninput_items[0]>=k.* Basically, at the Decoder general_work() I have the following (just a overview, not pseudo-code): * if (ninput_items[0] wrote: > Hi Ron, > > just because I think this might be interesting to people dealing with > really high rates: > The maximum size is typically limited by the size of mmap'able memory > that you can allocate; that depends on the circular buffer factory > used: > For the posix shared memory thing, I don't think anything is stopping > you from using "memory space size" order amounts of buffer. > For anonymous file-backed mmap'ed buffers, I'd expect that we haven't > addressed the possibility of using more than 32 bit addresses, so > somewhere around 2 GB you'd find your upper limit. > > Best regards, > Marcus > > On Fri, 2019-08-30 at 06:20 -0700, Ron Economos wrote: > > Just to put a number on this question, the DVB-T2 transmitter uses up to > 16 Megabyte buffers between blocks. I'm not sure what the absolute maximum > is, but 16 Megabytes should cover most applications. > > The DVB-T2 blocks use set_output_multiple() in conjunction with > forecast() to allocate these large buffers. > > Ron > > On 8/28/19 11:46, Laura Arjona wrote: > > > Hello GNURadio community, > > > > > > Does anyone know what is the maximum number of input items that an Out > Of Tree block can consume on each input stream? > > > > > > consume_each(consumed) --> what is the maximum value that the variable > consumed can take? > > > > > > Thank you very much. > > > > > > > > > -- > > > Laura Arjona > > > Washington Research Foundation Innovation Postdoctoral Fellow in > Neuroengineering > > > > > > Paul G. Allen School of Computer Science & Engineering > > > 185 E Stevens Way NE > > > University of Washington > > > Seattle, WA 98195-2350 > > > > > > > > > ___ > > > Discuss-gnuradio mailing list > > > Discuss-gnuradio@gnu.org > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- *Laura Arjona * Washington Research Foundation Innovation Postdoctoral Fellow in Neuroengineering *Paul G. Allen School of Computer Science & Engineering* 185 E Stevens Way NE University of Washington Seattle, WA 98195-2350 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Maximum input items consumed on each input stream
If you use set_output_multiple(), you don't have to check the input
buffer. The block will only execute if there are a multiple of the value
used in set_output_multiple() items available. For example, if
set_output_multiple() is set to 256, the block will only execute if
noutput_items is at least 256, but it could also be 512, 768, 1024,
1280, 1536, etc.
Since forecast() sets ninput_items_required to noutput_items, the same
number of items appears on the input buffer.
Here's a dummy block that just copies input to output to show the
structure. The loop in general_work() allows for any value of CHUNK_SIZE
to work properly. With a size of 8900, the loop will typically only
execute once.
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include
#include
#include "buffer_cc_impl.h"
#define CHUNK_SIZE 8900
namespace gr {
namespace laura {
buffer_cc::sptr
buffer_cc::make()
{
return gnuradio::get_initial_sptr
(new buffer_cc_impl());
}
/*
* The private constructor
*/
buffer_cc_impl::buffer_cc_impl()
: gr::block("buffer_cc",
gr::io_signature::make(1, 1, sizeof(gr_complex)),
gr::io_signature::make(1, 1, sizeof(gr_complex)))
{
set_output_multiple(CHUNK_SIZE);
}
/*
* Our virtual destructor.
*/
buffer_cc_impl::~buffer_cc_impl()
{
}
void
buffer_cc_impl::forecast (int noutput_items, gr_vector_int
&ninput_items_required)
{
ninput_items_required[0] = noutput_items;
}
int
buffer_cc_impl::general_work (int noutput_items,
gr_vector_int &ninput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)
{
const gr_complex *in = (const gr_complex *) input_items[0];
gr_complex *out = (gr_complex *) output_items[0];
printf("noutput_items = %d\n", noutput_items);
for (int i = 0; i < noutput_items; i += CHUNK_SIZE) {
memcpy(out, in, CHUNK_SIZE * sizeof(gr_complex));
in += CHUNK_SIZE;
out += CHUNK_SIZE;
}
consume_each (noutput_items);
// Tell runtime system how many output items we produced.
return noutput_items;
}
} /* namespace laura */
} /* namespace gr */
Ron
On 8/30/19 15:58, Laura Arjona wrote:
Thank you very much Marcus, Michael, Abin, and Ron, really appreciate
your responses.
To give some context, I just started designing a prototype reader to
implement a custom protocol for backscatter neural implants; very
excited to build my platform with GNU-radio :)
After reading all the information from your responses and links
provided, I still have a problem with my implementation. According to
the buffer sizes that you mentioned, I should not have this problem, but
I think I am missing something. I may need to re-design my
system/flow-graph, but I would like to get a last advice/help, if
possible. Thanks in advance!
_I want my block Decoder to /consume_each(>8900/) but I get overflows
"D" messages. See details below_
I have 2 general out of tree blocks: Gate and Decoder.
They both have/:/
/ ninput_items_required[0] = noutput_items;/
/ const gr_complex *in = (const gr_complex *)
input_items[0];/
/ gr_complex *out = (gr_complex *) output_items[0];
/
/
/
/
/
The flow-graph looks like /uhd_source -> /fir_filter_ccc ->/*Gate* ->
*Decode**r* -> other blocks. (Using a USRP N210 + SBX)
/
The idea is that I want the block /Decoder/ to only process the input
samples when I have received /k/ samples. Let's set k=~8900
So, at the /Decoder/ block general_work(), I set /consume_each(0)
/until /ninput_items[0]>=k./
Basically, at the Decoder general_work() I have the following (just a
overview, not pseudo-code):
/ if (ninput_items[0] And one interesting? thing happens. When /ninput_items[0]/ gets close
to /k=8500/ (or higher value), is when I start getting 'D', and after
that /ninput_items[0] = 800/, no matter the value of /k/.
/
/
/
/
Thank you.
Cheers
Laura.
On Fri, Aug 30, 2019 at 7:29 AM Müller, Marcus (CEL) > wrote:
Hi Ron,
just because I think this might be interesting to people dealing with
really high rates:
The maximum size is typically limited by the size of mmap'able memory
that you can allocate; that depends on the circular buffer factory
used:
For the posix shared memory thing, I don't think anything is stopping
you from using "memory space size" order amounts of buffer.
For anonymous file-backed mmap'ed buffers, I'd expect that we haven't
addressed the possibility of using more than 32 bit addresses, so
somewhere around 2 GB you'd find your upper limit.
Best regards,
Marcus
On Fri, 2019-08-30 at 06:20 -0700, Ron Economos wrote:
> Just to put a number on this question, the DVB-T2 transmitter
uses up to 16 Megabyte
