`tx.sh`¶

Lives on: the Hackerman Pi, at ~/hackrf_project/tx.sh. Source in this repo under hackerman/.

What it does¶

Transmits the test tone in signal.iq (written by generate_signal.py) at a power you choose, with the HackRF's amplifier always off, and logs every start and stop. It replaces start_tx.sh for short-range testing, where full power is far too strong.

#!/usr/bin/env bash
# tx.sh <gain 0-47>  — transmit signal.iq at 915.0 MHz (tone at 915.1), amp OFF
GAIN=${1:-30}
cd "$(dirname "$0")"
echo "$(date +%T) TX start, -x $GAIN, amp off" | tee -a tx_log.txt
hackrf_transfer -t signal.iq -f 915000000 -s 2000000 -x "$GAIN" -a 0 -R
echo "$(date +%T) TX stop" | tee -a tx_log.txt

Walkthrough¶

GAIN=${1:-30}: the first argument is the TX gain (0–47 dB). With no argument it uses 30.
cd "$(dirname "$0")": runs from the script's own folder, so it finds signal.iq no matter where you start it from.
hackrf_transfer ... -x "$GAIN" -a 0 -R: the same command as start_tx.sh, except the gain comes from the argument and -a 0 turns the amplifier off. -R loops the file until you press Ctrl+C.
tx_log.txt: every start (with its gain) and stop is timestamped, so during a test each logged bearing can be matched to the power that was being sent.

The tone sits 100 kHz above the 915.0 MHz center, so the Kraken must be tuned to 915.1 MHz.

Which gain to use¶

From the 16 Oct indoor test, HackRF about 3 m from the array (Kraken noise floor ≈ −64 dB):

Command	RSSI at the Kraken	Result
`tx.sh 0`	≈ −64 dB	lost in the noise
`tx.sh 20`	≈ −63 dB	barely detectable
`tx.sh 30`	≈ −60 to −62 dB	usable
`tx.sh 40`	≈ −52 to −56 dB	good, steady bearing
`start_tx.sh` (gain 40 + amp)	≈ −22 to −36 dB	too strong: bearings scatter

For the anechoic chamber the target is about −45 to −55 dB. Indoors in the lab, reflections off the walls make bearings unreliable at any power, which is why accuracy testing moved to the chamber.

Running it¶

Run it inside tmux so the transmitter keeps going if the SSH connection drops:

tmux new -s tx                 # or: tmux attach -t tx
~/hackrf_project/tx.sh 30

Change power with Ctrl+C and run it again with a new number. Detach with Ctrl+B, then D.

Background transmit: `tx_bg.sh`, and control from the Pi 5: `hackrf.sh`¶

Added for the 20 Oct chamber test. tx_bg.sh (on Hackerman, next to tx.sh) runs the same transmit in the background, so it keeps going if the SSH connection drops, without needing tmux:

~/hackrf_project/tx_bg.sh 40       # start (or restart) at gain 40
~/hackrf_project/tx_bg.sh status   # "TX running, gain 40" or "TX not running"
~/hackrf_project/tx_bg.sh stop

The key line detaches the transmitter from the terminal completely, so closing the session can't stop it:

setsid nohup hackrf_transfer -t signal.iq -f 915000000 -s 2000000 -x "$GAIN" -a 0 -R \
  > tx_bg.out 2>&1 < /dev/null &

Starting it again with a new gain stops the old transmit first (pkill -x hackrf_transfer), so there's never more than one running. Starts and stops go in tx_log.txt.

hackrf.sh (on the follower Pi 5, in ~/capstone/rfdf/) runs tx_bg.sh on Hackerman over SSH, so the transmitter can be driven from the chamber test screen:

ssh -o ConnectTimeout=5 -o BatchMode=yes <user>@<hackerman> "~/hackrf_project/tx_bg.sh $*" \
  || echo "Can't reach Hackerman. If it was already transmitting, it still is."

It takes the same arguments (hackrf.sh 40, hackrf.sh status, hackrf.sh stop) and needs a one-time passwordless SSH setup from the Pi 5 to Hackerman. On 20 Oct the Ethernet didn't reach the chamber edge, so the background mode was used directly on Hackerman instead; it kept the transmitter running with no connection at all.

tx.sh¶