Some notes on the SX1262;
3 Likes
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.
Thank you! i do understand, but there are very few information globally even in semtech support page. what is reason would be sx1262 could get preabmle detect and no other interrupts (header err, header ok, rxdone. etc).
Might be syncword issues, but its not a problem seen in TTN as far as I am aware.
I have a question, how can i transmite to TTN using a sx1262 but adding on a raspberry pi 4, somebody have some information, or something that could help me?
That’s not really supported, nor sensible.
First, you cannot just “transmit to TTN” - rather, its absolutely required that your device implement the full bidirectional LoRaWan protocol.
This has timing that’s a bit difficult under the pi’s multi-tasking Linux operating system and is a better fit for a small flash-based MCU dedicated to that task. There are ways it could be done on a pi, but nobody bothers to implement that, because most applications that can afford the power consumption of a pi also need more data than you are allowed to move over TTN.
If you’ve got an application that really, really fits TTN and uses a pi, you probably want to look at getting an SX1262 packaged in a module with its own MCU implementing the LoRaWan protocol stack and interfacing to an arbitrary host such as a pi via a serial UART with an AT command set.
If you can make a very, very strong case for why an SX1262 should be wired directly to a pi, and are willing to do a lot of low level programming yourself, the necessary changes can be explained… but that would need to be its own thread on that subject matter.
And first you need to demonstrate that you really understand the limitation on the amount of data you can expect to move through TTN.
And why a SX1262 ?