Re: Developing KrakenSDR Source
> > 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 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 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 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 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 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
Re: Developing KrakenSDR Source
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 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 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 >> >
Developing KrakenSDR Source
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
