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.
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 …
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 …
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? Onethinx.com | Module
(*) 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:
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,
Transmitting, not receiving. Which makes it even more unlikely.
Indeed, something is wrong or severely inequitable in the comparison.
Realistically, transmit power is mostly limited by law, not hardware choice.
I’ve been using the RHF0M062 and RAK4200 modules and they both work very well…
never going beck to using the LMic stack…
RHF0M062 AT command are well documented and are mostly complete, based on the older RHF78-052, supports ver 1.02 and 1.03 via a command, class A-B-C support . SX1262 and Cypress 32bit 4100s MCU
RAK4200 AT command are also well documented, based on the RAK811, support ver 1.02, soon with have 1.03 and 1.1 support, STM32L071 MCU and an SX1276
Just looked through the manual for the RHF0M062 and it looks really nice. The API is much more clean and organized compared to the HopeRF and Dragino SX1262 modules. I’ll probably try that one out next time.