Writing

We push MeshCore settings to field repeaters over the mesh. Most of the time that is fine. Sometimes you are tuning receive paths to save milliamps on a solar node and you wonder what happens if you push too far. A repeater that stops hearing you is a long drive.

set is permanent. MeshCore already has tempradio for a live RF experiment that clears on reboot, and hop.ignore for a volatile bench knob. Neither covers "try this pref for an hour, then put it back unless I commit."

Out in Nevada we cover a lot of empty ground with janknodes: repurposed solar-light enclosure, cell, repeater zip-tied to a fence post.

RAK4631 janknodes have been our keep-up proof. Field units hold about 4.0 V and have made forty-mile MeshCore hops with a stock SX1262 and no external amp. Twelve Heltec T096 janknodes sitting on the deck, built the same way, have not held voltage the same way. We did not run a bench meter campaign. We left them in the sun, polled battery voltage through the fleet tool, and changed two MeshCore settings that already exist on the radios.

A year ago I could not have told you what duty cycle meant. After spending time in the radio world, I understand it as the amount of time a radio is allowed to transmit per hour. A 50% duty cycle means the radio may use up to thirty minutes of transmit time in that hour. That is a ceiling, not a promise. If there is nothing to send, nothing goes on the air and no budget is consumed.

The hard part of a statewide mesh is not flashing a radio on a bench. It is changing firmware on a repeater you will not see again for months, over a link that is already busy carrying real traffic, without bricking the node or stepping on the mesh.

That is what mota is for. A .mota file is a self-checking firmware package that can travel over LoRa a kilobyte at a time. Neighbors advertise what they have. A node fetches the pieces it needs at the lowest radio priority we have. Nothing installs until someone says so, or until you have explicitly trusted a signer.

The original OTA design is vk496's. EnvyOS packages it with motatool, an apply bootloader we call EnvyBoot, and a release habit that matters more than any of the file formats: one delta from every prior fleet image, straight to latest.

Summary​

The purpose of this article is to introduce a Meshtastic Universal Sensor Interface template (hardware and software) that uses the Serial Module of Meshtastic as a data link to collect information remotely from sensors connected to a Meshtastic Node. While there is a wide range of sensors included in the portfolio of sensors that are integrated into the Meshtastic firmware and reported out of the Node as telemetry, there are other very capable sensors that are not included (generally very specific, unique, and professionally oriented sensors). Using the Serial Module and UART avoids tampering with the Meshtastic firmware or depending on the Meshtastic development group to modify the firmware for unique sensors. This strategy makes the Universal Sensor Interface independent of the Meshtastic firmware as long as the Serial Module is maintained by the development group.

Basically, I wanted to address a caveat that is mentioned in the Meshtastic documentation: "...other interesting sensor types and use cases we need to add a portnum (sic) for more generic telemetry packets and a second MCU will be required to interact with the sensor and process the data to be sent over the mesh."

Keep in mind, this project is intended to be a template only, I have however used this template to develop working remote sensor systems. It is up to you to cut, paste, plagiarize, and modify the template to your heart's content and make the project your own.

Nevada is full of radio towers, from AlertWildfire cameras and mine sites to state DOT compounds and commercial repeaters. We partner with tower owners constantly and we are grateful for the access they give us. A tower compound is often the right place to start thinking about a site, and it is not always where we finish.

While Meshtastic (MT) and MeshCore (MC) have some useful features to evaluate the path and signal quality between two nodes, there are instances where those features fall short; particularly when operating in a remote location without a robust mesh architecture or where there are no "active" mesh participants with the time nor proclivity to respond to signal strength requests. For example, a Scout camp is setting up a temporary, stand alone Meshtastic network to cover the confines of the camp area and the leaders want to verify the coverage using handheld nodes. In this case, a "Ping-Pong" like system would be useful.

In this article I will present a "Ping-Pong" system that is an example of a simple application that is based on the MT Universal Serial Interface that was the topic of a previous article. In the Ping-Pong application, the PIC of the Universal Serial Interface is programmed to listen for the word "Ping" received via the Serial Module, and if received, the word "Ping" is replaced with the word "Pong", and modified packet is transmitted back on a private channel. This verifies the integrity of the path between the two nodes without the need for other operators to be involved. I view the Ping-Pong system as a piece of mesh and LoRa test equipment. It also demonstrates how the Universal Serial Interface can be used for command and control of attached devices and sensors.

The addition of the Topaz MeshCore Node by MeshEnvy introduced MeshCore into the Antelope Valley and Coleville in Mono County California. Before that Node addition, it was crickets down here. The Mesh now covers from the Soldier Meadows area north of Black Rock to Topaz/Coleville in the south: a distance of 210 miles. The issue with this new resource is reaching the last mile with a WisMesh Tag which is a bit hard-of-hearing. I added the Coleville Node to provide more reliable coverage of the Antelope Valley with hand-held or mobile MC systems like the WisMesh Tag. The resulting improvement was on the order of approximately -4dB Tag to Topaz vs. +11.75dB Tag-Coleville-Topaz and beyond.

What is the best vertical antenna for a Mesh or LoRa radio?

From the beginning of my tenure with Mesh and LoRa, I have used the RAK4631/RAK19007 combination to homebrew my own hand-held and stand-alone Node devices. Since signal quality is important to LoRa, the antenna is something within my control that I can change to make the systems more effective. I found the plethora of antennas available daunting with wide ranges in advertised performance metrics and prices. I set out to determine which antenna provides the most bang for the buck.

Summary: The TX915-JKD-20, available from Amazon, proved to be the best performer at the best price. Figure 1 shows the tabular summary of the antennas tested.

Antennas tested (figure 1):

• A — Stock 1/4λ vertical stub antenna supplied with RAKwireless Mini Meshtastic Starter Kit (Rokland)
• B — 1/2λ end-fed vertical dipole, Linx ANT-916-CW-HWR-SMA-ND (DigiKey) — $12.30 each
• C — 915 MHz LoRa antenna, 5 dBi (Amazon) — $11.99 for two
• D — TX915-JKD-20, 4.3 dBi (Amazon) — $13.00 for five

At MeshEnvy, our mission has always been clear. We want to ensure that anyone, anywhere in Nevada, can stay connected. While the LoRa (Long Range) hardware standards provide a powerful foundation for this vision, the software protocols that drive that hardware are just as critical. After extensive testing and real-world experience, we are officially migrating our primary deployment strategy from Meshtastic to MeshCore.