Sending messages over more than a mile without cell towers, without Wi-Fi, and without paying a monthly fee sounds like a gimmick until you actually do it.

That is exactly what a small MeshCore setup can do. With one solar repeater mounted outside and one handheld companion node in your hand, you can create a private off-grid communication network that keeps working independently of the internet.

This setup uses the Seeed Studio MeshCore starter kit, which includes the MeshCore Starter Kit with a SenseCAP Solar Node P1 Pro and a Wio Tracker L1 Pro. Both come ready for MeshCore, which makes this one of the easiest ways to get a practical LoRa mesh up and running.

Table of Contents

• What MeshCore actually is
• The two pieces that make this network work
• Set up the repeater first
• Mount the repeater where it can actually do its job
• Set up the companion node
• Verify the repeater is visible from the companion node
• Manage the repeater remotely from the app
• How discovery and privacy work in MeshCore
• Test direct messaging across the mesh
• Use public channels too
• What you end up with
• Practical setup checklist
• FAQ

What MeshCore actually is

Before touching the hardware, it helps to understand what MeshCore is doing differently.

MeshCore is firmware built around LoRa, which stands for long range radio. LoRa is designed for tiny packets of data traveling surprisingly long distances while using very little power. It is not about streaming video or moving huge files. It is about reliable low-power communication.

The important part is the network model.

MeshCore uses a routed mesh architecture. Instead of blasting every packet through every node in the network, messages are routed through a better path. In practical terms, that gives you a few advantages:

• better reliability
• better scalability as the network grows
• better battery life
• less unnecessary traffic across the mesh

That is the big distinction from flooding-style mesh systems, where every node gets hammered with every packet. Routed mesh is simply a cleaner approach when you want a network that can grow and keep working efficiently.

The two pieces that make this network work

The starter kit gives you the core building blocks you need.

1. SenseCAP Solar Node P1 Pro

This is the repeater. It is the part you mount outside somewhere elevated so it can stay alive around the clock and extend your network.

It comes preloaded with MeshCore repeater firmware. Internally it is built around a low-power nRF52840 class architecture and an SX1262 LoRa radio, which is exactly the kind of combination you want for a solar-powered always-on node. There is also a built-in GPS module.

On the outside, you get:

• an integrated solar panel on the front
• mounting hardware on the back
• an antenna connection
• a USB port for maintenance or updates
• indicator lights and buttons

2. Wio Tracker L1 Pro

This is the companion node. Think of it as the handheld part of your setup.

It also comes preconfigured with MeshCore companion firmware and pairs to the MeshCore mobile app over Bluetooth. It has a rechargeable internal battery, a small display, USB charging, and a rugged enclosure. There is no assembly drama here. It is ready to use.

If you want the individual hardware pieces, the handheld is the Wio Tracker L1 Pro and the repeater is the SenseCAP Solar Node P1 Pro.

Set up the repeater first

Start with the solar repeater.

The first rule is simple and important: attach the antenna before powering the unit on. Do not skip that.

Screw the antenna onto the repeater first. If you want more flexibility in placement, the kit also includes an antenna extension so you can separate antenna placement from the main body if needed.

Once the antenna is attached, put the unit where it can see sunlight and power it on using the onboard power button. If the panel is getting solar input, you should see the relevant indication from the unit.

Configure the repeater from a computer

Even though the device arrives preflashed, you still want to configure it correctly for your region and network settings.

Connect the repeater to your PC with USB, then open the MeshCore flasher and configuration tool at MeshCore flasher.

From there:

1. Choose Repeater Setup.
2. Click Connect.
3. Select the repeater from the USB device list.
4. Set an admin password.
5. Optionally leave the guest password blank if you want telemetry to be viewable without logging in.
6. Set the correct region. This is the most important part.
7. Optionally fill in owner information.
8. Save and reboot the device.

If you are on Windows and the device does not appear in the USB selection popup, you may need a driver. The walkthrough points to this Windows driver guide. On many Linux and Mac setups, that extra step is usually not needed.

Mount the repeater where it can actually do its job

Once the repeater is configured, get it outside.

The number one thing that improves range is elevation. Higher placement generally means better line of sight, and with LoRa that matters a lot. These radios can handle some walls and trees, but height still makes a dramatic difference.

Good mounting spots include:

• under a roof edge
• on a second-story exterior wall
• on a fence post
• on a mast or rooftop location
• on a tree or elevated structure if mounted safely

Also make sure the solar panel faces the sun well enough to keep the repeater charged. A perfect solar angle is nice, but a bad radio location will hurt you more than a slightly imperfect solar angle. You want a practical balance between sun exposure and elevation.

Set up the companion node

Now move on to the Wio Tracker L1 Pro.

Same rule as before: attach the antenna before powering it on.

After attaching the antenna, use the side button to turn it on. The display should show that MeshCore is loading, along with the firmware version installed on the unit.

Pair it to the MeshCore mobile app

Install the MeshCore app from the Android or iOS app store, then open it and scan for nearby devices.

The companion node should appear in the list. Select it, then confirm the pairing PIN shown on the device screen. Once paired, the app connects over Bluetooth.

After pairing, give the node a meaningful name so it is easier to identify later. Something like a location, role, or personal label is far better than leaving a generic default.

Then set the region on the companion node to match the repeater. If the repeater is configured for USA and Canada, the companion node must use that same region too.

At that point, the handheld should remain connected to your phone and be ready to discover nearby nodes.

Verify the repeater is visible from the companion node

Once both devices share the same region, the companion node should discover the solar repeater automatically when it boots and joins the local mesh.

If it does not show up right away, you can manually scan from within the app by going into the tools area and using the nearby node discovery options.

When the repeater appears, you can inspect telemetry. If you left the guest password blank, you can immediately see useful information such as battery charge and temperature. That gives you quick confirmation that the repeater is online and healthy.

Manage the repeater remotely from the app

This is one of the nicer parts of the setup.

Once your companion node can reach the repeater over MeshCore, you can log in to the repeater from the app using the admin password you set earlier. That means your handheld can act as a management tool for the repeater even after it is mounted outside.

From the repeater management screen you can:

• request full status details
• check battery voltage
• rename the repeater
• update owner information
• change passwords
• sync the repeater clock
• view GPS position data if available
• send an advert so other nodes can discover it
• confirm the configured region

The GPS lock on a repeater is not always urgent, but it is there if you want positional data. Clock sync, however, is worth doing so the repeater stays properly aligned.

How discovery and privacy work in MeshCore

MeshCore is built with privacy in mind, and that affects how messaging behaves.

If one companion node tries to send a direct private message to another node that has not yet added it as a contact, that message will fail. That is expected behavior.

The way around that is node discovery.

A flood route message, which in this context is effectively an advert, announces your presence so nearby nodes can become aware of you. If the receiving node is configured to auto-add discovered nodes, the two sides can then recognize each other and private direct messaging starts working.

So the flow looks like this:

1. Node A sends an advert or flood route message.
2. Node B discovers Node A.
3. The nodes are added to each other, manually or automatically.
4. Private direct messages can now be delivered.

Test direct messaging across the mesh

With the repeater mounted outside and the handheld node connected to the phone, it is time to send messages.

In the demo, one companion node first advertises itself, then a second companion node discovers it. Once both nodes know about each other, direct messaging starts working normally.

The important point is that the message travels over the LoRa mesh, not over the internet. No Wi-Fi connection is needed for the network path itself, and the setup was specifically demonstrated with Wi-Fi disabled to make that point clear.

If you attempt a private message before the nodes know each other, it fails. After discovery and auto-add kick in, the same message goes through and is received on the second node.

Use public channels too

MeshCore is not limited to one-to-one messages.

You can also post into public channels. In the app, the public channel is available for non-direct messaging, and messages sent there can be seen by nodes participating in that channel.

This gives you two useful communication patterns:

• Direct private messages for one-to-one communication
• Public channel messages for broader shared communication

That combination makes the network flexible. You can keep some conversations private while still maintaining an open coordination channel.

What you end up with

Once both devices are configured, the repeater is mounted, and the companion node is paired, you have a real off-grid communication network.

At the smallest scale, it is just two building blocks:

• one solar repeater keeping a local MeshCore network alive
• one companion node that lets you access that network from your phone

From there, you can expand with more repeaters, more handhelds, or more fixed nodes. The routed architecture is what makes that growth practical.

For preppers, outdoor use, emergency communication, or just plain curiosity, this is one of the more compelling ways to stay connected when the normal network stack is gone.

Practical setup checklist

• Attach both antennas before powering either device on.
• Configure the repeater from USB using the MeshCore flasher.
• Set a proper admin password.
• Make sure both devices use the same region.
• Mount the repeater high and in good sunlight.
• Pair the companion node to the MeshCore mobile app over Bluetooth.
• Name the companion node clearly.
• Confirm the repeater shows up in nearby nodes.
• Use adverts or flood route messages for initial discovery.
• Then move on to private messages or public channels.

FAQ

That is exactly what this setup does. A Heltec V4 runs normal Meshtastic firmware, an ESP32-S3 runs WireClaw AI, and together they form a low-cost hardware bridge that can forward mesh messages to Telegram. The same little AI agent can also read sensors, remember custom names for devices, and create automation rules in plain language.

This is part one of the project and focuses on getting WireClaw running on the ESP32-S3, connecting it to Wi-Fi, linking it to an AI model, and controlling the hardware through Telegram. The Meshtastic wiring and takeover side comes in the second part, but this first stage already shows why the idea is so useful.

Table of Contents

• The idea: a standalone Meshtastic-to-Telegram box
• What WireClaw actually is
• The hardware used in this build
• Flashing WireClaw to the ESP32-S3
• First boot: connecting to the WireClaw setup access point
• Configuring Wi-Fi and the AI model
• Setting up Telegram with BotFather and IDBot
• After reboot: local dashboard and device status
• Controlling the ESP32 hardware from Telegram
• Reading sensor values through natural language
• Creating automation rules with plain English
• Reboots, persistence, and why this is practical
• How this fits into a larger Meshtastic setup
• What part one proves
• FAQ

The idea: a standalone Meshtastic-to-Telegram box

The end goal is simple. You send a message into the Meshtastic network and a Telegram message appears on your phone. No full computer. No always-on Raspberry Pi. Just a small hardware box doing the work.

Inside that box are two controllers:

• Heltec V4 running standard Meshtastic firmware
• ESP32-S3 running WireClaw AI

The ESP32 is not a LoRa radio in this setup. It is the smart controller. Its job is to connect to Wi-Fi, talk to Telegram, and use AI logic to interact with the connected hardware. The Heltec handles the Meshtastic side. Together, they make a neat little bridge.

What WireClaw actually is

WireClaw is an AI agent designed to live directly on a microcontroller. The basic pitch is that it is AI that lives on a wire. In practical terms, it means you can flash an ESP32, connect it to an AI backend, and then chat with it over Telegram to control pins, sensors, rules, and devices.

That makes it a very nice fit for hardware projects around Meshtastic, ESP32 development, and small automation jobs. If you enjoy this kind of ESP32 experimentation, you may also like this hands-on guide to using AI with microcontrollers.

One of the really fun parts here is that WireClaw is not limited to one exact board. It can run on several ESP32 variants, including very small ones. For this build, though, the ESP32-S3 from Lonely Binary is a good choice because it is basically a reference platform. A lot of ESP32 work tends to be tested first on boards like this, so it is a safe place to start.

The hardware used in this build

The ESP32-S3 board is just a microcontroller board with Wi-Fi, GPIO pins, and a built-in RGB LED. It is not a LoRa board. That matters, because the attached antenna is for Wi-Fi, not for Meshtastic radio.

The core hardware pieces are:

• ESP32-S3 board for running WireClaw AI
• Wi-Fi antenna connected to the board’s IPX connector
• Heltec V4 for the Meshtastic side of the bridge
• A good USB cable for flashing and power

The ESP32-S3 used here is the Lonely Binary ESP32-S3, and the Meshtastic radio on the other side of the box is the Heltec V4.

Once the antenna is connected, you are ready to flash the board and turn it into a tiny network-connected AI appliance.

Flashing WireClaw to the ESP32-S3

The flashing process starts at WireClaw’s website. The installer runs in the browser and expects a supported ESP32 board, Chrome, and a USB connection.

The first gotcha is an easy one to miss: on this specific ESP32-S3 board there are two USB-C ports. One is for UART and the other is the normal USB port. If the board does not appear in the flasher, check the port first.

That was the exact issue here. Plugging into the UART port did not expose the board the right way. After moving the cable to the USB port, the device appeared as a JTAG USB device and flashing could continue.

1. Connect the ESP32-S3 with a known good USB cable.
2. Open the WireClaw flasher page.
3. Select the detected board.
4. Install WireClaw and allow the tool to erase the device.
5. Wait for the flash process to complete.

If needed, you can also manually place the board into boot mode by holding boot, pressing reset, releasing reset, and then releasing boot.

First boot: connecting to the WireClaw setup access point

After flashing, the board boots with no configuration. WireClaw solves that by creating its own temporary Wi-Fi access point called something like WireClaw Setup.

Connect to that access point and open the setup page. On some systems this opens automatically. Otherwise, you browse to the local setup address shown by the device. That brings up the configuration form where you tell WireClaw how to reach Wi-Fi, Telegram, and your AI provider.

Configuring Wi-Fi and the AI model

The configuration page is where the project becomes useful. At minimum, WireClaw needs:

• Your Wi-Fi SSID
• Your Wi-Fi password
• An API key for your AI provider
• The model name
• The API URL
• A device name

In this setup, the AI backend used was DeepSeek. The API URL entered was the DeepSeek chat completions endpoint, and the chosen model was DeepSeekChat.

If you are already using internet services alongside Meshtastic, this type of cloud link will feel familiar. It is a different mechanism to MQTT, but the idea of extending your network beyond pure radio range is very much in the same spirit as using Meshtastic MQTT to communicate globally.

The device also gets a name. In the example here, it was named something like WireClaw VZH, which then shows up in status and local network access later.

Setting up Telegram with BotFather and IDBot

Telegram integration is one of the nicest parts of WireClaw because it gives you a simple chat interface to your hardware. To make that work, you need two values:

• Telegram bot token
• Telegram chat ID

The bot token comes from BotFather. You create a new bot using the /newbot command, give it a name, and Telegram returns the token.

The chat ID comes from IDBot. That gives you either your personal ID or the channel ID you want to use for notifications.

Those values get entered into the WireClaw configuration page along with a timezone. Once everything is filled in, save the configuration and reboot the device.

After reboot: local dashboard and device status

Once the configuration is saved, reconnect to your normal Wi-Fi network and reset the device. At that point, WireClaw comes up on your LAN and reports back through Telegram that it has started.

It also exposes a local dashboard via IP address or local DNS name. Inside that dashboard you can inspect:

• Configuration
• Prompt
• Memory
• Devices
• Rules
• Status

On the ESP32-S3 used here, WireClaw detected built-in devices including:

• An internal temperature sensor
• A clock
• An RGB LED

Controlling the ESP32 hardware from Telegram

This is where the whole thing starts to feel a bit magical. You can simply send a plain-language command in Telegram and the AI maps that to the actual hardware device names.

For example, the board exposes an LED called RGB_LED. Sending a command such as set the RGB_LED to blue changes the on-board LED immediately. The AI then responds in Telegram confirming that it made the change.

The same works for red, green, and so on. That alone is a nice proof that WireClaw is reading the device list correctly and can trigger real actions from a normal chat.

Teaching the AI simpler names

WireClaw is not just executing commands. It is also building memory. So instead of always using the exact hardware label, you can tell it:

From now on call the RGB_LED LED

After that, the AI remembers the alias. Then you can simply say:

Set the LED to green

and it knows what you mean. That memory shows up in the dashboard as well, so you can actually see that the alias was stored.

Reading sensor values through natural language

The same idea works with sensor data. The board has an internal temperature reading exposed as something like internal_temp. Ask the AI what the internal temperature is, and it returns the current value, around 36°C in the example shown.

Then, just as with the LED, you can rename it:

From now on call the internal temp temp

After that, asking What is the temp? works exactly as expected. Again, the alias is stored in memory.

Creating automation rules with plain English

One of the most useful features in WireClaw is that it can create rules from natural language. Instead of writing logic manually, you describe what you want.

A simple example used here was:

If the temp goes above 36C, send me a message

WireClaw interpreted that as a monitoring rule. It wanted the Telegram chat ID for the notification target, even though the ID had already been configured. That is one of those moments where you can see the AI is useful, but not infallible. Supplying the chat ID manually solved it immediately.

Once accepted, the AI created a rule to check the chip temperature every five seconds and send a Telegram alert if the value exceeded 36°C.

The generated rule then appeared in the dashboard under the Rules section.

Why this matters beyond a demo

This is not limited to onboard devices like LEDs and temperature sensors. The same approach can be used for GPIO pins and external hardware. The basic pattern is:

• Read a condition on one pin or sensor
• Trigger an action on another pin or service
• Notify you through Telegram

So you could define logic such as:

• If input 5 goes high, set output 7 high
• If a threshold is crossed, send an alert
• If a device state changes, report it remotely

That makes the ESP32 a very capable automation companion for Meshtastic gear, especially when you want a self-contained system instead of another Linux box to maintain.

Reboots, persistence, and why this is practical

A project like this only becomes genuinely useful if it survives a power cycle. WireClaw does. After unplugging and reconnecting the board, it boots back up, rejoins Wi-Fi, reconnects to Telegram, and keeps its stored memory and rules.

Asking it something like What are your rules? after a reboot confirms that the configuration is still there. That persistence is a big deal, because it turns the board from a fun experiment into something you can actually deploy.

How this fits into a larger Meshtastic setup

On its own, WireClaw gives you AI-assisted control and remote messaging on a cheap microcontroller. Combined with a Heltec V4, it becomes something more interesting for Meshtastic: a dedicated bridge between local mesh traffic and internet-based messaging.

That is especially attractive if you want to expand what your Meshtastic network can do without dragging in a full computer. It is also a nice complement to other techniques such as MQTT for Meshtastic, where cloud connectivity can extend the usefulness of the mesh far beyond direct radio range.

If you are building out your own hardware stack, you can also browse more Meshtastic devices here.

What part one proves

By the end of this setup, the ESP32-S3 is doing all of the following:

• Running WireClaw AI locally on the microcontroller
• Connecting to Wi-Fi
• Talking to a cloud AI model through API calls
• Receiving commands in Telegram
• Controlling onboard hardware like the RGB LED
• Reading onboard sensor values like temperature
• Remembering aliases and conversational context
• Creating and storing automation rules
• Persisting that configuration across reboots

That is already a powerful little platform before even getting into the full Meshtastic bridge wiring. The second half of the project is where the ESP32 starts taking control of the attached Meshtastic node and forwarding network messages, but the foundation is all here.

FAQ

That is also why I like it. For Meshtastic and MeshCore, this is not really what I would call a great solar node. The ESP32-S3 is not where I would go for ultra-low-power solar deployments. But for a tracker you can throw into a case, carry with you, and actually use on the move, this thing looks very promising.

I wanted to test the important bits properly:

• Can it be flashed cleanly on Windows?
• Does Meshtastic work well on it?
• Does MeshCore work well on it?
• And most importantly, does the built-in GPS actually work?

Table of Contents

• The hardware: small, tidy, and built for tracking
• Why this is better as a tracker than a solar node
• Windows driver issue: what to do if your PC does not see the Heltec device
• Flashing Meshtastic on the Heltec Wireless Tracker V2
• Initial Meshtastic setup over Bluetooth
• Meshtastic node discovery and what “unknown nodes” means
• Testing the built-in GPS in Meshtastic
• Flashing MeshCore on the Heltec Wireless Tracker V2
• MeshCore setup and pairing
• How MeshCore behaves differently from Meshtastic
• Testing channels and messaging in MeshCore
• Does GPS work in MeshCore too?
• What I liked most about the Heltec Wireless Tracker V2
• Final thoughts
• FAQ

The hardware: small, tidy, and built for tracking

Out of the box, the Heltec Wireless Tracker V2 is a nice compact little unit. It includes:

• ESP32-S3 processor
• Built-in GPS/GNSS
• LoRa antenna connection
• External GPS antenna connection
• Power and solar connectors
• A small onboard display

It also ships with the usual tiny LoRa antenna in the box. I used that just to get started, but realistically I would swap it for something better later.

On the board, one side is marked for LoRa and the other for GNSS. That makes setup straightforward. Clip the LoRa antenna on, connect a known-good USB cable, and you are ready to start flashing firmware.

One practical note here: use a USB cable that you know supports data. A lot of flashing issues end up being cable issues.

Why this is better as a tracker than a solar node

This is worth repeating because it matters when choosing hardware. The Tracker V2 uses an ESP32-S3, which is great for capability, but not ideal for super low power always-on solar use. If your goal is a permanently deployed solar repeater or remote node, there are better choices for that job.

But if your goal is a portable tracking node with built-in GPS in a very small package, this starts looking like a really strong option.

Windows driver issue: what to do if your PC does not see the Heltec device

I normally do this kind of flashing from a Mac, but this time I used Windows. Right away, I ran into one of the classic Windows problems: the machine did not recognize the device properly at first.

If that happens, the fix is usually to install the correct Silicon Labs driver. I put together a write-up for that on the LoraMeshDevices Hub, because this comes up often enough that it is worth checking first.

The basic idea is simple:

1. Plug the device in.
2. If Windows does not recognize it, install the Silicon Labs universal Windows driver.
3. Reconnect the device and try again.

If your Heltec is invisible to the flasher, do not fight the firmware tools first. Fix the driver layer first.

Flashing Meshtastic on the Heltec Wireless Tracker V2

For Meshtastic, I used the web flasher at flasher.meshtastic.org. The process is mostly straightforward, but there are a couple of gotchas.

Select the correct device

In the flasher, choose:

• Heltec
• Wireless Tracker V2

One wrinkle here is that because this hardware is still relatively new, the appropriate firmware may only be available in the alpha channel rather than the normal stable or beta selections. That was the case when I tested it.

So if the flash button is not available, check the firmware channel. Switching to alpha made the correct firmware selectable.

Do a full erase

I recommend doing a full flash erase to wipe the factory firmware. The device comes with factory test firmware loaded, and I prefer starting clean.

The sequence I used was:

1. Select the Tracker V2 in the flasher
2. Choose the latest alpha build
3. Enable full erase
4. Click erase and flash
5. Select the correct serial/JTAG device when the browser prompts for it

Avoid the auto-detect trap

This is one of those little annoyances that wastes time. The browser auto-detect option has never been particularly reliable for me. It can leave the serial port open or confuse the process.

If flashing fails after trying auto-detect, refresh the page, manually select the device again, and start over. That solved it here.

Once the flasher reaches the message about hard resetting via RTS pin, the firmware is loaded and the device should reboot into Meshtastic.

Initial Meshtastic setup over Bluetooth

After flashing, the Tracker V2 boots into Meshtastic and can be configured either using the onboard buttons or through the Meshtastic mobile app. The buttons do work, but the screen is tiny, so I prefer the app.

Using Bluetooth pairing was easy enough:

1. Open the Meshtastic app
2. Scan for nearby devices
3. Select the Tracker V2
4. Enter the Bluetooth pairing code shown on the device display

Once connected, I went straight into configuration.

Set your LoRa region

In the app, go into LoRa settings and select the correct region. In my case, that was United States.

I left the rest of the radio configuration alone and kept the preset at LongFast, which is what we use here. That may be different depending on where you are.

After saving, the device reboots. That is normal.

Rename the node

I also renamed the node so it would show up more cleanly in the network. I set the user name to something recognizable and left the short name simple.

Again, saving causes another reboot.

Meshtastic node discovery and what “unknown nodes” means

When the Tracker V2 first came online, it had already heard other nodes nearby, but their names had not been resolved yet. In the app this can look confusing, especially if you are expecting a full list right away.

If you enable show unknown devices, you can see nodes the device has already heard but has not fully identified yet. As the app and node continue working in the background, those unknown entries gradually resolve into named nodes.

So if it looks like your tracker is alone at first, give it a few minutes. It may simply still be resolving the network around it.

Testing the built-in GPS in Meshtastic

The built-in GPS is one of the main reasons this device is interesting, so I wanted to verify whether it was truly working and not just listed on paper.

Inside the Meshtastic device configuration, I checked the Position settings. The app showed GPS mode as enabled, which was a good sign that the hardware had been detected correctly.

At first, though, there was no position fix.

That is normal for a fresh GPS start, especially indoors. On the device itself, the GPS screen showed:

• No satellites
• No GPS lock
• No sats

I moved the device closer to a window, then eventually took it outside for a few minutes. After roughly five minutes, it started locking onto satellites.

Once it had line of sight to the sky, the GPS came to life properly. It initially showed up to 22 satellites, and once back indoors it was still holding onto around 9. That is actually very solid for a small integrated tracker.

With GPS working, the device updated time correctly and location became available inside the Meshtastic app.

Location privacy settings in Meshtastic

Meshtastic gives you control over how precisely your location is shared. In channel settings, you can choose to share your precise position or blur it with a privacy radius. In my setup, I could use the slider to announce a location within a given radius, rather than an exact point.

That is a nice feature if you want tracking functionality without broadcasting your exact position to everyone on the mesh.

Radio performance check

I also tested a traceroute to a nearby node. The Tracker V2 handled that fine, and one nice detail here is that this newer hardware can run at 28 dB, compared to 22 dB on the earlier Tracker V1. So you are getting a little more punch from the radio side as well.

At this point, Meshtastic on the Heltec Wireless Tracker V2 was working well:

• Flashed successfully
• Bluetooth paired successfully
• Region configured correctly
• Node discovery working
• GPS working
• Traceroute working

Flashing MeshCore on the Heltec Wireless Tracker V2

Next I wanted to test MeshCore, because a tracker like this is even more interesting when it works cleanly across both ecosystems.

For that, I used the MeshCore flasher at meshcore.io/flasher.

Select the right MeshCore firmware target

In the supported devices list, choose the Heltec Tracker V2. Then pick the mode you want.

For most people using this with a phone, the right option is Companion via Bluetooth. That is the one I selected.

I also chose to erase the device before flashing so there would not be any leftovers from the Meshtastic installation.

If MeshCore will not flash, use bootloader mode

This is the big troubleshooting point for MeshCore on this device.

If Meshtastic is already loaded, the flasher may not immediately take over. In my case, the device showed up with the existing firmware identity and refused to flash cleanly.

The fix was to manually put the Tracker V2 into flashing mode:

1. Press and hold the boot button
2. Press the reset button
3. Release reset
4. Release boot
5. Retry the flash process

Once that worked, the device appeared again as the proper JTAG/flash device, and the MeshCore flashing process continued normally.

After flashing completed and the device was reset, it booted into MeshCore. The first boot took a little longer, which is something I have seen on other MeshCore nodes as well.

MeshCore setup and pairing

After the firmware loaded, the device came up with MeshCore version 0.15 and used the color display properly, which was a nice touch.

I then opened the MeshCore app and paired over Bluetooth. One practical Android troubleshooting tip: if pairing acts weird or does not reconnect properly, completely kill the app and start it again. That solved one hiccup for me during setup.

After pairing, I configured:

• Device name
• Preset region as USA/Canada
• Everything else left mostly at defaults

How MeshCore behaves differently from Meshtastic

This part matters because MeshCore is not just “Meshtastic with different menus.” The discovery model is different.

In MeshCore, if you do not want to be discovered, you do not have to be discovered. Devices do not automatically reveal themselves the same way. Repeaters may only announce themselves occasionally, even as infrequently as every 12 hours.

So instead of passively expecting the app to fill up with nodes, you actively do a couple of things:

• Send an advert to tell others you are there
• Discover repeaters from the tools menu

When I ran repeater discovery, the app found several repeaters in the area and added them. Those are infrastructure nodes for message routing, not necessarily people I can chat with directly.

Testing channels and messaging in MeshCore

To test real traffic, I used two methods.

1. Public channel messaging

I sent a simple “Hello” on the public channel. The message was repeated by nearby infrastructure, which confirmed that the device was transmitting correctly.

2. A custom testing channel

I also added a channel called testing. MeshCore makes this pretty easy, and it even provides a QR code so someone else can quickly join the same channel.

After sending a test message on that channel, I got a response back from an autobot I already had set up there. That was enough to confirm the node could both send and receive successfully.

To add an actual person as a contact in MeshCore, they need to send an advert and you need to add them. I triggered an advert from one of my other home devices, and once it appeared, I could message it directly.

At that point the Tracker V2 was functioning as a full MeshCore companion node with:

• Repeaters discovered
• Public channel access
• Custom testing channel added
• Direct companion contact available

Does GPS work in MeshCore too?

Yes, and that was the last thing I specifically wanted to verify.

Inside the MeshCore settings, I enabled the position feature. Based on the earlier Meshtastic test, I expected I might need to take it outside again, but in this case it already had enough information to resolve position and place itself on the map.

That confirmed the built-in GPS is not just functioning under Meshtastic. It also works in MeshCore, which makes this little device a lot more attractive as a true all-in-one portable tracker.

What I liked most about the Heltec Wireless Tracker V2

After testing both firmware options, the Tracker V2 came away looking really strong.

The highlights for me were:

• Very compact form factor
• Built-in GPS instead of needing an external GPS module
• Stronger radio output than the earlier Tracker V1
• Fast firmware flashing compared to some older Heltec hardware
• Works with both Meshtastic and MeshCore
• Color screen support in MeshCore

It really feels like a purpose-built tracker node. Put it in a decent case with a battery and you have something small, capable, and genuinely useful for portable mesh networking.

I especially like that the GPS is integrated. A lot of other setups end up as a pile of extra modules and wires. This keeps things neat.

Final thoughts

I think the Heltec Wireless Tracker V2 is one of the better compact tracker nodes available right now for Meshtastic and MeshCore. It is not the node I would choose for a long-term solar deployment, but for a carry node, field tracker, or portable companion, it makes a lot of sense.

The built-in GPS works. Meshtastic works. MeshCore works. The radio performance looks good. And once it is in a proper case, it should make an excellent little travel node.

If you are comparing options for portable mesh hardware, this one definitely deserves a look.

FAQ

It does not route traffic. It does not act like a repeater. It does not replace your normal client nodes. Its whole job is to collect useful network data such as active nodes, packet paths, signal quality, and general network health, then send that information up to MQTT so apps can do something useful with it.

If you want better visibility into your network, easier troubleshooting, coverage mapping, or just a clearer picture of what is happening on your local mesh, adding a MeshCore Observer is a really good idea.

Table of Contents

• What a MeshCore Observer Actually Does
• Why Every Local Mesh Community Should Have One
• How the Data Flow Works
• The Simple Hardware Approach I Chose
• Getting the Observer Firmware
• Flashing the MeshCore Observer to a Heltec V3
• Configuring Wi-Fi and Location in the Serial Console
• What Happens After Setup
• Using MeshMapper to Visualize Observer Data
• A Real Example of Packet Tracking
• Live Mapping Packet Paths
• What the MeshCore Observer Is Not
• Final Thoughts
• FAQ
• Useful Links

What a MeshCore Observer Actually Does

Think of a normal MeshCore network as a mix of companions or client nodes, plus repeaters. Those devices are busy participating in the mesh. They send messages, relay packets, and keep the network moving.

A MeshCore Observer is different. It simply sits there and listens.

When it sees traffic on the mesh, it reports that data over the internet to an MQTT broker. From there, apps can use the information to visualize the network and help you understand what is going on.

That makes the observer useful for things like:

• Network mapping
• Coverage mapping
• Troubleshooting and diagnostics
• Performance monitoring
• Contributing to the wider LetsMesh ecosystem
• Security awareness, including spotting suspicious or unauthorized nodes

The mesh will still run perfectly fine without an observer. This is important. A MeshCore Observer is not required to make the network function.

But if you do have one in your area, the network becomes much easier to understand and manage because now that local activity can be published and visualized.

Why Every Local Mesh Community Should Have One

If you have a community network, it really helps to have at least one MeshCore Observer in the area. Without it, traffic is still happening, but you are mostly blind to the bigger picture.

With an observer in place, everyone benefits from shared visibility. You can begin answering practical questions like:

• Which nodes are currently active?
• How far is traffic actually propagating?
• Which repeaters are being used most often?
• Are there weak coverage spots?
• Are packets following the path you expected?

That is the real value here. A MeshCore Observer turns the mesh from something you hope is working into something you can actually inspect.

How the Data Flow Works

The overall flow is simple:

1. Your normal MeshCore network runs as usual with clients and repeaters.
2. The MeshCore Observer listens passively to activity on that mesh.
3. The observer uses an internet connection to send what it hears to MQTT brokers.
4. Apps consume that MQTT data and turn it into maps, packet traces, and other useful visualizations.

That is why the observer matters so much. It bridges local RF activity to tools that can make sense of it.

The Simple Hardware Approach I Chose

There are a few ways to stand up a MeshCore Observer, but I went with the simplest route.

You could run supporting pieces on something like a Raspberry Pi, but then you are also taking on the overhead of keeping another computer online and maintained all the time. For my setup, I wanted something cleaner and easier.

So I used a Heltec V3 that I already had available in my stack of nodes.

The reason this worked nicely is that the Heltec V3 has network capability, so I could connect it to Wi-Fi and let it push observer data out to the internet directly.

That made it a practical choice for an always-on MeshCore Observer without turning the whole project into something more complicated than it needed to be.

Getting the Observer Firmware

The custom observer firmware can be found through the LetsMesh forum. There is a write-up there that walks through the process and helps identify which devices support this observer setup.

On that firmware page, you select the node type you want and then choose the hardware platform. Supported options include several device types, including the Heltec V3.

Once you choose the correct hardware and confirm that you understand what you are downloading, you can grab the firmware file you need.

The key point here is that you are not flashing the standard firmware image. You are downloading a custom firmware build intended for the observer role.

Flashing the MeshCore Observer to a Heltec V3

After downloading the firmware, head over to the MeshCore flasher on the MeshCore website.

From there:

1. Open the web flasher.
2. Choose custom firmware instead of the normal node firmware option.
3. Upload the observer firmware file you downloaded.
4. Flash it to the Heltec V3 like you normally would.

That part is very similar to a normal firmware flash. The main difference is simply that you are using the custom observer image.

Configuring Wi-Fi and Location in the Serial Console

Once the firmware is flashed, the next step is to connect to the device through the serial console and set a couple of values.

This is where the observer becomes usable on your network.

You need to configure:

• Wi-Fi SSID
• Wi-Fi password
• Closest airport code

The Wi-Fi settings are required because the MeshCore Observer needs internet access to publish data to MQTT.

The airport code is also required. For example, in the Tampa area, the code used was TPA.

There are also optional fields where you can provide contact details such as your email address or public key so people can get in touch regarding your observer.

One practical tip I always recommend is to put devices like this on a guest network rather than your main network. That keeps things a bit cleaner and avoids giving experimental nodes unnecessary access to your primary LAN.

After setting the required values, reboot the node.

Once it comes back up, you should see that the Heltec V3 now has an IP address. That is the sign that it is connected to Wi-Fi and ready to begin feeding data into the MQTT servers.

What Happens After Setup

At this point, your MeshCore Observer is basically done.

You configure the radio side as normal, set the serial values for network access and location, and then it begins contributing data automatically.

From there, every time it hears mesh traffic, it can report what it sees upstream for use in apps.

That is the beauty of the setup. Once it is in place, it quietly does its job without needing to participate in packet routing.

Using MeshMapper to Visualize Observer Data

One of the most useful examples of observer-powered visualization is MeshMapper.

MeshMapper can consume data from LetsMesh and show useful details on a map. Depending on the data available, it can help with things like seeing where signal was picked up, where it was not, and how packets move across an area.

In the Tampa and St. Petersburg area, the observer showed up on the map as an active contributor. That confirmed it was online and publishing properly.

The really interesting part is the packet view.

This is where a MeshCore Observer starts proving its worth in a very practical way. You can begin seeing what traffic was heard, which nodes were involved, and how messages were propagated through the network.

A Real Example of Packet Tracking

To test the setup, a small client node was used along with the mobile app to send a message into the network.

The hardware used for that live test was a Seeed Wio Tracker L1, acting as a mesh client. A simple test message was sent from the app.

Once that message hit the network, the observer picked it up and reported it. In the packet data, it was possible to see:

• The original text message
• The rebroadcast path across nearby nodes
• A reply from a bot
• The observer that captured and forwarded those packet details upstream

That gives you a much clearer sense of what actually happened on the mesh. Instead of just knowing that a message was sent and received, you can see how it moved.

This kind of visibility is especially useful when a network is still growing. Even in a smaller area with only a modest number of nodes, you can already start verifying packet movement and relay behavior.

Live Mapping Packet Paths

One of the coolest parts of the whole setup is seeing packet movement drawn out visually on the map.

After sending another test message, MeshMapper showed the relay path in real time. The message originated locally, traveled outward, and then appeared at other points in the area, including Apollo Beach and back toward another nearby node.

That sort of visual pathing is exactly what makes a MeshCore Observer so valuable. It turns invisible RF behavior into something you can inspect and reason about.

In a larger network, this becomes even more interesting because you can start seeing more complex relay paths, denser propagation patterns, and a clearer picture of which infrastructure is doing the heavy lifting.

What the MeshCore Observer Is Not

It is worth being very clear about this, because it helps avoid confusion when planning a deployment.

A MeshCore Observer is not:

• A repeater
• A normal chat client
• A routing node
• A required component for mesh traffic to function

It is a passive listener that reports what it hears.

That limited role is exactly why it is so useful. Because it is not busy participating in routing decisions, it can focus on collecting and exporting network data.

Final Thoughts

If you already have a working MeshCore network, adding a MeshCore Observer is one of the easiest ways to get more insight out of it.

Using a Heltec V3 made the process simple. Flash the custom firmware, connect to the serial console, set Wi-Fi, set your nearest airport code, reboot, and let it start feeding data to MQTT.

From there, apps like MeshMapper can show you packet paths, relay behavior, and the overall health and shape of your local mesh.

For anyone building out a community network, I really think it is worth standing up at least one MeshCore Observer in the area. The network will run without it, but once you have that visibility, it is hard to want to go back.

FAQ

Useful Links

Links: (Note: As an affiliate, I earn from qualifying purchases)

• Heltec V4

• Seeed T1000E (Use code S0G9HWFL for a discount)

• Seeed T1000E at Amazon

• Seeed L1 Pro

• Seeed Solar Node

• Presentation

Meshtastic, Remote Management is one of those features that becomes incredibly useful the moment you put a node somewhere awkward, high up, sealed in an enclosure, or simply out of easy reach. If you have ever mounted a node in a tree and then realized you want to change a setting, turn Bluetooth off, or check battery status, remote management solves that problem nicely.

The basic idea is simple. Your phone talks to an admin node over Bluetooth, and that admin node talks to your target node over LoRa. Once it is configured correctly, you can manage that remote node without connecting to it directly.

It sounds complicated when you first hear it, especially because one admin node can manage several nodes, but the setup is actually straightforward once you know the sequence.

Table of Contents

• How Meshtastic remote management works
• Step 1: Copy the public key from your admin node
• Step 2: Add that public key to the remote node’s admin keys
• Step 3: Reconnect to the admin node
• Step 4: Reboot the remote node so it publishes itself
• Step 5: Exchange metadata, then open remote management
• What you can do once remote management is active
• Checking device metrics remotely
• What you can monitor after telemetry is enabled
• Why this matters for real deployments
• Quick Meshtastic remote management setup checklist
• Common gotchas to remember
• FAQ
• Useful links

How Meshtastic remote management works

At a high level, there are three parts involved:

• Your phone running the Meshtastic app
• An admin node connected to the phone over Bluetooth
• A remote node that will be managed over LoRa

In this setup, the admin node is a SenseCAP T1000E, and the remote node is a Heltec V4. The same approach applies more broadly, but those are the devices used here.

The key to Meshtastic, Remote Management is the admin node’s public key. You copy that public key from the admin node and add it to the remote node’s security settings as an admin key. Once that trust relationship is in place, the remote node can be managed over the mesh.

Step 1: Copy the public key from your admin node

Start by connecting the app to the node you want to use as your admin node. In this example, that is the SenseCAP T1000E.

Before turning Bluetooth off or changing anything else, go into the node settings and open Security. There you will find the node’s public key.

Copy that public key. This is the value you will paste into the remote node in the next step.

This step matters because remote management is not just a toggle you switch on. The remote node needs to know which admin node is allowed to control it.

Step 2: Add that public key to the remote node’s admin keys

Now connect to the node you want to manage remotely. In this case, that is the Heltec V4.

Again, go into Security. This time, instead of copying a key, you want to add an admin key.

Paste the public key you copied from the T1000E into that admin key field, then save it.

That is really the core configuration. Once the admin node’s public key has been added to the remote node, you have established permission for Meshtastic, Remote Management.

You can add up to three admin keys, which is handy if you want multiple trusted admin nodes.

Step 3: Reconnect to the admin node

After saving the admin key on the remote node, disconnect from it and reconnect your app to the admin node, the T1000E.

From here on, you are going to try to find the remote node through the mesh. If it does not show up immediately, that is normal.

In the example setup, the target node did not appear right away in the node list. The simple fix was to reboot the remote node so it would announce itself to the network again.

Step 4: Reboot the remote node so it publishes itself

If your admin node does not see the remote node yet, restart the remote device.

When the remote node boots, one of the first things it does is send out its presence on the network. That makes it visible to the admin node again.

After the reboot, the node appeared in the list and was ready to be managed.

Step 5: Exchange metadata, then open remote management

Once the remote node appears under your admin node, open that node and look near the bottom for Administration.

The first useful action here is Metadata. Triggering metadata exchange helps the admin node learn the information it needs about the remote device.

After metadata comes through, select Remote Management. If the keys match properly, the app will switch into remote mode for that node.

You will see the interface indicate that you are now remotely managing the target node. At that point, your phone is still connected to the admin node over Bluetooth, but the settings changes are being sent to the remote node over LoRa.

That is the big win with Meshtastic, Remote Management. You are no longer limited to physical Bluetooth access for every change.

What you can do once remote management is active

Once connected in remote management mode, the remote node behaves a lot like a directly connected node from a settings perspective. You can open different configuration sections and change values just as you normally would.

One very practical example is Bluetooth.

Turn Bluetooth off on the remote node

In the example, Bluetooth was disabled on the Heltec V4 while it was being managed remotely.

That means the node could no longer be connected to directly over Bluetooth afterward. From then on, access depended on remote management through the admin node.

This is useful when you want to reduce exposure, simplify field deployments, or prevent the need to leave Bluetooth enabled on a permanently mounted node.

Checking device metrics remotely

After Bluetooth was turned off, the next test was to read device metrics such as battery state and air utilization.

At first, nothing came through. That is an important little gotcha.

If you want to monitor those values with Meshtastic, Remote Management, the remote node must actually be configured to send telemetry data.

If metrics are missing, enable telemetry

Go back into remote management for the remote node and open the Telemetry settings. Then turn on the option to send telemetry data and save it.

Because this setting is being changed remotely, the save action is sent over the LoRa network to the target node. After that change, the node reboots.

Once it comes back up, device metrics become available from the admin node.

What you can monitor after telemetry is enabled

With telemetry enabled, the admin node can read useful health data from the remote node, including:

• Battery percentage
• Battery voltage
• Uptime
• Air utilization

In the example, the remote Heltec reported battery around 98%, then 97% after repeated refreshes. That is a nice reminder that constantly polling a node is not free. If you keep hammering on it, you will see the battery tick down.

There was also an indication that, while staying connected, metrics update automatically on a regular interval, roughly around once a minute.

That gives you a very practical way to check the health of a remote deployment without physically touching it.

Why this matters for real deployments

This is where Meshtastic, Remote Management really shines.

If you have a node mounted in a tree, on a roof, inside a weatherproof box, or somewhere you simply do not want to access all the time, remote management means you can:

• Change settings over the mesh
• Disable Bluetooth after deployment
• Enable or adjust telemetry remotely
• Check battery and uptime without taking the node down
• Manage multiple nodes from one admin node

That is a much cleaner way to run longer-term installations. Set the trust relationship once, verify the node is visible on the network, and then manage it from your admin node instead of climbing ladders or opening enclosures every time you need to tweak something.

Quick Meshtastic remote management setup checklist

1. Connect to your admin node in the app.
2. Open Security and copy its public key.
3. Connect to the remote node.
4. Open Security and add that public key as an admin key.
5. Save the setting.
6. Reconnect to the admin node.
7. If the remote node does not appear, reboot the remote node.
8. Open the node, request Metadata, then select Remote Management.
9. Change settings over LoRa as needed.
10. If you want battery and health data, enable Telemetry on the remote node.

Common gotchas to remember

• If the remote node is not visible, reboot it so it republishes itself to the mesh.
• If remote management does not open, double-check that the correct public key was added as an admin key.
• If device metrics are blank, telemetry probably is not enabled yet.
• If you turn Bluetooth off, direct local access is gone unless you turn it back on remotely or reconnect some other way later.

FAQ

Useful links

Links: (Note: As an affiliate, I earn from qualifying purchases)

• Seeed T1000E (Use code 'S0G9HWFL' for a discount)

• Seeed T1000E at Amazon

• Seeed L1 Pro

• Seeed Solar Node

This version of the Solar Meshtastic tree node is all about fixing the real-world issues that showed up in the first build. The original worked, but it was bright yellow, very visible in a tree, and had a few practical limitations around heat, retrieval, and solar handling. Version 2 keeps the same overall idea but makes the node far more stealthy, more manageable once it is up in the canopy, and a lot more interesting electrically.

The other big twist is the chip choice. Instead of sticking with the lower power NRF-based setup from before, this build tries something people usually warn against: running a Heltec V4 from three very small solar panels. That may be a terrible idea, or it may work better than people expect once the settings are tuned correctly. Either way, it is worth testing.

If you are building a Solar Meshtastic node for off-grid coverage, elevated placement, or a semi-hidden relay point, these changes are the ones that matter.

Table of Contents

• What changed in version 2
• Why the enclosure color changed
• New loops for retrieval and stability
• Solar input upgrades: from simple diodes to ideal diode modules
• The Heltec V4 experiment
• Battery choice and charging approach
• Internal assembly and wiring layout
• Flashing firmware and first connection
• Early power optimization steps
• Set up remote management before disabling Bluetooth
• Power settings for a small solar node
• Enable telemetry so you can actually monitor the node
• Initial battery readings and what to expect
• Final assembly and deployment
• Why this version is a better Solar Meshtastic tree node
• FAQ
• Links

What changed in version 2

The short version is this:

• New army green enclosure for better concealment in a tree
• Air gap behind the solar panels to reduce heat buildup
• Three lower rope loops for retrieval and orientation control
• Ideal diode modules instead of simple diodes on each solar panel
• Heltec V4 no-screen board as the experimental radio platform
• Remote management setup so Bluetooth can be disabled after deployment
• Telemetry enabled remotely for checking battery state over LoRa

Why the enclosure color changed

The first version was bright yellow. That had one obvious upside: yellow reflects a lot of heat from the sun. But it had one equally obvious downside: it stood out like crazy. You could spot it from a long way off once it was hanging in a tree.

For a Solar Meshtastic node intended to disappear into the canopy, that is not ideal.

Version 2 switches to army green. It blends into foliage much better, which is great for a stealth deployment. The tradeoff is heat. Dark colors absorb more solar energy, and if the panel sits directly against the body, the enclosure can get hotter than you want.

The heat fix: add an air gap

To deal with that, the solar panel is no longer mounted flush against the body. Small standoffs create a gap between the panel and the node itself. That gives heat at least some chance to dissipate instead of getting trapped between the panel and the enclosure.

It is a simple change, but this is exactly the kind of thing that matters on a permanently deployed Solar Meshtastic build. Small thermal improvements can make a big difference over time.

New loops for retrieval and stability

One of the best upgrades in this version came from feedback. The original had a top loop for pulling the node up into the tree, which works fine when everything goes perfectly. But gravity is not always enough to bring it back down.

So this version adds three lower hooks or loops.

These serve two very practical purposes:

• Retrieval: if the node gets hung up, you can attach another rope and pull it out instead of hoping it drops cleanly
• Orientation control: by tying an extra line to one of the lower loops, you can keep the unit from spinning freely

That second point matters more than it sounds. A tree node that spins around constantly is unpredictable. A more stable node is easier to position and more likely to keep the panel orientation you intended.

Solar input upgrades: from simple diodes to ideal diode modules

Electrically, one of the most important changes is how the three small solar panels are combined.

The setup still uses three panels, but the isolation method has been upgraded. In the earlier design, each panel used a simple diode on the positive lead. That was necessary because when one or two panels were lit and another was shaded, the shaded panel could start pulling power from the others. In other words, it became a parasitic load.

Simple diodes stopped reverse flow, but they came with some downside in the form of voltage drop and inefficiency.

Version 2 replaces those with ideal diode modules. Each panel feeds into its own module, and the outputs are then combined.

Why that matters

• Lower resistance than a basic diode approach
• Faster reaction to changing solar conditions
• Better isolation between panels when some are shaded and some are lit
• Less wasted power, which is important when your total harvest is tiny

When your entire charging budget is only a few hundred milliwatts, every bit of efficiency matters. That is especially true on a Solar Meshtastic node that may spend part of the day in partial shade, with different panels seeing different levels of light.

The Heltec V4 experiment

This is the part that makes the build interesting.

Instead of using the previous Seeed NRF-based board, this version tries a Heltec V4. A lot of people will tell you that is too power hungry for tiny panels like these, and to be fair, that concern is not crazy.

The three solar panels here are rated at about 200 mW each, so in total the system has around 600 mW of panel capacity. That is not much.

Meanwhile, the Heltec V4 can draw roughly:

• About 140 mA at idle
• Up to 1 amp when transmitting

That means this build is right on the edge. Maybe over the edge. The only honest answer is to test it.

Why try it anyway?

Because raw worst-case numbers do not tell the whole story.

On the Heltec V4, several things can be done to reduce power draw:

• Bluetooth can be turned off
• Wi-Fi can be turned off
• The no-screen version avoids display power draw
• Power saving mode can be enabled

With those settings, the current draw can drop dramatically. The expectation here is that it may come down to around 40 mA, and some people even report 10 to 15 mA with aggressive power saving.

There is already a similar Heltec V4 running on a roof with a 2 watt panel, and that one has stayed very healthy. But this tree node is using a much smaller solar budget, so this is still a real experiment.

If it does not hold up, the fallback plan is simple: swap the Heltec V4 for a Heltec T114 or another NRF-based option.

Battery choice and charging approach

The node uses a standard 3500 mAh battery. That gives a decent buffer overnight or during bad weather.

One of the more interesting choices here is the charging setup. Instead of adding an external charge controller, the build relies on the onboard charger on the Heltec board. The onboard charger is rated for 500 mA, which is a good match for this kind of low-power solar input.

The battery plugs into the connector labeled BAT, and the combined solar feed goes into the connector labeled SOL.

The reasoning is practical: an existing roof-mounted Heltec setup using only the onboard charge controller has already been running for months and has remained near full charge. So for this Solar Meshtastic build, it makes sense to keep the wiring simple and try the same approach.

Internal assembly and wiring layout

The internal assembly is straightforward, but there are a few details that should not be skipped.

Core hardware inside the node

• Heltec V4 no-screen board
• 3500 mAh battery
• SMA pigtail for the external antenna
• Bluetooth antenna attached to the board, even though Bluetooth is only needed temporarily
• Three solar panels
• Three ideal diode modules

Wiring summary

• Each solar panel positive lead goes into its own diode module
• The diode module outputs are tied together on the positive side
• All solar negatives are tied together
• The combined solar connection goes to the board's SOL input
• The battery goes to the board's BAT input

A small but important reminder from the build: always verify polarity on these connectors before plugging anything in. The plugs may fit, but that does not guarantee the wiring is correct.

Also, the board is secured inside the enclosure with adhesive tape so it cannot shift once the unit is closed and hoisted into place.

Do not power the radio without the antenna connected

One detail worth repeating: connect the antenna before powering the node. The SMA antenna gets attached first, then the board is powered. That is just good radio hygiene.

Flashing firmware and first connection

Once the hardware is assembled, the next step is flashing the latest firmware onto the Heltec V4.

After flashing, the node is discovered in the Meshtastic app over Bluetooth using the default PIN:

123456

Initial configuration includes:

• LoRa region: United States
• Preset: LongFast
• Device name: a custom name for the tree node

After the first save, the node reboots and starts picking up nearby nodes.

Early power optimization steps

Before the node goes into a tree, there are a few easy wins that immediately reduce wasted power.

1. Turn off LED heartbeat

The heartbeat LED is useful on the bench, but once deployed it is just wasted battery. Disabling it also makes the node less visible at night.

2. Set the time zone from the phone

This is just a normal setup step, but it is done while still connected locally.

At this point, the LED heartbeat is off and the node stops that regular blink that serves no purpose in a finished field deployment.

Set up remote management before disabling Bluetooth

This is one of the smartest parts of the whole build.

If the node is going to live up in a tree, Bluetooth needs to be turned off to save power. But if you disable Bluetooth too early, managing the node becomes painful. The solution is to set up remote administration over LoRa first.

How the remote admin setup works

An existing node, in this case a SenseCAP T1000E used as an admin node, provides a public key. That public key gets copied into the Heltec tree node as an admin key under security settings.

Once the keys match:

• The admin node can discover the tree node over the mesh
• Metadata can be exchanged
• Remote management becomes available

Sometimes the tree node needs to be rebooted once so it sends a fresh discovery packet and appears in the admin node's list. After that, remote administration can be used to change settings on the tree node without a direct Bluetooth connection.

Then Bluetooth gets turned off

With remote administration working, Bluetooth can safely be disabled on the tree node. From that point on, the node is managed over LoRa rather than over a short-range local link.

That is exactly what you want for a Solar Meshtastic deployment that may be physically awkward to reach.

Power settings for a small solar node

Once remote admin is available, the next priority is squeezing the most life possible out of the Heltec V4.

The power configuration used here is intentionally conservative:

• Enable power saving: on
• Wait for Bluetooth: irrelevant once Bluetooth is off
• Super deep sleep: left off
• Minimum wake time: left at 10 seconds

That keeps the node functional without going all the way into a more aggressive sleep configuration. The basic approach is to remove obvious waste first, then monitor battery behavior before making deeper changes.

For this particular Solar Meshtastic test, the important changes are:

• Heartbeat LED off
• Bluetooth off
• Power saving on
• Remote administration enabled

Enable telemetry so you can actually monitor the node

After all that, there was one missing piece: device telemetry.

Without telemetry enabled, the admin node cannot read device metrics from the tree node. The fix is simple. Remote into the tree node again, go to telemetry settings, and turn on telemetry transmission. In this setup, temperature units are also set to Fahrenheit.

Once telemetry is enabled, the admin node can request and receive metrics such as:

• Battery percentage
• Battery voltage
• Uptime
• Air utilization

That is what makes a remote Solar Meshtastic experiment practical. You do not want to keep dragging the node down from a tree just to check whether your power budget is working.

Initial battery readings and what to expect

Once telemetry was working, the initial battery state showed around 98%, and after repeated interaction and polling it dipped to 97%. That is not surprising. Any time you keep querying a remote node, you are spending some of the battery you are trying to conserve.

The important thing is that now the battery can be monitored over time, remotely, and under real operating conditions.

Based on the 3500 mAh battery alone, the expectation is roughly 24 to 36 hours without charging, depending on actual draw. With solar input contributing during the day, the node may remain comfortably afloat if the average current stays low enough.

That is the whole point of this test: to see whether a Heltec V4 can live on a tiny Solar Meshtastic power budget when configured carefully.

Final assembly and deployment

Once the internals are configured and telemetry is verified, the enclosure is closed up and sealed with a bit of silicone around the edge. Then the node is ready to go back up into the tree.

From there, the only thing left is to monitor the battery over the next few days and see whether the solar harvest is enough to support the Heltec V4 long term.

If it holds steady, great. If not, the enclosure and wiring approach are still solid, and the radio can be swapped for a lower-power board. Either way, version 2 is a meaningful improvement over the original design.

Why this version is a better Solar Meshtastic tree node

Even before the Heltec experiment proves itself one way or the other, version 2 improves the design in the ways that matter most in the field.

• It is harder to spot
• It handles heat better
• It is easier to retrieve
• It is easier to stabilize in a tree
• Its solar panel combining method is more efficient
• It can be managed remotely after deployment
• Its battery state can be checked over the mesh

That is exactly what a practical Solar Meshtastic node should do. It is not just about getting a radio to power on. It is about building something that can survive outside, stay useful, and remain manageable after it disappears into a tree canopy.

FAQ

Why change the node from yellow to army green?

The yellow enclosure reflected heat well, but it was highly visible in a tree. Army green is much more discreet and blends into foliage better, making the node more stealthy.

Does the darker color create heat problems?

It can, which is why version 2 adds standoffs behind the solar panel. That creates an air gap between the panel and the enclosure so heat can dissipate more easily.

What are the extra loops at the bottom for?

They let you attach additional ropes for retrieval and for stabilizing the node so it does not spin freely in the tree. That makes deployment and recovery much easier.

Why use ideal diode modules instead of basic diodes?

The ideal diode modules reduce losses and prevent one shaded panel from drawing power from the others. They are more efficient than simple diodes, which matters when the total solar input is very small.

Can a Heltec V4 really run from three tiny solar panels?

That is the experiment. It may work if Bluetooth and Wi-Fi are off and power saving is enabled, but it is definitely close to the edge. If it does not hold up, the fallback is to switch to a lower-power board like a T114 or another NRF-based option.

Why disable Bluetooth on the tree node?

Bluetooth uses extra power, and once the node is mounted high up, direct Bluetooth access is not practical anyway. The better approach is to enable remote administration first, then turn Bluetooth off.

How is the node managed after Bluetooth is disabled?

Remote administration is configured using admin keys. An admin node's public key is added to the tree node, allowing settings to be changed over the LoRa network instead of over Bluetooth.

How do you check battery status remotely?

Enable telemetry on the tree node. Once telemetry is turned on, another authorized node can read device metrics such as battery percentage, battery voltage, uptime, and air utilization over the mesh.

Links

Note: As an affiliate, I earn from qualifying purchases

• Heltec V4 (No Screen) - https://amzn.to/4dqVV4c

• 18650 Battery - https://amzn.to/4m95HKQ

• Battery Holder - https://amzn.to/4jZW9Pz

• SMA Connector - https://amzn.to/4bvpuz8

• 915Mhz Antenna - https://amzn.to/3PmXJBi

• XL0401 Ideal Diode Module - https://amzn.to/47PU5qd

• Solar Panels - https://amzn.to/47xSvJe

• 3D Printable Files - https://www.printables.com/model/1640281-meshtastic-meshcore-tree-node

• Project files and UPDATES - https://hub.lorameshdevices.com/projects/solar-tree-node-meshtastic-meshcore

This guide focuses on building a local LoRaWAN setup using the SenseCAP M2, Lorawan gateway and the built-in ChirpStack server. The goal is simple: receive sensor messages locally, keep your data closer to where it is collected, and be ready to add devices and profiles next.

Table of Contents

• Why LoRaWAN (and how it differs from mesh LoRa)
• Meet the SenseCAP M2: hardware and connectivity options
• The two key pieces of software: Lucy and local ChirpStack
• Step 1: Power on safely and enter hotspot mode
• Step 2: Connect to the gateway hotspot and open Lucy
• Step 3: Connect the gateway to your LAN/Wi-Fi (not just hotspot)
• Step 4: Set system time and timezone
• Step 5: Update firmware
• Step 6: Configure the LoRa network server to use local ChirpStack
• Where this leaves you (and what comes next)
• FAQ
• Links

Why LoRaWAN (and how it differs from mesh LoRa)

LoRaWAN is designed for devices that run on batteries for a long time. Typical use cases include smart cities, agriculture, asset tracking, and industrial IoT. In practice, sensors transmit over LoRa to a gateway, and the gateway forwards received packets to a network server, which then makes the data available to applications via APIs.

A key mental model:

• LoRa is the long-range radio link between sensors and the gateway.
• LoRaWAN is the standardized network protocol managing how messages are sent, received, and interpreted.
• Network server (often ChirpStack) is where you define devices and where received messages become usable data.

Instead of relying on an online cloud platform, the SenseCAP M2 can run a built-in local network server.

Meet the SenseCAP M2: hardware and connectivity options

The unit used here is the Seeed Studio SenseCAP M2 indoor multi-platform LoRaWAN gateway. It is not weather sealed, so it is meant for indoor setups.

What to notice on the hardware:

• LoRa antenna connector (in this case a 915 MHz antenna)
• Power input
• Ethernet for wired LAN connections
• USB-C port
• Button used for mode changes and startup behavior
• nano SIM slot for 4G LTE connectivity (depending on your gateway version)
• microSD slot
• Status LEDs that help indicate mode (hotspot vs normal operation)

Different versions exist depending on which connectivity methods you want (Ethernet, Wi-Fi, 4G/LTE, or combinations). You also choose the correct regional frequency plan. The unit discussed uses US915.

The two key pieces of software: Lucy and local ChirpStack

This is the part that makes the SenseCAP M2, Lorawan workflow particularly friendly if you want “local first”. The gateway runs two separate software components:

• Lucy (configuration interface): configure the gateway settings and network connection.
• ChirpStack (local network server): receive LoRaWAN packets and manage devices, APIs, logs, and data display.

Why you should care: with the built-in local ChirpStack, you can start building and testing a working LoRaWAN network without immediately sending everything to an external cloud service.

Step 1: Power on safely and enter hotspot mode

Start by connecting the LoRa antenna. The gateway can be sensitive to startup conditions, so it is a good habit not to power it before the antenna is attached.

To enter hotspot mode:

1. Plug in power.
2. Hold the button for 5 seconds.
3. Watch the LEDs change from green to blue and begin flashing slowly.

That blue flashing state indicates the gateway is now acting like a Wi-Fi hotspot so you can configure it right away.

Step 2: Connect to the gateway hotspot and open Lucy

On your computer, connect to the SenseCAP access point (SSID typically appears as SenseCAP Access Point or similar).

The default hotspot Wi-Fi password is shown in the quick start guide. In this setup it was:

12345678

Next, open a browser and go to the gateway’s hotspot IP address:

http://192.168.168.1

Lucy login credentials are printed on a sticker on the bottom of the gateway, including the default username and password.

Step 3: Connect the gateway to your LAN/Wi-Fi (not just hotspot)

Hotspot mode is only meant to get you through initial setup. The next goal is to connect the gateway to your home or lab network so you can reach it consistently and so it can forward LoRaWAN packets upstream.

Inside Lucy:

• Go to Interfaces and select the appropriate path for network access (LAN, LTE, WWAN, etc.).
• Use the scan button on Wi-Fi networks.
• Select your Wi-Fi network (in the example, a private network).
• Enter the Wi-Fi password and submit.
• Save and Apply properly.

Important gotcha: if you only “save” and forget “save and apply,” rebooting can leave the gateway stuck in the old configuration and it may not reconnect to Wi-Fi.

After applying changes, wait for the gateway to come back online, then find its new IP address on your network (it may change once it joins Wi-Fi).

Step 4: Set system time and timezone

In the system settings, sync time and set your timezone. Timezone matters for timestamps in logs and for consistent behavior across components.

In the setup described, the timezone was set to America/New_York.

Step 5: Update firmware

Check the firmware version and update if a newer build is available. The gateway includes an in-place update mechanism.

While updating:

• Do not power off the device while it is flashing or updating.
• Plan for a few minutes of update time and watch for LED activity changes.

After completion, re-open Lucy and confirm the version is now current.

Step 6: Configure the LoRa network server to use local ChirpStack

In the LoRa network settings, the gateway can forward packets to different destinations depending on your architecture.

The useful option here is to choose the local network server running on the gateway itself.

Once enabled, Lucy shows the IP address of the built-in ChirpStack instance. Open that server in a browser.

ChirpStack login is also provided by the gateway defaults (commonly admin/admin in this setup). After logging in, you should be able to access sections like:

• Devices (where you will add sensors later)
• API endpoints and integrations
• Logs and raw event views

Where this leaves you (and what comes next)

At this stage, the gateway is:

• Powered on with the correct LoRa antenna connected
• Configured via Lucy
• Joined to your Wi-Fi network
• Time-synced and firmware-updated
• Set to use the built-in local ChirpStack server for LoRaWAN processing

The next step is what makes it “real” for sensors: connecting devices, creating device profiles, and verifying that uplink messages show up in ChirpStack as expected.

FAQ

Do I have to use the hotspot method to configure the SenseCAP M2, Lorawan gateway?

No. You can also connect via Ethernet using your LAN. Hotspot mode is simply convenient for initial setup when you do not yet know the gateway’s network IP address.

Why is local ChirpStack useful?

It lets you keep packet processing and sensor data on your local network instead of relying on an external cloud platform. This can simplify early testing and improve privacy and control.

What connectivity options do SenseCAP M2 versions usually offer?

Common options include Ethernet, Wi-Fi, and some versions also include 4G LTE via a nano SIM. The exact mix depends on the specific model you purchased.

Which regional frequency plan should I choose?

Choose the version that matches your region (for example, US915 for many parts of the United States). Using the wrong region will prevent proper LoRaWAN operation.

What is the most common setup mistake people make?

In this workflow, forgetting to use “Save and Apply” after changing Wi-Fi settings. Without applying changes, the gateway may not reconnect as expected after reboot.

Links

• Seeed SenseCAP M2 (US) - https://www.seeedstudio.com/SenseCAP-Multi-Platform-LoRaWAN-Indoor-Gateway-SX1302-US915-p-5472.html?sensecap_affiliate=agiE1S0&referring_service=link
• Seeed Solar Node - https://www.seeedstudio.com/SenseCAP-Solar-Node-P1-for-Meshtastic-LoRa-p-6425.html?sensecap_affiliate=agiE1S0&referring_service=link

Ever wished you could move a small amount of data over miles without relying on Wi-Fi, cellular service, or a full mesh network? That was exactly the point of this build: use LoRa as the long-range link, then use Bluetooth as the “local display” so you can read messages directly on your phone.

This setup uses REYAX RYLR999 chips, which combine LoRa 915MHz and Bluetooth in one module. The cool part is the bridging approach: send over LoRa from one node, and on the receiving side bridge the data back out to Bluetooth so your mobile app can subscribe to what arrives.

What makes the RYLR999 interesting?

Inside each node is the latest REYAX silicon (the RYLR999). What makes these chips especially compelling for DIY is that they bring both radios to the table:

• LoRa (915MHz) for long-range transmission
• Bluetooth for reading data locally

There are also some practical details that make builds easier. The nodes can provide a strong transmit capability (described as 30 dBm LoRa output) and they support proper external antennas. Earlier versions often relied on smaller built-in antenna setups. Here, you get IPX connectors, so you can mount real antennas tuned for:

• 915MHz LoRa
• 2.4GHz Bluetooth

Finally, there are separate UART interfaces for the LoRa side and the Bluetooth side. The bridge is conceptually simple: feed data into the module over one interface, transmit across LoRa, and then output it over the other side so a phone can see it.

The core idea: bridge LoRa to Bluetooth

The project’s architecture is two nodes:

• Sending node: generates or receives a message, sends it over LoRa.
• Receiving node: receives the LoRa payload, bridges it out over Bluetooth.

On the phone side, the user workflow is straightforward. A mobile app connects via Bluetooth LE, subscribes to the incoming characteristic, and prints the received messages as they arrive.

Why this matters (beyond “range”)

This isn’t about building a full LoRa network or replacing every connectivity option. It’s a lower-level approach: if you only need to move small packets of data from point A to point B, LoRa does the long-distance part, and Bluetooth does the human-friendly part.

That’s why the idea fits real-world sensor use cases like:

• water level monitoring
• agriculture and livestock telemetry
• emergency and off-grid alerts
• infrastructure monitoring
• DIY prototypes that need “it just works” connectivity

Building the nodes (3D printed cases + real antennas)

Having chips sitting on a bench is annoying long-term, so the build started with 3D-printed enclosures. Each enclosure includes:

• two holes on top to mount the LoRa and Bluetooth antennas
• a bottom opening so the node can be powered

After the mechanical build, the first steps were functional testing:

• connect the chip to a PC using a USB-to-serial adapter
• send commands like reset and addressing (AT-style commands)
• confirm that a “hello” message successfully transmits and is received

Then the Bluetooth bridging behavior was added via the Bluetooth side jumpers/wiring so that messages appear on the phone app.

Generating test messages with ESP32-C3

To prove the concept reliably, an ESP32-C3 was used as a message generator on the sending node side. The reason is simple: it’s easy to send a periodic payload without needing external sensors while you validate the radio link.

The sending logic was “send every 10 seconds.” Each packet contained a small string like:

• “message: 52”, then 53, 54, and so on

Those messages travel:

1. from the ESP32-C3 to the REYAX module via UART
2. over LoRa to the receiving REYAX node
3. then bridged out over Bluetooth LE
4. and finally displayed in the mobile app

For the phone UI, the app used was LightBlue. The workflow was:

• connect to the device via Bluetooth LE
• select the correct characteristic
• subscribe to “messages received”
• display incoming payloads as UTF-8 strings

Power notes you should not skip

The demo used power banks for convenience, but the important lesson is voltage compatibility:

• These chips do not work on 3.3V.
• They require 5V.

So even if your ESP32-C3 runs happily at 3.3V, the LoRa/Bluetooth nodes still need the proper 5V supply. In this build, the ESP32-C3 primarily served as a logic sender, while the Bluetooth-focused side used wiring to ensure it still received 5V.

Real-world range test at Fort De Soto

The most convincing part was taking the system outside and seeing what it could do with actual obstructions, distance, and real antenna placement.

Pier to far parking lot

On the pier, the receiver kept getting packets as the sending node transmitted every 10 seconds. The narrator notes packet numbers climbing steadily, and then continued movement toward longer distances.

As the receiver moved farther, the link still produced usable traffic, even showing error packets along the way. Importantly, the test clarified that the result was achieved with a standard antenna, not an exotic custom antenna setup.

North beach distance (including “behind trees and bushes”)

The system was carried toward the far side and into locations where signal might be partially blocked. The receiver showed reliable packet reception during movement and reported values that included:

• RSSI (signal strength)
• SNR (signal to noise ratio)

Even when RSSI dropped significantly, the receiver still managed at least some successful decodes. That’s exactly what you want to know for sensor deployments: you need to know where “maybe it will work” turns into “it’s consistently readable.”

Concrete bunkers: still receiving, but decoding may fail

One of the more brutal tests was inside bunkers. The receiver recorded activity (it could “receive something”), but decoding failed with an error reported (an “Error 12”), which is a realistic reminder:

• RF can sometimes penetrate, but decoding depends on enough SNR.
• Expect better results outdoors than inside thick concrete.

Closing the loop: finding the source

The receiver eventually got much stronger RSSI again closer to the sending node, and packet numbers increased reliably. As the nodes approached alignment and separation decreased, the link became clearly stable.

That last part is practically useful. In the field, knowing whether you can “hunt down” a transmitting sensor by walking toward increasing signal helps with commissioning and troubleshooting.

Common DIY applications for this LoRa + Bluetooth bridge

This bridging approach is a great fit when you want:

• low data rates (small status updates)
• long distance without Wi-Fi or cellular
• easy inspection using a phone app
• a simple receiver that outputs readable Bluetooth data

Examples that map well to the demo:

• a pump or tank sensor sending periodic “level” values
• a gate sensor that reports “open/closed”
• a weather station that transmits short summaries
• off-grid alarms that trigger periodic updates for confirmation

FAQ

Project link

Project files: Bluetooth to LoRa Bridge

Links: (Note: As an affiliate, I earn from qualifying purchases)

• RYLR999 Amazon
• RYLR999 Digkey
• RYLR999 eBay
• RYLR999 US Distributor Lemos International
• RYLR999 US Distributor Micro Technology Group
• 3D Printer I use (1 color)
• 3D Printer I use (multi color)
• USB To Serial
• Project files

Table of Contents

• What this design solves
• Parts and tools (quick list)
• Design and enclosure notes
• Step-by-step assembly
• Meshtastic setup and configuration
• Deployment tips
• Common pitfalls and how to avoid them
• Why this is a good Meshtastic Solar approach
• FAQ
• Resources and files

What this design solves

Traditional single-panel solar nodes are sensitive to orientation. A node that spins when hoisted into a tree can end up in a direction that receives little sun. This tree node uses three panels arranged around the body so at least one panel receives light regardless of orientation. It is also built slightly heavier so it does not constantly blow around, and the enclosure is designed to drain water downward and seal at the bottom.

Parts and tools (quick list)

• Core board: Seeed nRF52840 with SX1262 (very power efficient for Meshtastic Solar).
• Alternative boards: Heltec V4, LoRa32/Heltec variants work too.
• Charge controller: Small simulated-MPPT TP4056-style step-up board (better than stock TP4056).
• Battery: 18650 (3500 mAh recommended).
• Solar: Small 5V micro-panels (three in parallel).
• Enclosure: 3D-printed body with drain design, or waterproof project box.
• Extras: SMA pigtail, breather plug, silicone sealant, 3M double-sided tape, small cable ties, hook for hoisting.

Design and enclosure notes

The enclosure is 3D-printed with a top hook and a bottom sealing plate so any water flows down and the bottom seals. I added indents for the solar panels and routed wires through small holes that are later sealed with silicone. There is a small breather plug at the bottom to help equalize pressure and reduce condensation inside the enclosure.

Step-by-step assembly

1. Prepare the LoRa board and antenna

Open the Seeed nRF52840 + SX1262 board, replace the default tiny antenna connector with a proper SMA pigtail, and identify the battery pads. The goal is to feed the board like it has a battery attached. The charge controller will simulate the battery connection rather than using the 5V pad.

2. Mount and waterproof the solar panels

Use three small panels and glue them into the side slots with a small bead of silicone at the top and bottom to lock them in place. Feed the wires through the designed holes, then seal the inside where each wire enters so the enclosure remains waterproof.

3. Wire panels in parallel and connect to charge controller

Join all positives together and all negatives together, then feed that pair to the solar input on the charge controller. Small panels should be paralleled for higher current while keeping voltage suitable for the charger. After wiring, verify the controller shows charging when exposed to light.

4. Mount the charge controller, battery holder and core board

Use 3M double-sided tape to secure the controller and the board to the inside of the enclosure; tape works well if placed carefully. Watch polarity on every connector—these small two-pin JST connectors are often wired inconsistently from suppliers, so confirm the board markings before plugging in.

5. Install breather plug, antenna and final sealing

Fit the breather plug and SMA connector and tighten. Add silicone around the antenna feedthrough and the breather plug for extra protection. Do not insert the battery until the antenna is attached; powering a radio without an antenna can damage the transmitter.

6. Battery and first power-up

Install the 18650 and plug the battery into the controller. Double-check positive and negative wiring. On power-up you should see the Meshtastic module LED flash. If using Bluetooth for initial setup, it can be paired temporarily, but for permanent deployment it is better to disable Bluetooth and enable remote management.

Meshtastic setup and configuration

Flash the latest Meshtastic firmware to the board. When first connecting via the Meshtastic mobile app the default PIN for devices without a screen is 123456. Configure LoRa region and channel (for example US frequencies like 906.875 MHz if applicable), set hops, enable MQTT if you use a backend, and give the node a sensible name like "voft.live tree node".

Deployment tips

• Orientation: The multi-panel approach mitigates random rotation, but still tie the node so it does not spin freely. A secondary tie prevents constant orientation changes in wind.
• Weight: Make the node slightly heavier so it resists being blown around but not so heavy that hoisting is difficult.
• Antenna: Use an external SMA antenna mounted at the bottom so it clears foliage and has space to radiate.
• Monitoring: Configure remote management and telemetry so you can monitor battery voltage and charging remotely and disable Bluetooth in the field.

Common pitfalls and how to avoid them

• Wrong JST polarity: Double-check connector orientation. Many cheap connectors are wired backwards.
• Powering without antenna: Never transmit without an antenna attached—this can damage the RF stage.
• Insufficient charge controller: Small TP4056 boards are okay, but a simulated MPPT controller will keep the battery healthier and harvest more energy in variable light.
• Leak points: Seal solar wire entry holes and feedthroughs with silicone. Use the breather plug to reduce internal condensation rather than sealing completely airtight.

Why this is a good Meshtastic Solar approach

This tree node balances simplicity and reliability. The Seeed nRF52840 + SX1262 board is low-power and well-supported by Meshtastic. Multiple small panels reduce orientation risk and keep the node charging despite rotation. The design is modular: you can swap in other low-power LoRa boards and different solar sizes, and the 3D-printed enclosure means the project is reproducible.

FAQ

What is the recommended board for a Meshtastic Solar node?

The Seeed nRF52840 with SX1262 is recommended for its power efficiency and LoRa performance. Heltec V4 and similar LoRa ESP32 boards also work if you prefer an alternative.

How do I protect the electronics from moisture?

Design the enclosure so water drains away from electronics and seal any wire entry points with silicone. Use a breather plug to reduce internal condensation rather than making the case completely airtight.

Can I use a different battery than an 18650?

Yes, but 18650 cells are compact, widely available and provide a good capacity-to-size ratio. If you use a different chemistry or cell format, ensure the charge controller and connectors match and that you adjust the enclosure accordingly.

How long will the node run on battery alone?

Run time depends on board power draw, duty cycle, and sunlight. With a low-power board like the nRF52840 + SX1262, conservative TX intervals and a 3500 mAh 18650, the node can run for weeks without sun, and months with regular charging from the panels.

Resources and files

3D print files, project documentation, and assembly files are available for reproducible builds. Use the printable files to adapt the enclosure size and panel layout.

Seeed nRF52840 - https://www.seeedstudio.com/XIAO-nRF52840-Wio-SX1262-Kit-for-Meshtastic-p-6400.html?sensecap_affiliate=agiE1S0&referring_service=link

Heltec V4 (No Screen) - https://amzn.to/4dqVV4c

Charge Controller - https://amzn.to/4uynMFF

18650 Battery - https://amzn.to/4koPUqq

Battery Holder - https://amzn.to/4jZW9Pz

SMA Connector - https://amzn.to/4bvpuz8

915Mhz Antenna - https://amzn.to/3PmXJBi

Solar Panels - https://amzn.to/47xSvJe

3D Printable Files - https://www.printables.com/model/1640281-meshtastic-meshcore-tree-node

Project files - https://hub.lorameshdevices.com/projects/solar-tree-node-meshtastic-meshcore

MeshCore treats sensor nodes differently from typical mesh devices. Instead of constantly broadcasting telemetry, a MeshCore sensor sits quietly and responds when a companion node asks for data. That pull-based approach helps extend battery life and keeps sensor nodes focused on sensing rather than relaying network traffic.

What is a MeshCore sensor?

A MeshCore sensor is a node whose primary job is to collect telemetry—temperature, luminosity, GPS, battery level—and deliver that information only when polled by a companion node. The device itself does not relay messages or act as a full network participant. That makes it ideal for long-term monitoring where power efficiency matters.

Hardware used in this example

The example setup uses a Seeed SenseCAP T1000-E as the sensor. It’s a compact tracker with built-in GPS, temperature sensor, lux sensor, and a battery. A separate companion radio (a Heltec V3 in this case) acts as the active device that polls the T1000-E for telemetry.

Pull vs push: why MeshCore pulls telemetry

Traditional Meshtastic-style setups often push telemetry periodically. MeshCore opts for a pull model: the companion node sends a request and the sensor replies. Benefits include:

• Lower power consumption on the sensor since it does not transmit constantly.
• Simpler sensor firmware—no need to participate in routing or message relaying.
• On-demand readings so the companion only requests data when needed.

Custom firmware and setup notes

Right now, turning a T1000-E into a MeshCore sensor requires a firmware change. That means compiling a small sensor section from the MeshCore source and flashing it onto the T1000-E as custom firmware. Once flashed, the T1000-E functions strictly as a sensor node.

The firmware change is lightweight: it disables routing/relay roles and exposes a telemetry endpoint that responds to authenticated requests from a companion.

Discovering and adding sensors in the MeshCore app

Use the app’s tools menu and choose "Discover nearby nodes." The app can find repeaters, room servers, companion nodes, and now sensors. When the companion radio is in range it will list detected sensors separately.

When the T1000-E appears in the sensor list you can add it. After adding, opening the node and hitting the telemetry button prompts the companion to authenticate and pull the latest readings.

Telemetry, commands, and map view

A telemetry request returns a concise payload: battery level, temperature, luminosity, and GPS coordinates if GPS is enabled. Because each telemetry call is a pull, the sensor only wakes to reply, keeping average power use low.

You can manage the sensor from the app once authenticated: set radio region, change basic settings, or issue commands. For example, sending a "GPS on" command will enable the GPS module and subsequent telemetry requests will include location.

The app map shows sensors with a distinct icon so they stand out from repeaters and room servers. Clicking the sensor on the map brings up its last-known telemetry and location.

Practical tips and best practices

• Use a dedicated companion radio to poll sensors. A small Heltec V3 or similar works well.
• Enable GPS only when needed—GPS uses more power, so toggle it from the companion when you need location fixes.
• Keep authentication secure—default passwords are fine for testing, but change them for production deployments.
• Place sensors thoughtfully so the companion can reliably reach them when it polls telemetry.

Where MeshCore sensor nodes shine

MeshCore sensor nodes are good for environmental monitoring, asset tracking, or use cases where periodic data is fine and long battery life is essential. They are especially useful when you want the advantages of LoRa range without loading small sensors with relay duties.

Quick setup checklist

1. Flash the T1000-E with the MeshCore sensor firmware build.
2. Power on the companion radio and open the MeshCore app.
3. Discover nearby nodes → select "Discover sensors".
4. Add the T1000-E entry and authenticate.
5. Request telemetry or send commands (for example, "GPS on").
6. Use the map view to verify location and sensor iconography.

Final thoughts

MeshCore’s pull-based sensor model is a useful pattern for low-power telemetry deployments. Converting a compact tracker like the T1000-E into a dedicated sensor node keeps hardware simple, preserves battery life, and still gives you on-demand access to temperature, light, GPS, and battery data via a companion device.

Links: (Note: As an affiliate, I earn from qualifying purchases)

• Seeed T1000E (Use code 'S0G9HWFL' for a discount) - https://www.seeedstudio.com/SenseCAP-Card-Tracker-T1000-E-for-Meshtastic-p-5913.html?sensecap_affiliate=agiE1S0&referring_service=link
• Seeed T1000E at Amazon - https://amzn.to/4qy0tJI