Writing

A lot of you have been asking for a step-by-step walk-through of how to make a solar repeater out of a solar light. I've made about 50 of them so far, so I feel like I finally have something useful to say about it. Enjoy the tutorial.

A janknode is a solar repeater in a repurposed solar-light enclosure. The panel and the cell are already in the housing. You take the light out and put a radio in.

I use an nRF board. The compact choices are a RAK4631 or a Seeed Studio board. The RAK kit shows up more finished, with JST leads for the panel and the cell. The Seeed board is about half the price and needs more soldering. Turnkey RAK, or budget Seeed. Either one works. The shells and the parts are at janknode.fyi.

Take a shell you can open. Pull the LED panel, solder the radio leads onto the battery leads, and drill for the SMA. Silicone both sides of that connector, and keep it out of the antenna. Tuck the board in and flash it.

Peavine Peak is the summit northwest of Reno and Sparks. You can see it from almost anywhere in town. The west summit is about 8,266 feet, and the crest already carries a lot of towers and dishes.

Dave Metts keeps a High Sierra site at the high point, looking over Reno, Sparks, and Cold Springs. A node there is the Reno end of the Silver Triangle: Reno to Las Vegas, Reno to Elko and Wells, and Wells back to Las Vegas. From Ophir Hill, a test node on a T-stake has talked to Peavine across about thirty miles.

This is the story of our Peavine Peak node, twice. The Hawk Fire took the first one out.

Thanks to Dave Metts at High Sierra Communications, NV Energy, Washoe County, and the firefighters and first responders who risked their safety to keep Reno safe. The new node is up. The old one is in the janknode hall of fame.

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.