Lesson Overview
The earlier lessons built the operator from the ground up: the operator and the net, voice procedure to a real standard, net discipline and control, the handling and logging of messages and reports, the law and licensing that keep a member lawful on the air, the radio set and the antennas that carry the signal, the troubleshooting that keeps a link alive, and the operational reports and routine that are the net's daily work. All of that is the bedrock, and none of it goes away here. What this lesson adds is the layer of digital and networked tools the Royal Kaharagian Army actually fields, and the right way to think about them: as assistants to voice, never as a replacement for it.
This matters because digital comms are seductive. A shared map showing every team member's position, with markers, routes, and a chat window, looks like the answer to every problem voice procedure ever struggled with. It is not. The map is only ever as good as the network underneath it, and networks fail, batteries die, servers go offline, and the mesh drops out behind a hill. When that happens, the team that has drilled clean voice procedure carries on, and the team that leaned on the screen is suddenly deaf and blind. So the discipline of this lesson is to value the tools for what they genuinely give, while building every plan so that it falls back, in good order, to the radio in your hand and the voice procedure in your head.
This is the knowledge layer. It teaches you what the tools are, how they fit together, and how to plan for their failure. The hands-on operating, loading certificates onto a device, joining the net on the shared map, configuring a mesh radio, and rehearsing the fallback to voice, is practised and signed off in person and on airsoft milsim exercises, where radio is actually transmitted only by licensed members or on licence-free and low-power sets. By the end you will be able to describe what Team Awareness Kit (TAK) is and name its client versions, explain the common operating picture and the Cursor-on-Target protocol that carries it, explain why a TAK server is needed and how the RKA's own self-hosted server is reached, describe Meshtastic LoRa mesh as a licence-free off-grid data bearer and how a gateway forwards only light traffic onto it, judge when to use data and when to use voice, and build and operate a PACE plan that falls back cleanly to voice when the network fails.
Key Terms
- Team Awareness Kit (TAK): a family of mapping applications that shows a team a shared, live map of itself and its surroundings; the clients are ATAK (Android), WinTAK (Windows), iTAK (Apple iOS), and WebTAK (in a web browser).
- CivTAK: the civilian public release of the TAK clients, freely available, which the RKA uses for its lawful training and home-defence work.
- Common operating picture (COP): one shared, current view of the situation that everyone on the net sees the same way: who is where, what has been marked, and where the routes run.
- Cursor-on-Target (CoT): the small standard data message that TAK uses to carry a position, a marker, a route, or a line of chat between devices; the common language the tools speak.
- Position Location Information (PLI): a member's own position reported automatically onto the shared map, the blue dot that shows where you are.
- Marker: a labelled point placed on the map by an operator to record something seen or planned: a hazard, a casualty, a rendezvous, a control point.
- GeoChat: the text chat carried inside TAK, tied to the map, so a message can be sent to the whole net or to one station and can point at a place.
- TAK server: a central service that relays CoT messages between devices so the picture can be shared beyond the range of any one radio link; the RKA runs its own, self-hosted.
- OpenTAKServer: the open-source TAK server software the RKA runs, reached at
tak.kaharagia.org, with a separate certificate issued to each user. - Per-user certificate: a unique digital credential issued to one member, which both proves who they are to the server and encrypts their traffic; loaded onto the member's device.
- Meshtastic: open-source firmware and small radios that form a self-healing mesh, each set relaying for the others, using long-range, low-power LoRa radio on licence-free ISM bands.
- LoRa: a long-range, low-power radio technique that carries very little data very far on very little battery; the bearer underneath Meshtastic.
- Mesh: a network in which each node relays messages for its neighbours, so the network has no central point and extends itself as nodes are added, with no fixed infrastructure.
- Gateway: a device or service that bridges two different networks, here the TAK net and the Meshtastic mesh, passing chosen messages between them.
- PACE plan: an ordered list of communications means, Primary, Alternate, Contingency, Emergency, so the team knows in advance what to fall back to when one fails.
Where the tools fit: data assists voice
Begin with the principle, because every tool below is subordinate to it. Voice carries command; data carries awareness. When a leader gives an order, makes a decision, or needs an immediate answer, that is voice work, because voice is instant, it confirms by readback, and it conveys urgency and intent in a way a screen cannot. When the team needs to know where everyone is, to mark a hazard for later, to share a route, or to keep a quiet running picture, that is data work, because the map holds it patiently and shows it to all at a glance without a word spoken.
The two are partners, not rivals. The shared map relieves voice of an enormous burden: the constant position reports, the long descriptions of where something is, the repeated "say again your location" that clogs a busy net. With a good picture on the screen, the net falls quiet for the things voice does best, and what remains is decision and order, passed clearly by the procedure you have already learned.
But the partnership only holds while the network holds. A screen tells you where your team was when the data last flowed; it does not tell you they are deaf because the server is down or the mesh has dropped. The hazard of any data tool is the quiet failure: the picture freezes, looks plausible, and lies. So the operator treats the map as an aid that must be checked against voice and against reality, and never lets a stale screen replace a radio check. The rest of this lesson teaches the tools; this principle governs all of them.
Team Awareness Kit: the shared map
The Team Awareness Kit, or TAK, is at heart a mapping application that several people run at once and that keeps all their maps the same. It began in specialist use and is now freely available in a civilian release, CivTAK, which is what the RKA uses for its lawful training and home-defence work. It comes in four flavours, one for each kind of device, and they all talk to one another:
- ATAK runs on Android phones and tablets, the most common client in the field because the kit is cheap, rugged, and pocket-sized.
- WinTAK runs on Windows, used at a base, an operations table, or an emergency-coordination point where a larger screen helps.
- iTAK runs on Apple iPhones and iPads, for members carrying that kind of device.
- WebTAK runs in an ordinary web browser, useful where nothing can be installed but a screen and a connection are to hand.
What all four show is the common operating picture, or COP: one current view of the situation that everyone shares. On that map a member sees the team's own positions reported automatically, the Position Location Information or PLI, each member a moving dot. A member can drop a marker, a labelled point recording something seen or intended, a hazard here, a casualty there, the rendezvous at this corner, and the moment it is placed everyone on the net sees it in the same spot. Routes can be drawn and shared so a patrol moves on a common plan. And GeoChat, a text chat built into the map, lets a member type to the whole net or to one station, with the message able to point at a place on the ground.
The value of this is hard to overstate for a small force. Much of the confusion of field work is people not knowing where the others are, where the reported thing is, or which way the plan now runs. The shared map answers all three at a glance, silently, for everyone at once. It does not replace the leader's orders or the signaller's reports; it removes the fog those orders and reports used to push through. A patrol whose members can each see the whole patrol, the marked hazards, and the agreed route on one map is a patrol that argues less, gets lost less, and keeps its voice net clear for command.
Cursor-on-Target: the language the tools speak
For all those devices to keep one shared picture, they must agree on how to describe a thing. That agreement is Cursor-on-Target, or CoT, the small standard message that TAK uses to carry a single piece of information from one device to another. When your dot moves on everyone's map, a CoT message carried your new position. When you drop a marker, a CoT message described that point and its label. When you draw a route or send a line of GeoChat, CoT carries that too. It is, in effect, the common language: a compact, agreed format that any TAK client can produce and any other can understand.
You will rarely think about CoT directly, any more than you think about the grammar of a sentence while speaking. But it helps to know it is there, for two practical reasons. First, because everything rides on CoT, anything that speaks CoT can join the picture, which is how other tools, including the mesh radios met below, are bridged into TAK. Second, CoT messages are individually small, so the picture is built from many tiny messages rather than one large stream, and that smallness is exactly what lets the picture survive on a thin or intermittent link. The figure shows the kinds of thing CoT carries and how they assemble into the one shared map.
CURSOR-ON-TARGET: small messages, one shared picture
Each device produces and reads CoT messages:
[ PLI ] your own position -> the blue dot, updated as you move
[ MARKER ] a labelled point -> hazard, casualty, RV, control point
[ ROUTE ] a drawn line -> the agreed path, shared to all
[ GEOCHAT ] a line of text -> to the whole net or one station,
able to point at a place
| every item is a small CoT message
v
+-------------------------------------------------------+
| THE COMMON OPERATING PICTURE (COP) |
| one live map every member sees the same way: |
| who is where, what is marked, where the routes run |
+-------------------------------------------------------+
Small messages -> the picture survives on a thin link.
Sharing beyond the local: the TAK server
Two TAK devices near one another can be set to share directly, radio to radio, with no help in between. But that only works while they are close, and a team spread across a town, or split between a patrol and a base, quickly outruns any direct link. To share the picture beyond the local area you need a TAK server: a central service that receives every device's CoT messages and relays them out to all the others, so a marker dropped by a member on one side of the area appears at once on the screen of a member on the far side, and at the base table too.
The RKA does not rent this from anyone or depend on an outside service that could vanish or read its traffic. It runs its own, self-hosted server: an open-source product called OpenTAKServer, reached at tak.kaharagia.org. Running your own server is the lawful, self-reliant choice for a sovereign force: the Principality owns the service, controls who is on it, and keeps its picture to itself.
Access is controlled by a per-user certificate. Each member is issued a unique digital credential, loaded onto their device, which does two jobs at once. It proves who they are to the server, so that only enrolled members join the net and a lost device can be shut out by revoking its certificate. And it encrypts the traffic between device and server, so the picture cannot be read in passing by anyone who is not on the net. A member's certificate is personal and is looked after like any other credential: not shared, not copied to another device casually, and reported at once if the device is lost, so it can be revoked. The figure shows the difference the server makes.
WHY A SERVER: local share vs. shared beyond the local
WITHOUT A SERVER (direct, radio to radio):
[ATAK]<-->[ATAK] only while close together;
the base and the far patrol see nothing.
WITH THE RKA SERVER (tak.kaharagia.org, OpenTAKServer):
[ATAK patrol A] --\ /-- [ATAK patrol B]
\ /
[iTAK member] -----> ( TAK SERVER, relays ) <------ [WinTAK base]
/ all CoT to all \
[WebTAK note] --/ per-user certs: \-- [ATAK member]
prove identity +
encrypt the traffic
A marker dropped anywhere appears on every screen.
Meshtastic: an off-grid data bearer
The TAK server solves sharing over distance, but it assumes a network underneath: a telephone signal, a Wi-Fi link, something carrying the data to the server. In the field that assumption often fails. There is no signal in the low ground, the mobile network is down after a storm, or the team is deliberately working away from any infrastructure. For exactly these cases the RKA fields Meshtastic.
Meshtastic is open-source firmware running on small, cheap radios that form a mesh: each set relays messages for the others, so the network has no central point and no fixed infrastructure, and it extends itself as more sets are added. Place sets across a team or along a route and they pass messages hand to hand, around hills and through gaps, with nothing but the radios themselves. The bearer underneath is LoRa, a long-range, low-power radio technique that carries very little data very far on very little battery, on licence-free ISM bands. That licence-free part matters: members can carry and use Meshtastic lawfully for data without an amateur licence, which makes it ideal for training and for a force whose members are not all licensed.
The price of that range and that tiny battery draw is bandwidth: a Meshtastic mesh carries only a trickle of data. You cannot push a live map full of detail through it, and you must not try. What it can carry is exactly the light, vital traffic that a team needs when nothing else is left: a position now and then, and a short line of text. Understood for what it is, a thin, licence-free, infrastructure-free pipe for the few bytes that matter, Meshtastic is a remarkable safety net. Misunderstood as a substitute for a real network, it disappoints. The art is to put only the right traffic on it.
Bridging the two: the TAK / Meshtastic gateway
TAK and Meshtastic are different networks speaking, at bottom, in different ways. To get the benefit of both, you bridge them with a gateway: a device or service that sits between the TAK net and the Meshtastic mesh and passes chosen messages across. Because CoT is the common language on the TAK side, and because the mesh can carry only a trickle, the gateway is deliberately fussy about what it lets through. It forwards only the light traffic: the position reports (PLI), so the blue dots keep moving on the map even when they are coming in over the mesh, and the chat (GeoChat), so short text still gets through. Everything heavier, the detailed map layers, large files, anything bulky, stays on the proper network and is simply not offered to the mesh.
The result is a graceful, layered capability. When the full network is up, TAK gives a rich shared picture over the server. When that network drops and the team is off-grid, the mesh keeps the two things that matter most, where everyone is and a way to send a short message, flowing across the gateway and onto the map. The picture thins but does not go dark. The figure below shows the whole stack: the rich TAK net over the server on top, the thin mesh underneath as the off-grid bearer, and clean voice procedure beneath all of it as the bedrock that never depends on any of the above.
THE LAYERED STACK: data assists, voice is bedrock
+-----------------------------------------------------------+
| TAK over the SERVER (tak.kaharagia.org, OpenTAKServer) |
| rich common operating picture: full map, markers, |
| routes, PLI, GeoChat -- needs a real network beneath |
+-----------------------------------------------------------+
| GATEWAY forwards ONLY light traffic
| (PLI position + GeoChat text)
v
+-----------------------------------------------------------+
| MESHTASTIC LoRa MESH (licence-free, no infrastructure) |
| off-grid bearer: a trickle of data, sets relay for each |
| other -- keeps the dots moving + short text when off-grid|
+-----------------------------------------------------------+
| when the network thins or fails...
v
+-----------------------------------------------------------+
| CLEAN VOICE PROCEDURE (the radio in your hand) |
| ACP 125 prowords, call signs, readback, the log |
| -- depends on NONE of the above; always falls back here |
+-----------------------------------------------------------+
Data or voice: choosing the right means
With the tools laid out, the operator's daily judgement is simply: for this thing, right now, do I use data or voice? The rule from the start of the lesson decides most cases. Use voice for anything that is a command, a decision, an urgent request, or anything that must be confirmed back to you immediately. An order to move, a contact report, a casualty that needs an answer this second, a leader changing the plan: these are voice, every time, because voice is instant, urgent, and confirmed by readback, and because a screen cannot convey intent or be sure it was read in time.
Use data for awareness that the map can hold: positions, marked points, routes, and quiet running notes. Where everyone is, a hazard logged for later, the agreed route, a short non-urgent message that need not interrupt the net: these belong on the map, where they sit patiently and show themselves to all without a word. Putting them on data keeps the voice net clear for the things only voice can do.
Two cautions complete the judgement. First, anything truly urgent goes by voice as well, even if it is also on the map, because you cannot be sure when, or whether, the other station will look at the screen, but a voice call demands attention now. A casualty marker is good; a casualty marker plus a spoken casualty report is right. Second, never let the map lull you into silence on the things voice owns. The temptation, once the picture is good, is to stop talking and trust the screen. That is the failure waiting to happen, because the screen can be stale and you would not know. Keep the routine radio checks; keep command on voice; let data carry only what data is for.
The PACE plan: ordering your means and falling back to voice
A team that depends on one means of communication is one failure from silence. The discipline that prevents this is the PACE plan, and it is the single most important idea in this lesson. PACE is an ordered list of the means you will use, named so the whole team knows, before anything goes wrong, exactly what to fall back to when each one fails. The letters stand for the order:
- Primary: the means you use normally, when all is well, the best tool for the job.
- Alternate: the next-best, used the moment the primary fails, with as little disruption as possible.
- Contingency: a means that is less convenient but more robust, for when both of the above are gone.
- Emergency: the last resort, the means that depends on the least and almost always works, however slow or limited.
The power of PACE is that the falling back is decided in advance, calmly, and rehearsed, so that on the day no one is improvising in the moment of failure. Everyone already knows: primary is down, go to alternate, and the whole team makes the same move at the same time without a word of debate. And the order is built deliberately so that as you go down the list, the means get simpler, more robust, and less dependent on infrastructure, ending in something that almost cannot fail. For an RKA patrol that means the bottom of every PACE plan is clean voice procedure on a simple radio, the skill the first five lessons of this course built, because it depends on nothing but the set in your hand and the procedure in your head. The figure shows a worked PACE plan for a patrol.
PACE PLAN: a patrol working away from base
---------------------------------------------------------------
| LEVEL | MEANS | WHEN / WHY |
---------------------------------------------------------------
| PRIMARY | TAK over the server | Normal working: full |
| | (tak.kaharagia.org) | shared map, PLI, |
| | + voice for command | markers, GeoChat. |
---------------------------------------------------------------
| ALTERNATE | TAK over Meshtastic | Network to the server |
| | mesh (PLI + GeoChat, | lost / off-grid: dots |
| | via the gateway) | + short text survive. |
---------------------------------------------------------------
| CONTINGENCY | VOICE on the section | Data is gone: report |
| | net (simplex / set | position and pass |
| | radios), full proc. | reports by voice. |
---------------------------------------------------------------
| EMERGENCY | Pre-arranged simple | Radios down too: meet |
| | fallback: rendezvous, | at the known RV at |
| | timings, visual/field | the set time; use |
| | signals, runner | field signals. |
---------------------------------------------------------------
Down the list: simpler, more robust, less dependent on kit.
The fallback to clean voice is decided and drilled in advance.
Write the PACE plan into your orders, brief it so every member can recite it, and rehearse the fallbacks until the move from one level to the next is automatic. A PACE plan that lives only on paper is no plan at all; the value is in the team having drilled it, so that when the screen freezes the whole patrol drops to voice in the same breath, passes a clean position report by the procedure of Lesson 02, logs it by Lesson 04, and carries on. The network failing should be a non-event for a team that has done this, an inconvenience absorbed, not a crisis.
In Practice: A Patrol Loses the Network
A four-member section under a Corporal is out on a training patrol, working a wide area away from the base. The signaller, a Private, has the section on TAK: each member's dot moves on the shared map over the RKA server at tak.kaharagia.org, the Corporal has marked two hazards and the rendezvous, and the agreed route is drawn for all to see. Command is on voice, as always; the map carries the awareness. This is the primary of the briefed PACE plan, and it is working well: the net is quiet, everyone can see everyone, and the Corporal gives only the occasional order by voice.
Moving into low ground, the section loses the signal that was carrying TAK to the server. On every screen the other dots stop moving and the picture begins to age. The signaller notices at once, because part of the drill is watching for the picture going stale, and calls it on voice: the section is dropping to alternate, TAK over the Meshtastic mesh. The mesh needs no infrastructure, so the gateway keeps forwarding the light traffic, the position reports and short GeoChat, hand to hand across the section's sets. The full rich map is gone, but the two things that matter most survive: the dots move again, thinly, and a short text still gets through. The section keeps working, the picture poorer but alive.
Then a member's set fails and the mesh thins below use. Without fuss the section drops to contingency, plain voice on the section net, because that level was briefed and drilled and every member knows the move. The signaller passes positions and a short situation report by clean voice procedure, prowords and readback as Lesson 02 taught, and the Corporal logs each by Lesson 04. There is no scramble, because the falling back was decided in advance. Had the radios themselves gone too, the section would have dropped to emergency, the pre-arranged rendezvous at a set time and field signals, and met up in good order regardless. Nothing was lost and nobody was deaf, because the team treated the digital tools as assistants to voice and built every level of the plan to fall back, calmly and together, to the clean voice procedure that depends on nothing but the set in the hand. The screen had failed; the section had not.
Check Your Understanding
- Describe what TAK is, name its four client versions and what CivTAK is, and explain the common operating picture and the part the Cursor-on-Target protocol plays in keeping it shared. Then explain why a TAK server is needed and how the RKA provides one of its own.
- Explain what Meshtastic and LoRa are, why the mesh is a useful off-grid bearer for the RKA, and why a TAK/Meshtastic gateway forwards only light traffic such as position reports and GeoChat. Give the rule for choosing data or voice for a given message.
- Set out the PACE plan in order, explaining what each level is for and why the means grow simpler and more robust as you go down the list. Explain why clean voice procedure sits at the bottom of an RKA patrol's plan, and why the fallback must be decided and drilled in advance.
Reflection (write a short paragraph): This lesson insists that data tools assist voice and never replace it, and that every plan must fall back, in good order, to the radio in your hand. Think honestly about your own habits with technology. When a screen gives you a clear answer, are you inclined to stop checking it against the world, and what would that cost you on a patrol if the picture had quietly frozen? Consider a PACE plan for some real activity you take part in, an exercise, a journey, a community task, and ask whether you actually know what you would fall back to at each level, or whether you simply trust that the first means will not fail. What is one thing you could practise so that, when your primary means of communication goes down, dropping to clean voice procedure is automatic rather than a scramble?
Summary
- Digital tools assist voice; they never replace it. Voice carries command, decision, urgent request, and anything needing immediate readback; data carries awareness the map can hold: positions, markers, routes, and quiet notes. A stale screen can lie, so the map is always checked against voice and reality.
- TAK (Team Awareness Kit) shows a team a shared map, the common operating picture: PLI position dots, markers, routes, and GeoChat. Its clients are ATAK (Android), WinTAK (Windows), iTAK (iOS), and WebTAK (browser); CivTAK is the civilian release the RKA uses lawfully.
- Cursor-on-Target (CoT) is the small standard message that carries each position, marker, route, and chat line between devices; because the messages are small, the picture can survive a thin link, and anything that speaks CoT can be bridged into the picture.
- To share beyond the local area you need a TAK server. The RKA self-hosts its own, OpenTAKServer at
tak.kaharagia.org, with a per-user certificate that both proves a member's identity and encrypts their traffic; a lost device's certificate is revoked. - Meshtastic is a licence-free, infrastructure-free LoRa mesh that relays hand to hand as an off-grid data bearer; its bandwidth is tiny, so a TAK/Meshtastic gateway forwards only the light traffic, position reports (PLI) and chat (GeoChat), keeping the dots and short text alive when the full network is gone.
- The PACE plan, Primary, Alternate, Contingency, Emergency, orders the team's means so the fallback is decided and drilled before anything fails; the means grow simpler and more robust down the list, ending for an RKA patrol in clean voice procedure that depends on nothing but the set in hand. The network failing should be a non-event for a team that has rehearsed it.
- This lesson completes SIG 201 by fitting the digital tools to the operator's discipline built in Lessons 01 to 09. It supports FLD 220 (Signals awareness), PME 210 (message and report writing for what the net carries), HCR 220 (continuity of communications when services fail), FLD 230 (the net on the move), and FLD 201 (Navigation, the ground the map depicts). It leads on in the speciality to SIG 220, Communications Security and Digital Discipline.
Crown Copyright © 2026 | Published by Authority of H.R.H. The Prince of Kaharagia