Point-to-Point LoRa Telemetry with the SX1262: RadioLib, Packet Design, and When to Skip LoRaWAN

LoRaWAN gets most of the attention in maker LoRa content because it's what The Things Network and Meshtastic are built on, but a huge share of real LoRa use cases don't need a network server, gateway infrastructure, or a mesh protocol at all — they just need one sensor node to reliably get a small packet of data to one receiver, a kilometer or three away, on battery power that lasts months. That's point-to-point LoRa: using the SX1262 radio directly, with a library like RadioLib, without LoRaWAN's join procedure, frame counters, or network server in the loop. It's simpler to set up, has less protocol overhead, and is the right choice for a huge fraction of remote-sensor and simple-telemetry projects that get needlessly complicated by LoRaWAN's infrastructure requirements.

When Point-to-Point Beats LoRaWAN

LoRaWAN earns its complexity when you need many independent nodes sharing infrastructure — a gateway serving dozens of sensors across a property, integration with a public network, or over-the-air data going straight into a cloud dashboard via The Things Network. Point-to-point LoRa is the better fit when you have one or a handful of nodes talking to one receiver you control directly: a remote soil moisture sensor reporting to a base station on your porch, a mailbox or gate sensor talking to a receiver inside the house, or a simple wireless weather station where you're already running the receiving Raspberry Pi or ESP32 yourself and don't need a network server as a middleman. Skipping LoRaWAN removes the join procedure, application server, payload decoder configuration, and duty-cycle/frame-counter bookkeeping — you're just sending bytes over the air and reading them on the other end, closer to how nRF24L01 or ESP-NOW work, but with LoRa's dramatically longer range.

Hardware and Library Setup

The SX1262 (found on boards like the Heltec WiFi LoRa 32 V3, many RFM95-successor breakouts, and standalone SX1262 modules) is the modern successor to the SX1276 used in most older LoRa tutorials, with better sensitivity and lower current draw. RadioLib is the library to use for point-to-point work on both ESP32 and Arduino targets — it supports the SX1262 directly and exposes the raw LoRa PHY layer without forcing you into a LoRaWAN stack, unlike some LoRaWAN-focused libraries that make bare point-to-point awkward to get to.

A minimal working pair needs: an SX1262 module wired via SPI (MOSI, MISO, SCK, NSS/CS) plus a few GPIO lines for RESET, BUSY, and DIO1 (interrupt), a matched antenna for your radio's frequency band (868MHz in most of Europe, 915MHz in North America — using the wrong band antenna will tank your range even if the radio itself is configured correctly), and RadioLib initialized with matching LoRa parameters on both ends.

Configuring LoRa PHY Parameters

Every parameter has to match between transmitter and receiver, and the settings trade range against data rate and airtime:

ParameterEffectTypical Long-Range Sensor Setting Spreading Factor (SF7-SF12)Higher SF = longer range and better sensitivity, but much longer airtime per packet and lower data rateSF9-SF11 for a few km with small payloads Bandwidth (7.8-500kHz)Narrower bandwidth = longer range, more susceptible to timing/frequency drift125kHz is the standard balance Coding Rate (4/5-4/8)Higher coding rate = more forward error correction overhead, better reliability in noisy RF environments4/5 for clean links, 4/7-4/8 for noisy or marginal links TX PowerHigher power = longer range, more current draw, and region-specific legal limitsMaximum allowed for your region if battery budget allows

A practical starting point for a battery sensor node sending small payloads a few times an hour over 1-5km line-of-sight is SF9, 125kHz bandwidth, coding rate 4/5, and maximum legal TX power for your region. Push spreading factor higher (SF10-SF12) if you need more range and can tolerate airtime of a second or more per packet and correspondingly lower duty cycle.

Packet Design for Reliability

Without LoRaWAN's built-in frame counters and acknowledgment handling, you need to build a small amount of reliability into your own packet format if the link matters:

• A simple sequence number in every packet lets the receiver detect missed transmissions and, if you're logging data, spot gaps rather than silently missing them.
• A short packet checksum or CRC (RadioLib and most radio hardware can supply CRC support directly) catches corrupted packets so the receiver doesn't act on garbled data — LoRa's forward error correction handles a lot of noise, but a validated CRC is your fallback for packets it can't fully recover.
• Optional acknowledgment. For anything where a missed packet matters (an alert or trigger, versus a periodic sensor reading you can afford to lose occasionally), have the receiver send a short ACK packet back and have the transmitter retry on a timeout with backoff. This adds complexity and airtime but turns an unreliable one-way broadcast into something closer to guaranteed delivery.
• Duty cycle awareness even without LoRaWAN's enforcement. Many regions have legal duty-cycle limits (1% is common in the EU 868MHz ISM band) regardless of whether you're using LoRaWAN's protocol — the airtime restriction is a radio-spectrum regulation, not a LoRaWAN-specific rule, so check your local regulations and keep transmission time within them.

Power and Range Expectations

An SX1262 in deep sleep between transmissions draws low enough current that a battery-powered sensor node sending short packets every few minutes to hourly can realistically run for many months on a single 18650 cell or a small LiFePO4 pack, especially paired with an ESP32's own deep sleep mode between radio events (see the site's ESP32 deep sleep guide for the microcontroller side of that power budget). Real-world range varies enormously with terrain and antenna placement — line-of-sight rural conditions with a decent antenna and SF10+ can reach several kilometers, while the same setup in a suburban area with buildings and trees in the path might only manage a few hundred meters to a kilometer. Treat published "LoRa range" numbers as best-case line-of-sight figures and test your actual link budget on site rather than assuming a spec sheet number will hold in your terrain.

Point-to-point LoRa with the SX1262 and RadioLib gets you nearly all of LoRa's range advantage over WiFi and Bluetooth without needing a gateway, a network server account, or LoRaWAN's join and frame-counter bookkeeping. It's the right tool for the very common case of one or two remote nodes reporting to a receiver you already control — save LoRaWAN and its infrastructure for when you're actually building out a multi-node network that benefits from shared gateway coverage and centralized data handling.