RadioShield

For quite a while now, there's been a bit of a backlog in the TODO list in RadioLib readme. Today, I can finally say that I have crossed one of the items off - nRF24 support is now in RadioLib!

I noticed something interesting about RadioLib - sometimes, adding support for new modules has some unforeseen consequences. Thanks to the modular interface-based design, old protocols can work seamlessly with new radios, even if that wasn't the original intention.

This was one of these "unforeseen consequences" - did you know it is possible to transmit Morse code using nRF24? Neither did I, and here's the SDR recording of exactly that:

I believe I have now topped my personal record in "most useless radio application" (previously set by "using SX1278 LoRa module as an FM radio to transmit .wav file"). Who needs data rates of up to 2 Mbps, when you can have good ol' fashioned 120 words per minute! You don't even need nRF24 to receive it, a skilled operator from the early 20th century can do the job for you - assuming you provide him with the equipment to receive the 2.4 GHz Morse code, of course.

Speaking of equipment, mine is rather basic. I'm still using RTL-SDR dongle, which has served me well for the past few years. It does have a small issue, in that it can only receive up to 1 GHz. How did I receive the 2.4 GHz signal you ask? I got an antenna with a down converter! That takes in the 2.4 GHz signal, shifts it down by 2278 MHz and we're in a convenient 100 - 200 MHz range, perfect even for the cheapest SDR. Isn't it an overcomplicated solution to a trivial problem? Of course it is, you could have probably noticed the pattern by now.

And that's about it for this update! More stuff is in development (maybe), so stay tuned! Preferrably to 2.4 GHz for the best Morse code out there!

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!

What's with the new name?

Let's get the obvious change out of the way first - the project was rebranded to RadioShield! Hopefully, this makes it more clear that the purpose of both the shield and the library is radio communication. There is also an open-source smartphone project named Kite, so admittedly, the name was pretty confusing from the very beginning. 

From now on, the hardware documentation for this project will be hosted at https://github.com/jgromes/RadioShield and the software at https://github.com/jgromes/RadioLib

Hardware Revision C

Along with the name change, there's also the newest hardware revision! This one was marked by a shift in the overall design philosophy - instead of supporting 3.3V and 5V wireless modules, only 3.3V modules are now supported (all wireless modules intended to be used with RadioShield are 3.3V anyway). In exchange for that, RadioShield now supports 3.3V and 5V Arduino boards!

Also, rev. C is much cheaper to make than the previous revisions and features improved compatibility with Arduino boards like Mega! There were also changes to the layout of module breakout boards - instead of mounting the module from the top, it's now mounted from the bottom. Not only this protects the modules from the outside environment, it also leaves the top side exposed for antenna connectors and LED indicators!

New modules

• CC1101 FSK module
• nRF24 2.4 GHz module
• SIM900C GSM module

Hardware for all of them is assembled, and software is currently under development.

In conclusion, RadioShield is now cheaper, better and more universal than ever before!

KiteLib now supports FSK modem on SX127x LoRa chips. Not only does this mean that you can freely swap between LoRa and FSK communication with a single communication module - there are some more interesting ways the FSK modem can be used:

RTTY Transmissions
By manipulating FSK carrier wave frequency, we can get the module to output RTTY data! This has been done in a few SX1278 projects before, but KiteLib is the first to implement user-friendly API. Using RTTY is now exactly as easy as using Arduino Serial port!

FM Transmissions
FSK modem also supports so-called continuous mode, in which the radio directly tranmits data fed to it on pins DIO1 (data) and DIO2 (clk). Here's the cool part: if you feed Arduino tone() function output into DIO2, this is the result: 

Yep. This signal was decoded using "Broadcast FM" in SDR Console app, so it should be possible to receive the tone() output on any FM receiver (as long as it can receive on 434 MHz).

So in summary, KiteLib can now send LoRa packets, FSK packets, RTTY transmissions and FM tones from a single communication chip.