[Hackrf-dev] Dropped samples

[Michael Ossmann]

Matt,

It is a common problem to need to pad the start and/or the end of data
fed into GNU Radio in a scenario like yours.  Various blocks in GNU
Radio require a certain amount of sample history to be full before they
produce output samples and require that buffer to be flushed in order to
produce output from every last input sample.  For example, an FIR filter
with n taps requires n+1 input samples in order to produce one output
sample.

Unfortunately it is a lot of work to try to predict how much padding is
needed in a flowgraph.  Every connection from one block to another has a
buffer, and many blocks have a sample history requirement.  To make
matters more complicated, the history requirement can change depending
on configuration such as the number of taps in a filter, and if you let
GNU Radio design your filters for you (which I recommend), you probably
have no idea how many taps they have.

Most people just pad their data until things work.

Mike


On Sat, May 19, 2018 at 12:16:47PM +0000, Matt Holmes wrote:
>
> Hi everyone,
> 
> I have created a transmitter using GRC with a hackrf one that sends a number of packets defined by a multiplier in the flow graph. To separate the packets I used a stream mux to multiplex Gaussian white noise at a minimal amplitude between them. During testing I noticed that either part or all of the first and last packet were missing. To overcome this I used a second stream mux to multiplex white noise to the beginning and end of the stream of packets. 
> 
> I assume that there is a mismatch between the hardware being ready to receive samples and the software delivering them. I also noticed that the number of samples dropped increased when I changed the top block to no GUI. 
> 
> Can anyone explain why this happens as although I have a workaround I would like to understand why samples are dropped. Also if anyone knows exactly how to calculate the number of dropped samples I could fine tune my transmitter. 
> 
> Thanks in advance 
> 
> 
> Regards
> 
> Matt
> _______________________________________________
> HackRF-dev mailing list
> HackRF-dev at greatscottgadgets.com
> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
>