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.
