1 Dec
2020
1 Dec
'20
5:28 p.m.
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
9 Dec
9 Dec
2:23 p.m.
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
5: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
10 Dec
10 Dec
10:06 a.m.
Hi Eric,
thanks for your reply!
I understand what you mean by the performance aspect, but 'immediately'
in my case did not mean that no latency should occur. And I think my
problem does not necessarily belong to the size of the buffer.
However, I'm surprised that this buffer is only flushed to the Hackrf
hardware when it is completely filled, whereas it is actually streamed
continuously with 4M samples per second via USB. This is a major
limitation.
Here is an example of what I mean:
If I create a simple communication protocol in grc where only a response
is made by sending a small acknowledgement packet for a request, but
otherwise waiting, the osmocom sink will never send this packet because
the buffer is not yet full. This inevitably leads to misbehavior in the
communication flow.
I could adjust the size of the buffer so that it is already completely
filled with the smallest of my packets, but his is not a very elegant
solution.
However, I'll try it!
Sebastian
Am 09.12.2020 um 16:39 schrieb Eric Wild:
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
11:15 a.m.
GNuradio is a streaming system by design, you need to insert as many
zeros as you need between your bursts (depending on the idle time you
want between your bursts).
That's inherent to the way GR buffers data between blocks and won't
call the work() method until it has "sufficient" data.
Cheers,
Sylvain
16 Dec
16 Dec
5:22 p.m.
Thanks for your advise!
Now i pad my message with zeroes so that the hackrf buffer is completely
filled. This works perfectly!
Am 10.12.2020 um 10:15 schrieb Sylvain Munaut:
GNuradio is a streaming system by design, you need to
insert as many
zeros as you need between your bursts (depending on the idle time you
want between your bursts).
That's inherent to the way GR buffers data between blocks and won't
call the work() method until it has "sufficient" data.
Cheers,
Sylvain
1264
days inactive
1279
days old
5 comments
3 participants
participants (3)
-
Eric Wild -
Sebastian Böhm -
Sylvain Munaut