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.
No comments:
Post a Comment