Not so keen to invest the money to test a SX1261MB2BAS, willing to accept freebies though.
I wonder if the different interface has put developers off, the SX1261/2 (and SX1280/1) are not register centric like the SX127x, but its not so difficult a change really ?
Although the silicon can be bought, its the availabilty of modules such as RFM96 etc that has a major affect on the application take up.
Written a complete new stack for these devices for our Onethinx LoRaWAN core.
I love these devices, lower power consumption and higher output.
I’ve seen that your topic was automatically closed … I opened it 
https://www.thethingsnetwork.org/forum/t/onethinx-core-module/22633/48
One oddity that does not assist compatibility between the SX126x and SX127x devices is the way they handle the ‘LoRa Sync Word’
The Semtech SX126x data sheet says;
Set to 0x3444 for Public Network
Set to 0x1424 for Private Network
And the SX127x datasheet says;
LoRa Sync Word - Value 0x34 is reserved for LoRaWAN networks.
So 16bits of ‘Sync Word’ for SX126x and 8bits of ‘Sync Word’ for SX127x.
Apparently Public Network = LoRaWAN network.
And yes for a Private (non LoRaWAN) network you set the SX126x to 0x1424 and the SX127x to 0x12.
I’m not sure this really different on the air, vs. different in how you configure it, but it could be interesting to ask Semtech about if there’s a way to do so.
I’ve noticed that the detection of the sync word is fairly leaky in terms of mismatches still being picked up some fraction of the time by gateways; it might be interesting to do statistical tests with different values in the node and see what is most successful in being detected by a gateway with TTN’s normal public lorawan network sync word setting.
Oh I have, and the developer portal guys did say how the LoRa sync word is configured, but as far as I know there is no explanation in the data sheets. Can you spot how its done, in essense (SX126x 16bit versus SX127x 8bit)
0x3444 = 0x34
0x1424 = 0x12
I too have noticed the detection of sync word is ‘leaky’ (I do like to check these things) which you might be inclined to think is a bug or at least worthy of a proper explanation.
According to the documentation,
RF transmitter output (SX1261 low power PA or SX1262 high power PA)
That probably explains why.
Hi Grazy,
From the code you have,
`.dio = {/* busy */ 9, /* DIO1 */ 8},`
How does this work? Is the busy Pin used same as DIO0 in the SX1276?
No, the BUSY pin is the BUSY pin. It indicates when the SX1261/2 is BUSY doing something as in it has not finished processing the last command.
The DIO0 pin on a SX1276 is normally programmed to tell you something has happened, a packet received, finished sending a packet etc.
Hi,
As @LoRaTracker say DIO0 from SX1276 and BUSY from SX1262 has nothing in common.
SX1262 do not have DIO0 and you can program the chip to send all events on DIO1 (this is simpler than SX1271)
But SX1262 has a BUSY pin that the SX1276 do not have. The code need to know connection of BUSY pin and DIO1 pin.
I reuse the same struct for the new chip.
for SX1276 .dio is [DIO0, DIO1]
for SX1262 .dio is [BUSY, DIO1]
The values are not used the same way in the library depending on which radio module is define for object radio line 32.
I may have to add more explanation to the README or make two different structure (it will make the compiled library larger).
I was curious to tests the low current capability of the SX1261, the data sheet says that current consumption during transmit should be around 25mA @ 14dBm, which is under half of what I measure on a Sx127x.
Considering that most of the battery power for a TTN node would be transmit power, the SX1261 promises to save you all that faff chasing very low sleep currents, which have a very marginal effect on battery life. Use a SX1261 and potentially you could double battery life.
I could not find a SX1261 module so I swapped the SX1262 on one of my modules for a SX1261 IC. Current consumption during TX for this modified module is around 35% lower than a SX127x. It would be unfair to give an exact figure, since I dont known if the switching inductor on the SX1262 module was the right part to power the PA on the SX1261.
Sleep current of the SX1261\62 is around half that of a SX127x, at 5mA.
Anyone know of a SX1261 module in the style of the RFM96 etc ?
Did you do the circuit modification what i marked with red?
Not sure what you are suggesting,
The left picture, you posted, shows the switching inductor in place, and it is there on the SX1262 module I was testing.
What i understand based on Semtech datasheet in case of SX1262 to reach the 22dBm output the PA needs 3.3V (3.1V on schematic?). It means that the SX1262 module schematic should be like on the right side (REG PA direct connection to VBAT). If you have module with SX1262 but the shema is same as left side the output will not reach the 22dBm because the VDD IN for REG PA is 1.55V (it is a buck converter so it can produce lower voltage than input).
You swapped the IC on the SX1262 module to SX1261 right? I think you need to modify the connection on your PCB to the same as left side to reach the lower consumption. (Additionally the higher input voltage on REG PA means higher output voltage and it is possible to fry your low power PA in SX1261).
Thanks, it prompted me to RTFM. There is a similar diagram on pages 33+ of the datasheet.
Whether it can be modified will require a very close inspection of the module.
I would suspect that the additional inductor on the SX1261 circuit, in the PA_SUPPLY line, is to reduce switching noise getting into the PA, so for test purposes it might be possible to replace it with a wire short.
Hi there, Have you done OTAA with sx1262? My custom module could send join req to the server, but no join ack catched…
Any experience like that?
Not tried the TTN stuff yet …
Which library are you using ?
Thanks for respond. My firmware based on lorawan bacismac, but under freertos and server is not TTN. Petr’s server. Server got join request, but lose many request too. My node getting preambledetect interrupt but no more… Seems to be sx1262 receiver logic has some bug, specially on sync word detecting
I raised a query about the syncword rules back in November, and Semtech have recently commented that they will publish something ‘within a month’ about the mysteries behind what syncwords work and which dont.
However, interoperability between SX126X to SX127X is fine as long as the SX126X syncword (16bits) is compatible with the SX127X one (8bits), which they are for TTN. So I see no inherrent issue with the SX126x if the published syncword is used.
Also note that if your getting interoperability issues with the SX126x on a non TTN server, this is probably not the right place to get an answer.