9 Dec
2020
9 Dec
'20
4:39 p.m.
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(a)b-tu.de <mailto:Sebastian.Boehm@b-tu.de>
>
> P.O. Box: 10 13 44
> D-03013 Cottbus
> GERMANY