Jean-Pierre MartineauandClaude Opus 5.5
a4619aa17d
docs/ was one flat folder: the user guides, the CLI manual, the device manuals, the code notes and an old survey side by side. It is now guide/ (features, configuration, connecting, terminals), cli/ (the manual as its README, the cookbook), devices/ (which manual is yours as its README, then one per device) and development/ (architecture, the survey); screenshots/ stays put. The index follows the folders. The device manuals are named for the device they are about: the PicoCalc's is picocalc-lyra.md, since MeshTerm runs on the PicoCalc's Luckfox Lyra core and on none of the others, and the uConsole's stays uconsole.md, since its CM4 and CM5 run it alike. A new cardputer-zero.md opens on a warning that the device is not supported yet, says what has been built and tested only in the simulator, and how to try it there. Every relative link was resolved from where it was written and rewritten from where it now lives, and the repo-root spellings in code, config and the release skill moved with them; the changelog's GitHub URLs too. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
92 lines
4.1 KiB
TOML
92 lines
4.1 KiB
TOML
# MeshTerm configuration: where things live, and which device to talk to.
|
|
# Copy to ~/.meshterm/config.toml (or pass --db / --port on the CLI).
|
|
#
|
|
# How MeshTerm itself behaves — transmit cooldown, message retries, how much history it
|
|
# keeps — is *not* here. Those are preferences: they live in ~/.meshterm/preferences.toml,
|
|
# and are edited on the Preferences page (or with `meshterm preferences set <key> <value>`).
|
|
# Every one has a built-in default, so that file only ever lists what you have changed.
|
|
#
|
|
# Profiles are optional. With no profile, no --port/--ble/--tcp, MeshTerm discovers attached
|
|
# serial devices and nearby Bluetooth companions, lets you pick one (interactively) or uses the
|
|
# single one present, and remembers the last device that connected as the default for next time.
|
|
# A network (TCP) companion isn't discoverable — name it with --tcp host:port, a TCP profile, or
|
|
# the picker's "add a network device" prompt. Define profiles below only to give your hardware
|
|
# stable aliases (e.g. --profile yagi, --profile handheld for Bluetooth, --profile wifi for TCP).
|
|
|
|
# Uncomment and name one of your own profiles below to make it the default. Left
|
|
# commented, MeshTerm finds the device itself, as described above.
|
|
# default_profile = "s3"
|
|
|
|
# Open the radio link as soon as the menu appears. False opens it lazily instead — only
|
|
# once monitoring is turned on or a tool first needs the radio.
|
|
connect_on_start = true
|
|
# db_path = "C:/Users/you/meshterm/meshterm.db"
|
|
|
|
# One [profiles.<name>] block per physical companion device.
|
|
[profiles.s3]
|
|
port = "COM5"
|
|
baudrate = 115200
|
|
description = "XIAO ESP32-S3 + Wio SX1262 serial companion"
|
|
|
|
[profiles.yagi]
|
|
port = "COM6"
|
|
description = "Yagi repeater (reaching the wider mesh)"
|
|
|
|
[profiles.local]
|
|
port = "COM7"
|
|
description = "Local-range repeater"
|
|
|
|
[profiles.observer]
|
|
port = "COM8"
|
|
description = "XIAO observer running a bot"
|
|
|
|
# A Bluetooth LE companion: give it an `address` (from `meshterm devices`) instead of a port.
|
|
# The `transport = "ble"` line is optional — a bare `address` already implies Bluetooth.
|
|
[profiles.handheld]
|
|
address = "AA:BB:CC:DD:EE:FF"
|
|
# transport = "ble"
|
|
# ble_pin = "123456" # only if your device requires a pairing PIN
|
|
description = "Pocket handheld over Bluetooth"
|
|
|
|
# A network (TCP) companion — a WiFi board, or a meshcored-style proxy — reachable at a
|
|
# host:port. Give it a `host` (and optional `tcp_port`, default 5000); a bare `host` already
|
|
# implies TCP, so the `transport = "tcp"` line is optional. A TCP companion isn't discoverable,
|
|
# so a profile (or --tcp host:port, or the picker's "add a network device" prompt) is how you
|
|
# reach one.
|
|
[profiles.wifi]
|
|
host = "192.168.1.50"
|
|
# tcp_port = 5000
|
|
# transport = "tcp"
|
|
description = "Basestation over WiFi"
|
|
|
|
# A radio on this machine's own SPI bus: MeshTerm runs its node while it is connected.
|
|
# The pins default to the uConsole AIO v1's, which needs nothing more than this (and is
|
|
# listed on the device screen anyway, whenever /dev/spidev1.0 exists).
|
|
[profiles.aio]
|
|
transport = "spi"
|
|
# [profiles.aio.spi]
|
|
# en_pins = [27] # the AIO v2 powers its radio from pin 27
|
|
#
|
|
# Which /dev/gpiochip<n> carries the pins is not a fact about the board: a uConsole's CM4
|
|
# has its 40-pin header on chip 0, a CM5 had it on chip 4 under its early kernels, chip 0
|
|
# once Raspberry Pi aliased it there, and another number again on some later kernels. So
|
|
# gpio_chip defaults to -1, which finds the chip by its label (pinctrl-rp1 on a CM5,
|
|
# pinctrl-bcm2711 on a CM4; `gpiodetect` lists them) and falls back to chip 0 where none
|
|
# carries either. Give it a number only to override that:
|
|
# gpio_chip = 4
|
|
|
|
# Any other board states its whole wiring — every pin and both switches, because a key
|
|
# left out keeps the AIO's value. Read them off the board's meshtasticd config; the
|
|
# values here are an illustration only. docs/guide/configuration.md has the key-by-key mapping.
|
|
# [profiles.hat.spi]
|
|
# bus_id = 0 # /dev/spidev0.0
|
|
# cs_id = 0
|
|
# reset_pin = 18
|
|
# busy_pin = 20
|
|
# irq_pin = 16
|
|
# txen_pin = 6
|
|
# rxen_pin = -1
|
|
# use_dio2_rf = false
|
|
# use_dio3_tcxo = false
|
|
# python = "/opt/radio/bin/python" # only to pick the Python that has openhop-core
|