10 Infrastructure-Denied IoT: Field Architecture
More
Depth: Practitioner
Progress saves as you read. Mark sections complete as you go; your progress appears in the sidebar.
10.1 Start With the Situation
This section: Start With the Situation — The radio family is selected, but remote operation still has five linked concerns.
The radio family is selected, but remote operation still has five linked concerns. A weak signal may make a message hard to receive. An antenna sends and receives that radio signal. Stored-data custody asks where reports wait safely during an outage; recovery asks how they reach their destination afterward. Power must also last in the field. The team must join these parts into an architecture that can be tested away from normal infrastructure.
10.2 Overview
This section: Overview — This route builds the field architecture and verifies weak-signal, antenna, power, and custody evidence.
This route builds the field architecture and verifies weak-signal, antenna, power, and custody evidence.
This is part 2 of 2. Review Infrastructure-Denied IoT: Radio Options when you need the first route.
10.3 Learning Objectives
This section: Learning Objectives
By the end of this chapter, you will be able to:
- explain HF and weak-signal telemetry limits
- design antenna and power architecture
- validate custody and recovery during outages
10.4 HF and NVIS as Background Knowledge
This section: HF and NVIS as Background Knowledge — Most IoT courses focus on short-range wireless and LPWAN.
Most IoT courses focus on short-range wireless and LPWAN. Infrastructure-denied environments sometimes require students to understand a less common option: high-frequency radio.
10.4.1 HF Radio
HF means High Frequency, usually 3-30 MHz. Compared with common IoT bands, HF has long wavelengths: tens of metres rather than centimetres.
HF is not attractive for normal IoT because:
Antennas are physically larger. Data rates are usually low. Propagation varies by time of day and solar conditions. Licensing can be complex. Hardware and installation need radio expertise.
HF becomes interesting when the application needs:
Regional coverage. Very small messages. No cellular infrastructure. No tower network. No clear line-of-sight. No subscription operator. Delay-tolerant telemetry.
10.4.2 Ground Wave, Skywave, and NVIS
HF signals can travel in several ways:
| Mode | Description | IoT relevance |
|---|---|---|
| Ground wave | Signal follows the Earth’s surface | Useful at lower HF/MF over some terrains, but loss can be high |
| Conventional skywave | Signal leaves at a lower angle and returns far away | Good for long-distance communication, often skips over nearby receivers |
| NVIS | Signal leaves at a steep angle and is refracted back over a regional area | Useful when nearby regional coverage is needed without line-of-sight |
NVIS means Near-Vertical Incidence Skywave. The transmitter sends HF energy upward at a steep angle. The ionosphere bends part of the energy back toward Earth, creating regional coverage that can fill the usual “skip zone” of long-distance HF.
Typical NVIS use is not broadband. It is better suited to robust low-rate messages, emergency communication, regional coordination, and sparse telemetry.
10.4.3 When NVIS Enters Design
Do not ask “Can we use NVIS?” first. Ask whether the application has become difficult enough that normal IoT links are weak fits.
| Consider HF/NVIS when… | Prefer another option when… |
|---|---|
| The payload is tiny: status, alarms, location, battery, or compact sensor summaries | The system needs images, audio, firmware updates, dashboards with frequent refresh, or interactive control |
| The deployment needs regional coverage without towers, cellular service, or reliable line-of-sight | A private LoRaWAN gateway, cellular IoT modem, satellite modem, or mobile collector can meet the requirement simply |
| Delay of minutes or longer is acceptable | The application needs tight real-time control or low-latency command response |
| The organisation can handle licensing, antenna installation, propagation planning, and radio troubleshooting | The deployment must be maintained by non-specialists with minimal radio training |
| Field testing can be repeated across time of day, season, weather, and solar conditions | The project needs predictable performance from datasheets alone |
The useful mental model is: NVIS is a resilience and coverage tactic for unusual low-rate telemetry, not a replacement for mainstream IoT networking.
10.4.4 Ionospheric Layers
HF propagation depends on the ionosphere, which changes across the day and with solar activity.
| Layer/condition | Effect |
|---|---|
| D layer | Absorbs lower HF energy, especially during daytime |
| E layer | Can support some propagation paths but is variable |
| F layer | Main layer for many HF skywave paths |
| Nighttime | D-layer absorption reduces; lower frequencies may improve |
| Daytime | Higher absorption; usable frequency may shift upward |
| Solar storms | Can disrupt or alter propagation reliability |
Two practical concepts matter:
- MUF, Maximum Usable Frequency: above this, the ionosphere may not return the signal on the intended path.
- LUF, Lowest Usable Frequency: below this, absorption and noise may make the link unreliable.
The usable frequency lies between these limits, and that window changes over time.
10.5 Key Idea
This section: Key Idea — HF/NVIS should not be taught as “better than LoRaWAN” or “better than satellite”.
HF/NVIS should not be taught as “better than LoRaWAN” or “better than satellite”. It is a different design point: lower data rate, larger antenna, more propagation uncertainty, but potentially useful when the site has no ground infrastructure and no reliable line-of-sight path.
10.6 Weak-Signal Digital Telemetry
This section: Weak-Signal Digital Telemetry — When radio links are weak, engineers can trade speed for reliability.
When radio links are weak, engineers can trade speed for reliability.
Weak-signal telemetry uses combinations of:
- Narrow bandwidth
- Error-correcting codes
- Repetition
- Time synchronization
- Long symbol durations
- Carefully structured payloads
- Receiver-side signal processing
The result is that messages can sometimes be decoded even when the signal is near or below what a human listener would consider obvious.
10.6.1 Payload Design
Low-rate links force discipline. A good telemetry message carries only what is needed.
Example compact fields:
| Field | Purpose | Encoding idea |
|---|---|---|
| Device ID | Identify sender | Numeric index or short alphanumeric code |
| Message type | Status, alarm, test, health | 2-4 bits |
| Timestamp | Event time | Relative time or compressed epoch |
| Location | Position if needed | Quantised latitude/longitude or site index |
| Battery | Power health | 8-bit quantised voltage or percentage |
| Sensor value | Main reading | Quantised engineering value |
| Check bits | Detect corruption | CRC or protocol-level checksum |
The important question is not “how many bytes can I send?” It is “what decision can the receiver make from this message?”
10.6.2 Latency and Duty Cycle
Weak-signal and ultra-low-power systems often transmit on schedules. A message may wait until the next slot, repeat over several slots, or be acknowledged only when a gateway is available.
This is acceptable for many monitoring applications but unsuitable for tight real-time control. A system that reports a status within 15 minutes can be excellent for remote monitoring and unacceptable for machine safety.
This section:
Checkpoint: Weak-Signal Trade-Offs
You now know:
- HF usually means 3-30 MHz, with larger antennas and more variable propagation than common IoT bands.
- NVIS belongs only where tiny, delay-tolerant telemetry needs regional coverage without towers, cellular service, or line-of-sight.
- Weak-signal systems buy robustness with narrow bandwidth, coding, repetition, scheduling, and compact payloads.
This section:
10.7 Antennas in Remote Deployments
This section: Antennas in Remote Deployments — A link-budget gain value is credible only if the installed antenna preserves the assumed orientation, height, and feedline condition.
A link-budget gain value is credible only if the installed antenna preserves the assumed orientation, height, and feedline condition. Inspect Figure 10.1 before accepting that value: the radiating elements, mast clamps, exposed connector, and descending feedline turn an abstract gain entry into field evidence.
Read Figure 10.1 from the radiating elements down the mast and feedline. Their vertical orientation and height shape coverage, while clamps, cable routing, and exposed connectors introduce alignment, loss, weatherproofing, and service questions. The photograph therefore connects antenna theory to the deployment review: a catalog gain is credible only when mounting, surroundings, feedline condition, and safe access preserve it in the field.
Photo: David Jordan (derivative: Chetvorno), CC BY-SA 3.0
10.7.1 Antenna Size
A simple half-wave dipole has approximate total length:
Examples:
| Frequency | Half-wave dipole length |
|---|---|
| 5 MHz | about 28.6 m |
| 868 MHz | about 16.5 cm |
| 2.4 GHz | about 6.0 cm |
Lower frequencies can help with propagation but make installation harder because the antenna becomes a physical structure.
10.7.2 Antenna Placement
Important placement questions:
Can the antenna be installed safely by the field team? Is the antenna above ground clutter or intentionally low for the propagation mode? Will vegetation touch or detune it? Can animals, machinery, wind, or flooding damage it? Is strain relief provided? Are connectors waterproofed? Is the feedline loss acceptable? Is the antenna legal for the frequency and transmit power?
10.7.3 Matching and SWR
An antenna must be matched to the transmitter. Poor matching reflects power back toward the transmitter, reducing radiated power and potentially damaging hardware.
In field systems, matching can change due to:
- Wet vegetation
- Soil moisture
- Cable movement
- Corrosion
- Connector water ingress
- Broken insulation
- Nearby metal objects
Remote systems should report enough health information to detect radio degradation before total failure.
10.8 Power Architecture
This section: Power Architecture — Remote IoT power design is dominated by average current, not peak current alone.
Remote IoT power design is dominated by average current, not peak current alone.
Average current across a wake cycle is:
where and . Battery life is approximately:
where is battery capacity in mAh and is average current in mA.
10.8.1 Radio Energy Usually Dominates
For many battery-powered nodes, the radio is more expensive than the sensor reading. Optimisation usually focuses on:
Sleeping most of the time. Reducing connection setup time. Sending compact payloads. Avoiding unnecessary acknowledgements. Batching readings. Transmitting only on significant change. Using local storage when the link is unavailable. Selecting a communication technology that matches the payload.
10.8.2 Gateway Power Is a Separate Problem
Students often design low-power sensor nodes but forget the gateway. A gateway may need:
- Continuous receiver operation
- Larger battery capacity
- Solar panel sizing
- Local processing
- Backhaul connectivity
- Weatherproof enclosure
- Physical security
- Remote reboot capability
An end-to-end design fails if the sensor node lasts for years but the gateway fails after one cloudy week.
10.9 Architecture Patterns
This section: Architecture Patterns — Infrastructure-denied IoT systems are usually built around a few recurring patterns.
Infrastructure-denied IoT systems are usually built around a few recurring patterns.
10.9.1 Pattern 1: Private Gateway
Sensors communicate to a privately installed gateway. The gateway uses whatever backhaul is available: cellular, satellite, wired internet, long-range Wi-Fi, or manual data collection.
Use when:
- Gateway installation is possible
- Many nodes are within radio range
- The site can support gateway power
- A private LPWAN or local mesh is practical
10.9.2 Pattern 2: Store-and-Forward
Nodes store readings locally and transmit when a link becomes available. The receiver may be fixed, mobile, aerial, or temporarily deployed.
Use when:
- Delay is acceptable
- Data loss is worse than late data
- Maintenance visits or mobile collectors are part of operations
10.9.3 Pattern 3: Event-First Telemetry
The node sends important events immediately while keeping detailed data locally for later retrieval. This pattern fits deployments where most readings are routine, alarms matter more than continuous streams, and radio bandwidth is scarce. The transmitted message should carry enough information for the receiver to make the required decision, while the local record retains detail that can wait.
Immediate transmission does not establish timely arrival. Link availability, scheduled radio operation, and retries still affect delivery. Define the acceptable alarm latency and test what happens during an outage. Local logs, event timestamps, and retry counters help identify which events remain stored, which reach the receiver, and which age out with an explicit reason. Later retrieval also needs a defined custody and recovery path.
10.9.4 Pattern 4: Multi-Tier Network
Low-power nodes send data to local relays or cluster heads, which forward it using a different, longer-range technology. This pattern fits sites where direct long-range links are too expensive, local aggregation reduces traffic, and some nodes can support larger batteries or solar power. The architecture places the longer-range forwarding role at components with suitable power support.
Evaluate both the local path and the forwarding path. A working sensor node may still lose contact with the destination when a relay or gateway becomes unavailable. Power budgets should reflect each component’s role, including receiving, processing, and forwarding where applicable. Field validation should disable a relay and examine route changes, saved records, delivery latency, and operator messages to assess custody and recovery.
10.9.5 Pattern 5: Alternate Propagation Path
The system uses a communication path that avoids the main obstruction problem, such as skywave instead of terrestrial line-of-sight.
Evaluate the alternate path from obstruction to operations. Identify why the primary terrestrial route fails, confirm that the proposed propagation mode can carry the small traffic volume within its latency bound, and then check antenna, spectrum, expertise, gateway power, and monitoring requirements. Finish by naming the fallback and retest condition. The pattern advances the chapter’s narrative only when it converts a physical-path limitation into an evidence-backed service route rather than treating unusual propagation as automatic resilience.
Use when:
- Terrain and vegetation block ground links
- Traffic is very small
- Latency can be relaxed
- Legal operation and radio expertise are available
This section:
Checkpoint: Architecture and Power
You now know:
- Node lifetime depends on average current across the full wake/sleep cycle, not only peak radio current.
- The gateway needs its own power budget; a sensor that lasts for years still fails if the gateway dies after one cloudy week.
- Private gateways, store-and-forward, event-first telemetry, multi-tier relays, and alternate propagation paths fail in different ways.
This section:
10.10 Field Validation
This section: Field Validation — Evidence for Field Validation starts in Figure 10.2.
Evidence for Field Validation starts in Figure 10.2. Look at Connected vs Disconnected Networks beside CONNECTED before accepting Connected versus disconnected network paths.
Figure Figure 10.2 contrasts a current path to the gateway with a group that has no end-to-end contact. The disconnected case keeps readings locally, waits for a useful link, then transmits when delay is acceptable. That sequence does not establish that records survived or arrived in time. The field check in the figure disables a relay and asks which saved records and alarms remain. The section’s custody table adds timestamps, retry counters, queue depth, route changes, and stale-data labels at each layer. These observations show what fails during an outage and what the operator should see.
| Custody layer | Evidence to collect | Failure response to test |
|---|---|---|
| Sensor node | Local log, event timestamp, battery margin, retry counter | Hold the record locally, retry within the energy budget, or age out with an explicit reason |
| Local mesh or relay path | Neighbor table, route changes, packet delivery ratio, received signal quality | Use an alternate path, degrade to event-only telemetry, or preserve evidence until contact returns |
| Gateway or mobile collector | Uptime, queue depth, visit record, local receive log | Store queued records until backhaul returns and reconcile duplicate or late messages |
| Backhaul and dashboard | Link status, last successful delivery time, stale-data indicator | Mark the dashboard stale, keep local copies, and avoid treating silence as a safe state |
Resilience comes from diversity, not from a magic single link. A field mesh, private LPWAN, satellite terminal, mobile collector, or delay-tolerant store-and-forward path can each fail in a different way. The evidence review should therefore include representative outages: pull the backhaul, disable a relay, delay the collector, or block one radio path, then confirm which records are preserved, which alarms age out, and which operator message appears.
10.11 Question: Proving Custody During Outages
This section: Question: Proving Custody During Outages
10.11.1 What to Measure
| Metric | Why it matters |
|---|---|
| Packet delivery ratio | Basic reliability of the telemetry path |
| Received signal strength | Indicates link margin and fading patterns |
| Signal-to-noise ratio | Separates weak signal from noisy environment |
| Latency | Shows whether the application can act in time |
| Battery voltage/current | Confirms energy model under real duty cycle |
| Temperature/humidity | Explains electronics and enclosure stress |
| Retry count | Reveals hidden reliability cost |
| Missed wakeups | Indicates timing, firmware, or power faults |
| Gateway uptime | Separates node failure from infrastructure failure |
| Installation notes | Captures antenna height, orientation, and local obstructions |
10.11.2 Factorial Test Design
When several variables may matter, vary them deliberately rather than changing everything at once.
Common factors:
- Frequency band
- Transmit power
- Antenna type
- Antenna height
- Payload size
- Message interval
- Site location
- Time of day
- Weather condition
- Gateway placement
A simple test matrix can reveal whether failures are caused by power, band choice, site geometry, antenna installation, or environmental timing.
10.11.3 Failure Classification
Classify failed messages rather than counting them only as missing.
| Failure class | Evidence |
|---|---|
| Node did not transmit | No local log entry, low battery, firmware crash |
| Transmitted but not received | Node log exists, gateway has no packet |
| Received but corrupted | Gateway detects invalid checksum or partial decode |
| Gateway unavailable | Multiple nodes missing simultaneously |
| Backhaul failed | Gateway received locally but cloud did not update |
| Time synchronization failed | Slots, timestamps, or weak-signal decoding fail |
| Antenna degraded | SNR gradually falls, SWR worsens, weather correlation appears |
This separation prevents teams from blaming the wrong layer.
10.12 Technology Selection Framework
This section: Technology Selection Framework — Use the following decision logic as a starting point.
Use the following decision logic as a starting point.
10.12.1 Step 1: Is There Existing Coverage?
Begin by checking whether reliable cellular or LPWAN operator coverage exists at the deployment site and whether subscriptions are acceptable. When both conditions are met, managed connectivity may be simpler than installing private infrastructure. Evaluate reliability against the application’s payload, latency, and power requirements. Unreliable cellular attachment and repeated retries can make an otherwise simple option costly in energy.
If managed coverage is unsuitable or subscriptions are unacceptable, assess whether a private gateway can be installed and powered. Gateway feasibility includes its placement, backhaul, maintenance, and independent power budget. Sensor battery life alone does not establish a viable communication system. This initial choice sets up the next assessment of whether the site can support a suitable radio path to the gateway.
10.12.2 Step 2: Is There a Clear Radio Path?
If a gateway can be placed high enough with acceptable line-of-sight or near-line-of-sight, private LoRaWAN or another LPWAN may be appropriate.
If vegetation, terrain, or access prevents a reliable terrestrial path, consider store-and-forward, mobile collection, satellite, or alternate propagation.
10.12.3 Step 3: Is the Sky Visible?
Visible sky makes satellite IoT a candidate for sparse remote telemetry. Its suitability still depends on antenna placement, power, cost, and the application’s delivery requirements. Assess sky visibility at the intended antenna location alongside the site’s terrestrial radio limitations.
Dense canopy, buildings, or valleys can obstruct sky view. In those conditions, satellite operation may require antenna relocation, longer acquisition times, or higher power, and it may be impractical. Evaluate these demands against safe installation, the energy budget, and acceptable latency. Field measurements of delivery, latency, and battery voltage or current help assess the proposed arrangement. If satellite remains a weak fit, the broader architecture can consider store-and-forward, mobile collection, or an alternate propagation path.
10.12.4 Tiny, Delay-Tolerant Payload?
Compact status or event messages make very low-rate communication options possible when the application can tolerate delay. Define the smallest payload that supports the receiver’s decision and the latency within which that decision remains useful. Small messages and relaxed timing provide room to use weak-signal techniques that trade speed for reliability, but tight real-time control remains a poor fit.
If the system needs images, audio, firmware updates, or interactive control, pair the low-rate link with local storage or a second retrieval channel. The architecture must account for these requirements alongside compact telemetry. Stored information needs a custody and recovery plan, while any second channel needs operational support. Evaluate the complete arrangement against payload, timing, power, and field delivery evidence.
10.12.5 Can Operations Sustain It?
A technically elegant radio link is not enough. Ask:
Who installs antennas? Who checks spectrum licensing? Who replaces batteries? Who diagnoses failures? Who owns the gateway? Who pays subscriptions? Who receives alerts? Who responds when telemetry stops?
The correct IoT design is the one the organisation can sustain.
10.13 Remote Environmental Alert Node
This section: Remote Environmental Alert Node — Scenario: A protected wetland needs low-cost water-level alerts from five sites.
Scenario: A protected wetland needs low-cost water-level alerts from five sites. There is no mains power and unreliable cellular coverage. Staff can visit once every three months. Each site needs to report only water level state, battery health, and a device health flag.
10.13.1 Requirement Summary
| Requirement | Value |
|---|---|
| Payload | Under 30 bytes |
| Message interval | Every 30 minutes, plus immediate threshold alert |
| Latency | 5-30 minutes acceptable |
| Lifetime | 3 months minimum without visit |
| Direction | Mostly uplink |
| Data type | Status and alert telemetry, not raw waveform |
10.13.2 Candidate Designs
| Design | Fit | Risk |
|---|---|---|
| Cellular node | Simple if coverage exists | Unreliable attach; high energy during retries |
| Private LoRaWAN gateway | Good if gateway can see sites | Gateway power and placement required |
| Satellite IoT | Wide coverage | Sky view, cost, power, antenna placement |
| Local logger only | Very robust locally | No timely alerts |
| HF/NVIS or another ultra-low-rate alternate radio | Good for tiny messages where ground paths, cellular, and satellite are weak fits | Requires specialist radio design, antenna planning, field validation, and legal checks |
10.13.3 Engineering Lesson
The application needs dependable delivery of small status and alert messages rather than high throughput. Link margin matters because weak signals and changing field conditions can make reception unreliable. Gateway availability matters because a functioning sensor cannot complete delivery through an unavailable gateway. The power budget must cover the node’s wake and sleep cycle, retries, and the gateway’s separate requirements.
Health reporting should help operators distinguish battery, radio, gateway, and backhaul problems. Installability connects antenna assumptions to safe mounting, feedline condition, and practical maintenance access. Operational response completes the design: someone must receive alerts, diagnose missing telemetry, and arrange repairs. Evaluate these priorities together against the required delivery delay and the interval between site visits.
10.14 Infrastructure-Denied Design
This section: Infrastructure-Denied Design — Use this checklist before committing to hardware.
Use this checklist before committing to hardware.
10.14.1 Application
Begin with the decision the receiver must make, then identify the smallest payload that supports it. Compact status, event, battery, and device health information may be sufficient when detailed sensor records are unnecessary for the immediate decision. Payload selection should preserve the information needed to interpret the report, including sender identity and measurement time where required.
Define acceptable latency before selecting the communication path. Scheduled transmissions, repeated attempts, and waits for gateway contact can suit monitoring while being unsuitable for tight real-time control. Decide which readings need prompt transmission and which can remain in local storage for later retrieval. Where delivery is delayed, check that records remain available and that their age is visible when they reach the receiver.
10.14.2 Radio
What is the link budget with conservative fade margin? What frequency bands are legal at the deployment site? What antenna can be installed safely and repeatedly? What happens after rain, vegetation growth, and connector aging? How will interference and noise floor be measured?
10.14.3 Power
Estimate average current across the complete wake and sleep cycle, using both current and time in each state. Battery lifetime depends on this average, so peak transmit current alone is insufficient for the estimate. Include connection setup and retry behavior, and check the worst-case current during retries. Compare the energy model with measured battery voltage and current under the deployed duty cycle.
Review operation during cloudy weeks and cold conditions rather than relying only on favorable field conditions. Give the gateway an independent power budget that reflects its receiver operation, processing, and backhaul needs. A long-lived sensor node still depends on gateway availability for delivery. Check whether node and gateway power can support the required interval between maintenance visits.
10.14.4 Operations
Assign responsibility for installing and maintaining each component before deployment. The visit schedule should be explicit because battery replacement, antenna servicing, and repairs must fit the site’s access constraints. Include a replacement plan for damaged enclosures, cables, and batteries, and identify who responds when telemetry stops.
Choose remote health information that supports diagnosis between visits. Battery measurements, retry counts, gateway uptime, local receive logs, and the last successful delivery time help distinguish failures at different layers. Classify a missing report by whether the node transmitted, the gateway received it, or the backhaul delivered it onward. Define who receives and escalates each failure, and what response follows. During outage tests, check that stale data and operator messages are visible.
10.15 Knowledge Check
This section: Knowledge Check
10.16 Choosing Connectivity Strategy
This section: Choosing Connectivity Strategy
10.17 Question: Why Low Data Rate Can Help
This section: Question: Why Low Data Rate Can Help
10.18 Summary
This section: Summary — Infrastructure-denied IoT is about sustaining a complete communication system under physical, energy, regulatory, and operational constraints.
Infrastructure-denied IoT is about sustaining a complete communication system under physical, energy, regulatory, and operational constraints. The main lesson is not that one technology is best. The lesson is that remote IoT requires disciplined requirement definition, link-budget thinking, power modelling, antenna planning, field validation, and operational ownership.
When the payload is small and latency can be relaxed, engineers gain design freedom. They can choose private LPWAN, satellite, store-and-forward, mobile collection, mesh, or specialist radio paths. The correct choice is the one that delivers the required decision-quality information with enough margin to survive the real deployment environment.
10.19 Key Takeaway
This section: Key Takeaway — Infrastructure-Denied IoT Connectivity should treat people, delay, consent, data quality, custody, privacy, intermittent connectivity, and deployment evidence as part of the sensing architecture.
Infrastructure-Denied IoT Connectivity should treat people, delay, consent, data quality, custody, privacy, intermittent connectivity, and deployment evidence as part of the sensing architecture.
10.20 What to Read Next
This section: What to Read Next
| Next topic | Why it matters |
|---|---|
| LPWAN Link Budget and Range | Learn the quantitative range calculations behind low-power wide-area links |
| LPWAN Technology Selection | Compare LoRaWAN, Sigfox-style networks, NB-IoT, and LTE-M |
| WSN Deployment and Sizing | Convert coverage requirements into node, gateway, and cost estimates |
| WSN Energy Management | Model duty cycle, sleep current, and battery lifetime |
| Human-Centric Sensing and DTN Review | Understand store-and-forward operation when continuous connectivity is unavailable |
| Energy-Aware Case Studies | Study practical energy failures and optimisations |
Find help
3 reviewed answers.
Where should I start in a module?
Open the module page from the sidebar to see its chapters in order. Use the module map to return to a topic you need.
Modules and pathsReviewed
What can I try when a project does not work?
Check the symptom, then work through the diagnostic steps. Keep the error message and the smallest example that reproduces it.
When you are stuckReviewed
How do interactive examples work?
Use the interactive guide to check how examples and simulations work before changing your project.
Interactive examples guideReviewed