Off-Grid Tactical Comms on the Battlefield: Meshtastic & ATAK Integration in a Border Conflict Exercise

In modern military exercises, reliable communication is as crucial as firepower. But what happens when troops operate beyond the reach of cell towers or traditional radio relays? In a recent border-conflict training scenario, our team at Defencebay demonstrated an innovative off-grid communication solution that kept 300+ personnel connected across a 5 km contested area with zero downtime. We achieved this by deploying military-grade Meshtastic mesh networking devices in conjunction with a highly scalable TAK server and a series of vehicle-mounted Meshtastic–TAK gateway units. This setup enabled real-time synchronization of ATAK (Android Tactical Assault Kit) devices in the field – even in the complete absence of GSM/cellular signals. In this post, we’ll delve into the scenario, the technology stack we used, how we integrated the systems, and the results and lessons from the exercise.

Scenario Overview: A Simulated Border Conflict with No Infrastructure

The training exercise simulated a light border conflict in a contested remote area. Three opposing forces (friendly and aggressor teams in the scenario) maneuvered against each other with relatively limited support assets. The conditions included:

• Forces & Equipment: ~900 personnel divided into three factions, with only light vehicles and weapons. Each faction operated a few dozen technicals (lightly armored pickup trucks armed with machine guns) and had no heavy artillery or air support. A handful of drones were available for reconnaissance, but no large-scale ISR assets or satellite comms for individual soldiers.
• Environment: The battlefield spanned several kilometers of rugged terrain (up to ~5 km across). This border area had no cellular coverage or existing comms infrastructure – a deliberate constraint to mimic real-world austere conditions.
• Mission Needs: Despite the minimal infrastructure, each force needed to coordinate movements, track friendly elements, mark points of interest, and share critical information (like spotting opposing units or calling for support). Situational awareness and team communication were paramount for mission success, yet conventional radios alone (voice-only, short-range) would be inadequate for coordinating 300 distributed operators.

Communications Challenge: How to maintain a common operational picture and reliable team comms for hundreds of dispersed operators in this communication-denied environment? The solution would have to be off-grid, secure, and robust against the terrain and conflict conditions. Traditional solutions like VHF/UHF tactical radios provide voice, but they don’t inherently share GPS locations or text data. We needed a digital network that could connect everyone without relying on fixed infrastructure – essentially creating a battlefield intranet on the fly.

Meshtastic Mesh Network – Off-Grid Links for the Battlefield

To solve the off-grid communications problem, we turned to the Meshtastic mesh networking platform. It is an open-source system built on low-cost LoRa radios, which are known for long-range, low-bandwidth communication. These devices form a self-forming, self-healing mesh network where each node can relay messages for others. In our exercise, we deployed roughly 150 Meshtastic nodes (small, rugged radio units) among the troops and vehicles:

• Long-Range Coverage: Each node can communicate over several kilometers. In fact, line-of-sight range between nodes is on the order of 5–10 km under good conditions. This meant that with careful placement (some nodes mounted on vehicles or high terrain), we achieved a radio mesh covering the entire operations area. Even if two devices were out of direct range, intermediate nodes automatically relayed messages, extending reach across multiple hops.
• Secure, Low-Power Comms: These communications are end-to-end encrypted for secure transmissions – a crucial feature for a military scenario to prevent eavesdropping. The radios are low-power, which not only helps with battery life but also means a minimal electronic signature – they are less detectable and less likely to give away positions compared to high-power broadcasts. This mesh allowed teams to coordinate with a degree of stealth, avoiding detection by not relying on easily intercepted high-power signals.
• Data Capabilities: Over these LoRa links, it primarily supports text messages and GPS location sharing. Team members could send short chat messages (e.g. status updates, coordinate reports) and broadcast their Position Location Information (PLI) to the network so that their teammates know where they are. The mesh also supports transmitting small data packets (for example, a grid location or simple sensor readings). This provided a basic digital communication channel for tactical data even with no internet or cellular service, since Meshtastic needs no external infrastructure to operate.

It’s important to note the limitations of LoRa-based mesh networks. They offer long range but extremely limited bandwidth. In practice, this means only short text and coordinate data can be sent – no images, videos, or large files over Meshtastic. For our scenario, that was acceptable for routine team comms (chat and locations), but we knew that any high-bandwidth data (like drone video feeds or detailed map imagery) would overwhelm the mesh. We planned our architecture accordingly to leverage the mesh for what it does best – robust low-bandwidth connectivity – and supplement it with other tech for heavy data as needed.

Bridging Meshtastic with ATAK: Vehicle Gateways and TAK Server Integration

While Meshtastic provided the radio layer for connectivity, we wanted to give our personnel the powerful situational awareness tools of the TAK ecosystem. ATAK (Android Tactical Assault Kit) is a widely used battle-management app that runs on Android devices (with equivalents like WinTAK on Windows and iTAK on iOS). ATAK allows operators to view and share geospatial information in real time – including the locations of friendly units, enemy sightings, danger areas, chat messages, and more. Essentially, it’s a digital map and communication platform that greatly enhances coordination. In fact, ATAK can integrate feeds from sensors like drones (displaying a drone’s live video and field-of-view on the map) and share that info among users. This was ideal for our needs – if we could connect ATAK to the off-grid mesh network.

The challenge: ATAK devices normally communicate over IP networks (Wi-Fi/Cellular) or tactical radios that provide network interfaces. In our scenario, with no GSM and no existing IP network in the field, how would hundreds of ATAK clients talk to each other? The answer lay in creating a bridge between the IP world of ATAK and the RF world of Meshtastic.

Defencebay Meshtastic–TAK Gateway: We developed and deployed a series of vehicle-mounted gateway devices to link ATAK users to the mesh network. Each gateway (installed in a command vehicle or other key platform) consisted of a small computer connected to a LoRa radio transceiver. The gateway software listens for ATAK data on one side and forwards it over the mesh on the other. Concretely, the TAK Meshtastic Gateway software works by listening for multicast UDP data from TAK clients (ATAK, WinTAK, iTAK) on the network side and forwarding those messages to its radio node, which then transmits them into the LoRa mesh. Similarly, it takes messages heard from the mesh network and injects them back as multicast CoT (Cursor-on-Target) messages to any ATAK clients on the network. This effectively makes the mesh network a pipe for ATAK data. In simpler terms:

• An ATAK user (say on an Android phone) sends a chat message or drops a location marker. ATAK (or WinTAK on a PC) will broadcast that as a CoT data packet on the local network (in this case, the vehicle’s LAN). The gateway picks up that packet and forwards it via LoRa to all mesh nodes in range.
• Conversely, if a Meshtastic-only user (perhaps using the mobile app or a connected handheld) sends a message or their device broadcasts its GPS, the gateway will take that and forward it over Wi-Fi/Ethernet as a UDP packet that ATAK clients can understand.

This bridging lets ATAK and Meshtastic users communicate seamlessly. In practice, ATAK-equipped soldiers could see icons on their map for anyone carrying a LoRa radio, since the gateway injected those positions as regular ATAK location (PLI) updates. Likewise, a mesh user could receive a text chat from an ATAK operator, because the gateway translated and relayed it into the mesh, and vice versa. Our gateway supports both chat messages and location updates in both directions – meaning full basic interoperability between the TAK network and the mesh network.

Example: An officer on a laptop running WinTAK could send a message like “Enemy spotted at hilltop!” through the TAK chat. One of our gateway vehicles would catch that message and broadcast it over LoRa. Within a second or two, a soldier in the field carrying a LoRa handheld would receive it on their device/app, even with no direct internet. That soldier could then respond “Acknowledged” using the same handheld, and the message would go back through the mesh to the gateway and pop up on the WinTAK chat for the officer. All of this happens behind the scenes, thanks to the gateway bridging software.

High-Capacity TAK Server: To manage all the data and clients, we utilized a TAK Server backend (running on a hardened server system). It acted as the central hub for our network. All ATAK/WinTAK/iTAK clients in the exercise were connected either directly or indirectly to this server. A few of the ATAK devices (particularly those in or near the gateway vehicles) had network connectivity and maintained a direct link to the server (more on that in a moment), while off-grid devices exchanged data through the gateways. The server aggregated positional data, managed chat rooms, and distributed “data feeds” (such as map overlays or drone video metadata) to everyone. A highly scalable server setup was essential because we had over 300 TAK clients active – a number well above what ad-hoc peer-to-peer networking alone could handle. By using the server-centric architecture, we ensured that all clients stayed synchronized with the latest battlefield picture.

Starlink Uplinks for Backhaul: As mentioned, pure LoRa mesh has severe bandwidth constraints – fine for text and GPS dots, but not for heavy data like images or live video. To support richer data and to connect our field network to remote command elements, we equipped several vehicles with Starlink satellite internet terminals. Starlink, operated by SpaceX, provides broadband internet even in remote areas and was an ideal complement to Meshtastic: Starlink gives high-speed connectivity anywhere, while the mesh system provides local, portable off-grid communication. We leveraged both in a hybrid network:

• The Starlink-connected vehicles acted as communication hubs. Each such vehicle had our gateway device on board and a Wi-Fi/router network connected to Starlink. This allowed any ATAK clients near that vehicle (within Wi-Fi range or connected via Ethernet) to have a direct link to the TAK server over satellite. For those users, high-bandwidth data (like the drone video feed) was accessible.
• The gateway in the vehicle also linked that Starlink-fed network to the mesh network, as described. This meant even ATAK users who were completely off-grid (out in the field with just a radio) could still receive updates that came from the server (albeit only the lightweight updates that could be forwarded over LoRa). For instance, if the command post uploaded a new map marker or a text order to the TAK server, it would reach the mesh via the gateway.
• Drone Feed Integration: We had a couple of small drones providing ISR overwatch in the exercise. The drones’ video streams were shared via the ATAK network – in practice, the drone operators’ ATAK devices published video or snapshots to the TAK server, and those were available to others. Obviously, streaming live video over Meshtastic was impossible (LoRa can’t handle video at only ~5 kbps throughput on average). Instead, the live drone feed was viewable by those ATAK users with Starlink connectivity (e.g. a commander at a vehicle could watch it). However, the presence of the drone (its icon and location) was shared as a CoT data point so that even off-grid users knew a drone was overhead and where it was looking. In essence, the drone’s coordinates and any sensor detections were propagated through the mesh, while the heavy video data traveled via Starlink to those who could receive it. This hybrid approach ensured everyone got the critical info they needed in near-real-time: map updates and alerts for all, rich video for those who could support it.

Extending Gateway Capabilities: The standard Meshtastic–TAK Gateway software (as available in open-source) initially supports only chat and basic location sharing due to the bandwidth constraints. In our Defencebay implementation, we pushed the envelope by enabling support for additional CoT data types. Notably, “markers” placed in ATAK (e.g., icon symbols for objectives, hazards, etc.) were successfully transmitted over the mesh so that our teams could share tactical graphics. We also experimented with sending certain data packages (small file bundles like simple map sketches or brief reports). These are normally disabled on LoRa because a large file would tie up the channel, but by carefully limiting sizes and using compression, we achieved limited data package transfer. This is a unique enhancement of our system – typically, other data types (images, large overlays) are not supported on Meshtastic networks due to throughput limits. By tailoring the data and using our gateways intelligently, we proved that small map files and markers can indeed be synced across a LoRa mesh in a pinch. This capability gave our units a richer common operational picture than just dots and text, without overwhelming the network.

Field Deployment of the Integrated Network

With the pieces above, we essentially built a multi-layer tactical network for the exercise. Here’s how it was deployed in the field:

• Meshtastic Nodes for Troops: Many soldiers were equipped with personal devices (either handheld nodes or Android phones paired via Bluetooth to a LoRa node). These were configured on a common mesh channel with an encryption key so that all friendly nodes formed one network. (Each opposing force in the exercise had its own mesh network and keys; the networks were separate to simulate real-world scenarios where enemies can’t see each other’s data. Our system can support multiple isolated meshes if needed, but for brevity we’ll focus on one side’s perspective.)
• ATAK Devices: Nearly every participant carried an ATAK or iTAK device – for example, an Android smartphone running ATAK for soldiers, a rugged tablet or laptop running WinTAK for vehicle commanders and exercise control staff. Those devices were pre-loaded with maps and connected either to a LoRa node (via our plugin/gateway approach) or to a Starlink hub if available. This means some ATAK clients were “off-grid” (Meshtastic-only) and some were “online” (near a Starlink and directly on the server), all sharing data through the server and gateways.
• Gateway Vehicles: We placed multiple gateway units on vehicles spread around the battlespace. Each gateway vehicle had: (a) a Meshtastic radio with a high-gain antenna (to cover long distance and link with many nodes), (b) a hardened laptop or single-board computer running the gateway software, and (c) a connection to a Starlink terminal or long-range Wi-Fi. These vehicles were positioned strategically – for example, one near each force’s command element – to act as bridgeheads between the local mesh and the global server network. They were powered by the vehicle, ensuring 24/7 uptime. Redundancy was a key consideration: with several gateways in range, if one went down or moved out of range, another could pick up the traffic, and the mesh would reroute accordingly. This contributed to our zero downtime achievement.
• TAK Server and Command Center: The system was running in a mobile command center (which had a Starlink dish for connectivity). It maintained connections with the gateway vehicles (over Starlink links) and any ATAK clients that happened to get on those links. The server synchronized all data – so if, say, a soldier’s ATAK (via Meshtastic) sent a position update, the server got it through the gateway and then distributed that to all other clients (so anyone on the network would see that soldier’s icon move). The server also fed common data (like the scenario’s operational graphics, or drone telemetry) down to the gateways to broadcast to the mesh. Because the server was the nexus, we could support 300+ concurrent devices without saturating any single radio channel; the heavy lifting of replication was done at the server and at the high-bandwidth links. The multicast approach of the gateway meant that ATAK devices on the same local network as a gateway could even receive mesh traffic directly via that multicast, further reducing load on the server for local dissemination.

Throughout the exercise, this architecture allowed us to maintain a unified situational awareness across all participants, despite the mix of connectivity. A user on a purely off-grid handheld could send a chat message that would reach a user on a Starlink-connected system miles away, and that message would also reach exercise control at the command post – all within a few seconds. The combination of long-range mesh radio and satellite backhaul created a resilient, distributed communication network with no single point of failure.

ATAK in the Field: User Experience and Capabilities

From the end-user perspective (the soldiers and commanders in the field), the system was game-changing. Every operator had the ATAK application showing a moving map of the area with icons for friendly units, team assets, and relevant battlefield points. ATAK is designed for exactly this purpose – to let units “see” the tactical situation digitally and communicate efficiently. According to an overview by the TAK developers, the app allows military teams to share geospatial information such as friendly and enemy positions, danger areas, and casualty reports in real time. It uses the Cursor-on-Target protocol to exchange data like team locations, tactical graphics, sensor readings, and chat messages between users. In practice during our exercise:

• Blue Force Tracking: Each friendly unit’s position (provided either via their device’s GPS or an attached Meshtastic GPS) was broadcast over the network. Troops could glance at their ATAK device and instantly know where their squad mates and vehicles were – no need for constant radio check-ins. This is a huge situational awareness boost; instead of wondering or giving away position by asking, they had a live map of everyone’s whereabouts. Even when units went behind a hill or treeline, as long as the mesh still had a path, their last known location updated for others.
• Chat and Coordination: ATAK includes a chat feature, which we used as a silent radio net. Team leaders could send text commands or reports (“Team A moving north to Objective X”) that all intended recipients would quietly receive. This was critical for stealth and clarity – messages came through ungarbled (as sometimes happens with voice in loud environments) and could be read at a glance. Thanks to the gateway, Meshtastic-only users were part of these chats seamlessly. For example, an engineer unit using just mesh radios could still get orders from the commander’s ATAK chat and respond, bridging what would otherwise be a communication gap.
• Map Marking and Data Sharing: Users frequently dropped markers on the ATAK map – indicating spotted enemy positions, marking cleared buildings, IED locations, etc. Because of our enhanced gateway, these markers propagated to others on the network via the mesh. This meant a soldier could mark a location on his device and his teammates would see that icon appear on their maps within moments, which is immensely helpful for quick coordination (“rally here”, “avoid this area”, etc.). We also used data packages in a limited way to send small image snippets (like a sketch of a plan or a photo of a target) to nearby units. When, for instance, a recon element with a Starlink connection took a photo of a simulated target, they were able to send a compressed version through the TAK server to a gateway, which then trickled it over LoRa to a forward team – giving them visual intel even with no direct internet.
• Drone Overwatch Feeds: As mentioned, drone footage was integrated into ATAK for the exercise. In ATAK, a plugin can display a drone’s video feed and telemetry on the map. In our setup, only those at the command post or in vehicles (with Starlink) could watch the live video feed due to bandwidth. However, even dismounted troops benefited: if the drone spotted something, the operator could drop a reference point or send a screenshot, which was shared over the mesh network as a tactical graphic or image. Additionally, everyone saw the drone’s location and orbit on their ATAK screen (updated via the server/gateway) so they knew where aerial eyes were watching. This all added up to a level of situational awareness that would have been impossible to achieve with analog radios alone.

Despite the complexity behind the scenes, users found the system quite intuitive after some training. Essentially, they just used ATAK on their device as they normally would. The only difference was in how they connected: some had a small Meshtastic device tethered to their phone, and others connected via a Wi-Fi hotspot in a vehicle. Once connected, the TAK server and gateways handled the rest, and everyone’s map stayed updated. The exercise participants quickly adapted to relying on the digital map for coordination, dramatically reducing voice chatter on the traditional radios. In an After Action Review, soldiers commented that they were able to move and act faster because they “already knew” where friendly elements were and had a common reference (the digital map) for plans. This mirrors real-world benefits reported by military units using ATAK – better informed decisions and faster team coordination by sharing a live operational picture.

Performance Results and Key Takeaways

The outcome of the exercise was very positive, both for mission success in the scenario and for validating the tech. Here are some key results and lessons learned from deploying the Meshtastic+TAK system in this simulated conflict:

• Robust Off-Grid Coverage: The mesh network proved highly reliable. We achieved coverage across the ~5 km theater with no significant comms gaps. Thanks to the self-healing mesh topology, nodes could drop out or move (as people and vehicles did in the exercise) and the network automatically rerouted messages via alternate paths. In fact, during one phase we had a gateway vehicle temporarily go offline, but the nearby mesh nodes still relayed unit positions to another gateway without users noticing any outage. This resiliency gave us zero downtime in practical terms – at no point was any team cut off from the network. It underscores that a well-planned mesh (with sufficient node density and placement) can be a true 24/7 communication lifeline in the field.
• Effective Range in Field Conditions: We observed reliable node-to-node links often at 3–5 km distances on the ground, which aligns with Meshtastic’s expected range (5–10 km line-of-sight). The hilly terrain and occasional foliage did attenuate signals, but having nodes on vehicles (with antennas ~3-4m off ground) improved reach. Multi-hop routing extended the overall network diameter far beyond any single link’s range. For perspective, similar systems have documented mesh network diameters of 50+ km in open areas when enough relay nodes are present – we didn’t quite stretch that far, but we covered our AO with a comfortable margin.
• Scalability and Traffic Management: One of the biggest questions was whether we could handle 300 concurrent devices sharing data, given the LoRa bandwidth limits. The solution was our hybrid network design: not all 300 were blasting into the mesh at once. Approximately half were primarily using the mesh, and others had direct server links via Starlink/Wi-Fi. The TAK server helped throttle and manage updates – for example, it could aggregate position reports and send them at a reasonable interval. We also configured mesh nodes to limit how frequently they broadcast PLI (each device didn’t transmit every GPS update every second; they used a reasonable update period and event-based updates). As a result, the LoRa channels were never saturated to failure. The multicast gateway approach also meant many ATAK devices on the same hub only counted as one stream over LoRa (the gateway sent one packet that was received by several co-located devices). In summary, the network was successfully scaled to 300+ clients – something that would be very hard to do with pure peer-to-peer radio comms. This demonstrates that with careful architecture, the ATAK–Meshtastic combo can support large deployments.
• Hybrid Network = Best of Both Worlds: Using both Meshtastic and Starlink gave us complementary capabilities. The mesh system provided the affordable, low-power, on-the-move coverage for every soldier, while Starlink provided the high-bandwidth, long-haul link to the server and external feeds. This hybrid approach meant critical large-data information (like drone video or bulk intel from higher HQ) could reach those who needed it, and at the same time, basic tactical data flooded the mesh reliably to everyone. By offloading heavy data to Starlink, we kept the mesh free for vital updates. Conversely, if the Starlink backhaul went down (which at times we simulated by disabling a dish), the mesh still carried on with local data exchange – the troops in the field could continue to coordinate via ATAK on the mesh even if they were temporarily cut off from the command server. This redundancy is a huge asset in real operations. In short, Starlink gave us the cloud connectivity, Meshtastic gave us the local resiliency – a combination strongly validated by the exercise.
• Situational Awareness & Coordination Boost: From an operational standpoint, the exercise was a success in large part due to the improved situational awareness. Participants reported that having real-time maps and digital comms significantly increased their confidence and speed in executing missions. They no longer had to radio back and forth to confirm locations or status – it was all visible on ATAK. As one might expect, this mirrors how such tools are intended to function: “Rather than radio a teammate to ask how close they are or where they last saw a target, you can simply look at the screen that overlays this info on the map in real time,” as an official TAK guide notes. Our exercise validated that claim fully. Coordination between dispersed units (and even between different teams in the scenario) became smoother. This also provided an immense training value: troops gained experience in using digital tools for command and control, which is increasingly important in modern military operations.
• Security and Encryption: All communications were protected through multiple layers of encryption – the mesh network was pre-shared-key encrypted, and the TAK server connections used SSL/TLS encryption for the clients connected to it. We managed the crypto keys in advance (a straightforward process, akin to loading an encryption key for a radio network). There were no observed attempts of interception or exploitation during the exercise (it was a controlled environment), but knowing that our data was secure against eavesdropping was essential. In a real conflict, this would protect operational information from enemy SIGINT. Moreover, the low probability of detection/intercept of LoRa (due to its low power and spread-spectrum nature) added a layer of comms security through stealth – as mentioned, special operations teams value the low electronic signature of such mesh radios to avoid drawing attention.
• Lessons on Bandwidth Management: We learned that it’s crucial to prioritize and filter data for an off-grid mesh. One must decide what information is truly needed at the edge (over LoRa) versus what can be left for higher-bandwidth channels. For instance, we didn’t try to send detailed drone video to every user; instead we sent only critical snapshots or coordinates to the edge. We limited routine traffic (like how often each device broadcasts its location). By establishing such protocols (which aligns with best practices – e.g., clear data prioritization to prevent network congestion), we kept the system running smoothly. Future iterations might automate some of this (e.g., an AI-based agent to manage network load is an interesting prospect), but even simple rules and good discipline by users (avoiding spamming unnecessary messages) went a long way.
• User Training & Adoption: Another takeaway was the importance of training the end-users on the tech. ATAK is a powerful tool, but to use it effectively under stress, soldiers need practice. We conducted a crash course for participants on how to use ATAK and how our mesh network operates. This paid off as users quickly got comfortable with sending chats and reading the map. We’d recommend any unit implementing this tech to include a solid training program (at least a few days of hands-on use and scenario-based drills) so that when it’s for real, the tech becomes second nature. In our case, the exercise itself doubled as training, and by the end of the operation, even those initially skeptical of relying on a smartphone were engaging fully with the system.

Conclusion: A Blueprint for Off-Grid Tactical Communication

This border conflict exercise showcased how a Meshtastic + ATAK integration can enable mission-critical communication anywhere – even with zero infrastructure. By combining Defencebay’s rugged Meshtastic devices, a scalable TAK server, and vehicle-mounted gateway hubs, we provided a level of situational awareness and coordination that greatly enhanced the effectiveness of troops on the ground. All of this was achieved with minimal cost and complexity compared to traditional military radio networks – leveraging open-source technology and commercial solutions like Starlink in creative ways.

The success of our deployment aligns with emerging trends in tactical communications. Others in the community have begun experimenting similarly – for example, hobbyist groups and militaries have used Meshtastic with ATAK for field exercises, like one tank platoon that networked their vehicles through the mesh to exchange locations and map data during training. Our exercise took this concept to a larger scale, proving that it can work for hundreds of users and multi-faceted operations.

Moving forward, we at Defencebay are excited to refine and expand this capability. We plan to further improve data throughput (exploring new LoRa modulation settings and mesh algorithms), integrate additional sensor feeds, and harden the system for electronic warfare resilience. We’re also keeping an eye on integrating future tech – from UAVs acting as radio relays to potential AI assistance in analyzing the flood of battlefield data for decision support. The ultimate goal is to give forces on the ground a decisive communication advantage, even when cut off from the usual networks.

For units operating in austere environments – be it military, peacekeeping, or disaster response – this exercise offers a template. A hybrid mesh-satellite network, anchored by a tool like ATAK, can keep your teams connected, informed, and synchronized when it matters most. In the absence of GSM or traditional comms, you can still “bring your own network” and achieve full digital situational awareness on the battlefield. Our team is proud to have demonstrated this capability, and we stand ready to deploy it in real-world missions where reliable off-grid comms can save lives and ensure mission success.