A budget Meshtastic build

By burt Published 2026-07-20 Class Hardware & DIY Read 14 min

Meshtastic is an open-source firmware that turns a cheap LoRa radio board into a node on a text-messaging mesh network. There’s no tower, no SIM card, and no carrier account: a message hops from radio to radio, relayed by every device in range, until it reaches its destination or runs out of hops. Because there’s no carrier in the loop, there’s no phone number attached to a message and no telco generating the retained call-and-SMS records that Australian law otherwise requires of every mobile message you send — a real point of difference from SMS, not just a cheaper one. The figures usually quoted for Meshtastic (331 km, in the project’s own range-test log) describe purpose-built record attempts, not the device that will sit in your bag. Below: a parts list priced in Australian dollars from an Australian retailer, a flashing walkthrough, and a plain account of what the range, the encryption, and the legal transmit limits actually are.

What Meshtastic actually is

A Meshtastic node is a small microcontroller — an ESP32 or a Nordic nRF52 — paired with a LoRa radio chip, almost always Semtech’s SX1262 or the newer LR1110. LoRa (Long Range) is a chirp spread-spectrum modulation: it trades data rate for sensitivity, which is why it can pull a usable signal out of the noise floor at distances a Wi-Fi or Bluetooth radio can’t reach, at the cost of a data rate measured in hundreds of bits per second rather than megabits. Meshtastic’s firmware runs on top of that radio and handles encryption, message relaying, optional position sharing, and a connection to a phone app over Bluetooth Low Energy or USB.

Every node is both a client and, by default, a repeater for other people’s traffic. That’s what makes it a mesh rather than a simple point-to-point radio link, and it’s the reason the “range” question doesn’t have one answer — covered further down.

Two ways onto the mesh, and what they cost in Australia

There are two reasonable paths on a budget: buy something that works the moment you charge it, or buy a board that ships pre-flashed with Meshtastic and add a battery yourself. Prices below are from Core Electronics, an Australian retailer, and each part links to a listing with a public star rating so you can check it yourself before buying.

Cheapest: XIAO ESP32S3 for Meshtastic & LoRa — from A$35.65

Seeed’s XIAO ESP32S3 for Meshtastic & LoRa pairs an ESP32-S3 with a Wio-SX1262 LoRa module, and is A$21.20 including GST at Core Electronics, rated 100% across 6 reviews at the time of writing. It ships pre-flashed and works as soon as it’s powered. It needs a separate battery: a 3.7V 2000 mAh LiPo pack with a 2-pin JST-PH connector is A$14.45 (99%, 71 reviews) and plugs straight into the board’s onboard JST-PH battery input — no adapter needed. Total: A$35.65.

One thing to know before you plan an antenna upgrade: this board’s external antenna port is IPEX (U.FL), not SMA. Attaching a standard SMA whip antenna means adding a short IPEX-to-SMA pigtail first. Fine to do, just budget the extra part and the fiddly connector.

A step up: RAK WisBlock Meshtastic Starter Kit — A$53.75

The WisBlock Meshtastic Starter Kit (RAK19003 base board + RAK4631 core module) is A$39.30 at Core Electronics (100%, though only 1 review on record, so treat that figure as thin rather than definitive) and includes a 2 dBi rubber antenna already fitted to a standard SMA connector — no pigtail required if you want to swap antennas later. It ships pre-flashed with Meshtastic. Add the same A$14.45 LiPo battery above (RAK’s connector is also 2-pin JST-PH) for a total of A$53.75.

Turnkey, no assembly: SenseCAP Card Tracker T1000-E — A$91.40

Seeed’s Card Tracker T1000-E is a credit-card-sized, IP65-rated unit with a Semtech LR1110 radio, built-in GPS, a sealed 700 mAh battery, and its antenna built into the case. Charge it, pair the phone app over Bluetooth, and it’s on the mesh — no flashing, no battery wiring. In Australia it’s A$91.40 at Core Electronics (sometimes discounted closer to A$70), noticeably more than converting Seeed’s own US$39.90 listing price at the current exchange rate, which reflects local distribution and GST rather than a different device. Seeed’s own datasheet lists 2–8 km communication distance “depending on antenna, installation, environments and LoRa mesh,” and up to two days of battery life — not the rosier 5–10 km and three-day figures that circulate in reviews and vendor blurbs elsewhere; the datasheet is the number to trust.

Either DIY board plus a battery lands under A$55; the T1000-E costs roughly 70–90% more for the convenience of skipping assembly entirely.

Flashing the firmware

All three boards above already ship pre-flashed, so day one requires no flashing at all. You’ll still need this process the first time a new Meshtastic release comes out, or if you buy a bare board that didn’t come pre-loaded:

Connect the board to your computer over USB.
Open flasher.meshtastic.org in Chrome or Edge. The web flasher depends on the WebSerial API, which Firefox and Safari don’t implement.
Select your exact board model — radio pinouts differ between Seeed, Heltec, LILYGO and RAK boards, so “ESP32” alone isn’t enough — and your region (see the regulatory section below).
Choose a normal flash or a full erase. A normal flash installs the new firmware and keeps your existing node name, channels, and radio configuration. The flasher also offers a “Full Erase and Install” option that wipes all of that first.
Pair over Bluetooth LE with the Meshtastic phone app, or use the web client, to finish or check configuration: channel name, pre-shared key, node role.

Use the full erase specifically when jumping between major releases (2.5.x to 2.6.x, say) or when a device is behaving oddly after an update. The reason is concrete: Meshtastic stores its configuration on the device as protobuf-encoded data, and a major release can change that schema. A normal flash generally handles this fine, but it isn’t guaranteed — one documented case had several device types stuck in a boot loop with a “can’t encode protobuf” error after a routine 2.5.5-to-2.5.6 update, resolved by downgrading and re-flashing cleanly. If you erase, export your channel and radio settings first (the app has an export function) and re-import them afterwards, rather than re-entering everything by hand.

Meshtastic firmware moves fast: check the GitHub releases page yourself before flashing, rather than trusting a version number in any article, including this one. At the time of writing the 2.7.x line has succeeded 2.6.x as the current release. The 2.6 release introduced a browser-based local configuration page (reachable at meshtastic.local over Wi-Fi or USB without the phone app), more efficient direct-message routing that avoids flooding the whole mesh with point-to-point traffic, and tighter LoRa slot timing that reduces collisions on a busy channel — detailed in Meshtastic’s own 2.6 preview post; those features carry forward into 2.7.

How a message actually crosses the mesh

An ordinary network — the Wi-Fi router at home, or the core of the internet — keeps a routing table: a stored list mapping each destination to the next hop that gets a packet closer to it, built and updated by protocols that continually probe the network’s shape. Meshtastic keeps no such map. Instead it uses managed flooding. When a node transmits, every neighbour that hears it rebroadcasts the packet once, with a hop-limit counter (3 by default) reduced by one at each rebroadcast. A node that has already seen a given packet’s ID drops any further copies instead of rebroadcasting them again; that duplicate suppression is the “managed” part — without it, a mesh of any size would drown itself in echoes within seconds. There’s no path chosen in advance and no single relay whose failure breaks the network: the message simply spreads outward until it reaches every node the hop limit allows.

A five-node mesh where node A and node E are never in direct radio range of each other. The message still arrives via two intermediate hops. Node D receives the same packet twice, once via each relay, and drops the second copy because it has already seen that packet ID.

The consequence: every extra hop adds latency, and because every node in range rebroadcasts, every hop also consumes airtime shared by the whole channel. The default hop limit of 3 can be raised to 7, but each increase multiplies how many rebroadcasts a busy mesh generates. This is a shared, very low-bandwidth medium, not a group chat with unlimited headroom.

Antenna choice

Meshtastic radios use a 50-ohm connector, usually SMA, and most boards ship with a short quarter-wave “stubby” antenna. Meshtastic’s own antenna documentation is direct about the trade-offs: a directional antenna reaches further than an omnidirectional one but has to be pointed at the other end, and a tuned half-wave whip generally outperforms the stock quarter-wave stubby for all-round use, at the cost of being noticeably less pocketable. Quarter-wave stubby antennas specifically rely on the device’s own circuit board to act as part of the antenna (a “ground plane”), so their performance is sensitive to exactly how the board is held or mounted — inside a metal case or gripped in a fist, it will perform worse than sitting in the open.

For a fixed base-station node — something mounted at a window or on a roof, not carried — a taller fibreglass omnidirectional antenna with several dBi of gain and quality low-loss coax is worth the money, because the node isn’t moving and elevation plus line of sight matter more than anything else. That’s solving a different problem to a handheld unit in a pocket, where the stock antenna, or a flexible whip upgrade, is the sensible choice.

Range: the record books versus what you’ll actually see

The eye-catching Meshtastic range figures are real, but they describe purpose-built attempts, not day-to-day carrying. Meshtastic’s own range-test log records a 331 km ground-to-ground contact between two mountains, on 868 MHz using the slowest (“Very Long Slow”) modem preset and specialised antennas at both ends, and a 206 km air link achieved by lifting one node on a balloon. Both required unobstructed line of sight over enormous distances, achievable from mountaintops or altitude, not from a suburban street.

The same protocol produces very different numbers depending on antenna, elevation and obstruction: roughly 2 km with a stock antenna through suburban buildings and trees, up to 8 km for a purpose-built tracker per its own datasheet, and well over 200 km for record attempts using elevation and specialised hardware.

Community range testing with stock stubby antennas through obstructed suburban terrain — houses, trees, no clear line of sight — has produced results around 2 km. Seeed’s own T1000-E datasheet specifies 2–8 km node-to-node, and is explicit that the figure depends on antenna, installation, environment and the state of the mesh, not a single clean number. Line of sight is the dominant variable here, well ahead of antenna gain, and far ahead of transmit power, which regulation caps tightly regardless (next section).

Regional power limits and duty cycle

Meshtastic’s region setting isn’t cosmetic. It sets the legal frequency plan, the power ceiling, and, in some regions, a duty cycle limit for the device, and transmitting on the wrong one is a regulatory breach, not just a technical mismatch. Per Meshtastic’s radio settings documentation:

US (US915, 902–928 MHz): up to +30 dBm ERP, with no duty cycle restriction under FCC Part 15.
Europe (EU868, 869.40–869.65 MHz): capped at +27 dBm ERP, with a 10% duty cycle enforced on a rolling one-hour basis — in practice, about six minutes of total transmit time per hour, shared across your own traffic and anything you relay for others.

Australia and New Zealand use the ANZ region setting, chosen in the app under Radio Config → LoRa → Region. The 915–928 MHz band here is available licence-free as a low-interference potential device (LIPD) class under ACMA rules, capped at 100 mW ERP for licence-exempt use — well below the US ceiling above, per the summary at is-this-legal.com. No licence is needed within that limit, but setting the wrong region — US915 instead of ANZ, for instance, because a guide you followed was written for an American audience — puts a device outside it.

What’s actually private here, and why people use it at all

Most people looking at Meshtastic as a privacy tool are comparing it to SMS, not to a hiking party’s two-way radios. That comparison is where it’s genuinely strong, for a specific and checkable reason: under the Telecommunications (Interception and Access) Act 1979, as amended in 2015, Australian carriers and internet providers must retain a defined set of metadata for every communication — including SMS — for two years: subscriber identity, the type of communication, and the location of the equipment used, though not its content. That metadata is accessible to law-enforcement and other statutorily authorised agencies without a warrant; only the message content itself needs one, per the Act’s own terms. An SMS you send necessarily creates that retained record, tied to your name and account. A Meshtastic message doesn’t, because there’s no carrier account generating it in the first place — no SIM, no phone number, no telco in the loop to retain anything.

That’s a real and specific advantage. It is not the same thing as the message content being unreadable to a nearby listener, and the two shouldn’t be conflated.

The default “LongFast” channel uses a pre-shared key published in the firmware source itself, so any Meshtastic device on that channel, including a stranger’s, can decrypt it. Direct messages, since firmware 2.5, use a Curve25519 key exchange to derive a key unique to each pair of nodes, readable only by those two endpoints.

The default primary channel, “LongFast,” uses the pre-shared key AQ== — base64 for a single byte, published in the firmware source and identical on every default Meshtastic install. Left as-is, anyone with a Meshtastic radio in range, on the default channel, can decrypt everything sent on it, including position if position sharing is on. That’s intentional — it’s meant as a common channel anyone can join — but it provides no confidentiality against a nearby listener, and Meshtastic’s documentation says so plainly.

Direct messages are different since firmware 2.5, which added public-key cryptography for DMs. Each node generates a Curve25519 keypair on first boot; two nodes perform a Diffie-Hellman exchange on first contact, and the resulting shared secret encrypts and authenticates messages between just that pair, using AES-CCM. That’s a real improvement over the earlier model, where every message, direct or broadcast, used the same shared channel key. It falls back to that weaker channel-key encryption if a node has no known public key yet for the recipient, which is worth checking if you’re relying on it.

Two further points worth knowing. Connecting a node to the public MQTT bridge (mqtt.meshtastic.org) uplinks map and position data to the internet; the default server truncates position precision to 10–16 bits to limit exposure, which reduces but doesn’t remove the leak — running a private broker is the actual fix if you’re bridging at all. And per Meshtastic’s own documented encryption limitations, the node ID and packet ID double as the encryption’s initialisation vector, so an attacker who reconstructs the plaintext of one packet can potentially forge later packets under that same node/packet-ID pair; and the node database, capped around 100 entries on most hardware, evicts old entries under memory pressure, after which a node number can be reused by an unrelated device with no way for the rest of the mesh to tell the difference, because trust in a node’s identity is on first contact rather than centrally verified.

What it’s actually useful for

The core case is avoiding a carrier relationship altogether: coordinating with people nearby without either party’s phone generating a metadata trail tied to a SIM and a name. Beyond that, it’s also a reasonable fit for coordinating a small group somewhere with no phone signal at all — a property with no reception, or a site where infrastructure is down or deliberately unavailable — though anyone whose primary need is that (rather than avoiding carrier metadata specifically) should weigh it against a plain UHF/VHF handheld radio, which is simpler, cheaper, and doesn’t depend on a mesh of relaying nodes being in range at all.

It isn’t a substitute for an encrypted messenger like Signal for anything where message content matters and a nearby adversary might be listening: keep to direct messages rather than the default channel, remember that who’s talking to whom is exposed to any radio in range in a way an internet-routed messenger doesn’t expose, and don’t uplink to public MQTT if that visibility is a concern.

Limitations

Text only, and slow: the LoRa presets Meshtastic uses run at a few hundred bits per second, shared across every node in range.
The default channel and its published pre-shared key provide no confidentiality against anyone nearby with a Meshtastic radio; only direct messages get per-pair encryption, and only once both sides already know each other’s public key.
It hides content from a nearby eavesdropper on the default channel poorly, but it removes the message from the carrier metadata trail that SMS generates entirely — those are two different kinds of privacy, and neither substitutes for the other.
Practical range depends overwhelmingly on line of sight; expect single-digit kilometres in built-up terrain, not the tens or hundreds of kilometres quoted in record attempts.
Node identity is trust-on-first-contact with no central verification, and a node database that evicts old entries under memory pressure, creating a window for identity confusion.
A firmware update across a major version can require a full device wipe if a normal flash doesn’t handle the configuration-schema change cleanly, resetting channels and the node database.
Transmit power and duty cycle are capped by regional regulation; the ANZ ceiling of 100 mW ERP is well below the US915 allowance, and choosing the wrong region setting is a compliance problem, not just a performance one.