Re: burst mode for hackrf one

[Roland Schwarz]

Am 05.11.22 um 16:01 schrieb Marcus D. Leech:

> I will also point out that it's naive to assume that all SDR hardware 
> supports the same set of features, or even that those
>    features are implemented in the same way.

I fully understand, that it's naive to assume that all SDR hardware 
supports the same set of features, or that those features are 
implemented in the same way.

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.

>    That requires hardware support, and unless the target hardware was 
> "born" with that hardware support, no amount of
>    "faking it" with software will help...

Hmm, not sure I understand you here. HackRF One for sure is a cheap 
piece of hardware which likely has no sophisticated tx/rx timing 
control. But turning on the transmitter when a burst packet is available 
and turning it off when the burst is complete does not sound 
insurmountable to me.

Please don't get me wrong: I am not looking for fast TX/RX half duplex 
control currently. I do understand that this will be possibly not doable 
with GnuRadio because there is no combined sink and source device 
concept available. Sending out bursts, however, should be possible.

As already said: I am seeking advice for the best starting point, 
considering my "problem". Shall I tinker with the three levels of 
gr-soapy which makes use of the Photos HackRF soapy driver, which in 
turn uses libhackrf, or shall I better write my own specific gr driver 
which directly depends on libhackrf?

Roland

OpenPGP_signature
Description: OpenPGP digital signature