Landseed / Field Guide / Hardware

Connectivity options for real-time alerts

An alert is only worth what it costs to get out of the landscape. The Landseed Link is the radio between a Landseed Lookout camera and the cloud: one printed circuit board, one of four modems, and the choice made on the assembly line rather than in the field.

Product
Landseed Link
Edition
V1.0 — work in progress
Compiled
16 September 2026
Source of record
LS_Link_Requirements_ED_09.17.26.xlsx
Framework
Four systems, agreed with ANFA, 16 September 2026
01

A connectivity solution for every park

Three things have to go right before anyone can act on an intrusion, and all three are power problems before they are anything else. There is no one-size-fits-all technology for getting an alert out of a reserve — but there is a system for every park.

First, the detection itself has to be worth something. A camera that triggers on everything records mostly nothing — grass moving, heat shimmer, an animal crossing the frame at night — and every one of those costs power to capture, power to store, and far more power to transmit. A camera that sends everything is a camera whose battery is finished in weeks, which ends the deployment before it has told anyone anything. So the first job is done on the edge: the AI in the camera decides what it is looking at, throws away the false triggers, and keeps only the object of interest — here, an intruder. We send what is useful and actionable, and nothing else.

Second, the detection has to leave the site. Edge AI on its own solves half the problem and can look like the whole of it. In a park with no cellular coverage, a correctly filtered image of an intruder is written to the SD card and stays there: a perfect record of something nobody was ever told about, recoverable weeks later by somebody walking to the tree. That is the gap this guide closes. A satellite link cheap enough and low-powered enough to leave in the bush is the part Landseed has solved — the low-cost ORBCOMM ST4300 carrying a cropped image of the intruder at about 4 W, which is §5.

Third, all of it has to run on a battery nobody is coming back to change. That constraint is why the other two look the way they do. Edge filtering exists so the radio can stay off. Cropping the image to the contents of the bounding box exists so that when the radio does come on, it is on for less time. The ST4300 is in the design because it does the work at roughly a tenth of the power of a broadband terminal. Each of those is a battery-life decision before it is a connectivity decision.

Which system a park gets is decided by the site, not by the product: park size, remoteness, vegetation, topography, and whether there is a cell network or any other communications infrastructure to work with. A large park will often want a mixture rather than a single answer — one sector with a tower in reach, one along the inhabited edge with coverage, and an interior with neither.

And the decision is made before assembly. The Link is one printed circuit board with a modem socket, and what goes into that socket is chosen on the assembly line. A wrong answer is not a setting to change in the field; it is the wrong board. That is why a site consultation comes before a shipment, and why §6 asks what it asks.

Four site conditions, four systems
What the site already has System What it costs you
A LoRaWAN gateway within radio reach, with working backhaul System 1 Nothing to build — and three things nobody at Landseed owns all have to keep working.
Usable cellular at the camera, not merely at the gate System 2 A cheap modem and an IoT SIM. Data is effectively unmetered at these volumes, so the whole image goes — no cropping penalty. You inherit somebody else's outages and somebody else's tariffs.
Neither, and a view of the sky System 3 A dearer modem than a cellular one, but small and about 4 W. Carries the cropped alert image inside a 16 KB message. Per-byte data is the most expensive here — that is the trade.
A staffed structure, sun, and a requirement a cropped image cannot meet System 4 Cheaper data than the ORBCOMM link and far more of it — paid for in power: 25–40 W against roughly 4 W, plus a battery that is still being sized. The last resort, not the upgrade.
02

One board, four links

Every Landseed Link is the same printed circuit board. What changes is which modem is plugged into the motherboard, and that decision is made at the assembly line — not by a technician standing in a park.

Common base platform — all four variants

ESP32-S3 microcontroller
LoRa — 433 MHz or 868/915 MHz
ESP32 Wi-Fi
modem socket — one common connector footprint
1Nothing plugs inThe socket stays empty. The base platform alone, backhauled over a LoRaWAN network somebody already runs.
2LTE moduleBuilt to the same format as the ST4300 so the two are interchangeable: same connector, same PCB size.
3ORBCOMM ST4300The low-cost ORBCOMM terminal, plugged into its own connector footprint on the motherboard. It is what makes a satellite link affordable enough to put in the field at all.
4Nothing plugs in — power doesNo modem module. A Starlink power supply, a larger battery and a solar panel, feeding a separate Starlink Mini. The exception rather than the default — see the power column in §5.

How to read the four names

The workbook names each variant as a chain — "LoRa to ORBCOMM Satellite", "LoRa to WIFI to Starlink Mini Satellite" — but it does not define the legs. Throughout this guide the first leg is read as the hop from the camera to the Link (Wi-Fi in System 1, LoRa in Systems 2, 3 and 4) and the last leg as the Link's uplink out of the landscape. That reading is consistent with the build matrix, which puts both LoRa and ESP32 Wi-Fi on all four boards — but it is a reading, and it should be confirmed before anyone builds to it.

Still open — requirement HW-5

That all four variants are one PCB in four assembly variants is the intent, and the workbook marks it TBA — to be analysed. It is not yet a settled result.

03

One Link, many cameras

The LoRa hop from a camera to the Link costs nothing to send. The hop out of the landscape is the one that carries a subscription — and every camera within LoRa range of the Link shares it. How many that is depends on how many trails are worth watching inside that range, not on the Link.

1 terminal · 1 subscription Landseed Link the only metered device here LoRa no charge to send one camera per trail worth watching LoRa range every trail inside reports to this Link dry sand river intruders — whichever braid they take in from the settlement side the track braids here into the reserve
One track in, braiding as it enters — flat mopane woodland, which is the common case rather than the exception. A camera on every braid worth watching, each sending over LoRa at no charge to a single Link standing where it has sky. How many cameras is set by the ring, not by the Link: whatever falls within LoRa range of it reports to it, which is five here and could as easily be ten somewhere the trail divides more. The Link holds the only metered device on the site, so one subscription is bought and divided by however many cameras are inside. Before, one braid got the camera and the rest were a guess, because a camera that had to reach the satellite by itself had to carry its own terminal. Illustrative: a schematic of the pairing in the landscape it is meant for. No boundary is drawn and none is needed — the track and the settlement side carry the geography.
Cameras on one Link
n

Open-ended to a point. Set by how many trails worth watching lie within LoRa range of the Link — five where the track braids five ways, ten where it braids ten.

Satellite terminals
1 was n

Whatever n is, the ST4300 is the only metered device on the site.

Each camera's share of one subscription
1/n

Recurring cost scales with terminals, not with cameras. Ten cameras on one Link is a tenth each, and the Link costs the same either way.

Pooling several cameras onto one gateway is long-settled practice, and it is the part of this architecture that needed no rethinking. What the Link changes is that the pooling point is now the same board in every variant.

How far out the ring should go

Radio will often reach further than the ring drawn in the figure. Landseed advises keeping a camera within about 10 km of its Link anyway — and the reason is not radio. It is that a response team has to be able to reach the place the alert came from while the alert still means something. A link budget that stretches to 30 km across open country is of no use if nobody can walk it in time.

What the Landseed Link changes is that the pooling point is now the same board in every variant. Pooling pays wherever the uplink carries a per-terminal cost: System 2 (one SIM and one data plan), System 3 (one ORBCOMM subscription) and System 4 (one Starlink service). It pays hardest on System 3, whose bytes are the dearest in the set — there, pooling and cropping are the two things holding the running cost down. System 1 is the exception — the backhaul there belongs to whoever runs the LoRaWAN network, so the saving is theirs rather than the park's.

What replaces the cost is airtime

Free to send is not unlimited to send. Every camera on a Link shares one duty-cycle budget in licence-free spectrum, and a handful of cameras that rarely trigger are not the same load as the same number triggering all night. Appendix A is about exactly this constraint.

In practice the number is set by geometry rather than by the device: as many cameras as there are trails worth watching inside LoRa range of the Link. Five in the figure above, because the track braids five ways there; ten where ten paths need covering. The device-side ceiling is a separate question and it is not established. Nothing in the source workbook addresses it, and no measured figure exists; the answer does depend on alert rate, spreading factor and band. Treat “open-ended” as open-ended to a point, and find the point before quoting one.

04

One flat landscape, three ways out

Forty-three kilometres of the Luangwa valley floor, at the real elevations — a plain with about 120 m of relief across the whole frame. Three clusters, each pooling however many cameras its range ring holds onto one Link, each leaving by the only route its corner of the reserve allows. The counts differ because the trails do. Drag to orbit.

The terrain is real; the deployment is not. Elevation is Copernicus GLO-30 for 31.70–32.10°E, 12.78–13.12°S — 43 × 38 km of the Luangwa valley floor, 517 to 639 m, downsampled to a 112 × 112 grid and drawn at vertical exaggeration ×34, without which a plain this flat renders as a sheet of paper. Watercourses are OpenStreetMap. Woodland cover is indicative, not mapped. No boundary of any kind is drawn. The three clusters, the tower and the coverage they imply are placed to show the mechanism — they are not a map of where LoRaWAN or cellular coverage actually reaches in South Luangwa, which is a question for the people who work there. The ring drawn around each Link is 10 km, the working maximum Landseed advises between a camera and its Link — set by how fast a response team can reach the alert, not by the radio.

West · a tower already there
Rising ground at the edge of the plain, with a tower carrying power and a connection. Four cameras onto one Link, and the Link interfaces with what exists. System 1.
South · toward the settlements
Near the inhabited side, where a tower put up for people is in reach of a device in the bush. Five cameras onto one Link, one SIM. System 2.
Interior · nothing at all
The middle of the plain: no tower, no gateway, no camp, and nothing to see over because there is no relief. Nine cameras onto one Link here — the ring is what sets that, not the Link — and the Link buys the only subscription. System 3.
Not shown · System 4
A Starlink Mini averages 25–40 W against roughly 4 W for the ST4300, and needs a staffed structure and a power budget, so it belongs at a camp rather than in a landscape view. §5 has it.
05

The four systems

Each is the same board. What separates them is not capability in the abstract but what the site already has — and what it will still have in three years, when nobody who chose it is still there.

1

Wi-Fi to LoRaWAN backhaul

Camera → Wi-Fi → Link → LoRaWAN → gateway → cloud

What plugs in

Nothing. The modem socket stays empty: ESP32-S3, LoRa and ESP32 Wi-Fi on the base platform, on the regular battery pack. The cheapest variant to build.

What the site must already have

A LoRaWAN gateway within radio reach of the Link, that gateway's own working backhaul, and a network server somebody operates. Three things, none of them ours.

What it carries

Short uplinks, inside whatever airtime budget the network and the local band allow. LoRaWAN is built for detections, not images — see Appendix A.

Where it fails

No gateway. Or a gateway whose backhaul is down. Or a Link sitting below the ridge line from it. The socket is empty, so there is no second route.

Not yet settled

  • Extended pack and solar are Possible, not committed
  • Charger specified only as “maybe 2 A”
2

LoRa to LTE

Camera → LoRa → Link → LTE → tower → cloud

What plugs in

An LTE module built to the same format as the ST4300 — same connector, same PCB size, so the two are interchangeable. Requirements HW-3 and HW-4, both accepted. Regular battery pack.

What the site must already have

Usable cellular coverage at the Link's own position, and a SIM and data plan that works on that network, in that country, for the life of the deployment.

What it carries

The whole image, uncropped, without paying for it. IoT SIM data is cheap enough at these volumes to be effectively unmetered, so this is the one uplink where payload size is not a design constraint. The cheapest hardware in the set, and one SIM and one data plan serve however many cameras reach the Link over LoRa (§3).

Where it fails

Coverage maps are drawn for people in vehicles on roads. Coverage at the gate is not coverage at the tree. And the network is somebody else's: an outage, a tariff change or a shutdown is not ours to fix.

Not yet settled

  • The LTE module is specified by format, not yet by part
  • Extended pack and solar are Possible, not committed
3

LoRa to ORBCOMM satellite

Camera → LoRa → Link → ORBCOMM → satellite → cloud

What plugs in

An ORBCOMM ST4300 satellite modem module, on its own connector footprint on the motherboard — requirement HW-2, accepted. Extended battery pack. The ST4300 is ORBCOMM's low-cost terminal, and that is what makes a satellite link affordable enough to leave in the bush at all: dearer than a cellular modem, far cheaper and far smaller than a Starlink, at about 4 W while registering and transmitting.

What the site must already have

Sky. A view of the horizon good enough for the ST4300's antenna, and nothing else at all. This is the variant that depends on no infrastructure anyone can take away.

What it carries

An image, not only a detection. The ST4300 carries up to 16 KB per message, and a Landseed alert image is cropped to the contents of the bounding box before it is sent — often under 5 KB. The picture goes out over narrowband because the picture was made small, not because the pipe was made wide. And whatever the message costs, every camera within LoRa range of the Link shares one of it rather than each buying its own (§3).

Where it fails

Closed canopy directly overhead; a gorge that cuts the sky. Mounting height and sky view do the work that a tower does elsewhere, which makes placement the whole job.

Not yet settled

  • Both Regular and Extended battery packs are marked Yes for System 3. Whether that means either, or both, is not stated
  • Extended pack and solar are Possible, not committed
4

LoRa to Wi-Fi to Starlink Mini

Camera → LoRa → Link → Wi-Fi → Starlink Mini → cloud

What plugs in

No modem module — power instead. A Starlink power supply, and no regular battery pack: the matrix marks it No for this variant alone. The extended pack and a solar panel are marked Possible, as they are on every variant — here they are not optional in practice.

What the site must already have

Somewhere to put a Starlink Mini and keep it fed — a camp, a ranger post, a gate — with sun for the panel and a structure to mount on.

What it carries

Broadband — full frames, a sequence, video, or somebody working online at the site. That is the only thing it carries that System 3 does not, because System 3 already sends the cropped alert image. Reach for System 4 when a cropped image genuinely is not enough, and not before.

Where it fails

On the power budget, mostly. Starlink's own specification sheet gives the Mini an average consumption of 25–40 W, a 12–48 V / 60 W input rating and a 100 W USB-PD requirement — against roughly 4 W for the ST4300. That is the reason this is the exception and not the default. Read it as a site uplink that cameras reach over LoRa, never as a camera-side option.

Not yet settled

  • HW-6 — a battery "sized to power a connected Starlink Mini" is TBD. Until that number exists, the power budget is an intention rather than a design
  • Extended pack and solar are Possible, not committed; the regular pack's cell size is “to decide”

What each uplink carries, and what it costs to run

These three columns decide most deployments between them, and they do not all point the same way. Cellular is cheapest on both counts where it exists at all. Where it does not, the choice is between a small, low-power terminal with expensive bytes (System 3) and a large, power-hungry one with cheap bytes (System 4) — and on a battery nobody is coming back to change, power usually wins.

Payload, power and what the data costs
UplinkWhat it carriesPower while transmittingRecurring data cost
System 1 · LoRaWAN Short uplinks, inside whatever airtime the network and the local band allow. A 20–40 KB image is not what LoRaWAN was built for — Appendix A. not established Somebody else's network, so somebody else's bill. Nothing of ours to pay.
System 2 · LTE The whole image, uncropped. Payload size stops being a design constraint here. not established Lowest. IoT SIM data at these volumes is cheap enough to treat as unmetered.
System 3 · ORBCOMM ST4300 Up to 16 KB per message. A Landseed image cropped to the bounding box is often under 5 KB, so the alert arrives with the picture in it. ~4 W Highest per byte — dearer than Starlink's. Bought back in power and in size, and mitigated by cropping and by pooling cameras onto one terminal (§3).
System 4 · Starlink Mini Broadband. Full frames, sequences, video, interactive access. 25–40 W
60 W input rating
Cheaper per byte than the ORBCOMM link, and far more of it. The bill it sends is a power bill.
ST4300 payload, crop size, power and relative data cost, and IoT SIM pricing: stated by Eric Dinerstein, 17 September 2026 — to be confirmed against the ORBCOMM datasheet before they go in front of a customer.
Starlink Mini: MINI SPECIFICATIONS, starlink.com — “Power Consumption: Average 25-40 W”, “Input Rating 12-48 V 60 W”, “USB PD Requirement 100 W, 20V/5A Minimum”. Read September 2026.
06

Choosing one

The order below is deliberate: it asks what the site already has before it asks what the site could have. Answer for the place the Link will actually sit.

Question 1 — payload

Does the site need more than a cropped alert image — full frames, a sequence, or somebody working online there?

Not “does it need a picture”: System 3 already sends one, cropped to the bounding box, at about a tenth of the power. This asks only whether that is genuinely not enough. It overrides the other three, so answer it honestly.

Question 2 — existing network

Is there a LoRaWAN gateway within radio reach of the site, with its own working backhaul?

Reach, not presence. A gateway at headquarters four ridges away is not reach, and a gateway whose satellite link is unpaid is not backhaul.

Question 3 — cellular

Is there usable cellular coverage at the site itself?

At the tree, not at the gate. If nobody has held a handset at the spot and watched it hold a connection, the answer is no.

Question 4 — structure and sun

Is there a staffed structure at the site — camp, post or gate — with sun for a panel?

This decides whether System 4 is possible at all. A Starlink Mini needs somewhere to mount it, something to keep it charged, and somebody who notices when it stops.

How to answer Question 3 without a coverage map

Most parks have some good cellular coverage, and first assessments of it are often wrong. Signal strength at the actual deployment site is frequently too weak to push an image alert out, even where a handset shows bars.

Stand at the spot the camera will go. Place a WhatsApp call, or send an email with a small attachment. If it goes through, the location probably has enough coverage to carry an alert. If it does not, the answer to Question 3 is no — whatever the map says.

Two minutes at the tree settles what a coverage map cannot.

These four questions are the short form of a longer one

The pre-deployment consultation asks six things, and all six are connectivity: how cellular coverage behaves across the park; the habitat type; the terrain type; whether there is a topographic high point nearby with a working connection, and its coordinates; which local operators actually cover the proposed camera sites — worth checking with a signal-mapping app on the ground, which will also tell you whether the network is 2G, 3G or LTE; and whether there is a LoRaWAN, SigFox, VHF or radio repeater tower with constant power and internet within reach, with coordinates.

Those six decide the answer, and they are worth answering properly: a wrong one does not mean a setting to change on site, it means populating the wrong board.

07

Build matrix

What is fitted to which variant, transcribed from the Variants sheet of the source workbook. The columns run from the simplest and cheapest system for the end user to the most demanding. The word “Possible” is the workbook's own, and it is doing real work — see below.

LS_Link_Requirements_ED_09.17.26.xlsx · sheet “Variants V2”
Component System 1
Wi-Fi to LoRaWAN backhaul
System 2
LoRa to LTE modem
System 3
LoRa to ORBCOMM satellite
System 4
LoRa to Wi-Fi to Starlink Mini
LoRaYesYesYesYes
ESP32 Wi-FiYesYesYesYes
LTENoYesNoNo
ORBCOMM ST4300NoNoYesNo
Regular battery pack
in the box; Li-ion, larger cell or prismatic
YesYesYesNo
Extended battery packPossiblePossiblePossiblePossible
Battery charger, with MPPT
or a like algorithm
YesYesYesYes
Starlink power supplyNoNoNoYes
Solar panelPossiblePossiblePossiblePossible
Yes fitted No not fitted Possible the workbook's own word — available on that variant, not committed to it
Observations carried from the workbook: the extended pack is “external battery or solar panel (15–24 V to accommodate Starlink)”; the charger is “maybe 2 A current charging battery”; the regular pack's cell size is “to decide”.

“Possible” is not a decision

Two rows — the extended battery pack and the solar panel — read Possible on all four variants. That is an honest answer to a different question: it says the platform can take them, not that any variant ships with them. Nothing in this guide should be read as saying a given system arrives with solar or with an extended pack, and the sheet's own next step is that the schematic block is still to be drawn and agreed.

08

Requirements register

The Requirements sheet, carried across whole — including its status column, which is the part most likely to be dropped in a retelling and the part that matters most.

LS_Link_Requirements_ED_09.17.26.xlsx · sheet “Requirements” · Landseed Link Requirements V1.1 — work in progress
IDRequirementApplies toStatus
GEN-1The LandSeed Link shall function as the communications gateway between the LandSeed Lookout camera and the cloud back-end.All variantsInferred
GEN-2The LandSeed Link shall be available in four deployment variants (System 1 through System 4), selected according to the connectivity infrastructure available at the deployment site.All variantsDocumented
GEN-3All four deployment variants shall share a common base platform, differing only in which additional communication module(s) are installed and any variant-specific configuration.All variantsDocumented
HW-1The base platform, common to all variants, shall include an ESP32-S3 microcontroller and LORA 433Mhz or 868/915 MhzAll variantsAccepted
HW-2System 3 hardware shall add a plug-in OrbComm ST4300 satellite modem module, with a corresponding connector footprint on the motherboard.System 3Accepted
HW-3System 2 hardware shall add a plug-in LTE Module . LTE Module should be the same format as the ORBCOM module. Will fir in thhe same connector and same PCB SizeSystem 2Accepted
HW-4Design LTE module same format as orbcom ST4300 to be interchangeableLTE moduleAccepted
HW-5Sistem 1,2,3 and 4 should be a comon platform. Same PCB but different assembly variantAll variantsTBA — to be analysed
HW-6System 4 hardware shall include a battery of greater capacity than the base platform's battery, sized to power a connected Starlink Mini terminal.System 4TBD
ENV-1Operating temperature -20 to 50 deg C in the shade - no sun exposure and -20 to 40Deg with sun exposureAll variantsNo status given
ENV-2Ip grade - IP67All variantsNo status given
NOTE-117 Sep 2026 - variants renumbered to order them from simplest and cheapest for the end user. System 1 unchanged (LoRaWAN backhaul). System 2 is now LoRa to LTE (was System 4). System 3 is now LoRa to OrbComm ST4300 (was System 2). System 4 is now LoRa to WIFI to Starlink Mini (was System 3). HW-2, HW-3 and HW-6 updated to match; the Variants columns were moved, not retyped.All VariantsDocumented

Requirement text is quoted as written in the source workbook, spelling included. The variant numbers changed on 17 September 2026 — anyone holding the 09.14.26 workbook has System 2 and System 4 the other way round, and System 3 where System 4 now is. NOTE-1 records the move. ENV-1 and ENV-2 are stated as requirements — they are not test results, and no environmental test report is referenced by the source.

09

What this guide cannot tell you

The most useful page in a field guide is the one that marks its own edges. Everything below is open in the source, and nothing below has been filled in from adjacent material.

Whether one PCB really serves all four

A common board in four assembly variants is the intent of the whole design. It is not yet an analysed result.

HW-5 · TBA

How big System 4's battery has to be

Bigger than the base platform's, and enough to run a Starlink Mini. No capacity, no duty cycle and no solar sizing accompany it.

HW-6 · TBD

What “Possible” commits anybody to

The extended battery pack and the solar panel are marked Possible on all four variants. That says the platform can take them. It does not say which variants ship with them, and nobody should quote it as if it did.

Variants V2

The battery, at both ends

The regular pack is “Li-ion, larger cell or prismatic — to decide the battery size”, and the charger is “maybe 2 A”. A charger with MPPT is now committed on all four variants, which is more than the sheet said two days earlier; the numbers behind it are not.

Variants V2 · observations

The schematic itself

The workbook's own next step is a schematic block, to be drawn and then discussed again for a final agreement. Until that exists, every row in §7 is an intention about a board that has not been laid out.

Variants V2 · next step

That the Link is the Lookout's gateway

The role the entire product rests on is marked Inferred in the workbook — an inference recorded as such, not a documented decision.

GEN-1 · Inferred

Any range, throughput, power or cost figure for the Link

No link budget, no measured range, no data rate, no current draw and no unit cost for the Landseed Link appears anywhere in this guide, because none appears in the source. LoRa range is set by antenna, gain, mounting height, terrain and canopy, and none of those has been measured for the Link. The payload and power figures in §5 are stated rather than measured, and are labelled as such wherever they appear.

Not measured

Where the coverage actually is

§4 places a LoRaWAN tower, a cellular tower and a satellite cluster on a real 43 × 38 km block of the Luangwa valley floor. The block is real; the three placements are not surveyed. Which parts of South Luangwa carry LoRaWAN, which carry cell, and which carry neither is a question for the people working there, and the answer changes which variant each sector gets.

Not surveyed

The ST4300's payload and power figures

The 16 KB message ceiling, the sub-5 KB cropped image and the roughly 4 W draw are stated by Eric Dinerstein and are the load-bearing numbers in the whole comparison. They have not been checked against an ORBCOMM datasheet, and no public ST4300 datasheet was found while compiling this edition. Confirm them before they appear in a proposal.

Stated, not verified

Where “open-ended” stops

In the field the count is set by geometry — how many trails worth watching fall within LoRa range of the Link. The device ceiling is the separate question, and it is unstated everywhere — the workbook is silent on it. It is a function of alert rate, spreading factor and band, and it wants measuring before anyone quotes a number in a proposal.

Not established

How the legs of each chain are divided

The variant names describe a chain but do not define which radio carries the camera and which carries the uplink. §2 states the reading used here; it is a reading.

Variants sheet · names only
A
Appendix A

LoRa is not LoRaWAN

The two words are used interchangeably in nearly every conversation about connectivity, and the difference decides whether System 1 is available to a site at all — and it explains why the Link behaves the way it does on the radio.

Layer 1 — the radio

LoRa

A modulation: Semtech's, proprietary, and licensed into chips from several manufacturers. It is built to be very good at transmitting long distances at low power, and it is correspondingly slow. Its native use case is machines that do not have much to say and do not have to say it often.

no addressing · no network · no operator
A protocol on top of it

LoRaWAN

A network protocol built on that radio. It adds bytes to the packet so it carries who is meant to receive it and who sent it, and it adds rules so that every device gets a fair share of a spectrum everybody else is using too: how often a device may talk, and how many bytes it may send each time.

addressing · fair-share rules · a permanent internet connection

The modulation and the protocol are different things

LoRa describes only how to encode bits and bytes and assemble them into packets. It says nothing about who a packet is for, and nothing about who may transmit when. Two LoRa radios set to the same frequency, bandwidth and spreading factor can talk to each other, and nothing else has to exist for that to work.

LoRaWAN wraps those packets in addressing and in airtime discipline, because radio spectrum is a shared resource and licence-free spectrum is shared with everyone. Its rules govern how often per day a device may talk and how many bytes it may send each time. Behind the gateways sits a network server that does the real work — de-duplication, session keys, adaptive data rate, downlink scheduling — and somebody has to run it.

LoRaWAN suits telemetry and GPS tracking well. It was never designed to move a 20–40 KB image, and it will not.

Why the Link is not a LoRaWAN gateway

The Link is a store-and-forward device. Most of the time nothing is being sent, so it holds no full-time internet connection — and that is where most of its power saving comes from, on a device that lives a long way from mains. It receives an alert from a camera, and only then wakes the satellite or cellular side.

Its LoRa receiver can sleep as well. Waking for a few milliseconds each second, just long enough to hear whether anything is trying to reach it, drops listening current toward the microamp range. LoRaWAN has no equivalent: a LoRaWAN gateway is meant to hold a permanent internet connection so that a packet can be routed the instant it arrives, and its link to the end device is bidirectional.

The Link also moves images with a unidirectional, broadcast protocol. An image can afford to lose a few packets, and that tolerance is what allows a power amplifier at the sending end and a low-noise amplifier at the Link to buy range a strictly acknowledged protocol could not.

Sharing a park with a LoRaWAN network

Where a protected area already has LoRaWAN towers, the two coexist on different frequencies rather than competing. Most commercial LoRaWAN gear operates above 800 MHz; the Link can operate at 433 MHz, which reaches further, and Landseed supplies the modem that is lawful where the legal band is 865–915 MHz instead.

What this means for each system

Every Landseed Link carries LoRa — requirement HW-1, on all four variants. Only System 1 uses it as LoRaWAN, where the Link is an end device on a network somebody else operates, with a gateway, a backhaul, a server and keys that all have to exist and keep existing. Systems 2, 3 and 4 use LoRa as a private store-and-forward hop where the Link, not a gateway, is the thing on the other end.

So a site survey reporting “we have LoRa” has not answered the question System 1 asks. “We have a LoRaWAN gateway with working backhaul, and here is who runs the network server” is the answer System 1 needs. The first sentence is about a radio. The second is about an organisation.

The frequency point is a requirement, not a preference. HW-1 offers 433 MHz or 868/915 MHz, and which is lawful depends on the country of deployment — so the band is an assembly-line decision exactly like the modem, and a reason to know the destination country before the board is populated.

And the payload argument has two answers, of which the cheap one wins. A 20–40 KB image is not something a narrowband link will carry — so System 3 shrinks the payload rather than widening the link: the alert image is cropped to the contents of the bounding box before it is sent, which puts it under 5 KB more often than not, inside the ST4300's 16 KB message. System 4 widens the pipe instead, and pays 25–40 W for it against roughly 4 W. That is why System 3 is the default in this guide and System 4 is the exception. See §9 — no range or throughput figure for the Link itself has been measured.

B
Appendix B

Where every claim here comes from

Each statement in this guide traces to one of the lines below, or it is marked in §9 as something the source does not settle. Quoted passages carry the date of the document they are quoted from, not the date of this edition.

Source of record
LS_Link_Requirements_ED_09.17.26.xlsx, sheets Variants and Requirements, V1.1, dated 17 September 2026. Every Yes / No / ? in §7 and every requirement line in §8 is transcribed from it, spelling included. Its Variants V2.1 sheet is the 16 September 2026 V2 sheet with the columns reordered and nothing retyped; V1.1 of the register renumbers the variants from simplest and cheapest for the end user. NOTE-1 records the move, and the superseded Variants V1 sheet is kept in the workbook with its original numbering.
Framework
The four systems, agreed with ANFA, 16 September 2026, per Eric Dinerstein.
ST4300 payload and power
16 KB per message; Landseed images cropped to the bounding box, often under 5 KB; about 4 W while registering and transmitting; and the ST4300 as ORBCOMM's low-cost terminal — all stated by Eric Dinerstein, 17 September 2026. Not confirmed against a datasheet; no public ST4300 datasheet was found. Logged in §9.
Starlink Mini power
MINI SPECIFICATIONS, starlink.com public specification sheet, read September 2026: “Power Consumption: Average 25-40 W”, “Input Rating 12-48 V 60 W”, “USB PD Requirement 100 W, 20V/5A Minimum”. Quoted for comparison only; Landseed has not measured a Starlink Mini.
Appendix A
Written for this edition. The radio behaviour it describes is the Link's own; the distinction between the modulation and the network protocol is general and not specific to any product.
Elevation, §4
Copernicus GLO-30 digital elevation model, window 31.70–32.10°E / 12.78–13.12°S, downsampled to 112 × 112 and drawn at ×34 vertical exaggeration. Read from the baked terrain of south-luangwa-landseed. © DLR e.V. 2010–2014 and © Airbus Defence and Space GmbH 2014–2018 provided under COPERNICUS by the European Union and ESA; all rights reserved.
Watercourses, §4
The Luangwa and the sand rivers are OpenStreetMap, ODbL — © OpenStreetMap contributors. Woodland cover is generated, not mapped, and is marked as indicative on the figure.
What is not drawn
No protected-area boundary appears anywhere in this guide, in §3 or §4, and none was consulted. The clusters, the towers and the coverage they imply are placed to show a mechanism; they are not a survey of where connectivity reaches in South Luangwa. §3 is drawn rather than surveyed throughout.
Brand and type
Grand Army, March 2026 — dark / cinematic context. Vendor names appear only where a named part is the subject; none of them is a statement about a commercial relationship. Hanken Grotesk and Fraunces, both SIL Open Font Licence, served from this page rather than from a font CDN, with the licence alongside them at fonts/OFL.txt.