v1.18.0-lou-16

MeshCore repeater firmware with auto-reply — a repeater answers test on its county's test
channel with a signal report, so the mesh can measure itself — on stock MeshCore 1.18.0 and on
agessaman's Observer firmware. Same boards and images as lou-15.

Find your file: https://sweden-mesh.github.io/firmware/

What is new

• The test channel follows the node's home region. With autoreply.region unset, a node
  answers on #test-<region home>. The setup wizards now set the county as home region and
  se as default scope, so a repeater's own adverts reach all of Sweden while auto-reply still
  answers for its county:

  region home se-jkp
  region default se
  region save
  set autoreply on
  > OK - #test-se-jkp (region home)
  

• region home is stock MeshCore (repeater 1.10 and later). The firmware only stores and shows
  it (^ in region); it changes nothing about what the repeater forwards.

• Order: autoreply.region, else region home, else region default unless it is two
  letters (a country such as se, or eu, too wide for a test), else the legacy
  #test-<iata> on Observer images.

• get autoreply and get autoreply.region say (region home) or (region default); the reply
  to region home <name> says where the node answers from then on.

Upgrading

• A node with region default <county> and no home region keeps answering where it did.
• Setting region default se on a node still on lou-15 moves its auto-reply to #test-se.
  Upgrade first, or give it set autoreply.region <county>.
• Settings carry over: the /autoreply file format is unchanged.

Which image

image	carries
<board>_repeater-<chip>-v1.18.0-lou-16-ar-<hash>	auto-reply, on stock MeshCore 1.18.0
<board>_repeater_observer_mqtt-<chip>-v1.18.0-lou-16-ar-<hash>	auto-reply, Observer, OTA
…_observer_mqtt-…-lou-16-rc-<hash>	remote control, Observer, OTA
…_observer_mqtt-…-lou-16-arrc-<hash>	auto-reply and remote control, Observer, OTA

ESP32: .bin updates and keeps settings (write at 0x10000); -merged.bin is a clean install
(erase, write at 0x0). An ESP32 node once updated over Wi-Fi may keep booting the old image
after a cable update: erase otadata with esptool.py --chip <mcu> erase_region 0xe000 0x2000.
nRF52 and RP2040: .uf2 onto the boot drive; .zip for DFU over Bluetooth.
firmware-index.json lists every file and is signed by the release key.

v1.18.0-lou-15

MeshCore repeater firmware with auto-reply — a repeater answers test on its county's test
channel with a signal report, so the mesh can measure itself — on stock MeshCore 1.18.0 and on
agessaman's Observer firmware, for every board that has room for it.

Find your file: https://sweden-mesh.github.io/firmware/ — pick the features and your board,
and get one file with how to flash it. Every file is also listed below.

What is new

• MeshCore 1.18.0 underneath. Stock images are built on MeshCore repeater-v1.18.0; Observer
  images on agessaman's observer-firmware as of 2026-11-08, which carries 1.18.0 too.

• Auto-reply on 93 stock repeater boards (lou-14: 15), among them every nRF52 board, the
  RP2040 and STM32 boards, and all 33 Observer boards (lou-14: 17). Not built: ThinkNode M8,
  which does not build in MeshCore 1.18.0 with or without auto-reply.

• The test channel follows the node's default scope. With autoreply.region unset, a node
  answers on #test-<region default> — the county name the meshat.se setup wizards give a node's
  own floods. set autoreply on is then all it takes:

  set autoreply on
  > OK - #test-se-jkp (region default)
  

  A stock node with no default scope is silent and says so:
  OK - on, but no channel: set region default <county> (or autoreply.region).

• autoreply.region still wins when set, for a node whose test channel must differ from its
  own floods' scope. get autoreply shows which is in effect: (region default) or
  (autoreply.region).

• One channel per node. The old #test-<iata> channel now only answers on a node with no
  region; a node with a region answers on its region's channel alone, so a probe gets one answer
  per node, never two.

• Capitals in a scope. A default scope such as SE06 answers on #test-se06 (channel names
  are lower case), and its replies keep the scope SE06.

• region default <name> says where auto-reply answers from then on, when auto-reply is on.

Upgrading

• Nodes with autoreply.region set keep their channel, and stop answering on #test-<iata>.
  Probes on #test-<iata> from now on reach only nodes without a region, and nodes not yet
  upgraded. Send probes on the county channel; during the change-over, on both.
• Nodes without autoreply.region but with a default scope start answering on
  #test-<default scope> after the upgrade. Check with get autoreply.
• Observer images: the Observer's own ota branch (prod/beta) is present, and in these images
  every branch points at this repository's releases: updates still come only from here, signed by
  the release key. ota check fetches over HTTPS.
• Settings carry over: the /autoreply file format is unchanged.

Which image

image	carries
<board>_repeater-<chip>-v1.18.0-lou-15-ar-<hash>	auto-reply, on stock MeshCore 1.18.0
<board>_repeater_observer_mqtt-<chip>-v1.18.0-lou-15-ar-<hash>	auto-reply, Observer, OTA
…_observer_mqtt-…-lou-15-rc-<hash>	remote control, Observer, OTA
…_observer_mqtt-…-lou-15-arrc-<hash>	auto-reply and remote control, Observer, OTA

ESP32: .bin updates and keeps settings (write at 0x10000); -merged.bin is a clean install
(erase, write at 0x0). nRF52 and RP2040: .uf2 onto the boot drive; .zip for DFU over
Bluetooth. firmware-index.json lists every file and is signed by the release key.

v1.17.1-lou-14

MeshCore Observer firmware with the fork's features — repeater auto-reply (a repeater
answers test on its regional channel with a signal report) and signed remote control over
MQTT — plus signed pull OTA, and for the first time core MeshCore images with auto-reply.

lou-14 is the split

lou-14 follows ar-13. The fork's features are now separate, and each image carries a
combination of them, named in the file and in ver:

image	carries	for
<board>_repeater_observer_mqtt-<chip>-v1.17.1-lou-14-arrc-<hash>.bin	auto-reply + remote control + OTA	what every release before this one was
…_observer_mqtt-…-lou-14-ar-<hash>.bin	auto-reply + OTA	an Observer repeater that is never commanded remotely
…_observer_mqtt-…-lou-14-rc-<hash>.bin	remote control + OTA	an Observer repeater that does not answer tests
<board>_repeater-<chip>-v1.17.1-lou-14-ar-<hash>.uf2/.zip/.bin	auto-reply, on upstream MeshCore 1.17.1	a repeater without WiFi or MQTT (15 boards, among them the nRF52 ones, the Heltec T096, the RAK WisBlock 1W (RAK3401) and the Wireless Stick Lite V3)

firmware-index.json lists every file with its board, features, hash and how to flash it; it is
signed by the release key. ver reads …-lou-14-arrc-observer-<hash> on an Observer image.

Pick the combination you had: a node on ar-11..13 had both features, so its image is arrc.

What changes for a node that had ar-13

• No automatic update from ar-11..13. Those releases ask for <board>.json, which this
  release does not publish: every node on ar-11..13 is flashed by cable once (keep the
  settings with the app image at 0x10000, as before). From lou-14 a node asks for
  <board>-<features>.json and only ever installs its own board and combination: the
  manifest carries a second signature over both, and a node refuses any other.
• Automatic OTA checks its own version properly. Up to ar-13 a node compared only the
  first part of its version, so any build on offer looked newer — its own included. Now an
  older build is never installed and an up-to-date node stays put.
• The private test request is sub-type 0xF0. ar-11..13 used 0x04; lou-14 answers only
  0xF0 and sends only 0xF0 (trigger private). A lou-14 node and an ar-13 node do not
  answer each other's private tests; mccontrol says so when both versions are known.
• autoreply.region scopes only auto-replies and the node's own probes. It used to scope
  every reply the repeater flooded — logins, ACKs, remote CLI answers. Those now follow
  upstream's own rule, the scope the request came in on.
• An image without remote control proves itself by the bridge. A newly installed image is
  kept once it has verified a signed command, or — with no command plane, or one that is off —
  once an MQTT slot has published and it has run ten minutes. Until then a reboot returns the
  previous image.
• ota.auto and ota.check.hours live in their own /ota file. A node reads them from
  its old /mqttcontrol until it is first set; a rollback to ar-13 finds them where they were.
• get stats is the command plane's own command, answered from the node's counters; an
  image without remote control does not have it.
• In an ar image the client id of each MQTT slot and the get mqtt.stats line are the
  Observer's own; the per-slot client id and the pw/jwt word come with remote control.
• In an rc image, trigger test, trigger private and the autoreply settings are refused
  as not-allowed; mccontrol hides them.

For a node on core MeshCore (ar on upstream)

There is no MQTT and so no mqtt.iata: the node has no legacy #test-<iata> channel and
stays silent until set autoreply.region <name> names its channel #test-<name>.
get autoreply shows the legacy switch as on, inert: no MQTT. No pull OTA.

Tools

mccontrol from backlog A23/A24 reads -lou- versions and the features they name, hides what an
image cannot do, and knows the 0xF0 cut-off. Older mccontrol takes a lou-14 node for the oldest
firmware it knows and offers less than it could.

Setting up a repeater: docs/quick-check-guide.md (which sections apply to which combination).
Everything about the combinations: docs/fork.md.