Skip to content
Gloucester County Amateur Radio Club

Gloucester County Amateur Radio Club

Skunkworks Advanced Project Team

Menu
  • Home
  • Club Activities
    • WSPR Activities
      • Current WSPR & Band Report
      • Clubhouse WSPR Station Report
      • WSPR Network Monthly Reports
        • September 2026
        • August 2026
        • July 2026
        • June 2026
        • May 2026
        • April 2026
      • WSPR Field Day 2026 — Propagation Comparison
    • Satellite Activities
      • Saturday Clubhouse Satellite Opportunities
      • Weekly Satellite Report
      • Upcoming ISS APRS Activities
      • Upcoming ISS Viewing Opportunities
      • GOES 19 Weather Video
      • Current ISS SSTV Images
    • Recent DMR Activity
  • Clubhouse
    • Saturday Clubhouse Weather
    • The GCARC Clubhouse
    • Grounding Project
    • Networking Infrastructure
    • Work and Test Bench
    • Clubhouse Satellite Station
      • Satellite Rotator Controller
      • Satellite Station Remote Operation
    • SatNOGS Ground Station
    • Earth-Moon-Earth (EME)
    • Discovery Satellite Snooping Dish
    • GOES-19 Satellite Reception
    • Clubhouse Remote nRSP-ST Resource
    • Skunkworks GitHub Resource
    • ISS SSTV
    • NOAA Weather Fax
    • ADS-B
  • Technical Resources
    • Working Meteor Scatter at W2MMD
    • WSPR Network Resources
      • The TAPR WSPR Board for Dummies
      • Why Is My WSPR Signal 1500 Hz Off? — A Tale of Two Frequencies
      • GCARC WSPR Network — Project Description
      • GCARC WSPR Network — Technical Reference
      • GCARC WSPR Network — Band Selection Guide
      • GCARC WSPR Network — Analysis and Reporting
      • The GCARC WSPR Network — Member Q&A
    • DMR
      • What is a DMR Codeplug?
        • What Are DMR Channels?
        • What Are DMR Timeslots?
        • What is a Talkgroup in DMR?
        • What Are DMR Zones?
      • What is a DMR Hotspot?
      • Configuring DMR Hotspot for GCARC Talk Group
      • Connecting to the GCARC DMR TalkGroup with a Yaesu System Fusion Radio and a Hotspot
      • Using DM-1701 CPS Program
      • Open GD77 on Baofeng DM1701
      • Pi-based OpenGD77 Flasher: Bypassing Windows Driver Headaches
        • OpenGC77 Codeplug
    • Software-Defined Radios
      • Software Defined Radio Demystified
      • Installing an RTL-SDR on a Windows PC
      • SDR Tech Saturday Presentation January 2025
      • SDR Client Applications for Mac
      • Creating a PiAware Station to Track Airplanes
        • Installing PiAware Using the Prebuilt SD Card Image with Raspberry Pi Imager
        • Installing PiAware using Command Line Commands
    • Receiving ISS SSTV Images
    • Meshtastic and MeshCore
      • MeshCore Node Handbook
      • Getting Started with Meshtastic on 915 MHz
      • How to Join the GCARC Channel on Your Meshtastic Device Using a QR Code
      • Installing the Meshtastic CLI on a Windows PC
      • Window-Mounted 915 MHz Meshtastic Yagi Antenna Project
      • Meshtastic CLI Commands
    • Exploring Ham Radio Digital Modes: Packet Radio and WSJT-X
      • Packet Radio (AX.25) in Amateur Digital Communications
      • Exploring WSJT Digital Modes
    • BTECH UV-PRO Radio
      • Satellite Mode for the UV-PRO
    • TIDRADIO H3 Resources
      • TIDRADIO TD-H3 Transceiver: Comprehensive Briefing
      • Overview of Stock Firmware Menu System
      • Comparison of Stock TIDRADIO Firmware vs. nicFW V2 Firmware
    • Balloon Project
      • Balloon Launch – 2025-03-17
    • 3D Printed Projects
    • Tech Saturday Presentations
    • Receiving ISS HamTV
  • STEM Activities
    • STEM Club Weather
    • STEM Club Villanova Trip
    • STEM Club Satellite Pass Schedule
    • STEM Camp 2026
      • Calculator Skills — TI-84 Evo
  • Public Service
    • GCARC Planning Documents
      • AuxComm Documents for Review
      • Amateur Radio & Served Agency Integration
      • Building Served Agency Capability
      • The Ham Next Door
      • NIFOG Guide
      • AUXFOG Guide
    • GCARC Resources
      • Winlink VHF and HF Gateways
      • APRS Weather Reporting Station
    • AREDN Development
  • AI Info
  • The Foundation
  • Blog
  • Contact

MeshCore Node Handbook

Field manual · W2MMD / GCARC

W2MMD MeshCore Handbook

Choosing a firmware role, flashing it, and configuring the result — for gateways and for companion nodes alike. Ends with the club’s own MeshCore repeater as a worked example.

Device values were read live over USB serial on 28 Aug and 3 Sep 2026. Where something comes from documentation rather than from a radio that answered for itself, it says so.

MeshCore is not Meshtastic

Two different protocols on the same LoRa hardware. They cannot hear each other, they share no tooling, and the meshtastic CLI and the MeshMon collector are blind to every node in this document. Where this manual says “repeater” it means a MeshCore repeater — nothing to do with the club’s voice repeaters.

Contents

  1. Roles & variants
  2. Flashing
  3. The three web tools
  4. Web / WiFi access
  5. Configuring a gateway
  6. Configuring a companion
  7. CLI reference
  8. Monitoring
  9. Network & FCC
  10. W2MMD Clubhouse node
  11. Troubleshooting

Roles and firmware variants

In MeshCore the role is the firmware. There is no set role command — you decide at flash time, and changing your mind means reflashing. Pick wrong and the node works perfectly while being unreachable by the tool you expected to use.

Six builds exist. Two are infrastructure, one is the client radio in three connection flavours, and three are specialist.

Infrastructure — “gateway” roles

BuildWhat it doesHow you reach it
RepeaterForwards packets to extend range. No message storage. The backbone role.USB serial CLI, or over the mesh with an admin password
Room ServerEverything a repeater does, plus a stored message history that users can pull — a small BBS.Same as repeater; adds a guest password (default hello)

Both expose the same text CLI over USB and both are screenless-friendly. Neither has Bluetooth of any kind — that surprises people, so it is worth saying plainly: you cannot pair a phone to a repeater.

Client — companion radio, three flavours

BuildConnectionGood for
Companion BLEBluetooth LE. Pairing PIN, default 123456 on nodes without a display.A handheld radio paired to your phone. The usual choice.
Companion USBBinary frame protocol over the USB cable.A node cabled to a PC that you want to script or log from.
Companion WiFiTCP on port 5000, over your LAN.A node that lives anywhere on the network, no cable, reachable from a browser.
The companion trap

No companion build speaks the text CLI. Open one in PuTTY, type get name, and you get silence — it only answers a binary frame protocol. A Companion BLE node is silent on USB entirely: it boots, runs perfectly, and says nothing on the wire, which looks exactly like a dead board.

If a node boots but answers nothing over serial, that is the expected behaviour of Companion BLE, not a fault.

Specialist

BuildWhat it does
Sensor NodeTelemetry source that reports readings into the mesh
KISS ModemPresents the radio as a KISS TNC to other software
Secure Chat TerminalStandalone chat on a device with a keyboard and screen — a T-Deck, typically. No phone needed.

Choosing

  • Infrastructure at a site, meant to relay for everyone → Repeater.
  • The same, but you also want stored messages people can retrieve → Room Server.
  • Your own radio, driven from your phone → Companion BLE.
  • A radio you want a computer to poll, log, or automate → Companion USB (cabled) or Companion WiFi (networked).

Flashing

The procedure is the same for a gateway and a companion node; only the firmware you select differs. The hardware precautions below apply to both, and the board-target one is the mistake that costs the most time.

Match the board target exactly

Boards that look interchangeable are not. The RAK3401 talks to its radio over SPI1 rather than standard SPI, and its 1W booster needs pin 31 (ANT_SW / IO3) driven to key the amplifier. Flash a RAK4631 build onto RAK3401 hardware and the node boots, accepts every command, reports healthy, and emits nothing usable.

The same class of mismatch bites on ESP32-S3: a build that routes its serial to the chip’s native USB peripheral will be silent on a board whose USB connector is wired through a CP2102 UART bridge. Symptom is identical — boots clean, says nothing.

Antenna first, and use a data cable

Connect the antenna before the node is powered. A 1W amplifier into no load can destroy itself. And many USB cables are charge-only — one of those enumerates nothing and is indistinguishable from a dead board.

  1. Pick the firmware

    From the MeshCore releases, take the build matching both your exact board and your chosen role from the tables above. Roles ship as separate downloads — there is no single image you configure afterwards.

  2. Open the flasher

    flasher.meshcore.io in Chrome or Edge. It talks to the board over USB only, and needs no install.

    File formats differ by chip: ESP32 takes .bin, nRF52 takes an OTA .zip. Grab the matching .uf2 as well if one exists — that is your recovery path.

  3. Enter bootloader mode if the board needs it

    Varies by hardware: hold BOOT while connecting on many ESP32 boards, double-tap RESET on nRF52. Most boards are handled automatically by the flasher.

  4. Recovery route for nRF52

    If the board will not enumerate or a flash fails partway, double-tap RESET. The Adafruit nRF52 bootloader mounts a small USB drive; drag the .uf2 onto it and the board reboots itself. This works even when the application firmware is bricked, because the bootloader lives in protected flash.

  5. Confirm what came up

    For a gateway, open the serial console and ask its version. A response confirms both the flash and the board target:

    ver     -> v1.17.1-d929643 (Build: 14-Aug-2026)
    board   -> RAK 3401

    For a companion node, silence on serial is expected for the BLE build — confirm it over Bluetooth instead. For Companion USB, confirm with meshcli -s <port> infos.

The three web tools

MeshCore has three separate browser tools, and they are not interchangeable. Most confusion about “I can’t find my node in the web interface” is someone in the wrong one for their firmware role.

ToolWorks withOver
flasher.meshcore.ioAny board, any role — installs firmwareUSB only
config.meshcore.ioRepeater and Room Server onlyUSB serial (WebSerial)
app.meshcore.nzCompanion firmware onlyBLE, USB, or WiFi

The config tool gives repeaters a full settings GUI, a manual CLI box, JSON import/export, and over-the-air firmware updates. The web client is a complete replacement for the phone app — messaging, contacts, node map, settings — which makes it the practical way to drive a companion node from a desktop.

Chrome, Edge, or another Chromium browser is the safe choice; WebSerial and WebBluetooth are what these pages rely on. Firefox works over WiFi, where no such API is needed, and Safari is reported reliable on Mac and iOS.

Nothing here needs the internet

These pages are static and the traffic is local — browser to node over USB, Bluetooth, or your LAN. The mesh itself never touches the internet.

Web / WiFi access to a node

This is the flasher option you have seen listed and found nothing written about. It is real, it is genuinely useful, and it is thinly documented for a specific reason worth knowing before you commit to it.

What it gives you

A Companion WiFi build joins your wireless network and exposes the companion interface over TCP on port 5000, accepting multiple clients at once. The node can then sit anywhere on the LAN — no cable, no Bluetooth range limit — and you reach it from:

  • A browser at app.meshcore.nz, choosing the network connection
  • The CLI: meshcli -t <ip> -p 5000
  • Your own code — meshcore.js takes new TCPConnection("10.1.0.226", 5000)

On a node with a display there is a Network (TCP) page showing connection status, the node’s IP, the port, and the SSID it joined. A long press toggles TCP on and off.

The catch: credentials are usually baked in at build time

For most boards the WiFi build is not something you flash and then configure. The SSID and password are compile-time constants — you edit WIFI_SSID and WIFI_PWD in ./variants/<board>/platformio.ini, build, and flash the result. Some builds accept credentials at runtime, but that is not the general case.

That is why prebuilt WiFi images are scarce and the documentation is thin: for most people this variant means compiling MeshCore yourself. If your network password changes, you rebuild and reflash.

Worth it for a fixed node at a known site where you want browser access without walking over to it. Not worth it for anything you carry.

Confidence

The TCP port, the multi-client behaviour, the Network (TCP) page, and the build-time credential requirement all come from MeshCore documentation and community write-ups — not from a WiFi node tested here. Treat the exact provisioning steps as a starting point rather than a verified recipe.

Configuring a gateway

Repeaters and room servers share one configuration surface: a text CLI at 115200 8N1 over USB, reachable from PuTTY, from config.meshcore.io, or from a script.

The console echoes what you type and answers with ->. There is no help and no ? — both return Unknown command. The CLI reference below is the actual command surface.

A freshly flashed gateway is anonymous, unsecured, and on default radio settings. Do these in order — the password first, because until you set it the node accepts the published default from anyone in earshot.

  1. Lock it down

    The default admin password is password and it is public knowledge. Anyone who can hear the node can otherwise reconfigure it. There is no getter — get password is not valid, by design.

    password <something-only-you-know>
    set guest.password <guest-password>
  2. Name it

    This is what appears in everyone’s contact list, so make it identify the site rather than the person.

    set name W2MMD Clubhouse
  3. Set the radio

    Frequency, bandwidth, spreading factor and coding rate in one command. All four must match the rest of your mesh exactly or the node is deaf and mute — not degraded, silent. Requires a reboot.

    set radio 919.5,500,10,5
    set path.hash.mode 1
    set tx 22
    reboot

    To trial a change on a node you cannot easily reach, use tempradio f,bw,sf,cr,<minutes> instead — it applies without saving and reverts on its own.

  4. Place it and set the clock

    Position feeds the map. Note there is no time query — bare time returns Unknown command; it only takes an epoch argument.

    set lat 39.716999
    set lon -75.2099533
    time <epoch>
    clock

    Get the epoch from date +%s on Linux. On Windows use [int][DateTimeOffset]::UtcNow.ToUnixTimeSeconds() — PowerShell’s Get-Date -UFormat %s computes from local time and will set the node hours off. The config tool pushes the browser’s clock for you, which avoids the whole problem.

  5. Make it discoverable

    Zero-hop adverts in minutes, flood adverts in hours, then one manual advert so anything nearby can add it immediately.

    set advert.interval 60
    set flood.advert.interval 12
    advert                 -> OK - Advert sent
    advert.interval has a floor

    The firmware accepts 60–240 minutes only, or 0 to disable. Anything lower is rejected outright:

    set advert.interval 30
    Error: interval range is 60-240 minutes

    60 is as often as a gateway can announce itself. This range is not in the published documentation — it was found on the device.

  6. Check it hears the mesh

    Give it real time on air first — an hour or more at a quiet site.

    neighbors

Administering one remotely

A gateway can be driven over the mesh rather than the cable. The client must first hear an advert from it, which is why advert.interval 0 makes a node effectively unreachable. Then log in with the admin password and issue commands by RF. Both the phone app and meshcore-cli can do this.

Configuring a companion node

Nothing from the previous section applies here. Companion firmware has no text CLI and does not appear in the config tool. Three ways in, depending on which flavour you flashed:

FlavourPhone appWeb clientmeshcore-cli
BLEPair over BluetoothWebBluetoothmeshcli -a <address>
USBUSB OTGWebSerialmeshcli -s <port>
WiFiOver LANNetwork connectionmeshcli -t <ip> -p 5000

The scriptable path

meshcore-cli installs from PyPI as pip install meshcore-cli and runs as meshcli. It speaks the binary companion protocol, which is the only thing these nodes answer.

CommandDoes
infos / iNode details
ver / vFirmware version
set <param> <value>Configure. set help lists parameters.
get <param>Read a parameter
self_telemetry / tOwn telemetry
time <epoch> / clock syncSet clock. clock sync pulls from the connected client — no epoch arithmetic.
advert / floodadvSend an advert / flood advert
contacts / lcList contacts
import_contact / export_contactExchange contacts by URI
card / eExport this node’s own URI

Chain them in one non-interactive call, -j for JSON:

meshcli -s /dev/ttyACM0 -j infos set name MNFQ-MC advert contacts
Contacts are not automatic

Two companion nodes must each hold the other in contacts before direct messages work. A node with Contacts (0) can hear the mesh but cannot address anyone on it. Either let it pick up an advert, or import the far end’s contact URI directly.

Check the position setting

A companion with position 0, 0 and “Share Position in Advert” enabled broadcasts null island to everyone in range — a wrong position rather than an absent one. Either set real coordinates or turn position sharing off.

Backing one up

The app’s Export Config screen writes out identity, radio settings, channels and contacts. Do this before changing radio settings. The export contains the private identity key, which is the one unrecoverable item: lose it and the node returns with a new public key and every contact in the mesh loses it. Anyone holding that export can impersonate the node, so keep it somewhere safe.

CLI reference

Gateways only — repeater and room server. Verified against a live repeater on firmware v1.17.1. The n/a rows are traps worth knowing, not omissions.

Status and identity

CommandReturns
verFirmware version and build dateworks
boardHardware identifier, from firmware rather than the USB descriptorworks
clockDevice time, UTCworks
neighborsUp to 8 recent, as {pubkey-prefix}:{timestamp}:{snr×4}, or -none-works
discover.neighborsActively probe for zero-hop neighboursworks
get name / role / public.keyIdentityworks
helpUnknown command — so are ?, status, stats, bare time, batn/a

Radio

CommandNotes
get radioAll four values at once: freq,bw,sf,crworks
get bw / sf / crNot individually gettable — use get radion/a
set radio f,bw,sf,crSaves to preferences. Reboot required.reboot
tempradio f,bw,sf,cr,minsApplies without saving, reverts after N minutes. The safe way to test a change remotely.works
set tx <dBm>Chip-level power. Reboot required.reboot
get afAirtime factorworks

Network behaviour

CommandNotes
advertSend one advert nowworks
set advert.interval <min>Zero-hop timer, minutes. Accepts 60–240 only, or 0 to disable.works
set flood.advert.interval <hr>Flood timer, hours. Default 12. 0 disables.works
set repeat on|offWhether it forwards packets at allworks
get flood.maxMaximum hop countworks
set path.hash.mode 0|1|2Bytes of public key per recorded hop: 1, 2 or 3. Needs firmware ≥1.14. Governs what the node originates; 1.14+ relays any width.works
set allow.read.onlyGuest read accessworks
set rxdelay / txdelayCollision-avoidance timingworks
get aclAccess control list (serial only)works

Security and lifecycle

CommandNotes
password <new>Sets admin password. Write-only — no getter, by design.works
set guest.password <pw>Guest access; this one is readableworks
time <epoch>Set clock from unix epoch secondsworks
rebootA timeout message on the console is normalcareful
eraseWipes the filesystem — identity, keys, all config. New public key on next boot, so every contact loses it.destructive

Monitoring

Gateway telemetry hides behind three hyphenated commands. They are easy to miss — status, stats and get stats all return Unknown command. Each returns JSON, so they drop into a logger with no parsing work.

CommandExample output
stats-core{“battery_mv”:4175,”uptime_secs”:2800,”errors”:0,”queue_len”:0}
stats-radio{“noise_floor”:-88,”last_rssi”:-50,”last_snr”:-11.00,”tx_air_secs”:0,”rx_air_secs”:0}
stats-packets{“recv”:0,”sent”:1,”flood_tx”:0,”direct_tx”:1,”flood_rx”:0,”direct_rx”:0,”recv_errors”:0}

Also clear stats to zero the counters, and log start / log / log stop to capture received packets to flash and dump them. All of these are serial only; over the mesh you get a smaller set.

Reading them: recv with recv_errors at zero means nothing is arriving at all; errors climbing means the node hears traffic it cannot decode, which points at a radio-parameter mismatch. A sensible noise floor proves the receiver is alive and measuring even when nothing is heard.

Stale fields

last_rssi and last_snr hold boot-time values until something is actually received. Identical readings across days are a sign of no traffic, not of a steady signal — do not trust them until recv is above zero.

Companion telemetry

Companion nodes report through meshcore-cli instead: self_telemetry for the node you are connected to, and req_status / req_telemetry / req_neighbours against a named gateway over the mesh. cmd <gateway> <command> sends raw CLI by RF.

meshcli -s /dev/ttyACM0 -j login <adminpw> \
  req_status "W2MMD Clubhouse" \
  req_telemetry "W2MMD Clubhouse"
Clocks do not survive a reboot

There is no battery-backed RTC. A genuine reboot or power loss resets the clock to a fixed default date and it counts up from there. Since set radio and set tx both require a reboot, any radio change silently wipes the clock — re-set it afterwards.

Pulling the USB cable is not necessarily a power cycle. With a battery attached the node keeps running and only the data link drops. Check stats-core uptime before assuming a reboot happened.

Network profile and FCC compliance

Every node on a mesh must share its radio parameters exactly. The profile below is MeshCore 500, adopted by PhillyMesh in August 2026 after the group concluded that the common defaults are not FCC compliant.

Revised — these are not the original numbers

PhillyMesh replaced its first MeshCore 500 guidance. The frequency moved from 902.250 to 919.500 MHz and the spreading factor from 11 to 10, after summer 2026 testing in the Philadelphia area found heavier ISM-band interference at the original channel. A path hash mode setting was added at the same time.

Nodes still on 902.25 are on a dead network. Everything has to move together.

ParameterMeshCore 500
Frequency919.500 MHz
Bandwidth500 kHz
Spreading factor10
Coding rate4/5 (shows as 5)
Path hash mode1 — 2-byte (some apps say 1-2 byte)
set radio 919.5,500,10,5
set path.hash.mode 1
reboot

Path hash mode

A repeater’s path hash is the first N bytes of its public key — a truncated fingerprint identifying it in a packet’s recorded route. path.hash.mode chooses how many bytes each hop consumes:

ModeBytes per hopDistinct IDsMax hops
0125664
1265,53632
2316,777,21621

The path field in a MeshCore packet is capped at 64 bytes, so wider hashes trade maximum hop count for fewer collisions between repeaters. One byte gives only 256 possible IDs, which on a growing regional mesh produces genuine clashes; two bytes effectively eliminates them while still allowing 32 hops — far more than any real route needs. That is why PhillyMesh standardised on mode 1.

set path.hash.mode 1
Mixed fleets are fine

This needs firmware 1.14 or later. A repeater on 1.14+ forwards one-, two- and three-byte paths regardless of its own path.hash.mode, so the setting governs what a node originates, not what it relays. Older repeaters cannot forward multi-byte paths at all.

Why 500 kHz

These meshes operate as unlicensed Part 15 devices rather than under an amateur licence — the default encrypted channels would be a problem under Part 97, which prohibits obscuring the meaning of a transmission. That puts them under 47 CFR §15.247, where digital modulation in the 902–928 MHz band must have a minimum 6 dB bandwidth of 500 kHz.

That one rule disqualifies most familiar presets. MeshCore’s own US default of 910.525, 62.5, 7, 5 is 62.5 kHz — eight times narrower than the floor. On the Meshtastic side the same rule leaves only LongTurbo.

The 1W output is not the problem: §15.247 permits up to 1 watt conducted in this band for digital modulation, which is what a booster module is built for. Antenna gain above 6 dBi requires a corresponding power reduction.

PhillyMesh position, Aug 2026

Infrastructure nodes move to MeshCore 500 as the primary network. LongTurbo tested poorly for region-wide use — workable hyper-locally, but it would not carry from the city to the suburbs the way LongFast did. Dual-radio sites keep Meshtastic LongTurbo on the default frequency slot alongside. The LF910 test ended because it was not compliant.

Migration is all-or-nothing

Radio settings are all-or-nothing. MeshCore 500 and the stock 910.525/62.5 defaults cannot hear each other, and neither can the revised 919.5 profile and the original 902.25 one — a node left on the old frequency is simply absent from the mesh. Every node you own has to move together, companions included.

The W2MMD Clubhouse node

A worked example of everything above: the club’s own MeshCore repeater. Note the distinction — this is a MeshCore data node, unrelated to the club’s voice repeaters, and invisible to every Meshtastic tool including the MeshMon dashboard.

Node identification read 2026-09-03 · profile revised 2026-10-06
Name
W2MMD Clubhouse
Role
MeshCore repeater (gateway)
Firmware
MeshCore v1.17.1-d929643 · 14 Aug 2026
Board
WisCore RAK3401 + RAK13302 1W booster
MCU / radio
nRF52840 · SX1262 + SKY66122 PA
Antennas
915 MHz SMA on RAK13302 (live) · 2.4 GHz PCB on RAK3401 (idle)
Host port
USB serial on the clubhouse workstation
Public key
CC247CAA69D682305F66A5DEF7195B1D514611DD0CC3AEAB4C6D6F6EF09AAA14
Network
PhillyMesh MeshCore 500
Radio
902.25 MHz · BW 500 · SF 11 · CR 5 — superseded, needs retune
Should be
919.5 MHz · BW 500 · SF 10 · CR 5 · path.hash.mode 1
TX
22 dBm at the chip → ~30 dBm after the booster
Position
39.716999, −75.2099533
Adverts
zero-hop 60 min · flood 12 h
Guest password
(ask a club officer)

Reaching it

Repeater firmware, so: config.meshcore.io in Chrome or Edge on the machine holding the USB cable (WebSerial needs a local connection), a serial console at 115200, or remotely over the mesh with the admin password once something has heard its advert. No Bluetooth — the repeater build has none.

Node-specific notes

  • TX 22 is correct — do not raise it. +22 dBm is the SX1262’s own hardware ceiling; the RAK13302’s SKY66122 amplifier takes that to roughly 30 dBm at the antenna. The node is already at full output.
  • Two antennas, mechanically interchangeable connectors. The flat PCB antenna belongs on the RAK3401 (2.4 GHz, idle under repeater firmware); the SMA whip via IPEX-to-SMA belongs on the RAK13302 (915 MHz, 1W). MHF1 and IPEX/U.FL will seat in either socket — crossing them puts 1W into a 2.4 GHz PCB antenna and kills the amplifier.
  • Flash only the RAK_3401 target. Never RAK4631, for the SPI1 and pin-31 reasons in the flashing section.
  • The clock needs re-setting after any reboot, including every set radio. It has run correctly across USB unplugs because the battery keeps it alive.
  • Windows gives one program exclusive use of a serial port. The config tool, a PuTTY window, or a stray Python process will lock everyone else out with Access is denied.

Status as of 3 Sep 2026

As last read on 3 Sep: battery 4175 mV, noise floor −88 dBm, receiver alive and measuring, recv 0 with recv_errors also 0 — it had heard nothing at all.

It is now on the superseded profile. PhillyMesh revised MeshCore 500 on 6 October, so this node and the club’s companion nodes all sit on a frequency nothing else is using. Firmware v1.17.1 is still the current release, so no firmware update is needed first — only the retune:

set radio 919.5,500,10,5
set path.hash.mode 1
reboot
# the reboot wipes the clock — set it again afterwards
time <epoch>

Until that is done, the zero recv count says nothing useful about coverage.

Troubleshooting

The node boots but answers nothing on serial

Work down in this order:

  • It may be a companion build. Companion BLE is silent on USB by design; Companion USB answers only the binary protocol, never text. Neither is a fault.
  • Line states. Opening a serial port asserts DTR and RTS, which holds an ESP32 in reset. Open with both deasserted, then pulse RTS to boot into the application.
  • Board-target mismatch. Wrong variant means a clean boot and no working I/O. Reflash with the exact target.
  • Charge-only cable. Enumerates nothing, looks like a dead board.

The node is alive but hears nothing

  • Radio mismatch. get radio must match the rest of the mesh on all four values. One wrong number is total silence, not reduced range.
  • Adverts off. Nothing can route to a node that never announces itself.
  • Nobody there. On a newly adopted profile, an empty neighbors may simply mean no one else is on it yet. Check recv_errors: zero alongside zero recv means an empty band, not a broken receiver.
  • Antenna and feedline. Confirm the SMA cable is on the LoRa module and not the BLE socket — the connectors mate either way.

“Access is denied” opening the port

Windows gives one program at a time exclusive use of a serial port. Close the other terminal, browser tab, or script.

Forgotten admin password

No recovery and no getter. Set a new one over USB with password <new> — physical access is the intended override. Do not reach for erase: that changes the public key, and every contact in the mesh loses the node’s identity.

Don’t point Meshtastic tools at any of this

Separate protocol. The meshtastic CLI and the MeshMon collector cannot read a MeshCore node and will error on the port. Equally, MeshCore nodes are invisible to the MeshMon dashboard by design — not a fault to chase.

Sources — MeshCore FAQ · CLI commands · companion protocol · RAK_3401 variant PR #1387 · flasher · config tool · web client · meshcore-cli

Device values read live over USB serial, 28 Aug and 3 Sep 2026. Web/WiFi variant details are from documentation, not from a node tested here.

 Save as PDF

Archives

  • July 2024
  • November 2023
  • April 2023
  • March 2023
  • June 2022
  • July 2021
  • April 2021
  • March 2021
  • September 2020
  • September 2019
  • August 2019
  • July 2019
  • June 2019
  • December 2018
  • November 2018
  • October 2018
  • September 2018
  • August 2018
  • July 2018
  • June 2018
  • May 2018
  • April 2018

Categories

  • Balloon
  • Clubhouse Infrastructure
  • Digital Position Tracking
  • Raspberry Pi
  • Satellite Images
  • Satellite Operations
  • Satellite Telemetry
  • SDR
  • Uncategorized
  • Home
  • Club Activities
    • WSPR Activities
      • Current WSPR & Band Report
      • Clubhouse WSPR Station Report
      • WSPR Network Monthly Reports
        • September 2026
        • August 2026
        • July 2026
        • June 2026
        • May 2026
        • April 2026
      • WSPR Field Day 2026 — Propagation Comparison
    • Satellite Activities
      • Saturday Clubhouse Satellite Opportunities
      • Weekly Satellite Report
      • Upcoming ISS APRS Activities
      • Upcoming ISS Viewing Opportunities
      • GOES 19 Weather Video
      • Current ISS SSTV Images
    • Recent DMR Activity
  • Clubhouse
    • Saturday Clubhouse Weather
    • The GCARC Clubhouse
    • Grounding Project
    • Networking Infrastructure
    • Work and Test Bench
    • Clubhouse Satellite Station
      • Satellite Rotator Controller
      • Satellite Station Remote Operation
    • SatNOGS Ground Station
    • Earth-Moon-Earth (EME)
    • Discovery Satellite Snooping Dish
    • GOES-19 Satellite Reception
    • Clubhouse Remote nRSP-ST Resource
    • Skunkworks GitHub Resource
    • ISS SSTV
    • NOAA Weather Fax
    • ADS-B
  • Technical Resources
    • Working Meteor Scatter at W2MMD
    • WSPR Network Resources
      • The TAPR WSPR Board for Dummies
      • Why Is My WSPR Signal 1500 Hz Off? — A Tale of Two Frequencies
      • GCARC WSPR Network — Project Description
      • GCARC WSPR Network — Technical Reference
      • GCARC WSPR Network — Band Selection Guide
      • GCARC WSPR Network — Analysis and Reporting
      • The GCARC WSPR Network — Member Q&A
    • DMR
      • What is a DMR Codeplug?
        • What Are DMR Channels?
        • What Are DMR Timeslots?
        • What is a Talkgroup in DMR?
        • What Are DMR Zones?
      • What is a DMR Hotspot?
      • Configuring DMR Hotspot for GCARC Talk Group
      • Connecting to the GCARC DMR TalkGroup with a Yaesu System Fusion Radio and a Hotspot
      • Using DM-1701 CPS Program
      • Open GD77 on Baofeng DM1701
      • Pi-based OpenGD77 Flasher: Bypassing Windows Driver Headaches
        • OpenGC77 Codeplug
    • Software-Defined Radios
      • Software Defined Radio Demystified
      • Installing an RTL-SDR on a Windows PC
      • SDR Tech Saturday Presentation January 2025
      • SDR Client Applications for Mac
      • Creating a PiAware Station to Track Airplanes
        • Installing PiAware Using the Prebuilt SD Card Image with Raspberry Pi Imager
        • Installing PiAware using Command Line Commands
    • Receiving ISS SSTV Images
    • Meshtastic and MeshCore
      • MeshCore Node Handbook
      • Getting Started with Meshtastic on 915 MHz
      • How to Join the GCARC Channel on Your Meshtastic Device Using a QR Code
      • Installing the Meshtastic CLI on a Windows PC
      • Window-Mounted 915 MHz Meshtastic Yagi Antenna Project
      • Meshtastic CLI Commands
    • Exploring Ham Radio Digital Modes: Packet Radio and WSJT-X
      • Packet Radio (AX.25) in Amateur Digital Communications
      • Exploring WSJT Digital Modes
    • BTECH UV-PRO Radio
      • Satellite Mode for the UV-PRO
    • TIDRADIO H3 Resources
      • TIDRADIO TD-H3 Transceiver: Comprehensive Briefing
      • Overview of Stock Firmware Menu System
      • Comparison of Stock TIDRADIO Firmware vs. nicFW V2 Firmware
    • Balloon Project
      • Balloon Launch – 2025-03-17
    • 3D Printed Projects
    • Tech Saturday Presentations
    • Receiving ISS HamTV
  • STEM Activities
    • STEM Club Weather
    • STEM Club Villanova Trip
    • STEM Club Satellite Pass Schedule
    • STEM Camp 2026
      • Calculator Skills — TI-84 Evo
  • Public Service
    • GCARC Planning Documents
      • AuxComm Documents for Review
      • Amateur Radio & Served Agency Integration
      • Building Served Agency Capability
      • The Ham Next Door
      • NIFOG Guide
      • AUXFOG Guide
    • GCARC Resources
      • Winlink VHF and HF Gateways
      • APRS Weather Reporting Station
    • AREDN Development
  • AI Info
  • The Foundation
  • Blog
  • Contact

Gloucester County Amateur Radio Club 2026 . Powered by WordPress