meshtastic

  1. services

After reading this [LWN review][] and being poked a few times by friends, I started playing around with meshtastic.

Note: I have started a whole website for the Montreal mesh project and will progressively migrate at least some content from here to there.

  1. meshtastic
  2. Range
  3. Scalability
  4. Privacy and security
  5. Hardware
    1. SenseCAP Card Tracker T1000-E
      1. Bricked
      2. Fun story
    2. T-Deck Plus
    3. T-Echo
    4. SenseCAP Solar Node P1
    5. XIAO nRF52840 & Wio-SX1262 Kit
    6. XIAO ESP32S3 & Wio-SX1262 Kit
    7. Other owned devices
    8. 2026 order
    9. Other devices
  6. Software
    1. Flashing special firmware
  7. MQTT
    1. Public gateways
  8. Links
  9. Fellow meshes
  10. Alternative LoRa networks

Range

I have, for a brief moment, seen a couple of nodes 20km away. I suspect it's because a fellow meshtastic user was traveling nearby and relaying those signals, as I haven't seen any more signals in a while.

I assume I can reach about 1-2km away in the city, but I have yet to get solid confirmation on this. I don't have an antenna high up yet so this is just with handheld devices.

In theory, range is line of sight which, if you're on top of mountains across the Adriatic sea, is over 300 kilometers. Meshtastic keeps track of records like those.

In practice, you can expect single or double-digit range depending on your hardware and prominence.

The site planner can help you show what you should be able to see. Combine with one of the maps, you should get a good idea of what you should be seeing.

Scalability

I have serious concerns about the scalability of the Meshtastic algorithm. It is basically "rebroadcast everything you get, up to three hops" and while they are pretty good at "marketing" it, my hunch is that this won't scale to a dense, thousand-node busy network, especially since everything (including direct messages) is on a common carrier.

@nullagent has a long rant about this on Mastodon that confirms my hunch and made me write this section. A few quotes:

Floodfill can't scale.

That's the core issue with meshtastic.

All the nodes repeat what they hear, kinda like "the people's mic" at a protest. This strategy is great if we all want to hear ONE person's speech across a whole crowd.

But try the people's mic with 10's hundreds or thousands of different bi-directional conversations and things get messy.

We're all shouting to hear and expecting the person next to us to repeat. But all they hear is noise and very rarely a few words here & there

I -frequently- run out of hops NOT network!

The broadcast algo eats up all the hops in the core downtown and rarely makes it out the otherside with low hop limit or even with the max

More concerning is his criticism of the core team culture:

The project is run in the usual tech-bro seeming ways and are rude ass fuck to new comers with less experience / platform than I who've made the -same- observations about floodfill's limits.

The core team is dying on the hill of the shitiest routing algo possible because they I guess don't want to read anything about routing research.

Bruh... I worked in a networking research lab in the early 2000's, almost every excuse this team has made is bullshit.

So when I have spent time and money learning an open source project, encouraged friends to also go learn and spend money.... and then the core team is rude as fuck to them when they have polite and honest feedback.... yea fuck that noise.

Meshtastic is gonna fail on the same dumb hill as many tech-bro led projects, fighting their community over dumbshit.

It's a perfectly fine toy of a project to learn LoRa but please know better is possible and we don't have to deal with these assholes.

He points at Meshcore and Reticulum as possible replacements.

Many mesh nets have switched to MediumFast as a response to some scalability problems, which is also described on this official blog post, which include:

Privacy and security

Default security is pretty much non-existent: in the default channel, packets are encrypted, but with a known key.

Other channels seem to use pretty solid encryption, but there's likely metadata leakage ("who is talking to who") in cleartext over the airwaves that can be easily sniffed by anyone in range. Joining a MQTT server makes that even easier to sniff.

Also note that Meshtastic only does encryption: you don't get things like forward-secrecy, authentication, or integrity, see the encryption section. This sounds minor, but this is a significant threat vector as, for example, if someone knows you wrote "hi" to a channel, even if they don't have the encryption key, they can replay that "hi" by sending the exact same encrypted packet. Security is hard. It seems like Reticulum does this better.

Nodes often transmit other telemetry like GPS location, temperature, and other sensors, by default. GPS location precision can be reduced (say "I'm in Montreal" instead of "I'm at 1234 boulevard Saint-Laurent") or completely turned off, but it might still possible to triangulate device's positions, as with any typical radio transmission. LoRa signals are "bursty" and low power, so that's more difficult than, say, classic ham radio signals though.

There's a Meshtastic ZPS project that tries to implement GPS-less localization, but it's using external positioning systems and WiFi/Bluetooth scans instead of a GPS, so it's not triangulation per se.

Weak default Bluetooth pairing codes (the "PIN") are often luggage-strength like 1234 or 123456. They should be changed unless you're okay with anyone within range taking control of your devices.

Physical access to the devices also likely leads to full compromise as devices can generally be put in "DFU" (Device firmware upgrade) mode relatively easily.

Hardware

Below are some Meshtastic-compatible devices I have personally tested and own.

Those are mostly taken from official device list, which you should consult for recommendations, particularly on chipset tradeoffs (e.g. ESP32 uses more battery, but is cheaper).

SenseCAP Card Tracker T1000-E

The SenseCAP Card Tracker T1000-E is a neat little device:

It has no display or keyboard, only a single button, a LED, and a "buzzer", kind of like the old PC speakers.

It's about the size of a credit card, but thicker (it won't fit in your wallet, but will definitely fit in your pocket).

My first battery test run lasted 3 days at which point it dropped from about 50% battery to zero in about an hour. Possibly the battery controller learning some things about itself. Their website specs it at 2 days battery. The battery recharged in a little over an hour (1h15m or so).

Only downside is it requires a phone, but it's a great device to start with as you can just shove it outside for three days and see what you pick up.

Make sure you configure the device: this will bring you environment sensors and a neat trick to find the device if lost, see below.

Note that the intro guide has crucial information about the device, but know that those are the functions of the main button:

Button action Description Buzzer
Press once Power on Rising melody
Press twice Update node/location info -
Press three times Switch on/off the GPS -
Press and hold for 5s Power off Falling melody

Bricked

Update: at the moment, the T1000-E is essentially bricked. I think I failed to do a wipe correctly and it just loops on the boot loader until it runs out of battery.

I have found the device much more difficult to debug than other platforms, and don't encourage getting one for development at least, if at all.

And yes, I did managed to get in DFU mode and reflash the firmware, I even tried to flash the bootloader, it never recovered.

Fun story

I lost that device one day! I had put it on top of a doorframe on the second floor to get better range, but when i came back at lunch, it wasn't there! I looked around on the floor, couldn't find it... but my phone could reach it over Bluetooth, so it was still around somewhere!

So i followed the upstream guide to setup the sensors, which includes a setting to use the "buzzer" to make sounds when new messages are received. So I started sending messages to the card from another Meshtastic device (the T-Deck+), which made the thing "buzz", and I could hear it!

It wasn't on the second floor anymore though. After about 2 minutes and 10 "ping" messages sent, I found it! It had fallen two floors down, in the basement stairwell, and here it was ringing... phew!

Seems like it survived the fall too. Amazing little device, and Meshtastic success!

T-Deck Plus

The T-Deck Plus is another unique platform:

The "meshtastic" firmware that comes with it is just bad, definitely not worth paying for. There's a "pre release" "technical preview" (2.6.0.f7afa9a) that is much better (see below), although writing this I have just noticed than the 2.6.3 "alpha" release. I have actually performed the following upgrades so far:

I have tried flashing at 115200 at first but 921600 seems to work fine too over USB. USB-C to USB-C does not work though, I need a USB-C to USB-A cable, bizarrely.

To flash the device, one needs to:

  1. power it off
  2. hold down the middle, black pointer ball
  3. switch on the power (the flip switch on the right)
  4. connect the USB cable
  5. release the middle ball once the USB device comes up

You will know it works when it shows up as a "Product: USB JTAG/serial debug unit" instead of "Espressif Systems LilyGO T-Deck (16 MB FLASH, 8 MB PSRAM)".

I couldn't use the GPS at first, and filed an issue which was promptly fixed: you need to enable it: from the UI, hold the "pin" logo in the main screen, this will turn on GPS and reboot. Same with wifi, one row below: hold the wifi icon and it will turn on WiFi and reboot.

There seems to be an issue with the remote control interface: I have found that I need to reboot in "programming mode" to get access to the Bluetooth interface to control it from my phone. According to this issue this might be fixed in newer firmware, but I have a fairly recent one and it didn't work. It could be a conflict with WiFi as well. According to the Meshtastic docs though, it's just the way it is.

Note that the device works as normal in programming mode: it's just the user interface that's different, but it otherwise receives, relays and sends packets fine, which is useful if you wan to do a range test.

All in all, this is a pretty amazing machine and one of the rare systems that allows communication without any other external device (like a phone or computer), which is really great. The new UI is fantastic, and you even have a rudimentary map showing remote nodes with offline maps

One improvement I want to do is to add an external antenna to increase the range, because as it is now it's not great. Apparently, there's an on-board ipex connector, so I'd just need a IPEX/SMA connector and a LoRa antenna.

The device was donated to a family member.

T-Echo

The T-Echo is an interesting device: e-ink, tiny, NRF5280 circuit, 53$USD

Built-in firmware is too old for the Android app.

Chrome-based flasher works well. Reflashtic works, but i had to specify the mountpoint because it is named TECHOBOOT and not T-ECHO:

./reflashtic.py --interactive --mountpoint /media/anarcat/TECHOBOOT/

The top-left button is the "reset" button, which I find a little counter-intuitive: I was expecting it to be a "confirm" button, and the "reset" button to be less accessible. But it works: double-click that button and it goes in DFU mode.

I left the GPS enabled but configured the node to not send its position in the LongFast channel for privacy reasons.

The device is pretty neat: it's tiny and light, much lighter than the Wispocket, while also being more compact. It feels a little more brittle, however, but I suspect it might be flyable on a drone.

There's a InkHUD interface that Meshtastic is developing. I'm not sure how it differs from the standard one.

I compared the battery of the T-Echo with the RAK WisMesh Pocket. Between 2026-03-16T20:53 and 2026-03-18T10:38 (so 37h45m), the devices went from full to 55% for the RAK and 18% for the T-Echo. This gives an estimated remaining time for the RAK of 46h8m, so a total run time of 3 days, 11h and 53min or 83h53m. At this rate, the T-Echo has 9h26m left, with a total 47h11 m.

This means the RAK has 1.8x the T-Echo battery life even though it has a much larger (and heavier) battery (3200mAh vs 850mAh), specifically 3.8 times larger.

Also, the USB-C charge controller is weird: if you plug it in a modern charger, it just doesn't pick up the charge. You must plug it in a legacy 5 volt USB-A charger for the charge to work, which is pretty annoying because I'm more and more standardizing on USB-C here.

Finally, I tested Meshcore on that thing and didn't see any relays. Worse, the firmware seems to use more power than the Meshtastic one, although I can't tell for sure. It has that neat feature that the backlight turns on when you tap the top "button".

SenseCAP Solar Node P1

The SenseCAP Solar Node P1 looks really nice: outdoors solar-powered relay with 4x18650 batteries, nRF4840, GNSS, BT 5.0, 3 power buttons, 5 LEDs, USB-C for debug, recommended by nyme.sh. At 70$USD, it's cheaper than its RAK wireless equivalent.

I first thought I could power it with only two 18650 batteries, but that doesn't seem like it.

Flashing it with reflashtic was also straightforward, the mountpoint is XIAO-BOOT. I marked the GNSS as NOT_PRESENT to speed up boot time, because otherwise Meshtastic was spending a couple of seconds probing for a device, at least in the shipped firmware (2.6.9) which does work with the current app.

I was surprised to see the machine boot up with minimal of indirect sunlight. Unfortunately, without batteries, it can't actually send messages out right now. I've tried slotting in batteries but it turns out it's better to actually charge those 18650 before you put them in solar equipment: that way, the solar only needs to top off batteries instead of bringing them up for nothing.

Next up on this one is outdoors endurance tests while, unfortunately, spring is coming (so no winter test yet, sorry).

XIAO nRF52840 & Wio-SX1262 Kit

The XIAO nRF52840 & Wio-SX1262 Kit is the smallest LoRa + Bluetooth kit I have ever seen. At 8mm × 22mm × 23mm, it's a little larger (but way spikier) than my thumb.

It ships with a Meshtastic 2.6.2.31c0e8f firmware, and I was able to flash it from the Chrome app. There is an extremely tiny "RST" button that allows it to flip to DFU, but I didn't find it until after trying out the web flasher.

Flashing through Chrome works as it seems to be able to kick the device over to DFU mode from the serial port, which makes me think this is something we should add to reflashtic.

XIAO ESP32S3 & Wio-SX1262 Kit

The XIAO ESP32S3 & Wio-SX1262 Kit is... something else. It doesn't look like it comes flashed with Meshtastic. Here's what the serial port looks like when you click the button twice:

I (147784) NimBLE: GAP procedure initiated: advertise; 
I (147784) NimBLE: disc_mode=2
I (147784) NimBLE:  adv_channel_map=0 own_addr_type=0 adv_filter_policy=0 adv_itvl_min=0 adv_itvl_max=0
I (147784) NimBLE: 

I (148894) NimBLE: GAP procedure initiated: stop advertising.

According to upstream, this is the "LoRa single-channel gateway firmware". It seems like the web flasher is able to flash a "community maintained" firmware, but that actually fails to boot with a loop on:

ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x3 (RTC_SW_SYS_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x403cdd11
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fce3810,len:0x178c
load:0x403c9700,len:0x4
load:0x403c9704,len:0xcbc
load:0x403cc700,len:0x2da0
entry 0x403c9914
I (26) boot: ESP-IDF v5.2.1-dirty 2nd stage bootloader
I (26) boot: compile time Nov 28 2024 14:14:32
I (26) boot: Multicore bootloader
I (30) boot: chip revision: v0.2
I (34) boot.esp32s3: Boot SPI Speed : 80MHz
I (38) boot.esp32s3: SPI Mode       : DIO
I (43) boot.esp32s3: SPI Flash Size : 8MB
I (48) boot: Enabling RNG early entropy source...
I (53) boot: Partition Table:
I (57) boot: ## Label            Usage          Type ST Offset   Length
I (64) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (71) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (79) boot:  2 factory          factory app      00 00 00010000 00177000
I (86) boot: End of partition table
I (91) esp_image: segment 0: paddr=00010020 vaddr=3c170020 size=6dd68h (449896) map
I (180) esp_image: segment 1: paddr=0007dd90 vaddr=3fc99e70 size=02288h (  8840) load
I (182) esp_image: segment 2: paddr=00080020 vaddr=42000020 size=168534h (1475892) map
I (450) esp_image: segment 3: paddr=001e855c vaddr=3fc9c0f8 size=061a8h ( 25000) load
I (456) esp_image: segment 4: paddr=001ee70c vaddr=40374000 size=15e68h ( 89704) load
I (476) esp_image: segment 5: paddr=0020457c vaddr=50000000 size=00004h (     4) load
I (476) esp_image: segment 6: paddr=00204588 vaddr=600fe000 size=0002ch (    44) load
E (482) esp_image: Image length 2049504 doesn't fit in partition length 1536000
E (490) boot: Factory app partition is not bootable
E (495) boot: No bootable app partitions in the partition table
...

But that's because the partition table was incorrect. If that happens, reflash and try a "full erase", it worked in my case.

This is a neat case: small and handy, but without display or battery. Probably the cheapest kit out there.

Other owned devices

I also own those devices, but have not written a thorough review:

2026 order

The above was ordered and tested in 2025. In 2026, I did it again and ordered a bunch more devices to examine, test, and give away.

I did not get the LoRa antenna (10$USD) because it was adding a whopping 70$ in shipping fees.

I'll need to find 18650 batteries for the Heltec devices. I assume this is about 5$ each. I could have gotten batteries with the build (2$USD) but it makes shipping more complicated and expensive, so I went the quicker way.

Other devices

The devices listed here have been moved to the local mesh hardware review guide.

Power is a whole other question, see power consumption measurements and old reseaulibre power notes

Devices without cases typically have 3D designs that can be downloaded and printed or bought, see this list.

Software

This section was mostly emptied in favor of the reseaulibre software docs, see there for updates.

Flashing special firmware

Update: this is kept for historical purposes, but this has, sadly, changed... You can now update use alpha releases without entering a secret code.

There are special "technical preview" or "pre-release" firmware available at https://flasher.meshtastic.org but only after you enter the Konami code (yes, really), which is, of course:

↑ ↑ ↓ ↓ ← → ← → b a

Yes, on your keyboard. Yes, in the web browser. The back of the page will turn black and the extra firmware will be shown in the second column. Funky.

In any case, flashing firmware like this only works in Chromium because Firefox doesn't support WebUSB (which is perhaps a good thing).

Note that you can also flash firmware without a web UI, but the flasher web UI is still useful to download the right firmware.

MQTT

Meshtastic devices can typically connect to a MQTT gateway or broker, see the MQTT module configuration. This allows meshtastic users to connect to other users not reachable over LoRa through the internet instead, essentially.

This can be used to extend the mesh around obstacles (like a mountain) or across cities (or stupid things like borders).

In MQTT, you can "scope" traffic by using a "topic". Those are hierarchical. For example, by default meshtastic will setup the topic msh/US if you're in the US region, but you could make that msh/CA or msh/CA/YUL to restrict your scope to YUL (Montreal) nodes. Someone looking at msh or msh/CA would see your traffic, but you wouldn't see theirs.

You could use an entirely different hierarchy like foo/ for yourself, but you are relying on someone not guessing that topic to avoid discovery.

Note that you can still encrypt packets as they go through, but packets have a signature that can reveal metadata.

For MQTT to work, your device needs to have internet access, either through WiFi or Ethernet. If you're connected over Bluetooth, you can also enable the "Client Proxy" mode which will make your phone relay the traffic to the MQTT server instead of the device.

You can run your own MQTT server with opensource implementations. Debian ships with mosquitto (C, well maintained), for example. See also Wikipedia's comparison page, which includes, of course, a Rust rewrite called RMQTT (not packaged in Debian).

Note that brokers can typically relay messages between them. For example, mosquitto supports the concept of bridges so you could use a local broker for your own purposes and relay messages to the official brokers (or a subset of them).

The mqtt(7) manual page provided by mosquitto is pretty good as well.

Public gateways

Links

Fellow meshes

Those are meshes I am particularly paying attention to, because they're friends or they are technically amazing:

See also the Réseau Libre neighbours.

Alternative LoRa networks

Created . Edited .