Iridium Short Burst Data: service guide
Understand the SBD messaging role, then specify the terminal, payload, power, antenna, delivery and commercial evidence for a remote-device pilot.
By Admin · Checked 20 October 2026.
Iridium describes Short Burst Data as a packet-based service for frequent short transmissions between equipment and a host system, with two-way messaging. This is a messaging-service profile, not a broadband substitution or a measured reliability review.
Start with three decisions
Define the message
Write down every field, its encoded size, reporting interval and delivery deadline. Ask the service provider to confirm terminal-specific uplink/downlink limits and allowance calculations.
Specify the installed system
Resolve the exact SBD terminal/module, firmware, antenna, mounting, sky view, supply and application interface. The service family alone is not a complete bill of materials.
Confirm the market and contract
Obtain the service provider’s written deployment-country confirmation and quote. Global portfolio language does not replace local authorization, provisioning or installation checks.
Specify and validate the service
A remote observation, end to end
Example pilot: report a timestamped tank-level observation with battery status and sequence number. Define the useful action when the latest observation is late. Preserve the sensor reading even if the first delivery attempt fails. This is a proposed test, not a customer deployment.
Payload and timing worksheet
Record encoded bytes per message, direction, reporting interval, alarms, retries and acknowledgement behavior. Obtain the exact terminal/service documentation for maximum message size and timing. No universal numeric payload or latency promise is assigned here.
Power and antenna checks
Document idle and transmission behavior with the chosen terminal and supply. Include installation restrictions, cable losses and expected obstructions in the provider brief. Measure the actual installation through normal operation and a defined outage/recovery test.
Commercial and operational boundaries
Quote terminal, antenna, activation, subscription, included messages/bytes, billing units, overage, host integration and support. Ask how queued/downlink messages expire and how the fleet is suspended or moved. Treat missing information as an open question.
Read service claims as claims
The source is the service provider’s description. IoTPapa has not measured message delivery, battery life, weather tolerance or availability. A two-way capability does not itself establish a safe remote-control design.
Finish the pilot with evidence
Compare the original observation timestamps with delivery and acknowledgement records. Review missing, duplicated and stale messages. Sign off the application’s fallback and manual response before expanding the fleet.
Primary sources
Continue with your next decision

NEXT DECISION
Explore satellite and space IoT
Review direct access, backhaul and data roles.


NEXT DECISION
Prepare a service cost model
Include message allowances and integration.
