How Do You Use LoRa Point-to-Point Without LoRaWAN?

Detailed Explanation

Every page in this cluster so far assumes a LoRaWAN network stack: OTAA join, a gateway, a network server, and a defined device class. That's the right architecture for wide-area telemetry feeding into a backend, which is what most commercial LoRa deployments are for. It's the wrong architecture for a closed pair of devices that just need to talk to each other directly, where LoRaWAN's gateway/network-server infrastructure and duty-cycle-driven design constraints solve a problem the application doesn't have.

LoRa itself, separate from LoRaWAN, is a chirp spread-spectrum modulation scheme implemented in silicon by the SX1262/SX1276-class transceivers already covered in SX1262/SX1276 hardware design. The radio IC has no idea whether the bytes it's sending are a LoRaWAN frame or something else entirely. Driving that same radio hardware directly, setting spreading factor, bandwidth, coding rate, sync word, and preamble length through the IC's own configuration registers, produces a private link with LoRa's long-range, low-power physical-layer characteristics but none of LoRaWAN's network-layer machinery.

What Changes Without LoRaWAN

A point-to-point design still uses the same radio, the same modulation, and largely the same RF hardware design as a LoRaWAN device. What's absent is everything LoRaWAN's protocol layer normally provides:

• No gateway or network server. Both ends of the link talk to each other directly; there's no intermediate infrastructure to deploy, maintain, or pay a network-server subscription for.
• No OTAA/ABP join procedure or session-key derivation. Any addressing, authentication, or encryption scheme has to be designed and implemented in application firmware.
• No standardised device class (A/B/C) behaviour. The receive-window timing, duty-cycle-driven sleep pattern, and downlink scheduling that LoRaWAN device classes define are a LoRaWAN concept; a point-to-point link's RX/TX timing is whatever the firmware designer implements.
• No LoRa Alliance regional parameters enforcement. A LoRaWAN stack bakes in the channel plan and duty-cycle limits for a given region (AU915, for example); a point-to-point design still has to comply with the underlying ISM-band regulations, just without a stack automatically enforcing them.

What remains is the physical-layer link budget and range advantage LoRa is chosen for in the first place: the same spreading-factor-driven trade-off between range, data rate, and airtime, and the same sensitivity and link-budget characteristics of the SX1262/SX1276 silicon, independent of which protocol layer (if any) sits on top.

Sync Word: The One Setting That Actually Matters for Coexistence

One configuration detail deserves explicit attention because it's easy to get wrong silently: the LoRa sync word. Semtech reserves a private sync word value (0x12) distinct from the public LoRaWAN sync word (0x34). A point-to-point design not intending to share spectrum with LoRaWAN traffic should use the private sync word, both because it's the semantically correct choice for a non-LoRaWAN link and because some regional LoRaWAN gateway firmware filters incoming packets by sync word, meaning a point-to-point device accidentally left on the public sync word can have its packets picked up (and potentially logged or flagged) by nearby LoRaWAN gateways it was never meant to talk to.

Practical Examples

A pair of devices exchanging status over a few hundred metres, for example a remote sensor and a base station in a location with no cellular coverage and no interest in cloud connectivity, is a straightforward point-to-point case: both ends run identical radio configuration, one initiates a transmission on a timer or event, the other listens and responds. Libraries like RadioLib (widely used with Arduino and PlatformIO) expose the SX1262/SX1276's physical-layer transmit/receive functions directly, without requiring a LoRaWAN stack, making this a comparatively small firmware task once the RF hardware from the SX1262/SX1276 hardware guide is in place.

A star topology, one base station receiving from several remote nodes on a shared channel, extends the same pattern but needs the application firmware to handle what LoRaWAN's MAC layer would otherwise provide: a lightweight addressing scheme so the base station knows which node sent a given packet, and a collision-avoidance or scheduling strategy (since raw LoRa has no built-in listen-before-talk or slotting mechanism beyond what the firmware designer adds) to keep multiple nodes from colliding when transmitting on the same channel at the same time.

Design Considerations

• Choose point-to-point deliberately, not by default, before designing around it. If the application genuinely needs wide-area coverage feeding into a cloud backend, LoRaWAN with a TTN gateway is almost always the better-supported, lower-maintenance path; building and maintaining a custom protocol on raw LoRa is a real, ongoing firmware cost that only pays off when the LoRaWAN architecture genuinely doesn't fit (no gateway coverage, sub-second latency requirements a LoRaWAN receive-window model can't meet, or a fully closed system with no interest in network-server infrastructure).
• Design the addressing and retry scheme up front, since nothing provides it by default. A LoRaWAN stack's frame counter, acknowledgement, and retry behaviour don't exist on a raw link; a point-to-point design needs an explicit packet format (source/destination identifiers if more than two devices are involved, a sequence number, and an application-level acknowledgement scheme) designed before firmware, not bolted on after a field failure reveals its absence.
• Implement encryption deliberately if the link carries anything sensitive. LoRaWAN's AES-128 payload encryption doesn't carry over automatically; a point-to-point design handling anything beyond non-sensitive telemetry needs its own symmetric-key encryption scheme and a defined key-provisioning process, since there's no OTAA join to derive one during commissioning.
• Confirm regulatory duty-cycle and power limits independently. Without a LoRaWAN stack's regional parameters enforcing them automatically, a point-to-point design operating in a duty-cycle-limited ISM band has to look up and implement the applicable limit itself; see the RF hardware guide's certification considerations, and confirm the specific band's rules with the relevant regulator (ACMA for Australia) rather than assuming LoRaWAN's built-in behaviour still applies.
• Custom radio protocol design: designing the addressing, retry, and security scheme for a point-to-point or private star LoRa network, and validating the RF hardware and firmware together, is exactly the kind of custom radio product work Zeus Design's team supports alongside standard LoRaWAN product development.

Common Mistakes

• Leaving the sync word at the public LoRaWAN value (0x34) on a design that was never meant to be a LoRaWAN device. This is easy to miss because it doesn't cause an obvious failure. It just risks unintended interaction with nearby LoRaWAN gateway infrastructure, and it's the wrong semantic choice for a link that isn't actually LoRaWAN traffic.
• Underestimating the firmware effort of replacing what LoRaWAN's MAC layer provides for free. Addressing, retry, acknowledgement, encryption, and channel/duty-cycle management all have to be designed and tested from scratch; teams sizing a point-to-point project against "just configure the radio and send bytes" routinely underestimate the actual scope.
• Copying spreading factor, bandwidth, and coding rate settings from a LoRaWAN regional parameters table without understanding what they trade off. Those values are tuned for LoRaWAN's specific range/airtime/regulatory-duty-cycle balance; a point-to-point link with different latency, range, or power requirements may need a genuinely different spreading factor and bandwidth choice, not the LoRaWAN default.
• Assuming a point-to-point link is exempt from the ISM-band regulations LoRaWAN devices comply with. The regulatory constraint attaches to the radio spectrum and hardware, not the protocol layered on top of it; skipping LoRaWAN doesn't skip the underlying duty-cycle or power-limit compliance obligation.