HackRF One stays in transmit mode when flow graph is terminated

[bradman1972]

Steps to reproduce

1. Execute flow graph in GRC that uses HackRF One as the osmocom sink for transmitting
2. Terminate flow graph using "stop" button in GRC, or alternatively hit red "x" on python window
3. HackRF One remains transmitting until it's reset or USB cable is unplugged

Expected behaviour

That the HackRF One should cease transmitting when the flow graph or python program is terminated.

Actual behaviour

HackRF One keeps transmitting until reset button is pushed or USB cable is unplugged.

Version information

Operating system: Mac OS X 10.11.6 (El Capitan)

hackrf_info output: MacBook-Pro:~ bradman$ hackrf_info
hackrf_info version: unknown
libhackrf version: unknown (0.5)
Found HackRF
Index: 0
Serial number: 0000000000000000909864c8371d9bcf
Board ID Number: 2 (HackRF One)
Firmware Version: 2017.02.1 (API:1.02)
Part ID Number: 0xa000cb3c 0x00644f65

GRC version 3.7.10.1

Output

Generating: '/Users/bradman/wbfm_stereo_transmitter.py'

Executing: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python -u /Users/bradman/wbfm_stereo_transmitter.py

Mac OS; Clang version 8.0.0 (clang-800.0.42.1); Boost_105900; UHD_003.010.001.001-MacPorts-Release

gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.10.1
built-in sink types: uhd hackrf bladerf soapy file 
Using HackRF One with firmware 2017.02.1 
gr::log :INFO: audio source - Audio source arch: osx
gr::log :INFO: audio_osx_source0 - 

Using input audio device 'Built-in Input'.
  ... which is the current default input audio device.
  Changing the default input audio device in the System Preferences will 
  result in changing it here, too (with an internal reconfiguration).

UUU
>>> Done

[dominicgs]

This is at least partly caused by the way that GRC shuts down the flowgraph, so I'm surprised that the stop button and 'X' button both cause this, I was under the impression that it was only one of them.

Nevertheless, we need to fix this, which will likely happen as part of the transceiver rework change #322

[arnt90]

i also get this situation with my HackRF.

also then i try update with >

root@kali:/home/andy# hackrf_spiflash -w hackrf_one_usb.bin
Error opening file hackrf_one_usb.bin

root@kali:/home/andy# hackrf_info
hackrf_info version: unknown
libhackrf version: unknown (0.5)
Found HackRF
Index: 0
Serial number: 0000000000000000909864c8385340cf
Board ID Number: 2 (HackRF One)
Firmware Version: 2015.07.2 (API:1.00)
Part ID Number: 0xa000cb3c 0x006e4753

[dominicgs]

The error opening the file is either because you do hot have permission to access it or you are not in the directory that contains the file.

[K4prc]

Any news on a fix for this? Mine is doing the same thing neither the stop button nor the red x turns the Tx off. I am using the latest firmware.

hackrf_info version: git-3447863
libhackrf version: git-3447863 (0.5)
Found HackRF
Index: 0
Serial number: 0000000000000000a06063c82513735f
Board ID Number: 2 (HackRF One)
Firmware Version: 2018.01.1 (API:1.02)
Part ID Number: 0xa000cb3c 0x006a475e

[bluegizmo83]

I have this issue as well with my hackrf one, running latest firmware. No matter how I stop gnuradio it keeps transmitting.

[jnunezortuno]

Same here. En 6 ago. 2018 2:54, en 2:54, Daniel Brooker <[email protected]> escribió:

…

I have this issue as well with my hackrf one, running latest firmware. No matter how I stop gnuradio it keeps transmitting. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #354 (comment)

[dominicgs]

There is a probable fix for this in the git repository, but not in the released firmware. We hope to get a release out in August or September.

…

On Mon, 6 Aug 2018, 03:40 jnunezortuno, ***@***.***> wrote: Same here. En 6 ago. 2018 2:54, en 2:54, Daniel Brooker ***@***.***> escribió: >I have this issue as well with my hackrf one, running latest firmware. >No matter how I stop gnuradio it keeps transmitting. > >-- >You are receiving this because you are subscribed to this thread. >Reply to this email directly or view it on GitHub: >#354 (comment) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#354 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFmY78FalxptWE_svzD2pVQ3wTeg_bsks5uOA8WgaJpZM4MMK8S> .

[jemussi]

Same here. Also seems to happen with SDRangel whilst attempting Tx. Also numerous other glitches in SDRangel running on Windows 7 but probably several factors there.

[keyboarderror]

I have this issue in GRC for Ubuntu 18.04. It only happens when using QT GUI enabled flow graphs. WX or no GUI shut down normally. I was wondering if it was an issue with QT.

[bluegizmo83]

I think I heard somewhere that a fix for this issue is already in the latest firmware code here on github, but you have to compile the firmware from the source here on github and update, as there hasn't been a compiled release firmware since January 2018. I haven't gotten around to doing this myself yet, so I can't verify this is true.

[keyboarderror]

Thanks for the hint. I've managed to compile and install Firmware Version: git-509c8f4 (API:1.03) as of 6/12/19 and there's no change on the flow graph problem.

[mossmann]

I have this issue in GRC for Ubuntu 18.04. It only happens when using QT GUI enabled flow graphs. WX or no GUI shut down normally. I was wondering if it was an issue with QT.

I can reproduce these results both for RX and TX. I suspect a GNU Radio bug.

[Frohrer]

Calling hackrf_info in CLI terminates the transmission after flow-graph has been terminated. Otherwise it keeps transmitting. Firmware Version: 2018.01.1 (API:1.02)

[bluegizmo83]

I created a work-around solution to this GRC TX issues. Its rather simple to use.

As @Frohrer posted above, when the HackRF is stuck in TX mode after terminating a flow-graph, you can simply call hackrf_info and it will reset the stuck TX issue!

So, with that in mind, I created a very simple python script that you can load in a Python Module block in GRC that automatically calls hackrf_info when the flow-graph is terminated. This was written with Windows users in mind, so it will probably need some tweaking for Linux use.

Below is the python code to input into the Python Module block, just modify the file location for your hackrf_info file:

import atexit
import subprocess

def exitnow():
    # Enter your hackrf_info.exe file location below.
    # Be sure to use double backslashes between folders and double quotes at the begining and end.
    hackrf_info_location = '"C:\\SDR Tools\\GNUradio 3.7\\bin\\hackrf_info.exe"'

    # You can adjust the timeout period below. A small timeout is required, otherwise hackrf_info will try
    # to run while the flowgraph is still shutting down, causing the process to fail with an Access denied error.
    timeout_in_seconds = '1'
    
    cmd_to_run = 'timeout ' + timeout_in_seconds + ' > null && ' + hackrf_info_location + ' > null'
    process = subprocess.Popen(cmd_to_run, shell=True)
    print('\n' + '\n' + '.....     WAITING ' + timeout_in_seconds + ' SECONDS TO FORCE STOP TX     .....' + '\n')
    
atexit.register(exitnow)

[NoraCodes]

An equivalent block for Unices:

import atexit
import subprocess
from gnuradio import gr


class blk(gr.basic_block):  # other base classes are basic_block, decim_block, interp_block
    """Runs hackrf_info to force the hackrf to cease transmission at exit."""

    def __init__(self):  # only default arguments here
        """arguments to this function show up as parameters in GRC"""
        gr.basic_block.__init__(
            self,
            name='Exit HackRF at Exit',   # will show up in GRC
            in_sig=[],
            out_sig=[]
        )
        atexit.register(exitnow)

def exitnow():
    cmd_to_run = "sleep 2 && hackrf_info"
    process = subprocess.Popen(cmd_to_run, shell=True)
    print("\n\nForce exiting hackrf txmode")

Doesn't work from the X in GNURadio

[uhexafluoride]

I was having this same problem with my hackrf using Kali Linux 2020.1, GNUradio 3.8.1 and I found a solution.
looking at the symbolic link "/usr/bin/python" I noticed it was linked to "python2.7"
I simply erased /usr/bin/python and then a "ln -s /usr/bin/python3.7 /usr/bin/python" fixed the problem. I hope this helps..

Chris Graves

[rjbergTU]

I was having this same problem with my hackrf using Kali Linux 2020.1, GNUradio 3.8.1 and I found a solution.
looking at the symbolic link "/usr/bin/python" I noticed it was linked to "python2.7"
I simply erased /usr/bin/python and then a "ln -s /usr/bin/python3.7 /usr/bin/python" fixed the problem. I hope this helps..

Chris Graves

I would use "ls -s /usr/bin/python3 /usr/bin/python" instead, as python3.7 may be changed to python 3.8 or higher, leaving the link to python 3.7 useless.

[JSubby]

Hi all! I am trying to get the 'Hello World' GRC (just tuning in FM radio stations) operational with my HackRF One and am having similar issues and am wondering if anyone here has suggestions. The issue I suspect is similar, but instead of getting struck while transmitting, I am trying to receive only. I have had no luck calling hackrf_info from the command line interface or with redefining the symbolic link as discussed above. Some details:

1. Running Ubuntu 20.04

2. Output of hackrf_info before I start GRC or andy flow graphs:
   hackrf_info version: unknown
   libhackrf version: unknown (0.5)
   Found HackRF
   Index: 0
   Serial number: 000000000000000075b068dc306e3907
   Board ID Number: 2 (HackRF One)
   Firmware Version: 2018.01.1 (API:1.02)
   Part ID Number: 0xa000cb3c 0x00614f5c

3. Running GRC version 3.8.1.0 (Python 3.8.2). The GRC flow graph consists only of an osmocom Source connected to a QT GUI Frequency Sink - the first step of the 'Hello World' GRC.

4. When I start the GRC for the first time, the Rx LED on the HackRF One lights up and the flow graph works as expected. I am able to stop the flowgraph with the 'Kill the flow graph' button, and the Rx LED goes out on the HackRF One unit. I am also able to run hackrf_info from the command line and get the same output as above.

5. When I restart the GRC flow graph a second time, without any changes, the Rx LED on the HackRF One again lights up (as expected), BUT I get no data plotted in flow graph (just a blank plot). And now
   a) I cannot kill the flow graph at all from GRC.
   b) The Rx LED remains ON
   c) The output of the hackrf_info command indicates the resource is busy:
   hackrf_info version: unknown
   libhackrf version: unknown (0.5)
   Found HackRF
   Index: 0
   Serial number: 000000000000000075b068dc306e3907
   hackrf_open() failed: Resource busy (-1000)

6. Even after running the hackrf_info command, the GRC flow graph is still stuck. Eventually I get and error message in GRC that the flow graph is not responding and use 'Force Quit' to kill the flow graph, which stops with a 'Done (return code -9) message. However, now the HackRF One unit's Rx LED goes out and things return to nominal, but I still cannot successfully run the flow graph a second time.

7. The only way I can successfully run the flow graph again is to do a hard reset on the hardware. Then again, I can only run the flow graph once before things lock up. The one GOOD think about all of this is that it is REPEATABLE!

Unlike what Frohrer saw, running hackrf_info does not solve the problem. I don't know if it is a HackRF One firmware issue, a GRC issue, or possible a USB connection issue (though it does not seem like the latter). Any suggestions?? I am willing to experiment, but keep in mind that I am an RF electronics (hardware) engineer, and not (much of a) Linux guy or a programmer, so you may need to walk me through the steps.

[stackprogramer]

i had same problem hackrf one can not free from receiving, problem is not solved yet?

[bluegizmo83]

i had same problem hackrf one can not free from receiving, problem is not solved yet?

I heard that this issue is supposed to be fixed now in this GitHub firmware, it was fix about a year ago supposedly, but the author has not released a compiled version of the firmware since January 2018 so you'd have to compile the firmware image from source to test it. I never bothered do that myself so I can't say for sure if it's fixed or not.

[keyboarderror]

I can confirm the problem is fixed in 3.8 at least with self-compiled firmware. Didn't realise that was a requirement!

[mossmann]

I believe that most of these issues were likely caused by a bug in gr-osmosdr that has since been fixed. If you still have a similar problem, please open a new issue with information about how to reproduce the problem. Thanks, everyone!