title: High latency when transmitting with HackRF One from GNU Radio
body: <p>So I reverse-engineered an RC toy wireless protocol, and written a flow graph in GNU Radio Companion for reproducing the toy's commands.</p>
  
  <p>The sink block is osmocom sink, and transmitting device is HackRF One.</p>
  
  <p>The problem I encountered is severe lag between pressing button and toy reacting, which is about 1-2 seconds.</p>
  
  <p>Quickly pressing, for example, "forward" button twice will result in toy jerking forward twice in quick succession as well, about a second after pressing. So it's not like the flow graph itself is slow. The CPU usage is also fairly low. This looks like some buffering issue.</p>
  
  <p>I'm pretty sure that the flow graph itself reacts to button presses instantly, as debugging prints appear the same time as button is pressed/depressed, and square waves appear in the GUI scope sink instantly, as well.</p>
  
  <p>I tried to lower number of HackRF buffers to one (by settings device arguments to <code>hackrf,buffers=1</code>), but it didn't help.</p>
  
  <p>I set "Max Number of Outputs" to 10 for flow graph as well, and it also didn't make a difference (I tried some other values, too). Given that signal appears in the GUI scope much sooner than after 1 second, it shouldn't have worked anyway.</p>
  
  <p>How can I reduce the latency then?</p>
  
  <p><a href="https://i.stack.imgur.com/ZVTQp.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/ZVTQp.png" alt="GNU Radio Companion flow graph"></a></p>
  
  <p><strong>EDIT</strong>: I followed @Manos's suggestion and tried adjusting sample rate.</p>
  
  <p>Adding a rational resampler block with interpolation of 8 (and adjusting sink sample rate accordingly) AND setting <code>hackrf,buffers=1</code> makes latency almost non-existent.</p>
  
  <p>However, reducing output sample rate of my custom block to 500k and having 16x interpolation still causes noticeable lag, maybe 400-500ms (still not as dramatic as when it's 1M at both source and sink). I'm not sure how to fix it. Unfortunately, running my custom block at 1M consumes 100% CPU and causes occasional underflows.</p>