SX1262 LoRa Library for Proteus V1.1: two Arduino Mega 2560 boards with Ebyte E22-900M22S modules, the SX1262 Advance pop-up with its Radio page and the TEP Serial Monitor in its Simple interface

SX1262 LoRa Library for Proteus V1.1 (E22 + Arduino Mega)

2.5K Views
40
700
60
25
60
PCBWay

Hello friends, I hope you all are doing great. Today, I am going to share the new SX1262 LoRa Library for Proteus V1.1. The SX1262 is Semtech's newer LoRa chip, and the green Ebyte E22-900M22S module with its rubber-duck antenna is a favourite for long-range sensors at 868 and 915 MHz. With this SX1262 LoRa Library for Proteus, two modules in one design talk over a simulated LoRa air, and your Arduino drives them over SPI with the same RadioLib library you use on real hardware.

Version 1.1 replaces the first version of this post. You now get two devices: SX1262 Simple, with its control panel on the schematic, and SX1262 Advance, with a pop-up window and four measured LoRa test tools. The new SX1262 Arduino Proteus demo has two Arduino Mega 2560 boards that send packets, PING each other and reach 5 km with a higher spreading factor, shown in the compact Simple interface of our TEP Serial Monitor. Have you read version 1.0? Then jump to "What's New" below.

NOTICE: This library is very special to our team. Our SX1262 model speaks the chip's SPI command interface, holds the BUSY pin like the real chip, sends every packet with its real LoRa time on air and works out the RSSI and SNR at every distance. It took our team a lot of hard work, many test runs and many design changes. Your feedback is the fuel that keeps us going, so please tell us what you think in the comments below or in the SX1262 Library board of our forum. And if our free libraries help you, you can buy us a coffee. So, let's get started with the SX1262 LoRa Library for Proteus:

SX1262 LoRa Library for Proteus V1.1: two Arduino Mega 2560 boards with Ebyte E22-900M22S modules, the SX1262 Advance pop-up with its Radio page and the TEP Serial Monitor in its Simple interface
Figure: The SX1262 demo in Proteus 8.5: NODE 1 (Simple) sends, NODE 2 (Advance) receives at -77 dBm, the Radio page and Serial Monitor U4 in the Simple interface.

What is the SX1262 LoRa Module?

The SX1262 is a LoRa radio transceiver (it sends and receives) made by Semtech. It tunes from 150 to 960 MHz, so one chip covers the 433, 868 and 915 MHz bands, and it sends with up to +22 dBm. LoRa trades speed for range: a few bytes per second travel several kilometres, which is why LoRa runs farm sensors, meters and LoRaWAN gateways. The Arduino talks to the chip over SPI, plus three pins: BUSY (ready or not), DIO1 (packet done) and NRESET.

Our part looks like the Ebyte E22-900M22S: a green 20 x 14 mm module with a silver can, a TCXO as its clock and an IPEX antenna socket. RadioLib's default setting, a TCXO powered from the chip's DIO3 pin, matches this module.

The SX1262 at a Glance

SX1262 in numbers
FeatureValue
Frequency range150 - 960 MHz without a gap (RadioLib refuses other values); the E22-900M22S is built for 868 / 915 MHz
LoRa settingsSpreading factor SF5 - SF12, bandwidth 7.8 - 500 kHz, coding rate 4/5 - 4/8
TX power-9 to +22 dBm; the demo uses +14 dBm (25 mW)
Sensitivity (our model, 125 kHz)-119.5 dBm at SF5, -124.5 at SF7 (the panel rounds it to -125), -129.5 at SF9 and -137 dBm at SF12
BufferA 256-byte data buffer for the packets sent and received
ControlSPI commands (opcodes), the BUSY pin, DIO1 interrupts and NRESET
ClockA 32 MHz reference; on the E22, a TCXO powered from DIO3
Supply1.8 - 3.7 V; the pins are NOT 5 V tolerant

SX1262, SX1278, RFM95W, CC1101 or nRF24L01: Which Library Do You Need?

Our RF libraries for Proteus
Your moduleWhat it doesOur library
SX1262 (Ebyte E22-900M22S, rubber duck)150 - 960 MHz LoRa up to +22 dBm, SPI commands + BUSY, RadioLibThis article
SX1278 / Ra-02433 MHz LoRa, SPI registers, arduino-LoRaSX1278 LoRa Library for Proteus
RFM95W868 / 915 MHz LoRa (SX1276), SPI registers, arduino-LoRaRFM95W LoRa Library for Proteus
CC1101315 / 433 / 868 / 915 MHz FSK and OOK remote codes, SPICC1101 Library for Proteus
RFM69HCWSub-1 GHz FSK with ACKs, SPIRFM69HCW Library for Proteus
nRF24L012.4 GHz, SPI, short rangenRF24L01 Library for Proteus
HC-12433 MHz wireless serial module (UART)HC-12 Library for Proteus

All of them are compared in our RF Module Libraries for Proteus roundup.

Radio Terms You Will See in This Article

Radio terms
TermMeaning
LoRaSemtech's long-range modulation: every symbol is a chirp, a sweep across the whole bandwidth
Spreading factor (SF)SF5 - SF12: each step doubles the length of a chirp, and the receiver can decode a signal 2.5 dB weaker
Bandwidth (BW)The width of the chirp, 125 kHz in the demo: half the bandwidth means 3 dB less noise but twice the time
Coding rate (CR)Error correction: 4/5 sends five bits for every four data bits
SymbolOne chirp: 2^SF / BW, so 1.024 ms at SF7 and 125 kHz
dBmPower compared to 1 mW: 0 dBm = 1 mW, +14 dBm = 25 mW, +22 dBm = 158 mW; every 10 dB is a factor of 10
RSSIReceived Signal Strength Indicator: the level of the last packet in dBm
SNRSignal-to-noise ratio: how far the packet stood above (or below!) the noise, in dB
SensitivityThe weakest signal the receiver can still decode at its SF and bandwidth
Sync wordA network ID in every packet: 0x12 (private) on the SX127x, stored as 0x1424 on the SX1262
Preamble, header, CRC8 up-chirps that wake the receiver, a header with the length and coding rate, and a check value that reveals damaged packets
TCXOTemperature-compensated crystal oscillator: a clock that stays on frequency in heat and cold
BUSYAn output of the SX1262: HIGH while the chip is working on a command
DIO1The interrupt output: TX done, RX done, timeout
Time on airHow long one packet occupies the channel
Duty cycleThe share of time a transmitter is on the air; Europe allows 1 % at 868.0 - 868.6 MHz
LDROLow data rate optimisation, switched on for very long symbols (16 ms and more)

How Two SX1262 Radios Talk: LoRa, Commands and the BUSY Pin

The sketch only hands RadioLib a message, and the chip does the radio work. One packet, step by step:

  1. RadioLib's transmit() puts the chip into standby and writes the message into its 256-byte buffer.
  2. The command SetTx starts the transmitter: the chip starts its TCXO (5 ms) and ramps up its power amplifier (200 us).
  3. The packet goes out: 8 preamble chirps with the sync word, the header, the message and a 2-byte CRC, 1.024 ms per symbol at SF7 and 125 kHz.
  4. The chip raises DIO1 (TX done), and transmit() returns.
  5. A receiver with the same frequency, SF, bandwidth and sync word checks the CRC, stores the message and raises its own DIO1 (RX done); the Mega's INT0 sets a flag, and the sketch calls readData().

Notice what is missing: an ACK. The sender never learns whether anybody heard it. The PING and PONG of the v1.1 demo show how to add a reply.

Spreading Factor and Range: Why SF9 Reaches 5 km

The level at the receiver is the TX power minus the path loss. Our model uses free-space loss up to 1 m and a path-loss exponent of 3.0 beyond it, like a built-up area. A LoRa receiver compares that level with the noise, -117 dBm in a 125 kHz channel, and each SF needs a minimum SNR: -7.5 dB at SF7, -12.5 dB at SF9, -20 dB at SF12. With the demo's +14 dBm:

  • 100 m: -77 dBm, far above the noise: OK.
  • 2 km: -116 dBm, only 0.8 dB above the noise, and SF7 still decodes it.
  • 5 km: -128 dBm, an SNR of -11.2 dB, below the noise: too weak for SF7, OK for SF9.

A longer chirp collects more energy, so the receiver can pull the signal out from below the noise. The price is time: a 12-byte packet takes 41.2 ms at SF7, 144.4 ms at SF9 and 1155.1 ms at SF12.

Bandwidth and Coding Rate

250 or 500 kHz is faster than the demo's 125 kHz but lets in 3 dB more noise per step. The coding rate 4/5 adds one check bit to every four data bits. Both nodes need the same SF and bandwidth.

RSSI and SNR: Two Different Numbers

The RSSI says how strong a packet was, the SNR how far above the noise it stood; a negative SNR is normal for LoRa at long range. The SX1262's RSSI scale ends at -127.5 dBm, while the SNR keeps falling, and our model caps the SNR at +10 dB. For weak links, watch the SNR.

Commands Instead of Registers: SPI and the BUSY Pin

The older SX1276 / SX1278 (our Ra-02 and RFM95W libraries) are run through registers: the Arduino writes a value to an address. The SX1262 takes commands: an opcode plus parameters, such as SetRfFrequency, SetTx or GetPacketStatus, each answered with a status byte. While the chip works on a command, boots or starts its TCXO, it holds BUSY HIGH, and RadioLib waits for LOW before every command. Leave the BUSY wire open, and begin() fails. Our model holds BUSY with real timing.

The TCXO on DIO3

A TCXO (temperature-compensated crystal oscillator) stays on frequency where a plain crystal drifts. The E22 powers it from the SX1262's DIO3 pin, and the chip waits 5.00 ms for it to settle before it sends. RadioLib's begin() assumes this TCXO; a module with a plain crystal needs a TCXO voltage of 0.

Sync Word: 0x12 Becomes 0x1424

A receiver accepts only packets with its own sync word. The SX127x uses one byte, 0x12 for private networks; the SX1262 stores the same word as two bytes, 0x1424. So an SX1262 and an SX127x module with matching settings understand each other.

What's New in SX1262 LoRa Library for Proteus V1.1

If you used version 1.0, here is what has changed:

  • Two devices in TEPSX1262.LIB: SX1262 Simple (SX1262TEP, the v1.0 device, so old designs keep working) and SX1262 Advance (SX1262ADVTEP) with a pop-up window.
  • A redrawn board: the Ebyte E22-900M22S look with an SMA rubber duck instead of v1.0's generic board; the 9 pins stay where they were.
  • A live antenna and three LEDs: the duck lights orange while sending and green while receiving. PWR, TX and RX are a TEP addition: the real E22 has no LEDs.
  • Close and reopen: a red X and a PANEL button on the Simple, OPEN PANEL on the Advance.
  • Four measured test tools (Advance): Link test, Time on air, Range and Registers. The link budget and the DISTANCE buttons are unchanged.
  • A two-Mega demo with the TEP Serial Monitor instead of Virtual Terminals. The sketches keep every v1.0 output line and add commands (SEND, PING, STATUS, SF, BW, PWR, AUTO, HELP).
  • Lighter package: about 6.5 MB, without the C++ source code (v1.0: about 12.9 MB).

A v1.0 design keeps its old symbol: new model and DISTANCE buttons, but no new board, LEDs or red X. Here its panel shows the chip's state before any sketch has set it up:

A v1.0 SX1262 design after the update to v1.1: the old dark generic SX1262 board with an ANT pad and the v1.0 SX1262 LoRa CONTROLS panel in STANDBY RC
Figure: A v1.0 design after the update: the old board and the v1.0 panel in the reset state; re-pick the part for the new one (PC render).

SX1262 LoRa Library for Proteus: Simple vs Advance

Both devices run the same model; only the panel differs:

SX1262 Simple vs Advance
FeatureSimpleAdvance
Full SX1262 model (SPI commands, BUSY, DIO1, NRESET, sleep, CAD, real time on air)✔✔
Ebyte E22 board, glowing rubber duck and PWR / TX / RX LEDs✔✔
DISTANCE buttons 10 m - 20 km and the link-budget verdict✔✔
Control panel on the schematic (mode, settings, counters, last packet)✔✘
Pop-up window you can move, resize and minimise✘✔
Radio page: what the sketch set, traffic, distance and reach✘✔
Link test, Time on air, Range and Registers✘✔
TEP Dark / Light theme, text size, Help page with Copy diagnostics✘✔
Same device name as v1.0 (old designs keep working)✔✘

Choose Simple to keep the radio's state beside your circuit, and Advance for hard numbers about your link. The demo has one of each, and the two talk to each other.

Download SX1262 LoRa Library for Proteus

Click the button below to download SX1262-LoRa-Library-for-Proteus-v1.1.zip (about 6.5 MB, without the C++ source code):

SX1262 LoRa Library for Proteus V1.1
  • README.txt: a detailed guide to the files, the wiring, the model, the test tools and real hardware.
  • Proteus Library Files: TEPSX1262.LIB (both devices), TEPSERIALMON.LIB and our Arduino library ArduinoV3TEP.LIB / ArduinoV3TEP.IDX with the Mega 2560.
  • Proteus Model Files: TEPSX1278.DLL, our LoRa family model, and TEPSERIALMON.DLL.
  • Proteus Simulation: SX1262-ArduinoMega2560.pdsprj, SX1262_Sender.hex, SX1262_Receiver.hex and copies of both DLLs.
  • Arduino Code: SX1262_Sender.ino, SX1262_Receiver.ino and the complete RadioLib 7.8.1 (Jan Gromes) with its examples, unmodified, under the MIT License with its license.txt; that is why this zip is bigger than our others.

Why TEPSX1278.DLL? One model file runs all our LoRa modules and keeps the name of the first one; our SX1278 and RFM95W libraries ship the identical file. No Proteus yet? Read How to Download and Install Proteus 7 and 8. New to libraries? Follow How to Install a New Library in Proteus.

How to Install SX1262 LoRa Library for Proteus

  1. Close Proteus and extract the whole zip file.
  2. Copy the four files from Proteus Library Files into the LIBRARY folder, usually C:\Program Files (x86)\Labcenter Electronics\Proteus 8 Professional\LIBRARY (on some PCs C:\ProgramData\Labcenter Electronics\Proteus 8 Professional\LIBRARY).
  3. Copy TEPSX1278.DLL and TEPSERIALMON.DLL into the MODELS folder.
  4. Start Proteus, press P and search for SX1262. You get the Simple and the Advance device (category Peripherals > Wireless).

Updating from v1.0? Replace TEPSX1262.LIB and TEPSX1278.DLL, and delete TEPSX1262.IDX if there is one in LIBRARY. A v1.0 design keeps its v1.0 symbol and runs with the new model; re-pick the part to get the v1.1 board. Never put back an older TEPSX1278.DLL: the files from before 30 Sep 2026 do not know the SX1262. Tested in Proteus 8.5; Proteus 7 is not supported.

The SX1262 Board in Proteus

We designed the module as a clean TEP board shaped like the Ebyte E22-900M22S: the green board with gold stamp holes, the silver can with the white label (E22-900M22S, EBYTE, QR code, RoHS, CE, "SX1262, TCXO, +22 dBm"), the IPEX socket in the can's notch, where the real one sits, and a coax cable up to an SMA rubber duck. Below the can: the PANEL button, three LEDs, a SIMPLE or ADVANCE badge and the 9 pins. Here is U1, the Simple device, while it sends:

SX1262 LoRa Library for Proteus: SX1262 Simple board U1 sending, with the orange rubber-duck antenna and waves, PWR and TX LEDs lit, PANEL: SHOWN, the SIMPLE badge and the SX1262 LoRa CONTROLS panel at 100 m
Figure: U1 (Simple) sends: orange duck and waves, PWR and TX lit; its panel: RX CONTINUOUS, -77 dBm at 100 m -> OK.

The duck's ring and tip light orange, and the waves ripple out. PWR and TX are lit, while RX stays dark. On U2, the Advance device, the same parts light green when a packet arrives:

SX1262 Advance board U2 in Proteus receiving a packet: green rubber-duck tip and ring, green waves, PWR and RX LEDs lit, OPEN PANEL button and ADVANCE badge
Figure: U2 (Advance) receives: green duck and waves, PWR and RX lit.

Pinout

The 9 Proteus pins keep the v1.0 order, chosen so the demo wires do not cross. The real E22 has more pads (for example RXEN and TXEN for its RF switch, see the real-hardware notes below), so on real hardware always wire by the names:

SX1262 pins in Proteus (VCC GND NSS BUSY RST DIO1 MISO MOSI SCK)
PinFunctionDemo connection
VCCPower (3.3 V on a real module)Supply terminal
GNDGroundGND
NSSSPI chip select, active LOWMega D10
BUSYOutput: HIGH while the chip works on a commandMega D9
RSTNRESET: the reset input, active LOWMega D3
DIO1Interrupt output: TX done, RX done, timeoutMega D2 (INT0)
MISOSPI data from the radioMega D50
MOSISPI data to the radioMega D51
SCKSPI clock from the ArduinoMega D52

Rubber Duck, LEDs and Waves

Board animations (the same on both devices)
IndicatorWhat it shows
PWR LED (red)Lit while VCC and GND are connected
TX LED (orange)Blinks for every packet sent
RX LED (green)Blinks for every packet received
Rubber duck (ring and tip)Orange while sending, green while receiving
Waves above the duckRipple out while sending, in while receiving
PANEL / OPEN PANEL, SIMPLE / ADVANCEThe panel button and the device badge

Each blink is held 0.3 - 0.4 s, so you see it. There are no properties to edit: your sketch sets the frequency, SF, bandwidth and power over SPI, as on the real chip, and you choose the DISTANCE on the panel (100 m at every Run).

SX1262 Simple: The Control Panel on the Sheet

Beside the Simple board, the SX1262 LoRa CONTROLS panel shows what the radio is doing, without one debug line in your sketch. You can see it in the picture of U1 above, at the default 100 m:

The SX1262 Simple panel
PartWhat it shows
Header, red XSX1262 LoRa CONTROLS; the X closes the panel
Mode barRX CONTINUOUS or RX SINGLE (green), TX - SENDING (orange), STANDBY RC / XOSC, FS or SLEEP (blue), CAD; "(BUSY)" while the chip boots or calibrates; NO POWER - CHECK VCC / GND or IN RESET (red)
Settings line 1868.000 MHz SF7 BW 125 kHz CR 4/5: what the sketch set
Settings line 2SYNC 0x1424 CRC ON EXPLICIT +14 dBm (EXPLICIT: a header in every packet)
CountersSENT, RECEIVED, TOO WEAK (CRC ERR appears after the first CRC error)
LAST PACKETRSSI and SNR of the last packet received, then its text and length
DISTANCE TO THE OTHER RADIOS10 m, 100 m, 1 km, 2 km, 5 km, 10 km, 15 km, 20 km
VerdictAT 100 m: -77 dBm, SF7 NEEDS -125 dBm -> OK
Hint and footerCLICK A DISTANCE - HIGHER SF REACHES FURTHER; SX1262 LoRa 150-960 MHz +22 dBm

Why the Sender Says RX CONTINUOUS

U1 is the sender, yet its bar says RX CONTINUOUS. That is correct: the v1.1 sender listens between its packets, so node 2 can PING it (its last packet is the "PONG" from my PING test). A Hello packet is on the air for about 46 ms per second, so the bar rarely catches TX - SENDING, but the TX LED and the orange duck, held longer, show every one.

DISTANCE: 5 km Is TOO WEAK at SF7

Now click 5 km on the panel of U1. The verdict turns to -128 dBm, TOO WEAK, because SF7 needs -125 dBm:

SX1262 Simple panel in Proteus with 5 km clicked: AT 5 km: -128 dBm, SF7 NEEDS -125 dBm, TOO WEAK
Figure: 5 km at SF7: -128 dBm, TOO WEAK.

From now on, U4 stays silent while U3 keeps printing "Sent OK": without an ACK, the sender never notices. U2 counts the weak packets on its Radio page. The link uses the larger of the two radios' DISTANCE settings, so bringing them back needs a short distance on both.

Higher SF Reaches Further: SF 9 at 5 km

The hint at the bottom of the panel says it: a higher SF reaches further. Leave the distance at 5 km and type SF 9 in the send box of BOTH Serial Monitors (one node alone would break the link). The panel of U1 now shows SF9, and the verdict says OK again:

SX1262 Simple panel in Proteus at 5 km and SF9: AT 5 km: -128 dBm, SF9 NEEDS -130 dBm, OK
Figure: SF 9 on both nodes: at 5 km, -128 dBm is enough, because SF9 needs only -130 dBm.

On U4, the packets come back:

SX1262 receiver output in the TEP Serial Monitor Simple interface: SF 9 typed, then Hello TEP #51 to #54 received at RSSI -127.5 dBm and SNR -11.25 dB
Figure: U4: SF 9, then packets at 5 km with -127.5 dBm and SNR -11.25 dB.
[SX1262] Received: Hello TEP #45
[SX1262] RSSI: -77.0 dBm   SNR: 10.00 dB
SF 9
Spreading factor SF9 - set node 1 to the same SF
Link (10 s): 6 received, RSSI -77.0 dBm avg, SNR 10.0 dB avg, 0 sent
[SX1262] Received: Hello TEP #51
[SX1262] RSSI: -127.5 dBm   SNR: -11.25 dB
[SX1262] Received: Hello TEP #52
[SX1262] RSSI: -127.5 dBm   SNR: -11.25 dB

Packets #46 to #50 never arrived: too weak at SF7, or sent while only one node used SF9. From #51 on, every packet arrives at -127.5 dBm (the end of the SX1262's RSSI scale; the real level is -128 dBm) with an SNR of -11.25 dB: below the noise, and SF9 still decodes it. The price: 164.9 ms on air per packet instead of 46.3 ms. To go back, click 100 m and type SF 7 on both monitors.

Closing the Panel

Need room on the sheet? Click the red X. The board button says PANEL: CLOSED with a grey dot, while the radio and the sketch keep running; in my shot, U1 is just sending. Click PANEL to bring it back.

SX1262 Simple board in Proteus with the control panel closed: PANEL: CLOSED, PWR and TX LEDs lit and the orange rubber duck while U1 sends
Figure: The panel closed: PANEL: CLOSED, while U1 keeps sending (TX lit, orange duck).

SX1262 Advance: The Pop-Up Window

The Advance device keeps only the board on the schematic. At Run, the "TEP SX1262 Advance" pop-up opens with the look of our Serial Monitor and no Windows title bar: move it by its header, resize or minimise it, and reopen it with OPEN PANEL. The header shows the state (U2 · RX) and the Radio and Test tabs; the blue status bar counts TX, RX and too weak.

The Radio Page

SX1262 Advance Radio page in Proteus: RX CONTINUOUS, 868.000 MHz, +14 dBm, sync word 0x1424, SF7 BW 125 kHz CR 4/5, 99 packets received at -77 dBm, OK at 100 m (+47.3 dB), reach about 3.8 km
Figure: The Radio page: 99 packets received at -77 dBm, SNR 10.0 dB, OK at 100 m (+47.3 dB), reach about 3.8 km.
  • RADIO - WHAT THE SKETCH SET: 868.000 MHz, +14 dBm, sync word 0x1424 (= SX127x 0x12), preamble 8, SF7, BW 125 kHz, CR 4/5, sensitivity -125 dBm, CRC on.
  • TRAFFIC: 99 packets received, the last one "Hello TEP #102" at -77 dBm; 2 sent (the PONGs, 31.0 ms on air each); 4 too weak from my 5 km test.
  • DISTANCE: "OK (+47.3 dB)" and my favourite line, "These settings reach about 3.8 km; SF12 would reach 9.9 km".

The Test Page: Four Measured LoRa Test Tools

Every number on the Test tab is measured on the running model, and each tool ends with a "Good for:" line.

1. Link Test: How Far Does Your Link Reach?

Choose 10, 20 or 50 packets and click Run test. The tool records the next real packets this radio sends or hears: decoded, CRC error, too weak or nobody heard it, with level, SNR and time on air. The DISTANCE buttons sit on the tool. 10 packets at 100 m:

SX1262 link test in Proteus: 10 of 10 packets decoded at -77 dBm and 10.0 dB SNR, 46.3 ms on air, and the link budget from 10 m to 20 km with the lowest SF that works
Figure: Link test at 100 m: 10 / 10 decoded, -77 dBm, 10.0 dB, 46.3 ms on air.

U2 decoded all 10 packets from U1; every green bar stands above the dashed "SF7 needs -125 dBm" line. Click 5 km during a test, and the bars turn red. Below, the link budget and the lowest SF that works at every distance:

Link budget at SF7, BW 125 kHz, +14 dBm, 868 MHz (from the Link test)
DistanceRSSISNRAt SF7Lowest SF, time on air
10 m-47 dBm10.0 dBOK +77 dBSF7, 46.3 ms
100 m-77 dBm10.0 dBOK +47 dBSF7, 46.3 ms
1 km-107 dBm9.8 dBOK +17 dBSF7, 46.3 ms
2 km-116 dBm0.8 dBOK +8 dBSF7, 46.3 ms
5 km-128 dBm-11.2 dBTOO WEAK -4 dBSF9, 164.9 ms
10 km-137 dBm-20.2 dBTOO WEAK -13 dBnone (even SF12 is too weak)
15 km-143 dBm-25.5 dBTOO WEAK -18 dBnone (even SF12 is too weak)
20 km-146 dBm-29.2 dBTOO WEAK -22 dBnone (even SF12 is too weak)

The SNR is 10.0 dB at 10 m and 100 m (the cap), 0.8 dB at 2 km and below zero from 5 km on. At +14 dBm, 10 km is out of reach even at SF12; with +22 dBm (PWR 22) and SF10, it works. Good for: seeing how far your link reaches and how strongly each packet arrives.

2. Time on Air: How Long Is One Packet on the Air?

This tool does not use your sketch. Two model SX1262s in a private test air send one packet for every SF and bandwidth at 12, 32, 64 or 255 bytes. Each cell shows the time on air and, in brackets, the measured time from SetTx to TX done.

SX1262 time on air test in Proteus: 12-byte packets, measured 46.46 ms against the formula's 41.22 ms, a table of SF7 to SF12 at 125, 250 and 500 kHz and the EU 868 MHz 1 % duty cycle
Figure: Time on air, 12 bytes: 41.22 ms by the formula, 46.46 ms measured from SetTx to TX done; EU 868: 1 %, wait 4.08 s.
Time on air of a 12-byte packet, CR 4/5, CRC on, explicit header (SetTx to TX done in brackets)
SFBW 125 kHzBW 250 kHzBW 500 kHz
SF741.2 ms (46.5)20.6 ms (25.8)10.3 ms (15.5)
SF882.4 ms (87.7)41.2 ms (46.5)20.6 ms (25.8)
SF9144.4 ms (149.6)72.2 ms (77.4)36.1 ms (41.3)
SF10288.8 ms (294.0)144.4 ms (149.6)72.2 ms (77.4)
SF11577.5 ms (582.8) LDRO288.8 ms (294.0)144.4 ms (149.6)
SF121155.1 ms (1160.3) LDRO577.5 ms (582.8) LDRO247.8 ms (253.0)

Each SF step roughly doubles the time, and each bandwidth step halves it. LDRO marks the cells where a symbol lasts 16 ms or more: RadioLib switches the low data rate optimisation on there. The brackets are always 5.24 ms longer, and the footer says why: the TCXO start-up on DIO3, 40 us and the 200 us PA ramp.

The second card applies the duty cycle of your frequency. In Europe, 868.0 - 868.6 MHz allows 1 % (36 s per hour), so a 12-byte packet at SF7 must wait at least 4.08 s for the next one: at most 873 per hour. Our demo sends one per second, fine in a simulation but too often for a real EU link. Good for: choosing the SF and bandwidth for your message size and the legal duty cycle.

3. Range: Which SF Reaches the Distance You Need?

Two model radios send one 14-byte packet per SF at each of the 8 DISTANCE steps, at your bandwidth and power. Green cells were decoded, red ones too weak:

SX1262 range test in Proteus: one packet per spreading factor at eight distances, link budget 3.8 km at SF7 to 9.9 km at SF12, and how far the TEP LoRa modules reach
Figure: Range at +14 dBm, 868 MHz, 125 kHz: SF7 reaches 2 km (budget 3.8 km), SF9 to SF12 reach 5 km.
Range at BW 125 kHz, +14 dBm, 868 MHz (measured at the 8 DISTANCE steps)
SFLink budgetDecoded up toToo weak from
SF73.8 km2 km5 km
SF84.6 km2 km5 km
SF95.5 km5 km10 km
SF106.7 km5 km10 km
SF118.1 km5 km10 km
SF129.9 km5 km10 km

The steps are coarse, so SF7 (budget 3.8 km) passes 2 km and fails at 5 km. The second card compares the modules at their maximum power: the SX1262 at +22 dBm reaches 7.0 km (SF7) to 18.2 km (SF12), the Ra-02 at 433 MHz 9.5 to 24.8 km. Good for: picking the spreading factor that reaches the distance you need.

4. Registers: What Did Your Sketch Set Up in the SX1262?

The SX1262 has commands, not registers like the SX127x, so this tool reads the command state live and lists the Arduino's last SPI commands:

SX1262 command state read live in Proteus: GetStatus 52 RX OK, RF frequency 36400000 = 868.000 MHz, TCXO on DIO3 with 5.00 ms start-up, BUSY pin low, the last SPI commands with status byte and BUSY time, and U1 as PARTNER
Figure: Registers: the SX1262's command state, the last SPI commands with their BUSY times, and U1 as PARTNER.
  • GetStatus 52 = RX, OK; packet type LoRa; RF frequency 36400000 = 868.000 MHz; sync word 14 24 (= 0x12); the DIO1 mask: RX done.
  • SetPaConfig 01 04 00, SetTxParams 14 04: RadioLib asks for 0x14 (20) with a small PA setting (duty 1, hpMax 4), and +14 dBm comes out, with a 200 us ramp.
  • TCXO (DIO3) on, 5.00 ms start-up: the delay in the Time on air brackets.
  • GetPacketStatus 9A 28 9A: RSSI -77.0 (0x9A = 154, -154 / 2) and SNR 10.00 dB (0x28 = 40, 40 / 4); GetStats: 138 packets, 0 CRC errors; BUSY low: "ready for a command".

Read the SPI log from the bottom up, and you watch RadioLib fetch one packet: GetIrqStatus, GetRxBufferStatus, ReadBuffer (48 65 6C 6C 6F 20, "Hello " in ASCII), ClearIrqStatus, then GetPacketStatus, each with its status byte. BUSY stayed high for 2 us, and 10 us after ClearIrqStatus. U1 is marked PARTNER. Good for: checking what your sketch really set up and how long each command kept BUSY high.

Settings and Help

The gear opens Settings: theme (TEP Dark or Light), text size, open the panel at Run and window size, saved for your Windows user.

Settings page of the SX1262 Advance pop-up: theme TEP Dark or Light, text size, open the panel at Run and window size
Figure: Settings, saved under HKCU\Software\TheEngineeringProjects\TEP SX1262 Advance.

The ? icon opens Help & Support: eight cards and Copy diagnostics for a bug report. Report a bug and Suggest a feature open the SX1262 board of our forum; Read the article, User guide and Check for updates open this article; the other three open the donate page, our website and the forum. A links.ini next to the DLL can change the links.

Help and Support page of the SX1262 Advance: eight cards with their links to the SX1262 forum board, this article, the donate page, the website and the forum, and the Copy diagnostics button
Figure: Help & Support: every card shows its link; TEP SX1262 Advance v1.1, build 2026-10-06, TEPSX1278.DLL.

SX1262 LoRa Link with Arduino Mega 2560 in Proteus

Open SX1262-ArduinoMega2560.pdsprj from the Proteus Simulation folder, with the .hex files and the DLLs beside it. It has two Arduino Mega 2560 boards from our Arduino Library for Proteus V3.0 (the first image shows the whole circuit):

  • NODE 1 - SENDER: Mega 1 (ARD1) with SX1262_Sender.hex, the SX1262 Simple (U1) and Serial Monitor U3.
  • NODE 2 - RECEIVER: Mega 2 (ARD2) with SX1262_Receiver.hex, the SX1262 Advance (U2) and Serial Monitor U4.

Why an Arduino Mega 2560?

RadioLib's SX1262 driver plus the demo needs about 50 KB of flash, more than the 32 KB of an Arduino UNO. The Mega 2560 has 256 KB, hardware SPI on D50 - D52 and INT0 on D2 for DIO1. For a LoRa demo on an UNO, see our SX1278 and RFM95W libraries (arduino-LoRa).

Wiring

Demo wiring (the same on both Megas: RadioLib's standard SX126x pins)
FromToWhy
SX1262 VCC / GNDSupply / groundPower (+5 V in the simulation; a real module needs 3.3 V)
SX1262 NSSMega D10SPI chip select
SX1262 DIO1Mega D2 (INT0)Interrupt: TX done, RX done
SX1262 RSTMega D3NRESET: RadioLib resets the chip in begin()
SX1262 BUSYMega D9The handshake RadioLib waits for
SX1262 SCKMega D52SPI clock
SX1262 MISOMega D50Data from the radio
SX1262 MOSIMega D51Data to the radio
Serial Monitor RXD / TXD / GNDMega D1 (TX0) / D0 (RX0) / groundShows what the Mega prints, sends what you type

No wire joins the two nodes: they share one simulated air.

The Arduino Code

Both sketches use the unmodified RadioLib 7.8.1; the sender is based on its SX126x_Transmit_Blocking example, the receiver on SX126x_Receive_Interrupt. The radio object gets the four control pins:

SX1262 radio = new Module(10, 2, 3, 9);   // NSS, DIO1, NRST, BUSY

One line starts the radio with all its settings, the same in both sketches:

  int state = radio.begin(868.0, 125.0, 7, 5, RADIOLIB_SX126X_SYNC_WORD_PRIVATE, 14);

That is 868.0 MHz, 125 kHz, SF7, CR 4/5, RadioLib's private sync word 0x12 and +14 dBm. For the US or Australia, use 915.0 in both sketches. The DIO1 interrupt only sets a flag:

volatile bool receivedFlag = false;
void setFlag(void) {
  receivedFlag = true;
}

The v1.1 sender listens between its packets, so node 2 can PING it or SEND it a message:

  radio.setPacketReceivedAction(setFlag);   // DIO1 -> INT0 (D2)
  radio.startReceive();                     // v1.1: listen between the packets

radio.transmit() blocks until DIO1 signals TX done; that edge is not a packet, so the flag is cleared before listening again:

int transmit(const char* text) {
  int state = radio.transmit(text);
  receivedFlag = false;                     // the TxDone edge on DIO1 is not a packet
  radio.startReceive();
  ++sent; ++linkSent;
  return state;
}

While AUTO is ON, the sender sends the v1.0 message every second:

  if (autoSend && millis() - lastSend >= 1000) {
    lastSend = millis();
    sendHello();
  }

and prints the v1.0 lines, with the time on air from RadioLib's own formula:

  String str = "Hello TEP #" + String(count++);
  Serial.print(F("[SX1262] Transmitting: "));
  Serial.println(str);
  int state = transmit(str.c_str());
  if (state == RADIOLIB_ERR_NONE) {
    Serial.print(F("[SX1262] Sent OK, time on air "));
    Serial.print(radio.getTimeOnAir(str.length()) / 1000);
    Serial.println(F(" ms"));

The receiver reads the packet, then its RSSI and SNR:

  String str;
  int state = radio.readData(str);
  if (state == RADIOLIB_ERR_NONE) {
    strncpy(text, str.c_str(), size - 1);
    text[size - 1] = 0;
    lastRssi = radio.getRSSI();
    lastSnr = radio.getSNR();

A PING is answered before anything is printed, so the round trip measures the radios, not the 9600-baud Serial port:

  bool ping = strcmp(text, "PING") == 0;
  if (ping) transmit("PONG");               // answer first (the round trip), print afterwards

The SF command changes the spreading factor and goes back to listening; type it on both monitors:

  } else if (strcmp(text, "SF") == 0) {
    int sf = atoi(arg);
    if (sf < 5 || sf > 12) { Serial.println(F("SF needs 5 - 12, e.g. SF 9")); return; }
    spreadingFactor = sf;
    report(radio.setSpreadingFactor(sf), F("setSpreadingFactor"));
    radio.startReceive();

To change a sketch, install RadioLib (or copy Arduino Code\libraries\RadioLib into your sketchbook), select Arduino Mega or Mega 2560, export the compiled binary and load the new HEX file into its Mega; see How to get the HEX file from Arduino. New to Arduino? Start with our Arduino Tutorial for Beginners.

Serial Monitor Commands

Commands of the demo sketches (monitor quick buttons: PING, STATUS, SEND Hello from node 1 / 2, HELP)
CommandWhat it does
HELPThe command list
STATUSFrequency, SF, bandwidth, coding rate, sync word, power, counters and the last RSSI / SNR
SEND <text>A message to the other node now
PINGThe other node answers PONG; prints the round trip time
SF <5-12>For example SF 9: the spreading factor (type it on both monitors)
BW <kHz>For example BW 250: 7.8 ... 125, 250, 500 kHz (both monitors)
PWR <-9..22>The transmit power in dBm
AUTO <ON|OFF>Node 1 only: the Hello TEP packet every second

How to Run the Demo

  1. Press Run. Both Serial Monitors (9600 baud) and the pop-up of U2 open, and the Hello packets start.
  2. Type PING and STATUS on U3.
  3. Click 5 km on the panel of U1, then type SF 9 on both monitors. Back: 100 m and SF 7 on both.
  4. Close the panel of U1 with its red X and open it again with PANEL.
  5. Run the four tools on the Test tab of U2.

SX1262 Proteus Simulation Results

The Serial Monitor in Its Simple Interface

Both monitors in this demo run in the Simple interface of our TEP Serial Monitor, and every monitor screenshot in this article shows them that way. Only the log, the send box and one slim toolbar row stay visible (baud rate, follow, pause, search and clear). The header, the quick buttons and the status bar are hidden, so the window stays small next to your schematic.

  • Switch to it: right-click the log and choose Simple interface, or press Ctrl+Shift+U.
  • Back to the full view: click the corner button (the expand arrows at the top right), press Esc or Ctrl+Shift+U, or right-click and choose Full interface.
  • Your choice is remembered.

Type commands such as PING, STATUS or SF 9 in the send box and press Enter; the quick buttons come back with the full view. RXD2, the monitor's second input, is not used: the SX1262 talks SPI and has no serial line to watch. Read all about the monitor in TEP Serial Monitor Advance for Proteus.

Start-Up: Hello TEP Arrives

After Run, both sketches print their banners, and a packet goes out every second. The first lines of U3 and U4:

TEP SX1262 LoRa sender (Arduino Mega 2560 + RadioLib)
[SX1262] Initializing ... success!
Demo v1.1 - type HELP in the Serial Monitor for the commands
[SX1262] Transmitting: Hello TEP #0
[SX1262] Sent OK, time on air 41 ms
TEP SX1262 LoRa receiver (Arduino Mega 2560 + RadioLib)
[SX1262] Initializing ... success!
[SX1262] Starting to listen ... success!
Demo v1.1 - type HELP in the Serial Monitor for the commands
[SX1262] Received: Hello TEP #0
[SX1262] RSSI: -77.0 dBm   SNR: 10.00 dB

A few seconds later, U3 has sent Hello TEP #7:

SX1262 Arduino Proteus output of the sender in the TEP Serial Monitor Simple interface: Transmitting Hello TEP #2 to #7, each Sent OK, time on air 41 ms
Figure: U3: Hello TEP #2 to #7, each sent with a time on air of 41 ms.

and U4 has received every one of them at -77.0 dBm and 10.00 dB, the 100 m numbers:

SX1262 receiver output in the TEP Serial Monitor Simple interface: Received Hello TEP #2 to #7, each with RSSI -77.0 dBm and SNR 10.00 dB
Figure: U4: the same packets, each at -77.0 dBm and 10.00 dB.

Every 10 s, U4 adds a link line such as "Link (10 s): 6 received, RSSI -77.0 dBm avg, SNR 10.0 dB avg, 0 sent", and U3 its own with the packets it sent.

Why 41 ms Becomes 46 ms

From Hello TEP #10 on, U3 prints 46 ms instead of 41. The reason is one byte: "Hello TEP #9" has 12 bytes, "Hello TEP #10" has 13. RadioLib's getTimeOnAir() counts symbols of 1.024 ms: 12.25 for the preamble, 8 fixed ones, then 5 symbols (CR 4/5) for every block of 28 bits (4 x SF7) of header, message and CRC. 12 bytes fill 4 blocks: 40.25 symbols = 41.2 ms. The 13th byte starts a fifth block: 45.25 symbols = 46.3 ms. The sketch drops the decimals.

The TCXO has nothing to do with it: the printed number is the formula without the start-up. The TCXO shows up only in the Time on air tool's measured brackets (46.46 ms for 12 bytes), so the two 46s are a coincidence.

Typing Commands: PING, PONG and STATUS

Now U3, the sender. I typed PING, pressed Enter, then STATUS. Lines you send carry a blue TX tag, the Arduino's lines a green RX tag:

TEP Serial Monitor Simple interface in Proteus: PING typed, PING: PONG from node 2 after 81.0 ms at RSSI -77.0 dBm SNR 10.00 dB, and the STATUS lines of the SX1262 sender
Figure: U3: PING answered after 81.0 ms, and the STATUS lines.
[SX1262] Transmitting: Hello TEP #18
[SX1262] Sent OK, time on air 46 ms
PING
PING: PONG from node 2 after 81.0 ms (RSSI -77.0 dBm, SNR 10.00 dB)
[SX1262] Transmitting: Hello TEP #19
[SX1262] Sent OK, time on air 46 ms
STATUS
Status: 868.000 MHz, SF7, BW 125 kHz, CR 4/5, sync 0x12, +14 dBm
  sent 22, received 2, auto-send ON (every 1 s)
  last packet: RSSI -77.0 dBm, SNR 10.00 dB

PONG came back after 81.0 ms: two 4-byte packets of 31.0 ms on air each, about 5.2 ms each for the TCXO and the PA ramp, and the SPI commands of both Megas. STATUS tells my run: 22 sent (Hello #0 to #19 and two PINGs) and 2 received, the PONGs. On U4, a PING (my first one) arrives like any message:

SX1262 receiver output in the TEP Serial Monitor Simple interface: Received: PING, PONG sent back and the link line 11 received, 1 sent
Figure: U4: the PING arrives, node 2 answers with PONG, and the link line counts 11 received, 1 sent.
[SX1262] Received: PING
[SX1262] RSSI: -77.0 dBm   SNR: 10.00 dB
  -> PONG sent back
[SX1262] Received: Hello TEP #9
[SX1262] RSSI: -77.0 dBm   SNR: 10.00 dB
Link (10 s): 11 received, RSSI -77.0 dBm avg, SNR 10.0 dB avg, 1 sent
[SX1262] Received: Hello TEP #10

The link line counts 10 Hello packets plus the PING received, and 1 packet sent: the PONG.

Troubleshooting

  • "[SX1262] Initializing ... failed, code -2" or -705: chip not found or SPI timeout. Check SCK D52, MISO D50, MOSI D51, NSS D10, BUSY D9 (first, for -705), RST D3 and VCC / GND, and TEPSX1278.DLL in MODELS and beside the project.
  • The panel title says SX1278 on an SX1262 part: an older TEPSX1278.DLL is installed.
  • Nothing received: both sketches need the same frequency, SF, bandwidth and sync word (STATUS on both monitors; the Registers tool lists what does not match), and both DISTANCE settings count.
  • "[SX1262] CRC error!": the signal is at the edge; use the next SF or a shorter distance.
  • No monitor window or no pop-up: a DLL is missing; click OPEN MONITOR on the monitor part or OPEN PANEL on the board.
  • No red X / the old board: replace the LIB, delete TEPSX1262.IDX and re-pick the part.
  • "[AVR SPI] Clock frequency changed while in the Master mode": Proteus's ATmega model at start-up; harmless.
  • Your own sketch: hardware SPI and INT0 on D2 work in Proteus 8.5; only pin-change interrupts never fire there, so SoftwareSerial cannot receive (not needed here).

Things to Know Before Using a Real SX1262

The demo sketches use only RadioLib, so they run on two real Megas and modules, too. Keep in mind:

  • 3.3 V only: feed VCC from 3.3 V, never from 5 V, and use a level shifter (or a 3.3 V board) for SCK, MOSI, NSS and RST: SX1262 modules are NOT 5 V tolerant. In the simulation, VCC goes to +5 V, because the model only checks that it is powered. At +22 dBm, the data sheet lists 118 mA.
  • Antenna first: at +22 dBm, sending into a missing antenna can destroy the power amplifier.
  • RXEN / TXEN: the E22-900M22S has its own RF switch pins. Drive them from two Arduino pins (radio.setRfSwitchPins(rxen, txen)) or follow Ebyte's wiring with DIO2.
  • TCXO or crystal: modules with a plain crystal (for example some Ai-Thinker Ra-01SH) need begin() with a TCXO voltage of 0.
  • Legal bands and duty cycle: EU 868.0 - 868.6 MHz: 1 % duty cycle, 25 mW e.r.p. (869.4 - 869.65 MHz: 10 %, up to 500 mW); US 902 - 928 MHz (400 ms dwell time per channel), Australia 915 - 928 MHz. +22 dBm is far more than the 25 mW (+14 dBm) of the EU sub-band. For 915 MHz, change the first value of radio.begin() in both sketches.

Limitations of the Simulation

  • Not modelled: collisions, frequency errors, the spectral scan, the receive duty cycle (treated as continuous RX), the DIO2 / DIO3 outputs (their roles only affect timing) and the supply voltage. GFSK, BPSK and LR-FHSS commands are accepted, but nothing is sent in those modes.
  • The SNR is capped at +10 dB, the RSSI ends at -127.5 dBm, and the timing is close enough for RadioLib's timeouts, not to the microsecond.
  • The range is a teaching model (exponent 3.0 beyond 1 m); real range depends on your antennas and surroundings.
  • The model is our own implementation, written from Semtech's SX1261/2 data sheet and AN1200.13; it contains no RadioLib code.
  • Tested in Proteus 8.5 SP0 on 6 and 7 Oct 2026 (the demo, PING, 5 km and SF 9, the four tools and every Proteus screenshot here) and with 670 automatic PC checks, all passed, 49 of them with the unmodified RadioLib 7.8.1 and 30 with the real v1.1 sketches. The image marked "PC render" was drawn by the model's own code. Proteus 7 is not supported.

For other LoRa modules, see our SX1278 LoRa Library for Proteus (Ra-02, 433 MHz) and RFM95W LoRa Library for Proteus. They share TEPSX1278.DLL, so all three talk to each other in one design when their settings match. For other radios, try our CC1101 Library for Proteus, RFM69HCW Library for Proteus, nRF24L01 Library for Proteus or nRF24L01+PA+LNA Library for Proteus.

So, that was all about the SX1262 LoRa Library for Proteus V1.1. I hope the DISTANCE buttons, the glowing rubber duck, the four test tools and the SF 9 experiment at 5 km make LoRa much easier to understand, so your long-range project works the first time you wire two real modules. If you use the SX1262 LoRa Library for Proteus in a project, please share your feedback in the comments or in our forum, and if you have any questions, ask in the comments and I will help you out. Till the next tutorial, take care and have fun!


Comments

0

Join the conversation