Re: burst mode for hackrf one

[Marcus D. Leech]

On 05/11/2022 12:14, Roland Schwarz wrote:
> I never complaint that the behavior is different from my expectations. 
> (I inadvertently filed a bug, sorry for that.) Instead I am just 
> looking for the correct point to start, without reinventing the wheel. 
> Since documentation on the topic is sparse and understanding the data 
> flow from looking at three different layers, which are not implemented 
> in the same way as you say is hard, I thought I could try to get some 
> insight from the knowledgeable's on this list. :-)
>
> > Now *some* of this can kind of sort of be "faked" in the drivers. But 
> > things like hardware-precise burst timing?  Nope.
>
> As a first step I am not looking for 'precise' burst timimg. When I 
> create a burst PDU and convert it with PDU to Stream I am happy if 
> that packet is sent out by the transmitter. Currently the send buffer 
> waits until it is full before any data gets out of the tx.
So it seems that the question you're *actually* asking is somewhat 
disjoint from the question I *thought* you were asking--
  my apologies.

It *sounds* like you want to understand how to get "bursty" behavior 
from Gnu Radio's overall "streaming" doctrine--and THAT
  is only tangentially related to the underlying hardware.

"I created a PDU, sent it through the modulators, but the resulting 
buffer is small enough that it's getting 'hung up' inside GR".
   Since I'm not a TX guy primarily, I'm not actually sure how this is 
dealt with, and others might have some insights--there
  have been a crap-tonne of people who have used GR for TX, and often 
in "bursty" mode--like sending CW on HF, for example.
  One technique that likely works OK is "zero stuffing".  You send a 
constant stream of 0s in "idle" state, and when a PDU comes
  along it interrupts the otherwise-boring stream of 0s.