Defining the Personal Journey — Meshing Around with Meshtastic: Part 1

Hello folks, this is going to be a miniseries for my current Radio blog. I’ve been hard at work integrating some new technologies into my homelab. As such, I’ve been leaving a communication gap about my project experience. To address that, I’ve got the following content from my first week exploring Meshtastic. This is only the beginning of my dive into the technologies at hand, as I plan to expand upon this in the coming weeks.

So don’t think of this as a half-finished blogpost, but think of it as a sample for what’s to come while I’m out in the field juggling some surveying work with a new extension to my homelab work.

Starting with Security, Branching into Comms.

The first time I heard about emergency communications was something called the GETS card. This is a tool to provide priority access to cellular networks in the event of an emergency. But this doesn’t consider what happens when the grid goes down. In that case, radio comms over VHF/UHF are still viable. Is there another way to access a decentralized network should the system become unavailable? This is a scenario known as “the grid goes down” and favors preparing as an individual much like a business would prepare with a Disaster Recovery and Business Continuity plan.

Enter Meshtastic, a decentralized network connection over very tiny computers to access a network. It works similar to APRS which transmits packets over vhf/uhf as a digital mode. I discovered the project right before a trip to a convention. After gaining my radio license I’ve been feverishly curious to do more Small Board Computing (SBC) projects like this one.

Hooking Meshtastic to the Homelab, a Stationary & Mobile setup crash course.

I decided that the best way to start using Meshtastic was to make a new homelab segment specific for radio equipment. It’s taken a lot of trial and error but I’ve devised a unique setup with the goal of repurposing old gear for the network. However, the scrap bin was mostly scrap itself. This led to needing to budget and order a handful of parts to get the most of it. It was a good excuse to upgrade some network equipment and add the ham segment to my homelab.

The integration process took a couple of days to explore and work into. Once I got it going I was able to see the wide spread of locals and folks from as far away as Canada in the Meshtastic network. The antenna seemed to be doing the trick. It could talk to a node about 2 miles away to use as a main connectivity router over LoRA Radio. From there that device forwards everything outward to the rest of the network.

The antenna rig seems to be workable for the time being. I haven’t had the need to use a J-pole, but there are some issues with neighboring connections with the choice of antenna. It’s not a drastic issue, thankfully. Once I set up the antenna properly on a J-pole I may see some improvements here. My goal is to eventually set up outdoors and double the range every other week, going from 1 mile to 2, 4, 8 and so on.

Going with a distance test on a second device taught us a lot of things. For one the antenna types matter a lot. Antennas exist for outdoor base stations and mobile travel. The outdoor fiberglass on the base station couldn’t reach a mile out to a coiled antenna which was included with the kit. A UFL to SMA cable to any typical antenna performs adequate to the scenario and effectively doubles the range.

The previous test rig for our Antenna.

I felt the need only a few days later to make a setup with my portable system in case the grid goes down. For that we have a Heltec V3 coming to shove in with an emergency radio if needed. The setup for it uses the case it came in, and a spare car power outlet when running.

===

Power vs Positioning, Antennas & the physical connection.

I started by using some of the mapping apps available to plan Antenna position and location. These maps don’t actually tell you how many nodes are in your Meshtastic area(shoutouts to Brian Shea for his community meshmap). As of the time of writing there are about 228 nodes in the network around my area, spanning from Toronto to central New York. Obviously I couldn’t cover all of these nodes, so this had become a slow and steady process of expanding and organizing the range and effectiveness of radio transmissions.

I was getting best performance at lower power settings around 26 dBm and below. I noted the gate of 20 dBm would be the most effective for the given scenario, and that using too much power here would cause issues with communication, and it would also cause a fairly high error rate to occur. So we adjusted the power and antenna positioning. There’s allegedly some wiring issues with the power output on these devices despite being high power. I figure there could be a number of physics factors at play, but I won’t dig too deeply into it. Simply noting the results from testing, lower power output was better despite not stretching to the advertised range.

Like other node users, I saw immediate improvement of sent and received packet transmissions, and a relay packet sent without issue. I’m still determining the best course correction here, but antenna position and location matters the most, and high gain antennas seem to do better at lower power up close, and higher power further away.

Transmitted messages acknowledged by other nodes aren’t stored, forwarded and kept by other nodes unless the “Store & Forward” module is enabled. So the upcoming upgrade to the lab device and running in store and forward saved us a lot of the communication mishaps that we’d experience otherwise.

I’m still tinkering with the power levels here and there, trying to see if I can keep range and signal strength in a good balance for distant nodes. I also have a management interface I’m testing out that would work outside of the use of smartphones. Stay tuned for more info on integrating this environment with other SBC devices.

Some of the costs associated with the project as reflected by Amazon as of today:

• Meshtastic devices x2: $50~
• Antenna: $28
• Jpole: $18
• Tape: $6
• UFL Adapter: $8

Total: $110

Setting up MQTT via ESP32, a perplexing and painful learning experience:

I also had another project to dive headfirst into here: A weather station. Weather Stations are used across Meshtastic radio and use the MQTT protocol. The problem is that the use of MQTT is not used interchangeably between traditional IoT and Meshtastic’s implementation. Couple that with jargon like brokers and subscribers and you’re in for a nightmare reminiscent of a website owner trying to handle fullstack development in a pre-AI era. There are a lot of front and backend moving parts so strap in and let’s see what went wrong on the first push in what was going to be a weather station.

Firstly, everyone uses WeatherKit. WeatherKit is the standard protocol for apple devices to communicate weather data. When a phone sends weather data, it works no issue. In fact, Apple devices can get weather data via satellite. Apple’s satellite radio is outside the scope of this blog, but it’s a very powerful tool. (I have a vested curiosity recently about L-band communications, so there may be a blog post in the future on that area at some time.) Meshtastic devices that are communicating with mobile devices over Bluetooth can pull weather data from the device itself.

Another way it can pull this data is when connected via MQTT. This is the one time I’ll say the acronym isn’t that important, but the outcome still remains relevant. MQTT takes formatted data from a sensor, like a digital thermometer, and sends it to either a broker, a data source, or a subscriber, a data sink. From there it’s sent to the Meshtastic tool upon request.

But wait you say, doesn’t the Meshtastic node need to be connected to your network gateway to interact this way? Why yes it does, and that introduces a giant convoluted set of issues that would make a ham scoff. But we’re not only a ham, we’re an IT Ham, so we pushed onwards here. We’re using our Mikrotik mAP device to run the HF listener and the device can be either a broker or subscriber in this case. Ideally we’ll use it as the broker.

But we come across a trouble spot, what kind of MQTT data will we be gathering? Well I have a spare Govee ThermoHydrogmeter sitting around so we gave that device a shot outdoors. Well there’s pros and cons to using this, particularly that Govee’s ecosystem is locked down and their MQTT data, while accessible, is specific to their ecosystem. So the code that gets sent will need to be re-encoded before being delivered to Meshtastic.

But that doesn’t describe how it would connect to the MQTT server in the first place. Another limitation is the lack of Wi-Fi on this module. A middle-ware device would be needed to send the bluetooth data to a source. Our available devices include a handful of ESP32’s and an Android 7 phone. The android option would be to run a script in terminal emulation software. This doesn’t scale very well, and if the phone needs to restart then it’s not going to work again until the script is re-run. That brings us to the Esp32 devices.

Unfortunately, there’s not very good news with the available tools here. The best tool for the job is one called OpenMQTTGateway. This is written in C & C++ for Esp32 devices and has the hallmarks of a tool that would be just useful enough if not for the frustrations. Firstly, it seems to have rather unreliable wifi and bluetooth connectivity. In my testing I was unable to pair the Govee sensor to both an ESP32 C3 and a standard ESP32 dev board. It supposedly auto-pairs, but that functionality didn’t work.

When I was configuring Wi-Fi for the devices, the connection would constantly drop out. When the connection drops out, the config file is wiped from memory instantly. The Wi-Fi connection is still written, but the configuration for the server didn’t persist on reboot, similar to our android problem. So a good handful of hours was wasted in setting up when the device was simply not configuring the connection. It also would not talk to the Mikrotik MQTT broker due to the inconsistent connection issues.

Feeling rather defeated, I gave up on this idea for now. I’ll probably seek out a weather station that supports better radio or Wi-Fi connectivity instead of bluetooth-only. Besides, WeatherKit works just fine and nobody else in the mesh network seems to be using their own DIY station yet.

A lot more data to dive into soon.

Meshtastic is a deep and rewarding radio project. It’s one that may not require a ham license depending on how you utilize it. It’s turning out to be a very active and informative area to explore and the most involved project I’ve had in some time. I plan to keep running both the outdoor and mobile stations and adapting to the changing hardware and software ecosystem of the project. Make sure to follow if you’re interested in learning More alongside my blogs covering Security, Technology Media, and Community. See ya next time, folks.

Stay Safe Out There & 73.