search

jopohl / urh

Universal Radio Hacker: Investigate Wireless Protocols Like A Boss
GNU General Public License v3.0
10.6k stars 857 forks source link

Timing issues while sending data over gnuradio backend #426

Closed reald closed 5 years ago

reald commented 6 years ago

Expected Behavior

A received signal is played back at the same speed as recorded.

Actual Behavior

Using gnuradio backend a signal is played back between 2-3 times too slow.

Steps to Reproduce the Problem

  1. Record a signal with hackrf
  2. Play it back using hackrf and native backend. => Everything works
  3. Play it back using hackrf and gnuradio backend. => Signal is played back much too slow.

Same behaviour for the signal generator.

The gnuradio send script seems to be opened correctly:

/usr/bin/python2 /usr/local/lib/python3.5/dist-packages/urh-2.0.1-py3.5-linux-x86_64.egg/urh/dev/gr/scripts/hackrf_send.py --samplerate 2000000.0 --freq 433920000.0 --gain 0 --bandwidth 2000000.0 --port 40769 --if-gain 23 --baseband-gain 20

If you feed raw data (e.g. using ZMQ PUSH Sink in gnuradio companion) to the open port it works correctly.

Platform Specifications

jopohl commented 6 years ago

Do you have a specific reason to use the GR backend over the native backend? Native backend is recommended, because performance is best with it as you noticed.

Some background on this: The GR backend uses threads so the GIL strikes at full force here while the native backend works with processes.

reald commented 6 years ago

The reason for GR backend is that I was able to add PlutoSDR support easily. But transmitting does not work due to this timing problem. I found out that for a hackrf the behavior is the same if it is switched to GR backend. So I guess a bug somewhere in the GR backend control. I´m not a python expert and I was not able to solve it by myself. Even if the performance is lower at least it should work. Cpuload does not reach any limits.

jopohl commented 6 years ago

Ah I see, thanks for your effort to get PlutoSDR to work!

I just tested the Gnuradio backend with a HackRF and it is indeed slower than the native one, but I was able to switch a wireless socket anyway. Improving the performance of GR backend would require significant effort as a large part of the backend would need to be rewritten.

I think it would be better to add native support for PlutoSDR to solve this problem. I cannot get my hands on such a device so I would happily accept a PR for it. I can also give you some support in adding native support if needed.

jopohl commented 5 years ago

There was no feedback on this issue for some months now. I will close here. Just drop a comment if you feel, it should be reopened.