A while back, Semtech (the company behind LoRa) released a new line of LoRa transcievers - the SX126x series. I'm now proud to announce that SX126x support has been added to RadioLib! All the features that RadioLib/LoRaLib supports on SX127x are now available for SX126x as well, and in the same user-friendly API!

The reason for this addition to RadioLib is twofold:

1. Come on, it's a new LoRa module, how I could pass that. Especially since there seems to be no dedicated Arduino library for it (at the time of writing).
2. RadioLib is going to space! That's right, RadioLib will be used to provide LoRa, GFSK and RTTY communication for FOSSASAT-1 - open source picosatellite, that will (hopefully) be launched this October! The project is crowdfunded, check it out at https://www.gofundme.com/fossasat1-la-democratizacion-del-espacio/

But why SX126x, and not just the good-ol'-fashioned SX127x? There is very little doubt that SX126x is superior to SX127x series (note: Semtech didn't pay me to write this; not that I would turn them down if they wanted to). The receiver sensitivity has been improved, channel activity detection can now detect the whole LoRa transmission and not just the preamble, there's a better support for temperature-compensated crystals, and the list goes on and on. Clearly, a lot of thought has went into the design of this new and improved LoRa module.

Now, with that being said ...

WARNING: SLIGHTLY TECHNICAL RANT AHEAD! Read at your own peril.

I would very much like to know who designed the SX126x SPI interface, because it's probably the most unneccessarily convoluted thing I have ever seen. You see dear reader, in SX127x series, all configuration was done with a series of SPI registers. Want to change frequency or bandwidth? Write a register value, simple as that. Want to check current setting? Read the value back out. It's simple to implement, and it works. Other similar RF modules (like TI's CC1101, or HopeRF's RFM69) have a very similar interface.

On SX126x however, most configuration is done using SPI commands. In itself, that wouldn't be that bad. The problem (or rather, one of the problems) is that you can't just change one parameter; you have to change a bunch of them all at once, in a single command. For example, when setting channel bandwidth, you also have to set several other parameters, like coding rate, spreading factor, low data rate optimization, etc. - even if you don't actually want to change their values! There's also no way to read settings, so everything has to be saved on the host system. I probably wouldn't even mind, if all of the SPI registers were replaced with SPI commands, but that's the thing: THEY WEREN'T! There's a bunch of them still lying around, to save stuff like sync word bytes and CRC configuration. And judging by their addresses (0x06B8 to 0x912), there's a lot more undocumented registers. My main bet is that ALL the settings are still saved in those registers, only now they are undocumented and/or inaccessible! This is basically taking a well known, proven system and then slapping a new layer over it - without getting any benefits in return.

WHY?! Who thought this was a good idea? I'm genuinely curious as to the justification behind this. It surely must have been a lot more complicated (and expensive) than just using the same register-based interface as the previous modules - perhaps even keeping some level of compatibility. Instead, they decided to implement this fairly unique mess ...

Perhaps I'm wrong and this new and improved SPI interface is the next step, and soon all RF modules will be using the Semtech's SPI-Command-Paloosa® but I highly doubt it - and may your deity of choice have mercy if it is!

I also have to touch on the documentation quality - mainly the datasheet. For a long time, I considered Semtech's datasheets one of the best - well structured and accurate. With SX126x however, the accurace is quite simply gone. Take the power amplifier configuration, for instance. The datasheet only gives a few "recommended" configuration values for for different output power settings - six in total. Some of the parameters aren't explained in any way, so if you want to change the output power to something other than the "recommended" values, you're out of luck - you can no longer predict the effects of your specific configuration. Even if it's just something as trivial as decreasing the transmission power level from 14 dBm to 7 (or any other value not included in the "recommended").

There's a lot more I could delve into in both the SPI interface and the docs (why does the module return status code on every transaction byte except for the first one?), but it all boils down to this: SX126x is a really good radio module - with a really bad SPI interface. And since someone has already wrapped up the ugly interface into a nice, user-friendly API, then all that's left is a really good radio module! So, go get one! The price is comparable to any other LoRa module, and with all the added features, I will 100% suggest them over SX127x.

RANT OVER Finally ...

I think that's more than enough for this update. As always, there's more stuff in development for RadioLib, so stay tuned!