Beginer questions about RadioLib SX1262

[MarusGradinaru]

Hi !

I am verry new to RadioLib and LoRa. Basicaly, it is my first time !
I want to make a peer-to-peer connection between 2 LoRa modules with SX1262 chip.
I use VSCode with Platform IO and Arduino framework to program it. The control device will be ESP32-DevKitC.

I have been studying the RadioLib library for some time, with the help of ChatGPT, but it doesn't have all the answer for my questions. So I decided to ask those who know better. I will start with the first one... and then, others will follow.

In the SX126x_Settings.cpp example, I see that the module can be initialized with and without parameters:
int state = radio1.begin();
state = radio2.begin(915.0, 500.0, 6, 5, 0x34, 2, 20); - this is SX1268, but it doesn't matters here

I searched through the library source files but I can't find any declaration of the begin() without parameters. I was curious to see what are the default parameters and to understand how things works (I am learning C++ too). The only begin() method I found is with parameters, in the SX1262.cpp file:

int16_t SX1262::begin(float freq, float bw, uint8_t sf, uint8_t cr, uint8_t syncWord, int8_t power, uint16_t preambleLength, float tcxoVoltage, bool useRegulatorLDO) {
{

I searched other files too, but with no luck...
So, can someone share a link to the RadioLib source file where I can understand why the begin() can be called without parameters ?
Thanks !

[jgromes]

Hi there, and welcome!

The thing you're looking for is called a default argument. This is a mechanism that lets you assign a default value to a function or method argument that will be used if no other value is provided. For C++ methods, it is usually located in the header file. So continuing your example, for SX1262::begin, the values can be found here:

RadioLib/src/modules/SX126x/SX1262.h

Lines 32 to 47 in b91c6af

	/*!
	\brief Initialization method for LoRa modem.
	\param freq Carrier frequency in MHz. Defaults to 434.0 MHz.
	\param bw LoRa bandwidth in kHz. Defaults to 125.0 kHz.
	\param sf LoRa spreading factor. Defaults to 9.
	\param cr LoRa coding rate denominator. Defaults to 7 (coding rate 4/7).
	\param syncWord 1-byte LoRa sync word. Defaults to RADIOLIB_SX126X_SYNC_WORD_PRIVATE (0x12).
	\param power Output power in dBm. Defaults to 10 dBm.
	\param preambleLength LoRa preamble length in symbols. Defaults to 8 symbols.
	\param tcxoVoltage TCXO reference voltage to be set on DIO3. Defaults to 1.6 V.
	If you are seeing -706/-707 error codes, it likely means you are using non-0 value for module with XTAL.
	To use XTAL, either set this value to 0, or set SX126x::XTAL to true.
	\param useRegulatorLDO Whether to use only LDO regulator (true) or DC-DC regulator (false). Defaults to false.
	\returns \ref status_codes
	*/
	virtual int16_t begin(float freq = 434.0, float bw = 125.0, uint8_t sf = 9, uint8_t cr = 7, uint8_t syncWord = RADIOLIB_SX126X_SYNC_WORD_PRIVATE, int8_t power = 10, uint16_t preambleLength = 8, float tcxoVoltage = 1.6, bool useRegulatorLDO = false);

with the help of ChatGPT

Word of advice, don't use that thing for anything more than to give you links to real sources or better yet - throw it into the garbage. I understand it feels like its helping you, but it really, really isn't.

[MarusGradinaru]

Oh, I see... It is exactly like in Delphi (I am a Delphi programmer). But I wasn't aware that the default parameters are only specified in the header file, for C++. Thanks !

Do you ever worked with Waveshare Core1262-HF module ? In the documentation it doesn't say what voltage should I set to the TCXO on DIO3... And neither if it support DC-DC or just LDO power supply...

[MarusGradinaru]

Those from the Waveshare finally answer me, and they said:
"TCXO can supply power below 1.8V, and the default is 1.7V;
DIO3 uses the pin on the SX1262 chip and can generate a voltage of 1.7V"
Their English is not very good (being Chinese) and I don't know if I understood correctly... Are they saying to power the TCXO with 1.7V?

[jgromes]

And neither if it support DC-DC or just LDO power supply...

Based on the schematic, it seems they are using the DC/DC option. Notice the L7 and L8 inductors connected between DCC_SW, VREG and VDD_IN pins of the SX1262. This configuration is straight from the SX1262 datasheet:

Are they saying to power the TCXO with 1.7V?

Seems like it. The TCXO voltage is one of the arguments of the SX1262::begin method. It's reasonably easy to test whether the voltage is correct, because if you specify the wrong value, the method will return a non-zero status code because the TCXO will fail to start.

[MarusGradinaru]

the method will return a non-zero status code because the TCXO will fail to start.

Yes, but if I set a voltage greater than the maximum rating of the TCXO power supply, won't it destroy it ?

[jgromes]

Indeed, that's why you should start from lower voltages and only go higher if it doesn't work. There is also not a sharp cut-off. Most (/nearly all) electrical devices have some tolerance on the input voltage. Coincidentally, for the SX1262, it can even be seen in the image I posted. While the nominal input votlage it requires is 3.3V, it will work up to 3.7V. That's because in the real world, no voltage source is absolutely accurate.

[MarusGradinaru]

I have another question...
How can I use custom settings and pins for the SX1262 class SPI ?

For settings, I think I have to use the overloaded Module() function that takes additional 2 parameters for SPI configuration. But I'm not sure how should I do...

Is this variant ok ?

SPISettings mySPISettings(4000000, MSBFIRST, SPI_MODE0);
Module* ws_mod = new Module(PIN_CS, PIN_DIO1, PIN_RESET, PIN_BUSY, SPI, mySPISettings);
SX1262& LORA = *new SX1262(ws_mod);

Or this variant ?

SPISettings mySPISettings(4000000, MSBFIRST, SPI_MODE0);
SX1262 LORA = new Module(PIN_CS, PIN_DIO1, PIN_RESET, PIN_BUSY, SPI, mySPISettings);

And then, for pins... Where should I call: SPI.begin(...new_pin_configuration...);:

• after I created the module ?
• after I call LORA.begin(...) ?

Do I need to use LORA.setSPI(&SPI); too, if I use the default SPI ?

[StevenCellist]

See https://github.com/jgromes/RadioLib/wiki/Basics

[MarusGradinaru]

Perfect ! Thanks !

[MarusGradinaru]

Here's another one...
When I use LORA.setDio1Action(IrqHandler); when will that handler be called ? Ar what event that is happening in SX1262 ? RX done, TX done, enything else ? Or all of them togheter ? And if so, how do I differentiate between them ?

[jgromes]

I think that from the irqMask I can choose what interrupts I want to receive on DIO1, but what does the "irgFlags" parameter

irqFlags controls which events are monitored by the radio. Combined with irqMask (by a bitwise AND), you get the events which will trigger DIO1.

I also cannot find where the default values for those parameters are defined

Those macros are slightly different - notice how they do not contain the string _SX126x_. These are defined in the PhysicalLayer class to form a basic common interface for all radio modules. For example, SX127x has different IRQ flag bits, but it still has the concept of "interrupt when packet is received". PhysicalLayer allows us to abstract away that difference, but that is a bit more advanced usage.

[MarusGradinaru]

If I used SX1262.startReceive(); and received a data packet, do I have to issue SX1262.startReceive(); again, after I process it, or the module remains in receive mode by default ? In other words, if I put the chip in receive mode with startReceive(), does it stay like this until I explicitly change it to another mode (sleep, transmit), or there are some internal triggers that can stop reception (a corrupted packet or someting) ?

[jgromes]

The radio keeps receiving - this is why in the example, there is no repeated call to startReceive, though it is not stated there directly.

[MarusGradinaru]

Even if it receives a corrupt packet or some kind of errors ?

[jgromes]

Even in that case. For example, if the packet is corrupted, it will trigger a CRC error, but the reception will continue.

[MarusGradinaru]

Lets say I'm in RX listening mode and I received a packet. I read the packet and now I want to transmit a replay.

I use:
state = LORA.transmit(data, 12); // to transmit
state = LORA.startReceive(); // to return to RX mode

What should I do if transmit() fails with state != RADIOLIB_ERR_NONE ? Do I need to do some clean up before returning to RX mode ? Or I can go directly ?

[StevenCellist]

At some point you could start reading the datasheet instead of asking everything ;)

But would it hurt you to switch to standby just to clear any possible error or odd thing that may have occurred?

[MarusGradinaru]

Steven, I already read it many times, but in SX1262 datasheet doesn't say how RadioLib works.
I have no problem with temporarily switching to standby, but I like to understand how it works.

[HeadBoffin]

but I like to understand how it works.

Read the source code?

[MarusGradinaru]

@HeadBoffin I did that too. But I am a verry beginer in this ESP32, SX1262, C++, Radiolib stuff. This is my first try, and some questions are to big for me... I need a little guidance.
Here's a prof that I already studied the source code... I even dicovered a little bug : #1561

@everybody
I made a map of what does internally the SX126x::transmit() and SX126x::startReceive() functions, to see more clear the big picture. As you can see, if the transmit function is interrupted at any point by some error, the receive function can reconfigure all the settings needed for the new mode (reception), even the RF switch and IRQ flags...

SX126x::transmit()
   - SX126x::standby()
      - RF Switch: Idle 
      - send SPI command: standby  (put the chip in standby mode) 
      - return status
   - return error if fails
   - PhysicalLayer::startTransmit() -------------------------------
      - SX126x::stageMode()
         - check for erors, return if found
         - send SPI command: setPacketParams  (packet configuration)
         - return error if fails
         - send SPI command: setDioIrqParams  (configure IRQ flags)
         - return error if fails
         - send SPI command: setBufferBaseAddress
         - return error if fails
         - send SPI command: writeBuffer  (upload data buffer)         
         - return error if fails
         - send SPI command: clearIrqStatus  (clear IRQ status flags)
         - return status
      - return error if fails
      - SX126x::launchMode()
         - RF Switch: TX mode
         - send SPI command: setTx  (begin transmision)
         - return error if fails
         - wait for PA ramp up    
         - return status 
      - return status   
   - return error if fails -----------------------------------------
   - wait TimeOnAir period
   - update data rate 
   - SX126x::finishTransmit()
      - send SPI command: clearIrqStatus  (clear IRQ status flags)
      - return error if fails
      - SX126x::standby()
         - RF Switch: Idle 
         - send SPI command: standby  (put the chip in standby mode) 
         - return status
      - return status
   - return status

 SX126x::startReceive()
   - PhysicalLayer::startReceive() 
      - SX126x::stageMode()
         - SX126x::startReceiveCommon()
            - SX126x::standby()
               - RF Switch: Idle 
               - send SPI command: standby  (put the chip in standby mode) 
               - return status
            - return error if fails
            - send SPI command: setDioIrqParams  (configure IRQ flags)
            - return error if fails
            - send SPI command: setBufferBaseAddress
            - return error if fails
            - send SPI command: clearIrqStatus  (clear IRQ status flags)
            - return error if fails
            - send SPI command: setPacketParams  (packet configuration)
            - return status
         - return status
      - return error if fails
      - SX126x::launchMode()
         - RF Switch: RX mode
         - send SPI command: setRx  (begin reception)           
         - return status
      - return status
   - return status

[HeadBoffin]

I even dicovered a little bug

Well done!

the receive function can reconfigure all the settings needed for the new mode

Yes, we know, RL sets everything it needs to do the job required of each time so that if anyone does interact with the radio directly, at least RL can recover from any misuse.

If you are new to all of this, best to stick to the standard recipes provided in the examples and as you build up experience & working solutions, then you can start hacking on stuff. The time taken to switch modes is nothing in the context of the millisecond transmission times, so there's no huge penalty here. Whereas the Rx1 delay in LoRaWAN is a whole other matter!

It's not normal for a silicon manufacturer to document third party software in their data sheet.

[MarusGradinaru]

The timeout for SX1262.receive(data, len) is hard coded to 100 symbols ? Won't I get a timeout error if I send larger data buffers, such as a maximum of 255 bytes ?

[jgromes]

You won't, because the timeout will not trigger when data reception is already in progress. But in any case, interrupt-driven reception is nearly always the better option.

[MarusGradinaru]

What do you mean by "interrupt-driven reception is nearly always the better option" ? Isn't this the case for SX1262.receive(data, len) ? I saw that it uses the DIO1 interrupt...

[jgromes]

As per the API reference documentation and the examples: receive is a blocking method, it will block program execution until packet is received, or timeout occurs, whichever comes first. Interrupt-driven does not wait for anything, it will start reception and the trigger an interrupt, when data is available, leaving your main program to other things in the meantime.

[MarusGradinaru]

@jgromes It seems I was right... 😞 I did some further testing with the SX1262.receive(). I used a payload of 32 bytes and changed the spread factor from 12 to 5. At SF7 the receive() fails with -6 timeout code. If I lower the payload to 7 bytes, I can receive even with SF5. I think the calculated timeout is to small and the sender doesn't have time to respond. In the serial terminal, the sender report it has successfully transmited the message, but the receiver returns with timeout error. The modules are at a distance of 1m between each other.

[jgromes]

@MarusGradinaru low spreading factor values mean shorter symbol length, and consequently, shorter timeout duration for the blocking receive method. The SX1262 datasheet does not specify waht happens when the timeout triggers during packet reception, at least from what I know. So in general, I would highly recommend you use the interrupt-driven reception. There are very few use cases when the blocking reception would be better.

[MarusGradinaru]

This should be the final software for communication between 2 LoRa SX1262 modules with RadioLib... What do you think ? Is not tested yet... I still have to make the hardware wirings between the LoRa and ESP32 modules...

https://github.com/MarusGradinaru/lora-p2p/blob/main/lora_client_server_example.cpp

The software is the same for both the Client module and the Server module, and the version is chosen during compilation through the "#define TX_MODULE" directive. I implemented 2 test commands: CMD1 and CMD2, which send the command along with a small data buffer, and receive another buffer with the requested data back... The commands are sent when touching the GPIO4 and GPIO2 pins of the ESP32-DevKitC.

[HeadBoffin]

It's very specific to the ESP32.

How does it improve on https://github.com/jgromes/RadioLib/blob/master/examples/SX126x/SX126x_PingPong/SX126x_PingPong.ino?

[MarusGradinaru]

It is not about improvement, it is about learning and doing things in my own way...

[HeadBoffin]

It seemed you were proposing this as a solution for P2P.

If it's just for your own consumption, then testing will reveal any issues and you can take it from there.

[MarusGradinaru]

No, I'm not proposing anything... Is the software that I made for my project. But I made it like an example of how to use LoRa P2P Server/Client connection...

I wired a module today (ESP32+SX1262), uploaded the RX version of the software, and everything seems to be working fine, I didn't get any errors so far... But I can't confirm that it's perfectly functional because I don't have anything to emit with, as for the second SX1262 module I'm missing the ESP32 controller...

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1344
load:0x40078000,len:13964
load:0x40080400,len:3600
entry 0x400805f0
[ 464][I][esp32-hal-psram.c:96] psramInit(): PSRAM enabled
Starting program for RX Module (Server)...
[SX1262] Initializing LoRa... done !
[SYS] Starting LoRa Server task... done !
[SX1262] Starting to listen... done !

[MarusGradinaru]

@jgromes please allow me one last question before powering up my modules.
I want to convert my ESP32 software that I created, to run on a Raspberry Pi Pico device with Earle Philhower's Arduino-Pico framework.
On ESP32 I configure the RadioLib like this, and it works:

SPISettings mySPISettings(2000000, MSBFIRST, SPI_MODE0);  // 10 cm long wires SPI
SX1262 LORA = new Module(PIN_CS, PIN_DIO1, PIN_RESET, PIN_BUSY, SPI, mySPISettings);
void setup() {
  SPI.begin(PIN_CLK, PIN_MISO, PIN_MOSI, PIN_CS);
  int16_t state = LORA.begin(...)
}

But on Pico, I learned from the internet that I must do in this way:

SPISettings spiSettings(2000000, MSBFIRST, SPI_MODE0);
SX1262 LORA = new Module(PIN_CS, PIN_DIO1, PIN_RESET, PIN_BUSY, SPI, spiSettings);
void setup() {
  pinMode(PIN_CS, OUTPUT);
  digitalWrite(PIN_CS, HIGH);
  SPI.setSCK(PIN_CLK);
  SPI.setRX(PIN_MISO);  // SPI0 RX (MISO)
  SPI.setTX(PIN_MOSI);  // SPIO TX (MOSI)
  SPI.begin();
  int16_t state = LORA.begin(...)
}

They say that on Pico version I must configure manually the CS pin, because on this framework the CS is set by default to be software controlled. But, when I call SX1262 LORA = new Module(PIN_CS,...), this doesn't automatically configure the CS pin too ?
I can set the SPI.CS pin to be hardware or software controled, but I don't know what RadioLib expects...

[jgromes]

They say that on Pico version I must configure manually the CS pin

I don't know who "they" are in this case, but "they" are wrong, at least in the context of RadioLib. The CS pin is automatically set as output and controlled by the library, so you don't need to touch it.

[MarusGradinaru]

Thank you guys for helping me with this project ! What @jgromes did is not just a library, it is a work of art ! 😍

I finally did the field test... I attached the modules and the antenna to a piece of cardboard and attached them to the top of a stick. I left one right at the gate, where my yard begins (it's 350m long and 11m wide), then I took my laptop with me, along with the other module connected via USB and tested the connection from place to place, sending a command to the stationary LoRa server and receiving a packet back from it. The results are as follows:

  1 m,  RSSI =  -17.00 dBm,  SNR = 11.00 dB,  Freq. Error =  -91.06 Hz
 47 m,  RSSI =  -58.00 dBm,  SNR = 10.75 dB,  Freq. Error = -118.19 Hz  (behind a wooden cabin)
 68 m:  RSSI =  -78.00 dBm,  SNR = 10.75 dB,  Freq. Error = -110.44 Hz
 98 m:  RSSI =  -82.00 dBm,  SNR = 10.75 dB,  Freq. Error = -110.44 Hz
141 m:  RSSI =  -85.00 dBm,  SNR = 10.75 dB,  Freq. Error = -114.31 Hz
218 m:  RSSI =  -93.00 dBm,  SNR = 10.75 dB,  Freq. Error = -118.19 Hz  (here the orchard begins)
245 m:  RSSI = -106.00 dBm,  SNR =  6.25 dB,  Freq. Error = -118.19 Hz  (a valley begins here)
280 m:  RSSI = -107.00 dBm,  SNR =  5.50 dB,  Freq. Error = -122.06 Hz
320 m:  RSSI = -114.00 dBm,  SNR = -1.50,dB,  Freq. Error = -102.69 Hz

Both modules have 5 dBi stick antennas and were configured as follows:

#define FREQ       869.5   // Frequency: P band, 500mW (27dBm), 10% 
#define BW         125.0   // Bandwidth (KHz)
#define SF         9       // Spreading Factor [5..12]
#define CR         7       // Coding Rate: 4/7 [5..8]
#define SYNCW      0xE3    // Sync Word: Custom [Private: 0x12, Public: 0x34] 
#define TX_PWR     9       // TX Power (dBm) [-9..22] / with 5 dBi antenna = 14 dBm (25 mW)
#define TX_DC      10.0    // TX Duty Cycle (% percent)
#define PAMB       8       // Preamble Length [6..20] 
#define XOV        1.7     // TCXO Voltage (V)
#define LDO        false   // Use LDO only ? [false:LDO and DC-DC, true: just LDO]

The full software can be found here:
https://github.com/MarusGradinaru/lora-p2p
It works on ESP32 and Raspberry Pi Pico.

What do you think ? 😃

[jgromes]

I would recommend sticking to the 0x12 sync word for private networks (as that is whast you have, a non-LoRaWAN private "network" with two nodes in it). Using other values might have some side effects. You might also want to try different SF and BW values to find the best tradeoff between range, power consumption and data rate. Other than that, glad to see you running the experiments!

[MarusGradinaru]

Does RadioLib library is compatible with the latest Arduino-ESP32 framework, version > 3.0 ?
It seems that the default instaled framework version in my Platform IO was 2.0.17. And I want to upgrade...

[jgromes]

I'm not completely sure - the easiest/fastest way is to just try it. For what it's worth, our CI (continuous integration) builds RadioLib on Arduino-ESP32 version 2.0.17.