Seeed SenseCAP Solar Node P1 🏴󠁧󠁢󠁳󠁣󠁴󠁿 built by ScotMesh

Node pages & API: Yes

Firmware update over the air: Bluetooth update window, or USB bootloader

Heltec V2/V3/V4, Heltec Wireless Tracker V2, XIAO ESP32S3, T-Beam Supreme, T-Deck

Node pages & API: Yes

Firmware update over the air: WiFi update window

T-Beam, T3S3, LoRa32 v1/v2/v2.1, RNode NG 2.0/2.1, Feather ESP32, generic ESP32

Node pages & API: Yes

Firmware update over the air: USB only (one firmware slot)

RAK4631, RAK3401, T-Echo

Node pages & API: Original microReticulum pages (the new ones don't fit their flash yet)

Firmware update over the air: USB

1. Open rnode.scotmesh.net in Chrome or Edge on a computer. Choose Standalone node, pick your board, and flash.

2. On the configure step:

• pick ScotMesh 868 (or 433);

• give the node a name;

• choose its role (normally Fixed relay);

• paste your identity hash under Remote management. That makes you its admin.

3. The node restarts in transport mode and announces its NomadNet page. You can do everything else from that page over the mesh.

Open the node's NomadNet address in Nomad Network or MeshChatX. You'll find the address:

• at the end of the flasher;

• on the node's About page;

• in the node's announce.

Every page is small enough to arrive in one LoRa packet, so it loads first time even on weak links. Most are 150–300 bytes, and the limit is 409.

The home page shows:

• the node's name;

• its battery, as a bar (green / amber / red) with % and voltage, plus ▲ while charging or ▼ while discharging;

• uptime and the number of known routes.

An admin can also show the radio settings, airtime and an operator line. The footer always shows the firmware version and the board. Not identified means your browser hasn't identified to the node. That's fine for visitors.

Routes lists the node's path table: destination, hops and when it was last heard. Neighbours lists the transport nodes it hears directly, with their names where they announce one. To change the view:

• tick Short for 8-character addresses (or leave it off for full ones);

• set Rows and press Apply;

• use next and back to page through.

An admin can hide both pages from visitors.

You are an admin if your identity is on the node's remote-management list (the same list rnstatus -R checks). In your browser, choose Identify for the node (NomadNet: the Identify option on the page; MeshChatX: identify to this node) and reload. The page then shows 🛡️ Verified identity and an Admin link. There is no password to log in with: being identified is being logged in.

Admins see every row. A * marks rows that visitors don't see.

If an admin has switched on password registration, a visitor who has identified sees Register. Entering the password adds their identity as an admin, or puts them in a queue for an existing admin to approve.

The hub shows battery and uptime, and warns you when a radio trial needs confirming or someone is waiting for approval. It links to three sections.

Settings

Pages: Name & announce: renaming announces straight away. Announce every 30 min, 1 h, 3 h, 6 h or 12 h. Home page: what visitors see, telemetry API on or off, and a visitor preview. Map: rmap.world position. Radio, Role, Power

Access

Pages: Admins: add by identity hash; remove with confirmation. Password registration. Change log: every admin change, with time and who made it.

Device

Pages: Health: free RAM and flash, starts and last reset reason, noise floor, last RSSI/SNR, airtime, packets, table sizes. Lights & Bluetooth, Logs (last five log lines), Maintenance, Restart & update, About

Change the name, set an optional operator line (e.g. a callsign) and set how often the node announces its page. Longer intervals save airtime on a busy channel. Renaming announces at once.

Tick what visitors may see. Preview shows the page as a visitor would see it. Telemetry API turns the /api endpoints on or off.

Radio changes are a trial. Enter new settings (or pick ScotMesh 868 / 433) and press Try these. The node uses them for five minutes. Reconnect on the new settings and press Keep. If you don't, the node goes back to the old settings by itself, so a mistake can't strand a remote node.

Role:

• Fixed relay: forwards for everyone. Use it for hilltop and roof nodes.

• Access point: for a node that serves nearby clients.

• Mobile: for a node that moves.

• End device: never forwards.

A role change applies after a restart.

Below a chosen battery level, the node can lower its TX power to 10 dBm or turn its radio off until it has charged. It can also keep its radio off below 3.3 V to protect the cell.

• Admins (up to 8): paste a 32-character identity hash and press Add. Tap an identity to remove it; you're asked to confirm. The node won't remove its last admin.

• Password registration is off by default. An admin sets a password. Someone who knows it can identify to the node and register their own identity as an admin.

• Three wrong tries lock that identity for 15 minutes.

• Ten wrong tries in an hour pause registration.

• With Needs approval ticked, new registrations wait for an existing admin.

Lights:

• the activity LEDs can be on, off, or on only for the first 10 minutes after a start;

• Blink 30 s helps you find a node on a mast;

• error patterns always show.

Bluetooth can be turned off to save power on a sealed box. Unpair all forgets paired phones.

From here you can:

• announce now;

• restart automatically every day or every week;

• clear stored routes and data;

• factory reset. This keeps the node's identity and its admins.

• full reset. The node forgets its identity too: new addresses, no admins, no settings. Use it to hand a node on, or before re-flashing it as a different node. Afterwards it needs USB to make it yours again (the flasher's Reconfigure path).

Anything disruptive asks you to confirm, with a link that works once, for two minutes.

Updates are started from the node's page over the mesh, but the firmware itself is too big to send over LoRa, so someone has to be near the node with a phone or laptop for the transfer. The node accepts the new image's hash by itself afterwards; you don't need rnodeconf or the flasher.

WiFi update (ESP32 boards with two firmware slots: Heltec V2/V3/V4, Tracker V2, XIAO ESP32S3, T-Beam Supreme, T-Deck):

1. Device → Restart & update → WiFi update → Yes, start. The page shows a one-time WiFi password. Write it down; it is shown once.

2. The node restarts as a WiFi access point called ScotMesh-Update, off the mesh, for 20 minutes.

3. Within WiFi range, join that network with the password and open <nowiki>http://192.168.4.1</nowiki>.

4. Choose the .bin from inside the board's release zip (for example rnode_firmware_heltec32v3.bin) and press Update. The node verifies it and restarts into the new firmware.

A WiFi update leaves the node running from its second firmware slot. That's fine for the flasher (it always resets the slot choice), but if you later update by hand with esptool or rnodeconf, write boot_app0.bin at 0xE000 as well as the firmware, or the board keeps booting the old slot and refuses to start transport ("device init failed").

If nothing is uploaded in 20 minutes, or the upload fails, the node restarts unchanged. The 4 MB boards (T-Beam, T3S3, LoRa32, RNode NG, Feather, generic ESP32) have one firmware slot and can only be updated over USB.

Bluetooth update (SenseCAP P1):

1. This restarts the node with a Bluetooth firmware-update service for 20 minutes. It advertises as SenseCAP P1 DFU.

2. Within Bluetooth range, open nRF Device Firmware Update or nRF Connect on a phone.

3. Send the node's rnode_firmware_seeed_solar_node_p1.zip from the releases (github.com/A13xB0/microReticulum_Firmware/releases).

If nothing connects, the node restarts normally when the window closes.

USB bootloader is for someone on site with a laptop. The node waits in its bootloader until it is flashed (for example from rnode.scotmesh.net) or reset.

None of these start below 30 % battery unless the node is charging.

The flasher keeps a node's identity, settings and routes across a reflash, which is what you want for an update. To wipe a node and start again (a second-hand board, or one you want new addresses for), tick Start from scratch: erase everything first on the flasher's Flash step. On ESP32 boards that erases the whole flash; on the P1 and other nRF52 boards it asks the firmware for a full reset and wipes the EEPROM. Either way the node comes back with a new identity and the flasher provisions and configures it again.

1. On Settings → Map, paste the node's position straight from Google Maps. Right-click the spot and click the coordinates, e.g. 56.19858019391934, -3.1666195614405708. Degrees-minutes-seconds works too.

2. Set its height in metres.

3. Choose Exact or ~1 km.

4. Tick Publish and save.

The node then sends the standard Reticulum interface-discovery announce on the announce interval. It's the same announce a PC node sends with discoverable = yes. rns.scotmesh.net peers with rmap.world, so the announce reaches the map through the backbone.

The position is public once published. Use ~1 km if that matters.

For trackers and dashboards, the node answers plain JSON requests on the same NomadNet address.

• No identity is needed.

• An admin can switch the API off under Home page.

• Each reply fits in one packet.

• List endpoints page with o (offset) and n (rows), and add "more": true when there are more rows.

/api

Request data: —

Reply (real examples from the bench P1): {"v":1,"api":["bat","up","radio","net","sys","health","pos","paths","nbrs","all"]}

/api/bat

Request data: —

Reply (real examples from the bench P1): {"percent":96,"voltage":4.11,"charging":true}

/api/up

Request data: —

Reply (real examples from the bench P1): {"uptime":134,"reset":"soft-reset"}: seconds since start, and why it last started

/api/radio

Request data: —

Reply (real examples from the bench P1): {"freq":869462500,"bw":125000,"sf":9,"cr":5,"txp":22,"airtime":4.4,"noise":-105,"rssi":-59,"snr":10}

/api/net

Request data: —

Reply (real examples from the bench P1): {"routes":159,"neighbours":1,"rx":20,"tx":18,"links":1}

/api/sys

Request data: —

Reply (real examples from the bench P1): {"fw":"v1.86-scotmesh.3","board":"SenseCAP P1","name":"…","free_ram":33472,"free_flash":1822720}

/api/health

Request data: —

Reply (real examples from the bench P1): {"free_ram":33472,"free_flash":1822720,"reboots":7,"reset":"soft-reset","paths":159,"paths_max":500,"announces":0,"neighbours":1}

/api/pos

Request data: —

Reply (real examples from the bench P1): {"lat":56.19858,"lon":-3.16662,"height":310}, or {"error":"not published"}

/api/all

Request data: —

Reply (real examples from the bench P1): battery + uptime + network + airtime in one reply

/api/paths

Request data: {"o":0,"n":5,"s":0}

Reply (real examples from the bench P1): {"total":159,"o":0,"cols":["dest","hops","age_s","via"],"rows":[[…],…],"more":true}

/api/nbrs

Request data: {"o":0,"n":5,"s":1}

Reply (real examples from the bench P1): {"total":1,"o":0,"cols":["dest","age_s","name"],"rows":[…]}

s=1 gives 8-character addresses. Unknown paths answer {"error":"unknown endpoint","see":"/api"}. If the node is short of memory, it answers {"error":"busy"}.

Here's a tracker in Python. It needs Reticulum installed and connected to the mesh, e.g. with a TCP interface to rns.scotmesh.net port 4242:

Keep one link open and poll every few minutes. Each request and reply is a single small packet (typically 3–5 s round trip over three hops).

• The node keeps its settings in its own flash. Its identity and admin list survive firmware updates and a factory reset.

• One exception: RNode NG 2.0/2.1 and LoRa32 v2.1 nodes flashed with v1.86-scotmesh.2 or earlier get a new identity when updated to .4 or later, because those boards moved to a larger app slot (2.25 MB) to fit the pages. Add the node's new identity to your admin list again afterwards. Updates after that keep the identity.

• Memory is watched: Health and /api/health show free RAM, so a slow leak shows up as a trend.

• pages and the API never copy the route table;

• the change log is a fixed 1.3 KB file;

• below about 8 KB of free RAM, the node answers "busy" rather than risk running out.

• The LEDs on the P1:

• white flash: packet received;

• blue flash: packet sent;

• blue and white alternating fast: the radio failed to start (the node restarts itself after a few seconds).

• Full debug logging stays in the firmware. Connect over USB and open a serial console at 115200 to see it.

• Upstream differences and the full change history are in the repository's README.