Writing

MeshEnvy operates a public mesh across Nevada. The mesh is comprised of both MeshEnvy equipment and equipment supplied by individual community members. The mesh is open and anyone can extend it by adding their own equipment.

In order to reason about and understand the mesh, it is helpful for individual sites to share a name and location publicly. Then others can see where the mesh is dense, where it is sparse, and plan how to extend it. Without knowing where a certain site is located, it is more difficult to conduct legitimate mesh-building work. Builders have a reasonable basis for wanting site names and locations.

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.

MeshEnvy operates a public mesh across Nevada. Privacy-first routing is how our backbone repeaters behave on the air.

MeshEnvy does not publicly disclose repeater names or locations. The coverage map shows where the mesh reaches, not individual node identities or coordinates, consistent with our privacy policy. Backbone repeaters run in privacy mode. They do not answer anonymous requests for site-identifying data.