Processing time and block size

Hello, as I can understand the Kraken software collects signals for block_size time and then make the processing for t_proc (which small compared to block_size) time thus a DoA estimation is produced every block_size+t_proc time. Is this correct?
Can the processing time be significantly larger than the block_size so that to occur loss of data (because the next block has produced but the processing has not finished)?
I have chosen block_size of 500 msec, is there any guide in order to select appropriate the block_size based on the duration of the signal we hunt?

Yes data can be lost if the processing time is longer than it takes to sample it. This is mostly the reason why we chose the current block size as it balances the processing time required on the DSP side, and the processing time on the DAQ side for the Pi 4 hardware. At different settings on the Pi 4 it can cause one side of the producer-consumer chain to become a bottle-neck and samples get dropped.

But on faster hardware, it does not really matter because there won’t be a bottleneck. Regardless, I would suggest trying to keep the CPI a power of two for processing efficiency.

Smaller block sizes might be more useful for weak intermittent signals as the energy of that signal will be spread out less over the sampled block, but then you also need to worry about the intermittent signal being split at a block boundary which is more likely to happen with small block sizes.

For strong continuous signals with decent signal strength the block size doesn’t really matter. You can go down to about 50ms or less on faster hardware.

For weaker continuous signals you get more processing gain with longer block sizes and that can help get better results.

Thank you Carl. I don’t change the CPI, just the block size. Does changing the block size affect the CPI too?

Yes the block size is calculated from the CPI size, and vice versa.

1 Like

What is the formula describing the relation of CPI and block_size?

CPI = data_block_len * daq_decimated_sample_rate

So e.g. by default

CPI = (436.90666 / 10^3) * 2400000 = 1048576

Decimation on the DSP side does not affect this, only on the DAQ side

1 Like