Mbed SX1261MB2BAS configuration

Hi everyone,

For educational purposes, I’ve been trying to write an application that uses Semtech’s SX1261 modem, embedded on the SX1261MB2BAS shield, to send a message to another LoRa device: Seeed Studio’s HopeRF RFM95-based Grove LoRa module (868MHz version).

I’m using the Nucleo-STM32F103 board (which has an STM32F103RBT6 CPU) to communicate with the SX1261 shield. I have written an application in Rust, which essentially follows the steps in paragraph 14.2: ‘Circuit Configuration for Basic Tx Operation’ from the SX126x data sheet.

On the receiving side, I’m using pyRFM’s rfm95_server example, which prints any received messages in my terminal. I’m using the standard configuration: 125kHz bandwith, coding rate 4/5, Spread factor 7, CRC ON. This works pretty much out pf the box when sending data between two Grove LoRa modules.

However, my application does not seem to be able to send a message to the Grove LoRa module. I have done some logic analysis with a Saleae Logic analyzer, and the analysis seems to show a correct communication sequence between the STM32F103 and the SX1261.

I have uploaded my code to this GitHub repo.
The code is written in Rust. I did add some annotations which should clarify what I’m trying to do.

I have a couple of questions about it:

  • Is it at all possible to send LoRa messages directly from an SX1261 to a HopeRF RFM95?
  • If so, what am I doing wrong?

Thanks in advance,

Henk

@LoRaTracker would be best to answer, but there are some key differences between the two radio chips you have there.

But this is the TTN forum, so mostly help will be centred around you getting a LoRaWAN packet from one of your devices to TTN via a gateway.

The SX127X and SX1261X series are chalk and cheese really.

They do interface completly differently as you seem to have found, the SX127X is configured by writing to a series of registers (0x00 to 0x7F) whilst the SX126X is configured by a series of API style commands, and has registers as well.

The SX127x and SX126x do talk to each other, with the exception of not bieng compatible for SF6, and the SX127x does not have SF5 of course. You can also get into a right pickle if you start changing syncwords. Apart from that the two ranges do talk to each other just fine, when configured correctly.

Rust I dont know, but I dont see a setup for the TCXO which is often fitted to the SX126x.

I have written an Arduino library that uses a common sketch style and function calls across the SX126X,SX127X and SX128X range, there are basic TX and RX examples that work on Atmel, ESP32 and some have been tried on STM32. Someone did report a problem with the SX1261MB2BAS, so presumably it needs some particular setup.

If someone were to donate a couple of the SX1261MB2BAS to me I would check it out.

This is the setup I use for a SX126X;

//***************************************************************************************************
  //Setup LoRa device
  //***************************************************************************************************
  LT.setMode(MODE_STDBY_RC);
  LT.setRegulatorMode(USE_DCDC);
  LT.setPaConfig(0x04, PAAUTO, LORA_DEVICE);
  LT.setDIO3AsTCXOCtrl(TCXO_CTRL_3_3V);
  LT.calibrateDevice(ALLDevices);                //is required after setting TCXO
  LT.calibrateImage(Frequency);
  LT.setDIO2AsRfSwitchCtrl();
  LT.setPacketType(PACKET_TYPE_LORA);
  LT.setRfFrequency(Frequency, Offset);
  LT.setModulationParams(SpreadingFactor, Bandwidth, CodeRate, Optimisation);
  LT.setBufferBaseAddress(0, 0);
  LT.setPacketParams(8, LORA_PACKET_VARIABLE_LENGTH, 255, LORA_CRC_ON, LORA_IQ_NORMAL);
  LT.setDioIrqParams(IRQ_RADIO_ALL, (IRQ_RX_DONE + IRQ_RX_TX_TIMEOUT), 0, 0);   //set for IRQ on TX done and timeout on DIO1
  LT.setHighSensitivity();  //set for maximum gain
  LT.setSyncWord(LORA_MAC_PRIVATE_SYNCWORD);
  //***************************************************************************************************
1 Like

Hi, thanks for your elaborate answorer. It seems my SX1261 is not fitted with a TCXO, just with a 32MHz XTAL. Trying to calibrate the device after setting dio3 as TCXO ctrl, results in an error status. Also, I’m not sure wheter a DC-DC regulator is availabe.

Could you provide any details on the specific problem?

Thanks

The reported problem was that one of my programs, which otherwise works fine, would appear to go into transmit but there would be no TX_Done or timeout IRQ activating the DIO1 pin.

Hmm that does not happen with the particular board I’m using.

You did not actually say what the problem was, apart for that you could not send a message.

Is the SX1261MB2BAS actually trasnmitting, is the frequency correct, is the air time about right …

You’re correct. My question is quite unspecific, which is part of the problem. The reason for that is that I have no idea how to pinpoint the cause of the problem any further, as I’m not in the possession of a spectrum analyzer or an oscilloscope. May I ask which analysis tools you use in general to diagnose LoRa connectivity problems?

Will I be able to answer these questions using an RTL-SDR?

I use a cheap SDR to see if its transmitting, check the frequency and bandwidth and at high spreading factors you can see if the air time of a packet is as expected.

And I do have proven working modules and code for most all of the LoRa modules …

That does help. I’m going to try and run you tx example and see if that works.

With the RTL-SDR I found out that a couple of things were going wrong:

  • I was sending with FSK modulation
  • The value I was passing to SetRfFrequency was incorrect, causing the modem to send on 915MHz
  • The preamble length was 0x0800 instead of 0x0008, which is just slightly off
  • The PacketParams were not correct (header type and payload length interchanged, crc needed to be switched on

With those issues fixed, I am now able to receive messages with the Grove LoRa module using pyRFM.

Hope somebody in the future is helped with this info.

Having established a working Rust application for the sx1261, I will now continue to work on my more generic Rust driver implementation.