Hi Sebastian,

since the hackrf is half-duplex and has no timestamp support (only continuous streaming) the buffer size was chosen at the time to provide a reasonable tradeoff between latency and performance for higher sample rates - I suppose you could just decrease it if that is the problem, but there is still no way to just send something immediately, there will always be a considerable latency between the host and the rf output.

-Eric

Am 09.12.2020 um 13:23 schrieb Sebastian Böhm:

Does anyone have any idea what could be the reason for this behavior?

Am 01.12.2020 um 16:28 schrieb Sebastian Böhm:

Hi,

i try to transmit 2.48 ghz radio packets (beacons) at a fixed time interval (e.g. every 1 s) via hackrf using the osmocom sink in gnuradio. Without exception, the beacons are all received by my sniffer "golden device" hardware, but burst.

It seems that the packets are only transferred via USB to the hackrf device hardware when the buffer with the fixed BUF_LEN 262144 (32*16*512) is completely filled. For my setup this are e.g. 18 beacon frames, which are transmitted as burst. When I look at the USB interface, I can see this burst of data every 18 seconds in a full USB request block (URB) of size 262144 byte. All other URBs (also of size 262144 - every approx. 200us) transferred via USB are filled with zeros only. So this burst behavior should be caused by gnuradio.

How can I achieve that the complex data of the osmocom sink's input is immediately (with the next URB) transferred to the hackrf hardware? Am I missing any options of the GRC module?

Thank You in advance!

Regards,
Sebastian

--
__________________________________________________________

Sebastian Boehm
Brandenburg University of Technology Cottbus - Senftenberg
Computer Networks Communication Systems Group

E-Mail: sebastian.boehm@b-tu.de

P.O. Box: 10 13 44
D-03013 Cottbus
GERMANY