<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi Eric,</p>
    <p>thanks for your reply!<br>
      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.</p>
    <p>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.</p>
    <p>Here is an example of what I mean:<br>
      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.<br>
      <br>
      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.</p>
    <p>However, I'll try it!<br>
    </p>
    <p>Sebastian<br>
    </p>
    <div class="moz-cite-prefix">Am 09.12.2020 um 16:39 schrieb Eric
      Wild:<br>
    </div>
    <blockquote type="cite"
      cite="mid:6097eaf0-0f92-599e-7017-b3d3aaeb10e5@sysmocom.de">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <div class="moz-cite-prefix">Hi Sebastian,</div>
      <div class="moz-cite-prefix">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.</div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix">-Eric<br>
      </div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix">Am 09.12.2020 um 13:23 schrieb
        Sebastian Böhm:<br>
      </div>
      <blockquote type="cite"
        cite="mid:0b9d4c0e-eefd-cf5f-c23c-6eb94791a2fc@b-tu.de">
        <meta http-equiv="Content-Type" content="text/html;
          charset=UTF-8">
        <p>Does anyone have any idea what could be the reason for this
          behavior?<br>
        </p>
        <div class="moz-cite-prefix">Am 01.12.2020 um 16:28 schrieb
          Sebastian Böhm:<br>
        </div>
        <blockquote type="cite"
          cite="mid:c6a553b6-ee76-d23c-2f49-40197a4ec183@b-tu.de">
          <meta http-equiv="content-type" content="text/html;
            charset=UTF-8">
          Hi,<br>
          <br>
          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.<br>
          <br>
          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.<br>
          <br>
          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?<br>
          <br>
          Thank You in advance!<br>
          <br>
          Regards,<br>
          Sebastian<br>
          <div class="moz-signature">-- <br>
            <font face="monospace" color="Gray">
              __________________________________________________________<br>
              <br>
              Sebastian Boehm<br>
              Brandenburg University of Technology Cottbus - Senftenberg<br>
              Computer Networks Communication Systems Group<br>
              <br>
              E-Mail: <a href="mailto:Sebastian.Boehm@b-tu.de"
                moz-do-not-send="true">sebastian.boehm@b-tu.de</a><br>
              <br>
              P.O. Box: 10 13 44<br>
              D-03013 Cottbus<br>
              GERMANY<br>
            </font></div>
        </blockquote>
      </blockquote>
      <p><br>
      </p>
    </blockquote>
  </body>
</html>