[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: burst mode for hackrf one
From: |
Roland Schwarz |
Subject: |
Re: burst mode for hackrf one |
Date: |
Sat, 5 Nov 2022 17:14:30 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 |
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
Re: burst mode for hackrf one, Roland Schwarz, 2022/11/05
Re: burst mode for hackrf one, Marcus Müller, 2022/11/05