satlinkd's command line and every section of satlinkd.toml, with the shipped values, the defaults, and how to change the configuration on a board.
satlinkd is configured by one TOML file. On the board it is /etc/satlinkd/satlinkd.toml,
installed by the firmware build from stellar-fw/overlay/etc/satlinkd/satlinkd.toml.
The configuration file. Without it, ./satlinkd.toml then /etc/satlinkd/satlinkd.toml are searched
-l, --log-level
SATLINKD_LOG_LEVEL
A log filter (info, debug, satlink_api=debug,info, …). When given, it overrides [observability] log_filter
--dry-run
—
Load and validate the configuration, then exit without starting any service
If the configured filter would silence the daemon's own info messages, the daemon says so on
standard error: a filter string that parses but matches nothing is otherwise indistinguishable
from a quiet daemon.
On the board the daemon is started at boot by /etc/init.d/S99satlinkd {start|stop|restart} and
logs to /var/log/satlinkd.log.
Require a JWT on mutating requests (needs the auth build feature)
auth_secret
—
empty
HS256 secret for those tokens
max_body_bytes
—
20 MiB
Largest request body. Hex payloads double in size, and a transmit request costs about 11× its useful bytes in memory while it is processed. Use /ws/tx for large transfers
Required, no default.true uses an in-memory stub instead of the hardware. It is mandatory on purpose: a board whose configuration lost this key refuses to start rather than serving invented register values
trace_writes
true
Log every PL register write by name
trace_to_kmsg
true
Send those lines to /dev/kmsg, so they reach dmesg and the serial console, and survive in the kernel log when the RAM-disk log file is lost to a freeze
PL registers sampled on every tick by catalogued name; assertable as reg.<name>. Unknown names are reported at startup and dropped. Default: none. See Telemetry and Metrics
Claim the modem's IIO devices at startup. Leave it off on a bench: holding them makes every other tool fail with EBUSY, which looks like a dead modem. The daemon claims them on demand
buffer_length
4096
4096
IIO buffer length in samples; a block is buffer_length × 4 bytes and carries buffer_length useful bytes
Run the AD9361 calibration and interface tuning once at startup. Off because a conditioning from a power-cycled part has taken a board off the network; turn it on only after measuring it on your board
boot_profile
none
The profile whose rate the startup tuning targets
condition_timeout_s
180
Give up on the startup conditioning after this long (the API comes up regardless)