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@greatscottgadgets.com > https://pairlist9.pair.net/mailman/listinfo/hackrf-dev > _______________________________________________ HackRF-dev mailing list HackRF-dev@greatscottgadgets.com https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
