Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hackrf_transfer: First TX/RX after USB connection / reset does not contain any signal #1438

Open
5830ification opened this issue Apr 5, 2024 · 1 comment
Labels

Comments

@5830ification
Copy link

What type of issue is this?

permanent - occurring repeatedly

What issue are you facing?

While using hackrf_transfer I have noticed, that both TX as well as RX with hackrf_transfer do not contain any signal on the first run after connecting the HackRF to USB or performing a reset using the reset button. All subsequent runs of hackrf_transfer are fine, however as soon as the device is reset or reconnected, the first run will not contain any signal again.
I have witnessed this issue with multiple rev9 units, I currently only have access to a single one for testing. I can reproduce the issue on Windows 10, macOS 14.4.1 and Ubuntu.
All tested units are outfitted with a TCXO.

For RX I generated a 200 MHz CW at -30 dBm and fed it to the input of the HackRF.
I generate my first recording rec1.bin using
hackrf_transfer -p 0 -a 0 -x 0 -B -s 6e6 -f 199e6 -n 65536 -r rec1.bin
Output:

call hackrf_set_sample_rate(6000000 Hz/6.000 MHz)
call hackrf_set_hw_sync_mode(0)
call hackrf_set_freq(199000000 Hz/199.000 MHz)
call hackrf_set_amp_enable(0)
call hackrf_set_antenna_enable(0)
samples_to_xfer 65536/0Mio
Stop with Ctrl-C
 0.3 MiB / 0.023 sec = 11.3 MiB/second, average power -25.4 dBfs, 11040 bytes free in buffer, 0 overruns, longest 0 bytes

Exiting...
Total time: 0.02344 s
hackrf_stop_rx() done
Transfer statistics:
278912 bytes transferred by M0
262144 bytes transferred by M4
0 overruns, longest 0 bytes
hackrf_close() done
hackrf_exit() done
fclose() done
exit

Second recording generated without any changes to the setup using
hackrf_transfer -p 0 -a 0 -x 0 -B -s 6e6 -f 199e6 -n 65536 -r rec2.bin
Output:

call hackrf_set_sample_rate(6000000 Hz/6.000 MHz)
call hackrf_set_hw_sync_mode(0)
call hackrf_set_freq(199000000 Hz/199.000 MHz)
call hackrf_set_amp_enable(0)
call hackrf_set_antenna_enable(0)
samples_to_xfer 65536/0Mio
Stop with Ctrl-C
 0.3 MiB / 0.022 sec = 11.9 MiB/second, average power -17.4 dBfs, 10432 bytes free in buffer, 0 overruns, longest 0 bytes

Exiting...
Total time: 0.02232 s
hackrf_stop_rx() done
Transfer statistics:
278880 bytes transferred by M0
262144 bytes transferred by M4
0 overruns, longest 0 bytes
hackrf_close() done
hackrf_exit() done
fclose() done
exit

Notice that the second invocation reports much higher average power.
Here are the PSDs of the first and second recording respectively (note differently scaled y-axis):
psd1
psd2

Clearly, the CW is missing in the first recording but present in the second. The issue can also be reproduced for longer recordings.
Output of hackrf_info:

hackrf_info version: git-18b485e3
libhackrf version: git-18b485e3 (0.9)
Found HackRF
Index: 0
Serial number: 0000000000000000675c62dc316666cf
Board ID Number: 4 (HackRF One)
Firmware Version: 2024.02.1 (API:1.08)
Part ID Number: 0xa000cb3c 0x00614f5b
Hardware Revision: r9
Hardware appears to have been manufactured by Great Scott Gadgets.
Hardware supported by installed firmware:
    HackRF One

I also tested FW version 2023.01.1 and witnessed the same effect. As far as I am aware I can not test any earlier revisions as 2023.01.1 is the earliest supported version for HW rev9.

An identical issue can be observed for TX, here I verified using a spectrum analyzer, that no output signal can be observed on the first run, while the expected output signal is present on subsequent runs.

What are the steps to reproduce this?

RX: Apply a signal to the RF input. Connect the HackRF via USB. Run a recording using hackrf_transfer with parameters suitable for the choice of signal. Observe that the signal is not present in the recording. Rerun the same recording command. Observe that the signal is now present in the file as expected.

TX: Same as RX, choose a file to replay, observe that on the first run of hackrf_transfer the signal is not actually visible on the RF output of the HackRF, while it is present on subsequent runs.

To trigger the "missing" first run either unplug and reconnect the USB-cable or simply press the Reset button on the HackRF.

Can you provide any logs? (output, errors, etc.)

No response

@gavenkoa
Copy link

I experience the same issue, using HackTV, linked to libhackrf. After initial USB plugging first command produces nothing visible by spectral analyzer, restarting the command fixes the issue:

hacktv -f 535250000 -g 30 -s 16000000 -r test -m ntsc-i

Windows 10, Mingw64/MSYS2 build of libhackrf + HackTV. See steps: https://github.com/gavenkoa/tv-result/blob/master/hacktv-mingw64-pacman/README.md

@martinling martinling added the bug label Apr 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants