You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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):
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
The text was updated successfully, but these errors were encountered:
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:
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:
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:
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):
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:
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
The text was updated successfully, but these errors were encountered: