Has anyone tried the new SX1262-based modules?

I want to use the new SX1262 chip from Semtech, but I also don’t want to attempt to implement the gigantic lorawan stack in my own project to get it to work. As a result I’ve been looking for a module that packages all of that nonsense into something that lets me send it serial commands, similar to the Microchip RN2903.

Here are two options that I’ve found.
https://www.dragino.com/products/lora/item/150-lm502.html
https://www.hoperf.com/modules/LoRaWAN/RFM6501W.html

They both make me a bit nervous – I have a feeling I won’t be able to get them to work. It looks like the module from dragino is missing some AT commands that are needed to enable only certain channels and to set a specific frequency for those channels.

Has anyone tried these or something similar?

“All of that nonsense”?

The LoRaWAN spec :wink:

It is, to say the least, complicated with a lot of things that are fairly hard to implement in practice… most implementations have had a long path to sound functionality, with or without spec compliance. That said, rather than an argument for handing over the task, I personally see this is a reason why it is absolutely critical that the code lives where one can fix it.

To address the original question, I think there’s a thread around here somewhere about the Heltec PSoC + SX1262 offering but do not remember the details. And I think I might(?) have seen some hints in the pycom microphython node side implementation (while looking for the gateway code they seem not to have published). LMiC does not seem to have it as it would be substantial work to switch radio interfaces. One could check if the more official LoRaMACNode stack has support… rereading I realize that list is heavily biased towards codebases that hopefully work but are maintainble rather than canned solutions with “no user serviceable parts inside” as the asker was apparently seeking.

Ultimately, the best all-around solution may be something that is believed to work in the condition in which it is sold, but where the code that makes it work is in a public repo, and where someone independent of the manufacturer reports that they’ve successfully built and flashed that. Seeing a 3rd party pull request for some small fix would thus be an encouraging sign.

2 Likes

Has anyone tried the new SX1262-based modules?

Yes, and they have some benefits for point to point LoRa use.

Not sure there is much of an advantage for TTN use however.

Yeah that’s what I meant by nonsense. I did go through the effort of porting the latest LoRaMAC-node code over to Arduino, but it’s a huge pain in the butt and I didn’t quite get it to work reliably. I’d rather have someone else do this task who has more time to port the code and test everything, and then package that into a module. It just feels like I’m reinventing the wheel.

I wanted to try an SX1262 based module for the range increase. (22dB vs 18.5dB)

The SX127X would have been capable of 20dBm, but TTN limits you to 14dBm in most places.

We, your servants, will go forth and make the code for you, our master, to use without any effort.

How the heck do you think these things come to be?

Make the effort of merging @LoRaTracker’s code with the most likely Arduino LMIC candidate, and you will redeem yourself and we will worship you …

1 Like

My point is that this task has already been done before by a large company – that’s all the RN2903 and RN2483 are. Some employees got paid to take LoRaMAC-node (or LMIC) and put a serial wrapper around it and now it’s the most popular LoRaWAN module out there.

Yes, every person could spend weeks properly porting over the stack of lorawan code to each of their lora projects, but ultimately that’s a waste of time and effort when a company could do it one time and offer it as standalone serial module that works across all platforms.

…but yes you are right, maybe I should attempt to do it myself instead of waiting for a company to do it.

Feel free to contact lots of compainies and tell them the great opportunity they are missing out on …

1 Like

Myself, I cannot see a good reason why anyone would choose to put the time and effort into producing an RN2483 equivalent for the SX1262.

The extra 2dBm is one I guess, giving maybe 25% more distance for the few places where that is legal …

Power consumption would be the main one

Have you looked at the Onethinx PSoC 6 (Cypress) based 126x(*) module … integrated LoRaWAN stack, BTLE, embedded secure element & Integrated (PCB) antenna? https://www.onethinx.com/module.html

(*) Literature & web variously refer to '61, '62, & 6x!.. you may want to check options with @Rolf1
Not AT command based and uses dev kit other than arduino based if that is important to but…

Been a bit quiet on the forum lately…

It can get confusing.

The SX126X series have internal support for a DCDC switcher to power the RF side, previous SX127X series used a LDO.

The DCDC switcher can cut power consumption in half, but on the SX1262 and SX1268 the switcher only operates on the RX side. With a TTN node spending very little time in receive mode there is little power saving and no particular advantage in using the SX1262 or SX1268.

The SX1261 however uses the DCDC switcher to power RX and TX, so potentially would be close to cutting the LoRa device power consumption in half and significantly extending battery life. That would be a significant advantage over SX127X devices.

I’d say it mostly depend on the application. If you are designing a node and you’ll manufacture less than 1000 units, you can go ahead and look for a module. If you are planning for larger qtys, I’d invest in a certified radio module and run the LoRaWAN stack on STM32 and call it a day making way better margins and controlling the supply chain easier.

Hello there,

Can you please check https://github.com/Lora-net/LoRaMac-node
As I see https://github.com/Lora-net/LoRaMac-node/tree/master/src/radio/sx126x support there.

So I don’t think you need to worry about stack integrations.
It will just depend on which MCU/SIP/SOC you plan to use.

On another note the new STM32WL chip from ST st.com/en/microcontrollers-microprocessors/stm32wl-series.html is expected to have a great SX126x support.

If anyone is interested, I ordered a HopeRF RFM6501W (which uses an SX1262) and tested it against a Microchip RN2903:

image

I disabled ADR on both and set both modems to SF10BW125 with max power output settings. Here is the RSSI+SNR from a fixed location for both. As you can see, the signal from the RFM is noticeably
stronger.

RN2903
“data_rate”: “SF10BW125”,
“coding_rate”: “4/5”,
“rssi”: -77,
“snr”: 8

RFM6501
“data_rate”: “SF10BW125”,
“coding_rate”: “4/5”,
“rssi”: -53,
“snr”: 10

Here is a quick sketch I used to test the RFM module:

#define DEV_EUI "D891231340"
#define APP_EUI "70B3D123133472"
#define APP_KEY "2CD2123213BB2B726E36264"

// RFM
#define loraRfmSerial Serial7
#define LORA_RFM_RESET_PIN 30

void printResponse(void)
{
  delay(500);

  while (Serial7.available())
  {
    Serial.write(Serial7.read());
  }
}

void setup()
{
  Serial.begin(115200);
  Serial7.begin(115200);
  delay(5000);

  // Reset LoRa modem
  pinMode(LORA_RFM_RESET_PIN, OUTPUT);
  digitalWrite(LORA_RFM_RESET_PIN, LOW);
  delay(2000);
  digitalWrite(LORA_RFM_RESET_PIN, HIGH);
  delay(2000);

  // Get DEV EUI (for some reason the first command always fails)
  Serial7.write("AT+CDEVEUI?\r");
  printResponse();

  // Get DEV EUI
  Serial7.write("AT+CDEVEUI?\r");
  printResponse();

  // Set APP EUI
  Serial7.write("AT+CAPPEUI=");
  Serial7.write(APP_EUI);
  Serial7.write("\r");
  printResponse();

  // Set APP Key
  Serial7.write("AT+CAPPKEY=");
  Serial7.write(APP_KEY);
  Serial7.write("\r");
  printResponse();

  // Set Join Mode to OTAA
  Serial7.write("AT+CJOINMODE=0\r");
  printResponse();

  // Set App Port to 1
  Serial7.write("AT+CAPPPORT=1\r");
  printResponse();

  // Use channels 8-15
  Serial7.write("AT+CFREQBANDMASK=0002\r");
  printResponse();

  // Disable ADR
  Serial7.write("AT+CADR=0\r");
  printResponse();

  // Set Data rate (SF10 - BW125)
  Serial7.write("AT+CDATARATE=0\r");
  printResponse();

  // Set uplink frequencies
  Serial7.write("AT+CFREQLIST=1,2,8,903900000,904100000,904300000,904500000,904700000,904900000,905100000,905300000\r");
  printResponse();

  // Set downlink frequencies
  Serial7.write("AT+CFREQLIST=2,2,8,923300000,923900000,924500000,925100000,925700000,926300000,926900000,927500000\r");
  printResponse();

  // Set RX2 window...missing BW500 options in CDATARATE needed for US915
  //Serial7.write("AT+CRXP=0,0,923300000\r");
  //printResponse();

  // Join
  Serial7.write("AT+CJOIN=1,1,10,8\r");
  delay(15000);
  printResponse();
}

void loop()
{
  while (Serial7.available())
  {
    Serial.write(Serial7.read());
  }

  // Send some data
  Serial7.write("AT+DTRX=0,1,22,48656C6C6F48656C6C6F00\r");
  printResponse();
  delay(20000);
}

The module does work, but it’s missing a command that would be needed to properly setup the RX2 window for US915.

Sorry, but a 24 dB difference in uplink signal is clear indication that something is wrong with one of the tests.

Try moving the node further away so you’re getting signal in more like the -100 to -80 range and repeat the test.

Be careful that you’re using the same antenna type on both, and have commanded the same transmit power level

Make sure antenna connection is tight (tools not finger tight) & then swap antenna and average/analyse results from the two versions. Also do runs with just one antenna connected and tx’ing (make sure the one without ant is powered off to avoid damage) also rotate system wrt distant receiver to ensure local loading and unbalanced reflections reduced. Make sure rcvr is well into far field and not too close to test set up, and test in open environment…a large field?

I moved the gateway further away and here are my results:

RN2903
“data_rate”: “SF10BW125”,
“coding_rate”: “4/5”,
“rssi”: -112,
“snr”: -8.5

RFM6501
“data_rate”: “SF10BW125”,
“coding_rate”: “4/5”,
“rssi”: -95,
“snr”: 8.5

The antennas are both the same. I’ve tried swapping them and it makes no difference. For the RN2903 I’m using the arduino-device-lib library and PWRIDX=5, which I think is the max setting. I’m not sure what else could be wrong?

And in this case the RFM6501 is allegadly receiving signals at +8.5dB SNR and the RN2903 is receiving them at -8.5dB SNR.

Thats a difference of 17dBm.

One of those devices is broken, incorrectly connected, or reporting the wrong signal levels,