Introduction — Building More Than a Radio Network

There is no shortage of documentation explaining what MeshCore is, or how to flash firmware onto a compatible radio. The official documentation covers supported hardware, installation procedures, configuration options, and protocol features well. What is much harder to find is documentation that follows the process of building an actual network from the ground up, complete with incorrect assumptions, unexpected problems, troubleshooting, and the lessons that only emerge through field experience. This article is intended to document that process.

Like many technical projects, this one did not begin with a finished design. It began with a single T-Beam, curiosity about a new mesh networking platform, and a willingness to experiment. That curiosity evolved into a small but functional local infrastructure consisting of a Bluetooth Companion, two T-Deck field clients, a mobile repeater installed on an RV, and a fixed repeater serving the local area. Along the way there were firmware updates, configuration changes, interface quirks, hardware failures, and numerous opportunities to better understand how MeshCore actually behaves outside of a laboratory environment.

One of the recurring themes throughout Signal in the Storm is that resilient communications are rarely created during an emergency. They are built beforehand through planning, experimentation, and repeated testing. A communication system becomes resilient because someone invested the time to understand its strengths, discover its weaknesses, and refine its operation long before it becomes necessary. MeshCore is no different.

The goal of this article is not simply to explain which menu options to select or which buttons to press. Instead, it documents the evolution of two infrastructure nodes, PCG Nomad, a mobile RV repeater, and PCG Cold Springs, a fixed repeater installed at my home, and the practical decisions that shaped their deployment. Those decisions included selecting appropriate hardware, establishing naming conventions, publishing a public repeater, diagnosing an unexpected hardware failure that initially appeared to be a software problem, and validating that multiple repeaters could coexist as part of the same local network.

1. Why MeshCore?

LoRa-based networking has matured significantly over the past several years. What began primarily as a technology for low-power telemetry has evolved into a practical platform for decentralized communications, allowing users to exchange messages without relying on cellular networks, Internet infrastructure, or centralized servers. Among the available projects built around LoRa, MeshCore has emerged as an interesting alternative because of its emphasis on efficient routing, lightweight infrastructure, and encrypted peer-to-peer communications.

At first glance, MeshCore appears similar to other mesh networking projects. For example, nodes exchange information over LoRa radios, messages are encrypted, and repeaters extend network coverage beyond the range of a single device. The differences become more apparent when examining how MeshCore organizes the network. Rather than treating every device identically, MeshCore allows nodes to assume specialized roles that improve efficiency and scalability.

A Bluetooth Companion serves as an interface between a mobile device and the radio network. A client, such as the LilyGO T-Deck, provides a self-contained user interface for messaging and network management. Repeaters extend coverage by forwarding traffic across the mesh, while Room Servers provide additional capabilities for more complex deployments. This separation of responsibilities encourages users to think about infrastructure in much the same way they would design any other communications system; not simply as individual radios, but as components of a larger network.

That architecture was one of the primary reasons I chose to explore MeshCore. Rather than focusing exclusively on handheld devices, it encourages deliberate infrastructure planning. A fixed repeater can provide reliable neighborhood coverage. A mobile repeater can extend that coverage while traveling or during public events. Companion nodes allow users to carry lightweight hardware without sacrificing access to the network. Each role contributes something different, making the overall system more flexible than a collection of identical nodes performing the same function.

Another appealing characteristic is MeshCore's conservative use of radio resources. Efficient routing becomes increasingly important as networks grow. Every unnecessary transmission consumes airtime, increases congestion, and reduces overall capacity. By emphasizing intelligent routing instead of indiscriminate retransmission, MeshCore provides a foundation that scales more gracefully as additional infrastructure is deployed.

For readers familiar with Meshtastic, this article should not be interpreted as a comparison intended to declare one platform superior to another. Both projects have different design philosophies and continue to evolve rapidly. My interest in MeshCore was not replacing one ecosystem with another; it was understanding how its architectural choices might support the development of a reliable local communications infrastructure.

Ultimately, that objective shaped every decision that followed. The goal was never to own another radio, it was to build a functioning network to serve as another layer to my existing communications.

2. Planning the Network

Before flashing firmware or configuring radios, it is worth spending time deciding what kind of network you actually intend to build. That planning process influences hardware selection, node roles, naming conventions, and future expansion far more than many newcomers realize. From the beginning, my objective was to build a layered network rather than a collection of independent devices. Each radio would serve a specific purpose within the overall system.

The first component would be a Bluetooth Companion, allowing an Android phone to access the mesh while carrying only a compact radio. This configuration provides an excellent everyday interface while minimizing size and power consumption. The second component would be a T-Deck, functioning as a fully self-contained field client. Unlike a Bluetooth Companion, the T-Deck integrates the display, keyboard, processor, and LoRa radio into a single device. It serves as an ideal platform for using MeshCore directly from dedicated hardware without relying on a smartphone.

Infrastructure formed the third layer of the design. Rather than depending entirely on handheld nodes communicating directly with one another, I wanted dedicated repeaters capable of extending coverage throughout the local area.

The first repeater became PCG Nomad. As the name suggests, its primary role would be mobility. Installed on the roof of my RV, it could provide extended coverage while traveling, during training exercises, or when operating away from home. A mobile repeater also creates opportunities to evaluate how MeshCore performs under changing topology as infrastructure moves through the network.

The second repeater became PCG Cold Springs, a fixed installation intended to provide continuous local coverage from my home. Unlike the mobile repeater, its location would remain constant, making it an ideal candidate for publication on the public MeshCore map.

Establishing a clear naming convention early also proved valuable. Rather than assigning arbitrary names, each infrastructure node communicates its purpose. Nomad immediately identifies a mobile asset, while Cold Springs identifies a fixed geographic location. As networks grow, descriptive naming becomes increasingly important for administration, troubleshooting, and documentation.

Planning ahead also made future expansion considerably easier. The architecture already anticipates additional repeaters, improved antenna installations, battery-backed power systems, solar-powered remote nodes, and broader coverage testing. By viewing the project as infrastructure rather than isolated devices, every new node can be integrated into a coherent system instead of becoming another standalone experiment.

3. Selecting the Hardware

With the network architecture established, the next step was selecting hardware appropriate for each role. One of MeshCore's strengths is its support for several popular LoRa development boards, allowing builders to tailor hardware choices to the intended application rather than forcing every node to use identical equipment.

For everyday access, I selected a LilyGO T-Beam configured as a Bluetooth Companion. The Companion role is intentionally minimalist, and it provides radio connectivity while allowing the Android application to handle user interaction, contacts, messaging, and administration. The result is a compact package that can be carried easily without sacrificing access to the mesh. For many users, this combination may represent the simplest and most practical introduction to MeshCore.

To provide a dedicated standalone client, I chose the LilyGO T-Deck. Its integrated keyboard and display allow operation without an external phone while also serving as an excellent platform for exploring MeshCore's features in greater depth. Throughout this project, the T-Deck became an invaluable diagnostic tool, particularly when searching for nearby repeaters and confirming that changes to the infrastructure were behaving as expected.

The backbone of the fixed home network, however, would be built around LilyGO T-Beam radios configured as repeaters. The T-Beam combines an ESP32 processor, LoRa transceiver, integrated GPS receiver, battery management circuitry, and support for external antennas into a relatively compact platform. Those characteristics make it well suited for infrastructure roles, particularly when accurate location reporting is desirable.

GPS capability was especially important. A mobile repeater benefits from automatically reporting its current position as it moves through the coverage area, while a fixed repeater can either publish its actual GPS location or use manually configured coordinates to represent its permanent installation. That flexibility allows infrastructure nodes to provide meaningful geographic information to other MeshCore users while supporting a variety of deployment scenarios.

Another advantage of the T-Beam is its suitability for future expansion. The same platform can be mounted in a vehicle, installed in a weather-resistant enclosure, paired with a higher-performance antenna, powered by a battery or solar panel, or integrated into more permanent infrastructure projects. Standardizing on a common hardware platform also simplifies maintenance, spare parts, and firmware updates across the network.

At this stage, the project remained relatively modest with one Bluetooth Companion, one T-Deck, one mobile repeater, and one fixed repeater. Yet even this small collection of devices represented something more significant than individual radios. It represented the beginning of a deliberately designed communications infrastructure; one intended to grow through continued experimentation, careful documentation, and real-world field testing.

4. Flashing the Firmware

With the hardware selected and the overall network architecture planned, the next step was installing MeshCore itself. Although the flashing process is straightforward, it is also the point where the physical hardware begins to take on a defined role. A T-Beam is simply a development board until firmware transforms it into a Bluetooth Companion, a repeater, or another type of network node.

One aspect of MeshCore that immediately stood out was the quality of the browser-based flasher. Rather than requiring users to manually download binaries, install command-line tools, or compile firmware from source, the official flasher provides prebuilt images for supported hardware and walks the user through the installation process. For anyone new to ESP32 development, this removes much of the complexity normally associated with embedded devices.

Even so, selecting the correct firmware image remains important. Several LilyGO boards appear very similar externally while using different LoRa transceivers or hardware revisions. Flashing the wrong image may still produce a functioning device, but individual features such as GPS, display support, LEDs, or radio operation may not behave correctly. Verifying the hardware model before flashing saves considerable troubleshooting later.

My first installation configured a T-Beam as a Bluetooth Companion. The process was uneventful. After erasing the existing firmware, the MeshCore image was written to the radio, the device rebooted, and Bluetooth pairing with the Android application completed without difficulty. Within a short time, I was able to exchange messages and begin exploring the MeshCore interface.

That successful installation also provided an important point of reference, because with the Companion operating normally, later problems encountered while configuring repeaters could be compared against a known-good installation. In technical troubleshooting, having one working configuration often proves more valuable than having several unknown ones.

The next step involved configuring a second T-Beam as a repeater. Although the flashing procedure was essentially identical, the operational behavior changed significantly. Unlike a Companion, a repeater is intended to operate continuously, forwarding traffic for other nodes rather than serving as an interactive client. The administrative interface exposes additional configuration options related to advertising intervals, infrastructure settings, radio parameters, and location reporting.

This stage also introduced the browser-based USB administration interface. Instead of relying entirely on serial terminals, many configuration tasks, including naming the node, assigning coordinates, selecting radio presets, and managing firmware, could now be performed through a clean graphical interface. At the same time, the serial console remained invaluable for diagnostics because it reported information not always visible elsewhere, including GPS status, satellite lock, and internal clock synchronization.

As the network grew, I found myself moving regularly between three administrative tools. The browser interface handled initial configuration, the Android application provided day-to-day management, and the serial console offered direct insight into what the repeater was actually doing internally. Each interface revealed different aspects of the system, and learning when to use each became part of understanding MeshCore itself.

By the time the firmware had been successfully installed on multiple devices, the project had moved beyond simple experimentation. The individual radios now had defined responsibilities within the network. The next challenge was turning those freshly flashed devices into functioning infrastructure.

5. Building the First Repeater — PCG Nomad

The first infrastructure node deployed was PCG Nomad, a mobile repeater intended to travel wherever I did. Rather than viewing it simply as another radio, I approached it as a mobile communications asset whose purpose was to extend the local mesh beyond the range of handheld devices.

Installing the repeater in a vehicle offered several advantages. A vehicle typically provides a more favorable antenna location than a handheld radio, offers continuous power while driving, and naturally moves through different portions of the local coverage area. As a result, the repeater could potentially bridge users who would otherwise be unable to communicate directly.

I did not use the LilyGO T-Beam for the mobile RV installation, and instead I purchased a SeedStudio SenseCAP Solar Node which originally had Meshtastic firmware installed. Once it arrived in the mail, I was able to flash it with the Meshcore firmware using Meshcore's web-based application for flashing and configuration via the Console.

Configuration began with assigning an appropriate name. Rather than using a serial number or arbitrary callsign, I chose PCG Nomad. The name immediately communicates its role, and anyone discovering the repeater on the mesh can reasonably infer that it is mobile infrastructure rather than a permanently installed station. As the network expands, descriptive naming conventions become increasingly valuable for both administration and troubleshooting.

The repeater was configured using the recommended United States and Canada radio preset operating at 910.525 MHz with a bandwidth of 62.5 kHz, spreading factor 7, and coding rate 5. These settings provide a practical balance between range, airtime efficiency, and compatibility with other MeshCore users operating on the recommended preset. Rather than experimenting with custom parameters immediately, remaining on the recommended configuration made interoperability the higher priority.

The Android application also introduced remote administration capabilities. From the phone it was possible to review configuration information, monitor telemetry, request updates, and access many of the repeater's settings without connecting a USB cable. For infrastructure that may eventually be mounted in less accessible locations, this capability is extremely useful.

One of the more interesting discoveries during early configuration was that the various administrative interfaces did not always update simultaneously. Certain configuration values appeared immediately in one interface while remaining blank in another until refreshed. Initially this seemed concerning, and it was easy to assume the repeater had failed to apply a configuration change when, in reality, the remote application simply had not requested fresh information from the node.

That distinction proved important throughout the project, because the interface displayed on a phone is not necessarily a live representation of the repeater's internal state. Often it is a cached snapshot awaiting an explicit refresh request. Once I understood that behavior, several apparent problems disappeared without changing a single configuration value.

By the end of the initial setup, PCG Nomad had become a functioning mobile repeater capable of advertising its presence, participating in the local mesh, and being managed remotely. It would also become the first opportunity to investigate an unexpected problem, one that initially appeared to involve GPS.

6. The GPS Mystery

As soon as PCG Nomad was flashed with the Meshcore firmware and testing began, an issue appeared. The SenseCAP repeater itself reported an incorrect time, and invalid GPS location (when testing the Clock and GPS functionality via the Meshcore web-based Console). After initially flashing the firmware, the GPS and Clock appeared to operating normally, yet when reviewing the configuration again remotely via the Android application, the data indicated that no valid position existed. There was also an intermittent issue with the time that was difficult to repro, where the date would reflect 2024 as opposed to 2026.

At first glance, the symptoms suggested a possible hardware problem. Within the Android remote management interface, the reported position remained fixed at 0.0, 0.0, a location in the Gulf of Guinea commonly used as a placeholder when no coordinates are available. Selecting "Get Location from Repeater" simply returned the same invalid coordinates. From the perspective of the application, it appeared that GPS information was unavailable.

I reconnected the SenseCAP Solar Node via USB to my laptop, and opened the Meshcore web-based serial Console. Querying the GPS repeatedly reported an inactive receiver with an invalid position fix. Querying the Clock also reflected an inaccurate UTC time. After several attempts at re-configuring the settings and re-saving, ultimately I erased the previous firmware installation via the web-based application, re-flashed the Meshcore firmware, and re-configured all of my repeater settings. The second installation attempt yielded better results, as it reflected the correct UTC time when querying the Clock; however, the GPS issue persisted. Through the web-based Meshcore Console, I discovered GPS was turned off, and I was able to turn it on; however, the reported position remained at 0.0, 0.0 when selecting "Get Location from Repeater" in the Android remote interface.

Although the location issue itself did not resolve immediately, these observations strongly suggested that the problem was not with GPS reception, but with the factory configuration of the SenseCAP repeater, as well as with how the remote interface synchronized information from the repeater.

This experience reinforced a principle that extends well beyond MeshCore, in that, a graphical interface is only as accurate as the information it has most recently received. When diagnosing technical problems, it is important to distinguish between the state of the software displaying information, and the state of the device producing that information.

Eventually, the decision was made to manually assign the repeater's position temporarily while allowing additional time for future firmware revisions to mature. Because the repeater would spend most of its time traveling, automatic GPS reporting remained the long-term objective. For the moment, however, the repeater was fully operational despite these initial obstacles.

While troubleshooting the GPS and time issue, an important diagnostic question emerged; which source should be trusted, the application or the repeater itself? Prior to reinstalling the firmware or assuming a hardware failure, I compared information across multiple interfaces. The Android application, T-Deck, and Meshcore browser administration tools and serial Console, with each displaying different pieces of information. One observation I noted was that when remotely logging into the repeater via the Android application, it would occasionally lag behind until explicitly refreshed, and some fields that were configured in the web-based tool appeared blank. After manually refreshing the remote management screens, the previously blank radio settings populated correctly, and additional information began appearing that had been absent moments earlier.

The GPS mystery also served as an introduction to one of the recurring themes of this project, that the first explanation that comes to mind is not always the correct one. That lesson would become even more apparent during the deployment of the second repeater.

7. Diagnosing the Bad Antenna

The deployment of PCG Cold Springs introduced the most instructive troubleshooting exercise of the entire project. It also served as a reminder that hardware failures often masquerade as software problems, especially during the early stages of learning a new platform.

After flashing a second T-Beam with the same firmware version used successfully on my Android Bluetooth Companion, I expected the PCG Cold Springs repeater to come online with only minor configuration changes. Instead, the behavior was inconsistent, and the GPS remained inactive, no satellites were acquired, and several indicators suggested that something fundamental was wrong with the installation.

The natural assumption was that the problem involved firmware, and that initial conclusion seemed reasonable. The repeater had only recently been flashed, different firmware profiles existed for multiple T-Beam hardware revisions, and the GPS receiver refused to obtain a position. The serial console repeatedly reported the receiver as deactivated with no satellite lock. Several firmware-related possibilities immediately came to mind.

The first step was to eliminate software as the source of the problem. The firmware was erased completely and reinstalled, and the settings were reconfigured. The correct hardware profile was verified before re-flashing, and after the second installation, the serial Console was examined again. The clock, GPS status, and repeater configuration were checked repeatedly, and different commands were issued to determine whether the receiver could be activated manually.

Nothing changed.

At this stage, it would have been easy to continue searching for increasingly complicated explanations. Firmware regressions, undocumented configuration changes, or obscure hardware compatibility issues all seemed plausible. Instead, the troubleshooting process returned to a simpler question.

What if the firmware was functioning correctly?

Rather than assuming another software issue, attention shifted to the physical hardware itself. The antenna was removed, and replaced with another known-good antenna already available from the project.

The results were immediate.

After rebooting, the serial console reported an active GPS receiver, followed by a valid position fix and a steadily increasing satellite count. The internal clock synchronized correctly, confirming that the receiver was now functioning exactly as expected. The same firmware that had previously appeared defective suddenly behaved normally without any software changes whatsoever.

The conclusion was difficult to ignore, that the original antenna had almost certainly been defective. Although GPS operates on a different frequency than the LoRa radio, replacing the antenna coincided with the system beginning to operate normally. Whether the original antenna itself was damaged, poorly assembled, or another physical connection had been disturbed during replacement is ultimately less important than the broader lesson learned during the process. That troubleshooting should proceed from the simplest explanations toward the more complex ones.

Engineers sometimes joke that "firmware is guilty until hardware proves itself innocent." In reality, the opposite approach is sometimes more productive. Loose connectors, damaged antennas, defective cables, poor solder joints, and power problems occur far more frequently than obscure software defects. Verifying those simple possibilities early can save hours of unnecessary investigation.

That experience also reinforced the value of maintaining more than one known-good device. Because PCG Nomad was already operating correctly, comparisons between the two repeaters helped isolate the problem more quickly, than troubleshooting an entirely new installation would have allowed.

Perhaps most importantly, the experience built confidence. By the time the hardware issue had been resolved, I understood considerably more about MeshCore's diagnostic tools than I had before the problem appeared. The temporary setback ultimately became one of the most valuable learning experiences of the entire deployment.

8. Publishing a Public Repeater

With the hardware operating correctly, PCG Cold Springs was ready to become more than just another repeater inside my own local network. The next objective was publishing it as public infrastructure that other MeshCore users could discover.

Unlike a mobile repeater whose position changes continuously, PCG Cold Springs was designed as permanent infrastructure. Because its location would remain fixed, manually entering its coordinates made practical sense. Doing so, also eliminated any uncertainty about the position that would be advertised to other users.

The repeater was configured with descriptive owner information identifying Partisan Comms Group, along with a link to the website. Radio parameters remained on the recommended North American preset to maximize compatibility with other MeshCore users. Rather than experimenting with custom frequencies or unusual radio settings, the priority was interoperability and ease of discovery.

The next step involved adding the repeater to the public MeshCore map. Publishing infrastructure differs from simply operating a repeater locally. The listing includes the repeater's public key, geographic coordinates, radio parameters, and identifying information so that other users can discover the node before ever entering radio range. A generated QR code also simplifies importing the repeater into supported applications.

Initially there appeared to be another inconsistency. The repeater became visible within the Android application before it appeared on the browser-based MeshCore map. Once again, patience proved more useful than immediately assuming another configuration problem. After allowing time for synchronization, the listing appeared correctly on the public map with all expected information, including the repeater name, coordinates, radio preset, public key, and generated QR code.

Seeing PCG Cold Springs displayed on the public map represented an important milestone. Until that point the project had largely consisted of experimentation within a private environment. Publishing the repeater transformed it into public infrastructure available for anyone operating nearby on the same MeshCore radio preset. The network had moved beyond being a personal experiment and had become a small contribution to the broader MeshCore ecosystem.

9. Verifying the Network

Publishing a repeater is only one measure of success. The more important question is whether the infrastructure actually performs as intended under real operating conditions. To answer that question, I turned to the T-Deck.

One advantage of maintaining a dedicated field client, is that it provides an independent perspective on the network. Rather than relying solely on administrative interfaces, the T-Deck allows the user to interact with MeshCore as another participant would. If infrastructure is operating correctly, it should become discoverable regardless of how it is being managed.

Searching for nearby repeaters produced exactly the result I had hoped to see. Both PCG Nomad and PCG Cold Springs appeared simultaneously. Although this may seem like a small observation, it confirmed several important aspects of the deployment. First, the mobile repeater remained operational after its earlier GPS investigations. Second, the newly deployed fixed repeater was advertising correctly. Third, the two infrastructure nodes were able to coexist without interfering with one another or creating obvious routing problems.

This also validated the original network architecture developed before the first radio was ever flashed. The Bluetooth Companion, T-Deck, mobile repeater, and fixed repeater were no longer isolated experiments; they had become components of a functioning local mesh.

Seeing both repeaters appear together also reinforced the value of descriptive naming. At a glance, it was immediately obvious which node represented mobile infrastructure and which represented the permanent home installation. As additional repeaters are added in the future, maintaining that consistency will make network administration considerably easier.

The deployment had reached an important transition point; rather than configuring equipment, the focus could now shift toward evaluating network behavior. Coverage testing, routing efficiency, repeater placement, and long-term reliability become meaningful only after the underlying infrastructure has been demonstrated to operate correctly. For the first time, the project had achieved exactly what it was designed to accomplish; a functioning local MeshCore network built from multiple infrastructure nodes working together.

10. Lessons Learned

Every technical project produces two kinds of knowledge. The first consists of procedures that can be documented in a manual, and the second consists of practical experience gained only through deployment. While both are valuable, it is often the second category that saves the most time for the next person attempting a similar project.

Looking back over the deployment of PCG Nomad and PCG Cold Springs, several lessons stand out. The first is to avoid assuming that firmware is responsible whenever something behaves unexpectedly. Modern embedded software is remarkably reliable, while physical components remain susceptible to loose connections, defective hardware, damaged cables, and manufacturing inconsistencies. The faulty antenna reinforced that principle far more effectively than any theoretical discussion could have.

Second, administrative interfaces should not be treated as infallible representations of the underlying device. Throughout this project, there were several occasions when configuration screens displayed incomplete or outdated information until they were manually refreshed. The repeater itself continued operating normally despite those temporary inconsistencies. Cross-checking information between the Android application, browser interface, and serial Console prevented several unnecessary troubleshooting detours.

Third, diagnostic tools should be used systematically rather than selectively. The serial Console became one of the most valuable resources available because it reported exactly what the hardware was doing internally. GPS status, satellite acquisition, and clock synchronization provided objective information that could be compared against higher-level interfaces whenever questions arose.

Another important lesson involved infrastructure planning. Establishing meaningful node names before deployment simplified administration from the very beginning. PCG Nomad immediately communicates a mobile asset, while PCG Cold Springs identifies a fixed geographic installation. Clear naming conventions become increasingly valuable as networks expand beyond only a handful of nodes.

Publishing a repeater also demonstrated that building infrastructure involves more than simply placing a radio on the air. Providing accurate coordinates, consistent owner information, and interoperable radio settings makes the repeater more useful to the broader community. Infrastructure is most valuable when others can discover and understand it easily.

Perhaps the most significant lesson, however, extends beyond MeshCore itself, in that real understanding develops through experimentation. Documentation explains what should happen, and field experience reveals what actually happens. Those two perspectives are complementary, and both are necessary. The official documentation provides the foundation, practical deployment builds the confidence to troubleshoot unfamiliar problems, adapt to unexpected situations, and continue expanding the network with a clearer understanding of how each component contributes to the whole.

By this point in the project, the objective was no longer simply learning MeshCore. It had become learning how to design, build, maintain, and gradually improve communications infrastructure, one node at a time.

11. Future Expansion

Although the deployment described in this article represents a functioning local MeshCore network, it should be viewed as a beginning rather than a finished system. Communications infrastructure is rarely complete; instead, it evolves through incremental improvements, additional testing, and a better understanding of how individual components interact under real operating conditions.

The next logical step is coverage testing. Up to this point, the primary objective has been establishing reliable infrastructure. The Bluetooth Companion, T-Deck, mobile repeater, and fixed repeater are all operating as intended, but knowing that devices can communicate is only part of the picture. Equally important is understanding where they can communicate and under what conditions.

That process will involve driving predetermined routes while monitoring which repeater is providing coverage, identifying areas where the network performs well, and documenting locations where communication becomes unreliable. Terrain, vegetation, buildings, and elevation all influence LoRa performance, and theoretical range estimates are rarely a substitute for actual field measurements.

Mobile testing will also help answer questions about repeater placement. A mobile repeater such as PCG Nomad is expected to introduce changing network topology as it moves throughout the coverage area. Observing how quickly routes adapt, how reliably messages are forwarded, and whether coverage gaps can be bridged through vehicle movement will provide valuable insight into MeshCore's routing behavior.

Another area of interest is long-term infrastructure reliability. Unlike handheld devices that are powered on only when needed, fixed infrastructure is expected to operate continuously. That raises practical considerations including power consumption, thermal management, battery backup, and resilience during extended utility outages. Eventually, I intend to evaluate alternative power sources, including solar charging systems capable of supporting unattended repeater installations for prolonged periods.

Future work will also include experimenting with antenna placement and elevation. The experience with the faulty antenna demonstrated just how influential relatively small hardware issues can become. As additional repeaters are deployed, antenna selection, feedline quality, mounting height, and surrounding terrain will likely have a greater impact on overall network performance than minor adjustments to firmware settings. Improving the physical installation often yields greater returns than endlessly modifying software configuration.

The current network also establishes a foundation for expanding beyond two repeaters. Additional infrastructure could be installed in neighboring areas to improve regional coverage or to create overlapping paths that increase redundancy. Mesh networking benefits from thoughtful infrastructure placement rather than simply increasing the number of nodes. Each new repeater should contribute meaningful coverage rather than unnecessary complexity.

There are also opportunities to explore additional MeshCore features as the project matures. Room Servers, larger multi-node deployments, more sophisticated routing behavior, and interoperability between fixed and mobile assets all represent natural extensions of the work described here. Perhaps most importantly, any future expansions will continue to be documented using the same philosophy that shaped this article. Rather than presenting only polished results, the goal will remain documenting the entire engineering process, including incorrect assumptions, failed experiments, unexpected observations, and the reasoning behind each design decision. Those experiences often provide more value than the final configuration itself.

Conclusion: Building Infrastructure One Node at a Time

When this project began, the objective was modest; learn MeshCore and determine whether it offered a practical platform for building a local communications network. What emerged over the course of that process was something considerably more valuable than a successful firmware installation. It became an exercise in designing communications infrastructure.

Along the way, the project evolved from a single development board into a functioning network consisting of a Bluetooth Companion, a dedicated field client, a mobile repeater, and a fixed repeater published on the public MeshCore map. Each addition required new decisions, introduced new questions, and expanded my understanding of how the system operates beyond what can be learned from documentation alone.

Equally important were the unexpected problems encountered during deployment. The GPS interface that appeared inconsistent despite a healthy receiver. Administrative screens that required manual refreshes before displaying current information. A hardware problem that initially looked like a firmware defect but ultimately proved to be something as simple as a faulty antenna. None of those situations were part of the original plan, yet each became an opportunity to better understand both the technology and the troubleshooting process itself.

Those experiences reinforce a principle that extends well beyond MeshCore, that resilient communications are not created by purchasing equipment. They are created through deliberate planning, careful observation, systematic testing, and a willingness to investigate problems methodically rather than jumping to conclusions. Every successful deployment becomes stronger because of the challenges encountered during its construction.

That perspective has been a recurring theme throughout the Signal in the Storm series. That, reliable communications are built long before they are needed. Whether the technology involves amateur radio, HF networks, digital messaging, or LoRa mesh systems, the underlying principle remains remarkably consistent, that competence develops through preparation, not improvisation.

Looking ahead, this network will continue to grow. Coverage maps will become more detailed, additional repeaters will extend the infrastructure, longer-range testing and broader regional deployments will provide new opportunities to evaluate MeshCore under increasingly realistic conditions, and each expansion will bring its own lessons.

For readers considering building their own MeshCore network, my encouragement is simple: begin.

Start with a single node, learn its capabilities, add a companion, deploy a repeater, test it, break it, and fix it. Document what you discover, and over time, those individual experiments become something much larger, a communications infrastructure built on practical experience rather than assumptions.

The two repeaters described in this article, PCG Nomad and PCG Cold Springs, are not the end of that process. They are simply the first permanent pieces of what I expect will become a larger network. More importantly, they represent the beginning of a continuing effort to better understand decentralized communications, and to share those lessons with others who are building their own resilient systems.

Every network starts with a single node, and every resilient network grows one deliberate step at a time.

—PCG