Part 1 was about format size — CAP, JSON, and ECP side by side. Read it here if you missed it.

This post is about LoRaWAN: one uplink, a hard byte ceiling, and what happens when your alert payload was written for HTTP.

I'm on the Egonex team. We built ECP after measuring our own emergency traffic. The numbers below are from the public spec and from stacks we run in test — not a thought experiment.

The frame budget

On LoRaWAN, the application payload is small. At conservative settings — EU868, SF12, DR0 — you often get about 51 bytes of application payload per frame. Faster data rates give you more room. SF12 is still the mode people use when coverage is bad.

A typical emergency alert in JSON is about 270 bytes. CAP XML is 669 bytes.

JSON does not fit in one LoRaWAN frame at DR0. CAP needs several frames or a different path.

That is the trade-off: one uplink now vs split, queue, reassemble, and hope nothing drops on the way.

Three ways teams handle it

1. Fragment the message. Split JSON across uplinks, reassemble server-side. Fine when the stack is mature and latency is not critical. On an alert path, every extra frame is another failure point.

2. Strip to codes. Type ID, zone ID, timestamp in a home-grown binary layout. Small on the wire. You own the schema forever, and every integrator needs your PDF.

3. Use a published binary format. Fixed layout, public spec, test vectors. ECP is what we use. You may choose differently — the point is to design for the frame budget, not gzip JSON and pray.

One frame, fixed layout

ECP's smallest alert is a Universal Emergency Token (UET): fixed size, big-endian on the wire, no field names.

Sender and receiver share the layout — struct semantics, not a self-describing document.

The UET fits in a single DR0 frame with bytes left for FPort overhead or a thin wrapper.

Need human-readable text or integrity on an untrusted link? Use a signed envelope: 22-byte fixed header + payload + truncated HMAC-SHA256 (tag usually 8–16 bytes; our SDK defaults often use 12). Structured alerts typically land in 45–100 bytes. At DR0/SF12, only the lower end of that range fits one frame; higher data rates give more headroom. Still well under JSON either way.

Exact sizes: wire-format.md and the repo test vectors.

LoRa carries bytes. It is not "ECP transport."

LoRaWAN is the radio. ECP is the application payload.

We ship WebSocket and SignalR adapters as NuGet packages. For MQTT, CoAP, or LoRaWAN there is no special plugin — you drop ECP bytes into whatever your stack already sends.

One encoding layer, several carriers. That split is deliberate.

Code: one frame, one alert

.NET 8 + ECP.Core:

using ECP.Core;
using ECP.Core.Models;

byte[] alert = Ecp.Alert(EmergencyType.Fire, zoneHash: 42, priority: EcpPriority.Critical);
// Fits in one LoRaWAN frame at DR0 — check alert.Length on your build

Put alert in your FRMPayload. Decode on the gateway or in your network-server hook:

if (Ecp.TryDecode(incomingBytes, out var message) && message.IsUet)
{
    var token = message.Token;
    // EmergencyType, Priority, ZoneHash, TimestampMinutes
}

Text plus signature:

byte[] hmacKey = LoadKeyFromSecureStorage(); // 32-byte key — your storage problem

var envelope = Ecp.Envelope()
    .WithType(EmergencyType.Earthquake)
    .WithPriority(EcpPriority.Critical)
    .WithPayload("Evacuate zone 4 via stair B")
    .WithHmacKey(hmacKey)
    .Build();
// Typical: 45–100 bytes — measure envelope.Length before you commit

Payload size depends on content and HMAC tag length. Measure; do not trust a blog post.

Check it yourself

git clone https://github.com/Egonex-Code/ecp-protocol.git
cd ecp-protocol/samples/ProofCard
dotnet run

-- --show-payload prints CAP, JSON, and ECP side by side. benchmarks/ECP.PublicBenchmarks reports throughput and allocations on your machine — relevant if you decode at the gateway.

In internal testing of our emergency platform, ECP handled 263,000+ system events (monitoring, ops traffic, integration tests). That is not "millions of LoRa nodes in the wild." Real lab and pre-production load. Your sensor path will differ.

What we are not claiming

• ECP is not a LoRaWAN stack, join server, or network-server replacement.
• It is not CAP for every scenario. Reliable IP + full CAP interop → use CAP.
• A minimal token carries machine fields, not a paragraph. Zone names and templates live on the receiver.

Related reading

• Part 1 — format comparison (CAP / JSON / ECP)
• GitHub — ecp-protocol
• Wire format specification

Question: On LoRa you've actually shipped — fragment JSON, roll your own binary, or something else? What broke in production?

Star on the repo if you want the next person searching "LoRa emergency payload" to find the spec.