trigger input broken

[mossmann]

What type of issue is this?

permanent - occurring repeatedly

What issue are you facing?

Thomas Roth reported in this presentation that trigger input doesn't work in the latest firmware: https://youtu.be/cFW0sYSo7ZM?t=1360

What are the steps to reproduce this?

https://hackrf.readthedocs.io/en/latest/hardware_triggering.html

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

No response

[alexhude]

Thomas also mentioned that he found older firmware version that works. That might help to narrow down the issue.
cc @stacksmashing

[chaloz]

I can confirm that I'm also not able to trigger start the HackRF with an external trigger pulse. See below my hackrf_info details. I have dropped an email to Thomas, if he could point me out to the latest working firmware. I'll report here if he gets back to me.

[nezza]

Hey there, apologies for not raising this as a ticket sooner and thanks for creating this one - it was quite a busy time and then I forgot 😅

Assuming my notes are correct the version that worked for me was "hackrf-2021.03.1".

Thanks for making such a great tool!

[miek]

I'm having trouble reproducing this, on the latest release it seems to be working correctly for me. I did hit one slight gotcha which is that the trigger input has a pull-up on it, so just jumpering it to 3.3V is not enough to trigger it - it has to be driven low first (which we could document better).

Starting with a jumper from trigger input to ground:

If I run hackrf_transfer -H, then remove the jumper to let the trigger rise to 3.3V, the capture begins:

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

$ hackrf_transfer -H -r /dev/null
call hackrf_set_sample_rate(10000000 Hz/10.000 MHz)
call hackrf_set_hw_sync_mode(1)
call hackrf_set_freq(900000000 Hz/900.000 MHz)
Stop with Ctrl-C
Waiting for trigger...
Waiting for trigger...
 4.5 MiB / 1.000 sec =  4.5 MiB/second, average power -31.4 dBfs
20.2 MiB / 1.000 sec = 20.2 MiB/second, average power -31.4 dBfs
19.9 MiB / 1.000 sec = 19.9 MiB/second, average power -31.4 dBfs
^CCaught signal 2
 3.7 MiB / 0.182 sec = 20.1 MiB/second, average power -31.4 dBfs

Exiting...
Total time: 5.18228 s
hackrf_stop_rx() done
hackrf_close() done
hackrf_exit() done
fclose() done
exit

Could either of you share any more details about the setup to help me reproduce it? Thanks!

[chaloz]

I think I misunderstood the whole concept. I can see that the HackRF starts transmitting somewhere after the trigger event, but I thought it would actually start transmitting within 1 clock cycle of the external trigger, which does not seem to happen.

What I currently see is some 12.5u seconds offset, which seems to be more or less fairly consistent. Is there a way to reduce this offset to 1 clock period?