> > Oh, maybe the confusion is over how many items you need to output at one > time. You can hold on to your buffer - one get_iq_online() worth - until it > is empty, through multiple work() calls. Copy out > min(amount_left_from_fetch, output_items) and return the number of items > you copied (not the max size given to work() by the scheduler). It's OK if > the scheduler says to output 1024 items and you only output 4 (bad example) > if that's what is most efficient, or if you have only 4 items left > internally.
Ah nice I think this was the missing piece of my knowledge. New stream implementation seems to be working now. Thanks! On Wed, Aug 17, 2022 at 2:30 PM Jeff Long <[email protected]> wrote: > Oh, maybe the confusion is over how many items you need to output at one > time. You can hold on to your buffer - one get_iq_online() worth - until it > is empty, through multiple work() calls. Copy out > min(amount_left_from_fetch, output_items) and return the number of items > you copied (not the max size given to work() by the scheduler). It's OK if > the scheduler says to output 1024 items and you only output 4 (bad example) > if that's what is most efficient, or if you have only 4 items left > internally. > > On Tue, Aug 16, 2022 at 10:19 PM Jeff Long <[email protected]> wrote: > >> Output buffer size is adjustable - set_min_output_buffer(min_items) will >> give a buffer that is at least num_items in size, but is often larger due >> to alignment requirements. I wouldn't use vectors just to get around buffer >> sizes. Very large buffers may not work due to the way they are allocated. >> Give this a try first. >> >> On Tue, Aug 16, 2022 at 9:24 PM Carl Laufer <[email protected]> wrote: >> >>> Thanks. I think it has to be a vector output. >>> >>> It seems that if I'm using a stream output, and have decimation blocks >>> downstream, output_items in the source is always smaller than cpi_size, and >>> I can't fit the 2^20 array into output_items. I think it expects the source >>> to adjust its output buffer size? I'd have to throw away data as there's no >>> way to tell heimdall at runtime to reconfigure to use a smaller cpi_size. >>> >>> Unless, is there any way to force output_items to always be [5, >>> cpi_size] when using a stream output in the source block? >>> >>> On Wed, Aug 17, 2022 at 2:13 AM Jeff Long <[email protected]> wrote: >>> >>>> Hi Carl, >>>> >>>> Use vectors only if data always needs to be grouped in exact >>>> quantities, e.g., if the GR flowgraph needs to always handle blocks of 2^20 >>>> items. In general, a 5-channel stream would be more flexible. The variation >>>> in the number of items would be due to the output buffer sometimes being >>>> empty and sometimes not. This depends on what is happening in downstream >>>> blocks, and also on random scheduling of threads. Hope that answers some of >>>> your questions. >>>> >>>> On Tue, Aug 16, 2022 at 9:49 AM Carl Laufer <[email protected]> wrote: >>>> >>>>> Hi All, >>>>> >>>>> I'm currently working on a GNU Radio source block for the KrakenSDR. >>>>> So far my block mostly seems to work as expected, but I'm having some >>>>> minor >>>>> issues and questions. >>>>> >>>>> If you didn't know, the KrakenSDR is 5 RTL-SDR receivers, on the same >>>>> clock with a noise source for coherence calibration of the channels. We're >>>>> using it for applications like radio direction finding and passive >>>>> radar, and mostly write our own code in Python. But having a GNU Radio >>>>> source would be useful for others. >>>>> >>>>> With KrakenSDR there is a DAQ software called "heimdall" which handles >>>>> all the coherent calibration automatically. In my source block, I'm able >>>>> to >>>>> successfully receive the data in the GNU Radio source block from heimdall >>>>> via a socket connection. >>>>> >>>>> First so you know, the heimdall DAQ buffers an array of "cpi_size" >>>>> (cpi = coherent processing interval) IQ data per channel, and outputs >>>>> those >>>>> arrays on the socket when it's filled. By default the cpi_size = 2^20. So >>>>> in my GNU Radio source I'm receiving five, 2^20 long arrays of coherent >>>>> complex IQ data every ~400ms. >>>>> >>>>> I believe in GNU Radio this is considered a vector? So should I make >>>>> the output of the source block five port vectors, with >>>>> out_sig=[(np.complex64, cpi_size)] * numChannels and set vlen to cpi_size >>>>> in the yaml? >>>>> >>>>> Or instead should I have it as an output stream out_sig=[np.complex64] >>>>> * numChannels, and be using Stream->Vector blocks when needed, with >>>>> num_items set to cpi_size? >>>>> >>>>> I've tried both methods, and they both work. But I don't understand >>>>> why when using the vector output implementation, the shape of output_items >>>>> keeps flipping between (5, 2, 1048576) and (5, 1, 1048576)? >>>>> >>>>> Code is all at https://github.com/krakenrf/gr-krakensdr if anyone >>>>> would care to take a look. Everything in Python. If anyone has any tips or >>>>> comments please let me know. Thanks to anyone for your insights. >>>>> >>>>> Regards, >>>>> Carl Laufer >>>>> >>>>
