The device stop work after repeat receive and stop operation.

[commthu]

Steps to reproduce
My software use "hackrf_start_rx" for 10 seconds and then stop,

result = hackrf_stop_rx(device);
result = hackrf_close(device);
hackrf_exit();

after 5 seconds, then repeat hackrf_start_rx to receive for 10 seconds and stop recieve, after 5 second,.....,and so on

Expected behaviour

Tell us what you expect should happen

Actual behaviour

Tell us what happens instead

after serveral minutes (3 minutes for example), the device is dead, restart my software does not work. I should re-connect the USB plug.

Version information

git-2dffba9

Operating system:

Win7-64-ultimate, also tried other windows systems, same problem

hackrf_info output:

If you are reporting a problem that involves third party software
(GNU Radio, Gqrx, etc), please report the version here.

Output

Insert any commandline or build output here

[dominicgs]

This is a known issue and is related to issue #322

[barto-]

@commthu As a temporary workaround you could use use the LPC43xx watchdog timer to reset the
hackrf when it's stuck. More info about the watchdog timer in the LPC43xx user manual, pages 1102-1109.
You will need to handle the reset in your application code (reopen the device after a reset).
@dominicgs Maybe it's possible to implement this logic in the firmware / libhackrf?

[dominicgs]

@barto- I added the reset feature in January, if should be available to anyone running the 2017.02.1 release as well as anyone using the latest git code.

(b047dd0)

[barto-]

@dominicgs When the hackrf is stuck you cannot send USB requests

[dominicgs]

@barto- I thought this issue was with the transceiver state being incorrect and not transferring data to the host. I thought the HackRF is still responding to USB control requests in this state. Is that not the case?

[barto-]

When it's stuck it doesn't respond to USB requests. The main loop in hackrf_usb.c it's not executed

[JoshuaKast]

I am adding here to note that I have a similar issue with the HackRF One.

Specifically, I have been using the "hackrf_transfer" program, to receive data from the device. What happens is this:

When I initially connect the device, and pull data using hackrf_transfer, I get a very strange IQ plot (output file is postprocessed in a Fortran program I wrote, and plotted in Gnuplot). The input signal to the device is BPSK signal generated by another SDR.

If I try again to run hackrf_transfer, I get this. Very low values of IQ, as if the receiver is not working.

However, if I use the HackRF as a source in Gnuradio (receiving using "osmocom source"), stop the flowgraph, and go back to using in hackrf_transfer, I get something that I would expect:

The issue is not just with hackrf_transfer. When I first run the Gnuradio flowgraph (simply dumping receive data to a file), I get something similar to the second plot above, a very meaningless IQ plot:

However, this IQ data seems to contain the correct spectral data, as seen by a fourier transform:

Running the Gnuradio flowgraph again gives correct IQ output.

As far as I can tell, repeated runs of the Gnuradio do not run into problems. Only repeated runs of hackrf_transfer. Running the Gnuradio flowgraph seems to "reset" the problem, and all works again until I run hackrf_transfer.

Here's my hackrf info:

hackrf_info version: 2017.02.1
libhackrf version: 2017.02.1 (0.5)
Found HackRF
Index: 0
Serial number: 0000000000000000a06063c82487755f
Board ID Number: 2 (HackRF One)
Firmware Version: 2018.01.1 (API:1.02)
Part ID Number: 0xa000cb3c 0x00704362

And the command I run:
hackrf_transfer -f 5800000000 -s 2000000 -n 1000000 -r outfile

[straithe]

We've recently done a release which includes some enhances and fixes to hackrf_sweep. Can you please try updating to the latest release to see if that fixes your issue?

[straithe]

I'm going to close this as there hasn't been a response in a while, but please re-open this issue or open a new one if you still need assistance.

[AlexFWulff]

I think that this is still a problem on the most recent release (2021.03.1). I wrote a C program that can reproduce an error where, after a few repeated start rx/stop rx calls in quick succession, the TX light stays on and the rx callback is never triggered.

Here is my hackrf_info output (platform is RPi 3 raspbian):

hackrf_info version: 2021.03.1
libhackrf version: unknown (0.5)
Found HackRF
Index: 0
Serial number: 0000000000000000088869dc24397f1b
Board ID Number: 2 (HackRF One)
Firmware Version: 2021.03.1 (API:1.04)
Part ID Number: 0xa000cb3c 0x0041474f

libhackrf is not installed globally - instead I'm manually linking in the compiled libhackrf 2021.03.1 binary.

Check out this gist for the program I'm using.

Below is the expected output. The rx should start, maybe get a few cycles before the callback isn't called, and then should restart again indefinitely.

Start
Not started yet
Valid length: 262144
Valid length: 262144
Valid length: 262144
Finally started
Start
Not started yet
Valid length: 262144
Valid length: 262144
Finally started
Start
Valid length: 262144
....

Below is the output I get after letting the program run for about 10 seconds (sometimes more, sometimes less). Eventually, the callback is never triggered and the program gets stuck on "Not started yet" forever.

Finally started
Start
Not started yet
Valid length: 262144
Valid length: 262144
Valid length: 262144
Valid length: 262144
Valid length: 262144
... [repeats a few times]
Finally started
Start
Not started yet
Not started yet
Not started yet
Not started yet
Not started yet
... [continues forever]

Is there a way to fix this to allow for start_rx and stop_rx to be called in quick succession?