Section 13 configuration files

13. Configuration files

sdroxide stores its settings under the per-user config directory:

Platform	Location
Linux	~/.config/sdroxide-brown/
macOS	~/Library/Application Support/org.sdroxide.sdroxide-brown/
Windows	%APPDATA%\sdroxide\sdroxide\config-brown\

This build keeps its own directory. SDR Oxide Brown uses a …-brown directory beside upstream sdroxide's, so the two builds never read or write each other's settings — run both and nothing is disturbed, and settings the two do not share (the 11 m and listening ones) cannot be dropped by the other build rewriting a file. Your existing settings are moved across automatically the first time this build starts after the change: their contents are copied into the …-brown directory, the original is left exactly where it was, and the old build keeps working. You should not have to do anything.

Moving settings to another installation

You do not have to know any of that to copy a station's setup somewhere else. Settings → General → Settings file has EXPORT…, which writes every settings file below — the root ones and each radio's — into a single sdroxide-settings.json, and IMPORT…, which puts one back. Between two machines, two user accounts on one machine, or a laptop being rebuilt, that is the whole job.

The files travel exactly as they are on the disk, so a bundle written by a newer sdroxide does not lose settings this one has never heard of. An import replaces what is here file for file and leaves anything the bundle does not mention alone — so a bundle from a one-radio station will not remove a second radio's configuration here — and it takes effect the next time sdroxide starts, because the settings already in memory would otherwise be written straight back over it.

Two things are deliberately not in the file, and both because they are not settings:

• Your logbook (qso_log.json). Two callsigns sharing a setup usually want their contacts kept apart, and a log that really is to be moved should go as ADIF from the LOG window, which every other program reads too.
• A saved server sign-in (remote_login.json), which holds a password for a server this machine connects to. A settings file is something people send each other.

Both buttons are on the machine the radio is attached to: a remote or browser client says so instead, because the settings it could reach are its own screen's and not the station's.

File	Format	Contents
config.toml	TOML	General settings: device_args, sample_rate, cal_offset_db, spectrum_fft, spectrum_fps, server_bind, server_port, tx_ham_only, swr_guard and swr_limit (the SWR guard, §6.1), audio_output, audio_input, region ("R1" / "R2" / "R3" — the IARU region every band plan follows, §6.1), cb_plan ("World" / "Cept" / "Germany80" / "Uk27_81" / "Us" / "Australia" — the CB channel plan, §6.1), cb_tx_allowed (true only after the 11 m transmit opt-in is confirmed, §6.1), plus the [ui] display preferences (including theme, button_style and window_style), the [speech] announcement settings (§6.3), the [remote_access] sign-in that server mode demands (§8.3, stored in plaintext) and the [remote_server] address the General tab dials (§8.2). Belongs to the machine the engine runs on — except [ui], [speech] and [remote_server], which belong to the screen in front of you.
radio.json	JSON	Which radio interface is selected and everything that configures it — the CAT/HPSDR/TCI/SmartSDR/RTL-SDR/rtl_tcp/SpyServer/RX-888/Airspy HF+/SDRplay/PlutoSDR sections, the converter offset and stated tuning ranges, and the radio's sound-card device names.
digi.json	JSON	Digital-mode operator settings: your callsign and grid, FT8/FT4/FT2 TX period, auto-sequence and message templates, the transmit-frequency hold (hold_tx_freq) and the per-band transmit offsets it pins (tx_audio_hz), the per-mode transmit-audio levels (tx_audio_levels, with tx_audio_level_fm / tx_audio_level_ssb as the level a mode with no entry of its own inherits), and the WSPR beacon's duty cycle, power and band-hop list.
memories.json	JSON	Saved memory channels.
bandstacks.json	JSON	Per-band memory of your last frequency/mode/filter (up to three per band).
profiles.json	JSON	The saved station setups from Settings → Profiles (6.12): each one's name, the remembered radio state (the same fields as session.json), the digital-mode settings and the band stacks. Shared by every radio of the station.
bandplan.json	JSON	The band plan itself, per IARU region: band edges, the CW/data/phone/beacon/all-modes sub-segments, and the PSK and RTTY skimmer windows — all in MHz. Written from the built-in IARU tables on first start and meant to be edited; narrow a band here and the transmit lockout narrows with it. Which region applies is region in config.toml. RELOAD BAND PLAN on the General tab applies an edit without a restart, and deleting the file restores the defaults. See §6.1.
digi_presets.json	JSON	The frequencies you have added to the digital modes' own lists yourself, as mode / dial_hz / note — written by the ＋ Save button in the ⇵ picker (§3.1) and readable and editable by hand, which is where a note comes from. Belongs to the station, so every radio and every remote client offers the same list. Absent until you save one.
session.json	JSON	Where you left the radio: both VFO dials and which of the two was selected, the mode, the RX/TX antenna ports, the AF volume, RX gain, AGC mode, squelch and noise reduction, the TX drive/tune drive/mic gain, and the front end's own gain stages (the sliders on the Radio tab's device panel), restored the next time you start. Written by the engine as you tune, so --freq, --mode, --antenna and --tx-antenna override it for a run without changing it. Gain stages are remembered by name: one your current front end does not have is kept, not thrown away, so switching back to the radio it belongs to brings it back, and a figure past what this device offers is clamped to its range.
qso_log.json	JSON	The logbook (digital and manual QSOs, with contest/QSL fields).
net.json	JSON	Network cockpit: DX cluster / POTA / SOTA / PSK / FreeDV Reporter / WSPRnet feed settings, and callsign-lookup / eQSL / QRZ / HamQTH / Club Log / LoTW credentials (stored in plaintext).
winlink/	directory	The Winlink mailbox: inbox/, outbox/, sent/ and archive/, one .b2f file per message holding it exactly as it rides the wire (§11). The account settings live in net.json, password included, in plaintext.
tciserver.json	JSON	Built-in TCI server: enabled, bind address, port, advertised device name, whether clients may transmit, and the client limit.
rigctld.json	JSON	Built-in Hamlib rigctld server: enabled, bind address, port, reported rig name, whether clients may transmit, and the client limit.
wsjtx.json	JSON	WSJT-X UDP broadcast: enabled, destination host and port, and the name clients see.
scanner.json	JSON	The scanner: memories or a range, the range and channel step, the level that counts as busy, the dwell, how it resumes, and which memories to skip.
renderer-fallback.txt	text	Written only when a panic came from the graphics driver: the next start renders through OpenGL and says so. Delete it to go back to the default renderer (14).
skimmer.json	JSON	Skimmers: which of CW / PSK / RTTY run, and each one's spot squelch in dB. Restored at startup; a narrowband (audio-mode) radio still forces them off without disturbing what you picked.
adsb.json	JSON	ADS-B decoder (§3.13): the two timeouts, how many history dots to keep, how far ahead the speed vectors reach, and the ceiling on the aircraft table. Restored at startup, and — like ism.json — a receiver that cannot feed the decoder forces it off without disturbing what you picked.
vdl2.json	JSON	VDL2 decoder (§3.15): which of the fourteen channels to listen on, the burst threshold in dB, how much log and how many stations to keep, and how long a silent station stays on the list. Restored at startup, and — like adsb.json — a receiver that cannot feed the decoder forces it off without disturbing what you picked.
ais.json	JSON	AIS decoder (§3.16): which of the two channels to listen on, the slot threshold in dB, the two timeouts, how many minutes of trail to keep, how far ahead the vectors reach, and the ceiling on the vessel table. Restored at startup, and — like adsb.json — a receiver that cannot feed the decoder forces it off without disturbing what you picked.
ism.json	JSON	ISM decoder: whether it runs, which device families it listens for, the burst threshold in dB, and whether the rtl_433 decoders are on, which band they watch and how wide a window they get. Restored at startup, and — like skimmer.json — a narrowband (audio-mode) radio forces it off without disturbing what you picked.
rtl433_flex.conf	text	Your own ISM decoders, in rtl_433's "flex" syntax (§5.5). Written with a commented example the first time the ISM decoder runs, and never rewritten afterwards — like bandplan.json, it is yours to edit. A specification that does not pass its check is listed in the ISM window and skipped; the rest still load. RELOAD DECODERS in the ISM window applies an edit without a restart.
input.json	JSON	Control inputs: keyboard bindings, panadapter mouse behaviour, mouse-button bindings, and the MIDI controller mapping. Belongs to the machine running the user interface, not the engine.
remote_login.json	JSON	A sign-in to somebody else's server that you asked this client to remember (§8.3). Written only when the Remember on this device box is ticked, holds the password in plaintext, and deleted when you untick it or the server refuses it. Belongs to the user interface, like input.json; the browser client keeps the same thing in local storage instead.
satellites.json	JSON	Satellite additions for the 3D tracker: subscribed element-set listings, element sets pasted in by hand, and frequency entries that override the built-in table. Belongs to the engine, like net.json: the listings are fetched and cached where the radio is, so remote and browser clients track the same satellites.
relay.json	JSON	The station's external transmit/receive switch (§6.11): which relay board or contact closure, the contact table, the sequencer's lead and hold times, what to do if it stops answering, and the transmit sense input. Belongs to the engine — the relay is bolted to the antenna — so remote and browser clients set up the real one.
broadcast_stations.json	JSON	Your own broadcast stations and corrections, merged over the downloaded schedule (§10.6). Never written by sdroxide, and absent until you create it.
broadcast/	CSV	The broadcasting season's schedule as downloaded from eibispace.de, one file per season. Managed by sdroxide: refetched when the season changes, and safe to delete.
sstv_messages.json	JSON	The overlay message stored for each of the five SSTV transmit slots.
voice_names.json	JSON	The label given to each of the ten voice-keyer slots.
voice/	dir	The voice-keyer recordings (slot1.wav…slot10.wav), 48 kHz mono. Drop your own WAV in to replace a message.
speech_voices/	dir	Extra voices for the spoken announcements: a Piper .onnx model and its .onnx.json config, side by side. Absent until you create it — the shipped voice lives with the program, not here. Note this is not voice/, which is the voice keyer.
sstv_tx/	dir	The five SSTV transmit-image slots (slot0.png…slot4.png).
sstv_rx/	dir	Received SSTV and RIFP pictures, kept for the gallery.
wefax_rx/	dir	Weather-fax charts received by an earlier version. Charts now go to ~/Pictures/sdroxide/wefax/, but this is still read so an existing collection stays in the gallery.
solar/	dir	Cached solar imagery, space-weather JSON and subscribed element-set listings for the 3D view, with an index of HTTP validators so refreshes stay cheap. Safe to delete; it is re-fetched on demand.
radios.json	JSON	The roster of configured radios (§2.17): each radio's id, the name you gave it (empty = named after its interface) and whether it is switched on (enabled, absent = on). Absent until you add a second radio. Written by the GUI, and — on a machine running --server — by a signed-in remote client adding or closing a radio (§8.1).
radio-<N>/	dir	An additional radio's own copies of the files that describe a radio: radio.json, session.json, scanner.json, tciserver.json, rigctld.json and wsjtx.json. The first radio keeps those files at the root, exactly where a single-radio installation has always had them, so adding and removing other radios never touches it. Kept on disk when the radio is closed.

Every file has sensible defaults, so a missing or partial file always loads. You normally edit these through the GUI rather than by hand.

---

From the User Manual. Home.