We ship Feathers fully tested but without headers attached - this gives you the most flexibility on choosing how to use and configure your Feather

Header Options!

Before you go gung-ho on soldering, there's a few options to consider!

Soldering in Plain Headers

Soldering on Female Header

Your Feather Radio does not have a built-in antenna. Instead, you have two options for attaching an antenna. For most low cost radio nodes, a short length of wire works great. If you need to put the Feather into an enclosure, soldering on a uFL connector (on Feathers that don’t already include this) and using a uFL to SMA adapter will let you attach an external antenna.

Wire Antenna

A wire antenna, aka "quarter wave whip antenna" is low cost and works very well! You just have to cut the wire down to the right length.

uFL Antenna

If you want an external antenna, you need to do a tiny bit more work but its not too difficult.

For Feather Radio boards that don’t already have a surface-mount uFL connector installed, you’ll need to get one. Feather RP2040 RFM boards already have this installed. Feather M0 and 32u4 require soldering.

You'll also need a uFL to SMA adapter (or whatever adapter you need for the antenna you'll be using, SMA is the most common).

Of course, you will also need an antenna of some sort, one that matches your radio frequency.

For Feather M0 and 32u4:

(this step can be skipped for Feather RP2040 RFM, which already has a uFL connector installed)

For all radio-capable Feather boards:

The first thing you will need to do is to download the latest release of the Arduino IDE. You will need to be using version 1.8 or higher for this guide

After you have downloaded and installed the latest version of Arduino IDE, you will need to start the IDE and navigate to the Preferences menu. You can access it from the File menu in Windows or Linux, or the Arduino menu on OS X.

A dialog will pop up just like the one shown below.

We will be adding a URL to the new Additional Boards Manager URLs option. The list of URLs is comma separated, and you will only have to add each URL once. New Adafruit boards and updates to existing boards will automatically be picked up by the Board Manager each time it is opened. The URLs point to index files that the Board Manager uses to build the list of available & installed boards.

To find the most up to date list of URLs you can add, you can visit the list of third party board URLs on the Arduino IDE wiki. We will only need to add one URL to the IDE in this example, but you can add multiple URLS by separating them with commas. Copy and paste the link below into the Additional Boards Manager URLs option in the Arduino IDE preferences.

https://adafruit.github.io/arduino-board-index/package_adafruit_index.json

Here's a short description of each of the Adafruit supplied packages that will be available in the Board Manager when you add the URL:

• Adafruit AVR Boards - Includes support for Flora, Gemma, Feather 32u4, ItsyBitsy 32u4, Trinket, & Trinket Pro.
• Adafruit SAMD Boards - Includes support for Feather M0 and M4, Metro M0 and M4, ItsyBitsy M0 and M4, Circuit Playground Express, Gemma M0 and Trinket M0
• Arduino Leonardo & Micro MIDI-USB - This adds MIDI over USB support for the Flora, Feather 32u4, Micro and Leonardo using the arcore project.

If you have multiple boards you want to support, say ESP8266 and Adafruit, have both URLs in the text box separated by a comma (,)

Once done click OK to save the new preference settings. Next we will look at installing boards with the Board Manager.

Now continue to the next step to actually install the board support package!

The Arduino IDE gives me "Device Descriptor Request Failed"

This can require "manual bootloading".

If you ever get in a 'weird' spot with the bootloader, or you have uploaded code that crashes and doesn't auto-reboot into the bootloader, double-click the RST button to get back into the bootloader. The red LED will pulse, so you know that its in bootloader mode. Do the reset button double-press right as the Arduino IDE says its attempting to upload the sketch, when you see the Yellow Arrow lit and the Uploading... text in the status bar.

Don't click the reset button before uploading, unlike other bootloaders you want this one to run at the time Arduino is trying to upload

The Feather/Metro/Gemma/QTPy/Trinket M0 and M4 use an ATSAMD21 or ATSAMD51 chip, and you can pretty easily get it working with the Arduino IDE. Most libraries (including the popular ones like NeoPixels and display) will work with the M0 and M4, especially devices & sensors that use I2C or SPI.

Now that you have added the appropriate URLs to the Arduino IDE preferences in the previous page, you can open the Boards Manager by navigating to the Tools->Board menu.

Once the Board Manager opens, click on the category drop down menu on the top left hand side of the window and select All. You will then be able to select and install the boards supplied by the URLs added to the preferences.

Install SAMD Support

First up, install the latest Arduino SAMD Boards (version 1.6.11 or later)

You can type Arduino SAMD in the top search bar, then when you see the entry, click Install

Install Adafruit SAMD

Next you can install the Adafruit SAMD package to add the board file definitions

Make sure you have Type All selected to the left of the Filter your search... box

You can type Adafruit SAMD in the top search bar, then when you see the entry, click Install

Even though in theory you don't need to - I recommend rebooting the IDE

Quit and reopen the Arduino IDE to ensure that all of the boards are properly installed. You should now be able to select and upload to the new boards listed in the Tools->Board menu.

Select the matching board, the current options are:

• Feather M0 (for use with any Feather M0 other than the Express)
• Feather M0 Express
• Metro M0 Express
• Circuit Playground Express
  
• Gemma M0
• Trinket M0
  
• QT Py M0
  
• ItsyBitsy M0
• Hallowing M0
• Crickit M0 (this is for direct programming of the Crickit, which is probably not what you want! For advanced hacking only)
• Metro M4 Express
• Grand Central M4 Express
• ItsyBitsy M4 Express
• Feather M4 Express
• Trellis M4 Express
• PyPortal M4
• PyPortal M4 Titano
• PyBadge M4 Express
• Metro M4 Airlift Lite
• PyGamer M4 Express
• MONSTER M4SK
• Hallowing M4
• MatrixPortal M4
• BLM Badge

Install Drivers (Windows 7 & 8 Only)

When you plug in the board, you'll need to possibly install a driver

Click below to download our Driver Installer

Download and run the installer

Run the installer! Since we bundle the SiLabs and FTDI drivers as well, you'll need to click through the license

Select which drivers you want to install, the defaults will set you up with just about every Adafruit board!

Click Install to do the installin'

Blink

Now you can upload your first blink sketch!

Plug in the M0 or M4 board, and wait for it to be recognized by the OS (just takes a few seconds). It will create a serial/COM port, you can now select it from the drop-down, it'll even be 'indicated' as Trinket/Gemma/Metro/Feather/ItsyBitsy/Trellis!

Please note, the QT Py and Trellis M4 Express are two of our very few boards that does not have an onboard pin 13 LED so you can follow this section to practice uploading but you wont see an LED blink!

Now load up the Blink example

And click upload! That's it, you will be able to see the LED blink rate change as you adapt the delay() calls.

Successful Upload

If you have a successful upload, you'll get a bunch of red text that tells you that the device was found and it was programmed, verified & reset

After uploading, you may see a message saying "Disk Not Ejected Properly" about the ...BOOT drive. You can ignore that message: it's an artifact of how the bootloader and uploading work.

Compilation Issues

If you get an alert that looks like

Cannot run program "{runtime.tools.arm-none-eabi-gcc.path}\bin\arm-non-eabi-g++"

Make sure you have installed the Arduino SAMD boards package, you need both Arduino & Adafruit SAMD board packages

Manually bootloading

If you ever get in a 'weird' spot with the bootloader, or you have uploaded code that crashes and doesn't auto-reboot into the bootloader, click the RST button twice (like a double-click)to get back into the bootloader.

The red LED will pulse and/or RGB LED will be green, so you know that its in bootloader mode.

Once it is in bootloader mode, you can select the newly created COM/Serial port and re-try uploading.

You may need to go back and reselect the 'normal' USB serial port next time you want to use the normal upload.

Ubuntu & Linux Issue Fix

 Follow the steps for installing Adafruit's udev rules on this page.

The ATSAMD21 and 51 are very nice little chips, but fairly new as Arduino-compatible cores go. Most sketches & libraries will work but here’s a collection of things we noticed.

The notes below cover a range of Adafruit M0 and M4 boards, but not every rule will apply to every board (e.g. Trinket and Gemma M0 do not have ARef, so you can skip the Analog References note!).

Analog References

If you'd like to use the ARef pin for a non-3.3V analog reference, the code to use is analogReference(AR_EXTERNAL) (it's AR_EXTERNAL not EXTERNAL)

Pin Outputs & Pullups

The old-style way of turning on a pin as an input with a pullup is to use

pinMode(pin, INPUT)
digitalWrite(pin, HIGH)

This is because the pullup-selection register on 8-bit AVR chips is the same as the output-selection register.

For M0 & M4 boards, you can't do this anymore! Instead, use:

pinMode(pin, INPUT_PULLUP)

Code written this way still has the benefit of being backwards compatible with AVR. You don’t need separate versions for the different board types.

Serial vs SerialUSB

99.9% of your existing Arduino sketches use Serial.print to debug and give output. For the Official Arduino SAMD/M0 core, this goes to the Serial5 port, which isn't exposed on the Feather. The USB port for the Official Arduino M0 core is called SerialUSB instead.

In the Adafruit M0/M4 Core, we fixed it so that Serial goes to USB so it will automatically work just fine.

However, on the off chance you are using the official Arduino SAMD core and not the Adafruit version (which really, we recommend you use our version because it’s been tuned to our boards), and you want your Serial prints and reads to use the USB port, use SerialUSB instead of Serial in your sketch.

If you have existing sketches and code and you want them to work with the M0 without a huge find-replace, put

#if defined(ARDUINO_SAMD_ZERO) && defined(SERIAL_PORT_USBVIRTUAL)
  // Required for Serial on Zero based boards
  #define Serial SERIAL_PORT_USBVIRTUAL
#endif

right above the first function definition in your code. For example:

AnalogWrite / PWM on Feather/Metro M0

After looking through the SAMD21 datasheet, we've found that some of the options listed in the multiplexer table don't exist on the specific chip used in the Feather M0.

For all SAMD21 chips, there are two peripherals that can generate PWM signals: The Timer/Counter (TC) and Timer/Counter for Control Applications (TCC). Each SAMD21 has multiple copies of each, called 'instances'.

Each TC instance has one count register, one control register, and two output channels. Either channel can be enabled and disabled, and either channel can be inverted. The pins connected to a TC instance can output identical versions of the same PWM waveform, or complementary waveforms.

Each TCC instance has a single count register, but multiple compare registers and output channels. There are options for different kinds of waveform, interleaved switching, programmable dead time, and so on.

The biggest members of the SAMD21 family have five TC instances with two 'waveform output' (WO) channels, and three TCC instances with eight WO channels:

• TC[0-4],WO[0-1]
• TCC[0-2],WO[0-7]

And those are the ones shown in the datasheet's multiplexer tables.

The SAMD21G used in the Feather M0 only has three TC instances with two output channels, and three TCC instances with eight output channels:

• TC[3-5],WO[0-1]
• TCC[0-2],WO[0-7]

Tracing the signals to the pins broken out on the Feather M0, the following pins can't do PWM at all:

• Analog pin A5

The following pins can be configured for PWM without any signal conflicts as long as the SPI, I2C, and UART pins keep their protocol functions:

• Digital pins 5, 6, 9, 10, 11, 12, and 13
• Analog pins A3 and A4

If only the SPI pins keep their protocol functions, you can also do PWM on the following pins:

• TX and SDA (Digital pins 1 and 20)

analogWrite() PWM range

On AVR, if you set a pin's PWM with analogWrite(pin, 255) it will turn the pin fully HIGH. On the ARM cortex, it will set it to be 255/256 so there will be very slim but still-existing pulses-to-0V. If you need the pin to be fully on, add test code that checks if you are trying to analogWrite(pin, 255) and, instead, does a digitalWrite(pin, HIGH)

analogWrite() DAC on A0

If you are trying to use analogWrite() to control the DAC output on A0, make sure you do not have a line that sets the pin to output. Remove: pinMode(A0, OUTPUT).

Missing header files

There might be code that uses libraries that are not supported by the M0 core. For example if you have a line with

#include <util/delay.h>

you'll get an error that says

fatal error: util/delay.h: No such file or directory
  #include <util/delay.h>
                         ^
compilation terminated.
Error compiling.

In which case you can simply locate where the line is (the error will give you the file name and line number) and 'wrap it' with #ifdef's so it looks like:

The above will also make sure that header file isn't included for other architectures

If the #include is in the arduino sketch itself, you can try just removing the line.

Bootloader Launching

For most other AVRs, clicking reset while plugged into USB will launch the bootloader manually, the bootloader will time out after a few seconds. For the M0/M4, you'll need to double click the button. You will see a pulsing red LED to let you know you're in bootloader mode. Once in that mode, it wont time out! Click reset again if you want to go back to launching code.

Aligned Memory Access

This is a little less likely to happen to you but it happened to me! If you're used to 8-bit platforms, you can do this nice thing where you can typecast variables around. e.g.

uint8_t mybuffer[4];
float f = (float)mybuffer;

You can't be guaranteed that this will work on a 32-bit platform because mybuffer might not be aligned to a 2 or 4-byte boundary. The ARM Cortex-M0 can only directly access data on 16-bit boundaries (every 2 or 4 bytes). Trying to access an odd-boundary byte (on a 1 or 3 byte location) will cause a Hard Fault and stop the MCU. Thankfully, there's an easy work around ... just use memcpy!

uint8_t mybuffer[4];
float f;
memcpy(&f, mybuffer, 4)

Floating Point Conversion

Like the AVR Arduinos, the M0 library does not have full support for converting floating point numbers to ASCII strings. Functions like sprintf will not convert floating point.  Fortunately, the standard AVR-LIBC library includes the dtostrf function which can handle the conversion for you.

Unfortunately, the M0 run-time library does not have dtostrf.  You may see some references to using #include <avr/dtostrf.h> to get dtostrf in your code.  And while it will compile, it does not work.

Instead, check out this thread to find a working dtostrf function you can include in your code:

http://forum.arduino.cc/index.php?topic=368720.0

How Much RAM Available?

The ATSAMD21G18 has 32K of RAM, but you still might need to track it for some reason. You can do so with this handy function:

Thx to http://forum.arduino.cc/index.php?topic=365830.msg2542879#msg2542879 for the tip!

Storing data in FLASH

If you're used to AVR, you've probably used PROGMEM to let the compiler know you'd like to put a variable or string in flash memory to save on RAM. On the ARM, its a little easier, simply add const before the variable name:

const char str[] = "My very long string";

That string is now in FLASH. You can manipulate the string just like RAM data, the compiler will automatically read from FLASH so you dont need special progmem-knowledgeable functions.

You can verify where data is stored by printing out the address:
Serial.print("Address of str $"); Serial.println((int)&str, HEX);

If the address is $2000000 or larger, its in SRAM. If the address is between $0000 and $3FFFF Then it is in FLASH

Pretty-Printing out registers

There's a lot of registers on the SAMD21, and you often are going through ASF or another framework to get to them. So having a way to see exactly what's going on is handy. This library from drewfish will help a ton!

https://github.com/drewfish/arduino-ZeroRegs

M4 Performance Options

As of version 1.4.0 of the Adafruit SAMD Boards package in the Arduino Boards Manager, some options are available to wring extra performance out of M4-based devices. These are in the Tools menu.

All of these performance tweaks involve a degree of uncertainty. There’s no guarantee of improved performance in any given project, and some may even be detrimental, failing to work in part or in whole. If you encounter trouble, select the default performance settings and re-upload.

Here’s what you get and some issues you might encounter…

CPU Speed (overclocking)

This option lets you adjust the microcontroller core clock…the speed at which it processes instructions…beyond the official datasheet specifications.

Manufacturers often rate speeds conservatively because such devices are marketed for harsh industrial environments…if a system crashes, someone could lose a limb or worse. But most creative tasks are less critical and operate in more comfortable settings, and we can push things a bit if we want more speed.

There is a small but nonzero chance of code locking up or failing to run entirely. If this happens, try dialing back the speed by one notch and re-upload, see if it’s more stable.

Much more likely, some code or libraries may not play well with the nonstandard CPU speed. For example, currently the NeoPixel library assumes a 120 MHz CPU speed and won’t issue the correct data at other settings (this will be worked on). Other libraries may exhibit similar problems, usually anything that strictly depends on CPU timing…you might encounter problems with audio- or servo-related code depending how it’s written. If you encounter such code or libraries, set the CPU speed to the default 120 MHz and re-upload.

Optimize

There’s usually more than one way to solve a problem, some more resource-intensive than others. Since Arduino got its start on resource-limited AVR microcontrollers, the C++ compiler has always aimed for the smallest compiled program size. The “Optimize” menu gives some choices for the compiler to take different and often faster approaches, at the expense of slightly larger program size…with the huge flash memory capacity of M4 devices, that’s rarely a problem now.

The “Small” setting will compile your code like it always has in the past, aiming for the smallest compiled program size.

The “Fast” setting invokes various speed optimizations. The resulting program should produce the same results, is slightly larger, and usually (but not always) noticably faster. It’s worth a shot!

“Here be dragons” invokes some more intensive optimizations…code will be larger still, faster still, but there’s a possibility these optimizations could cause unexpected behaviors. Some code may not work the same as before. Hence the name. Maybe you’ll discover treasure here, or maybe you’ll sail right off the edge of the world.

Most code and libraries will continue to function regardless of the optimizer settings. If you do encounter problems, dial it back one notch and re-upload.

Cache

This option allows a small collection of instructions and data to be accessed more quickly than from flash memory, boosting performance. It’s enabled by default and should work fine with all code and libraries. But if you encounter some esoteric situation, the cache can be disabled, then recompile and upload.

Max SPI and Max QSPI

These should probably be left at their defaults. They’re present mostly for our own experiments and can cause serious headaches.

Max SPI determines the clock source for the M4’s SPI peripherals. Under normal circumstances this allows transfers up to 24 MHz, and should usually be left at that setting. But…if you’re using write-only SPI devices (such as TFT or OLED displays), this option lets you drive them faster (we’ve successfully used 60 MHz with some TFT screens). The caveat is, if using any read/write devices (such as an SD card), this will not work at all…SPI reads absolutely max out at the default 24 MHz setting, and anything else will fail. Write = OK. Read = FAIL. This is true even if your code is using a lower bitrate setting…just having the different clock source prevents SPI reads.

Max QSPI does similarly for the extra flash storage on M4 “Express” boards. Very few Arduino sketches access this storage at all, let alone in a bandwidth-constrained context, so this will benefit next to nobody. Additionally, due to the way clock dividers are selected, this will only provide some benefit when certain “CPU Speed” settings are active. Our PyPortal Animated GIF Display runs marginally better with it, if using the QSPI flash.

Enabling the Buck Converter on some M4 Boards

If you want to reduce power draw, some of our boards have an inductor so you can use the 1.8V buck converter instead of the built in linear regulator. If the board does have an inductor (see the schematic) you can add the line SUPC->VREG.bit.SEL = 1; to your code to switch to it. Note it will make ADC/DAC reads a bit noisier so we don't use it by default. You'll save ~4mA.

Before beginning make sure you have your Arduino or Feather working smoothly, it will make this part a lot easier. Once you have the basic functionality going - you can upload code, blink an LED, use the serial output, etc. you can then upgrade to using the radio itself.

Note that the sub-GHz radio is not designed for streaming audio or video! It's best used for small packets of data. The data rate is adjustable but its common to stick to around 19.2 Kbps (thats bits per second). Lower data rates will be more successful in their transmissions

You will, of course, need at least two paired radios to do any testing! The radios must be matched in frequency (e.g. two 900 MHz  radios are ok, but mixing 900 MHz and 433 MHz is not). They also must use the same encoding schemes, you cannot have a 900 MHz RFM69 packet radio talk to a 900 MHz RFM9x LoRa radio.

Arduino Library

These radios have really excellent code already written, so rather than coming up with a new standard we suggest using existing libraries such as AirSpayce's Radiohead library which also supports a vast number of other radios.

This is a really great Arduino Library, so please support them in saying thanks for their efforts!

RadioHead RFM9x Library example

To begin talking to the radio, you will need to download the RadioHead library. You can do that by visiting the GitHub repo and manually downloading or, easier, just click the button below to download as a zip file:

Note that while all the code in the examples below are based on this version, you can visit the RadioHead documentation page to get the most recent version which may have bug-fixes or more functionality

Uncompress the zip and find the folder named RadioHead and check that the RadioHead folder contains RH_RF95.cpp and RH_RF95.h (as well as a few dozen other files for radios that are supported)
 
Place the RadioHead library folder your arduinosketchfolder/libraries/ folder.
You may need to create the libraries subfolder if its your first library. Restart the IDE.

We also have a great tutorial on Arduino library installation at:
http://learn.adafruit.com/adafruit-all-about-arduino-libraries-install-use

Basic RX & TX example

Now to get a basic demo going, where one Feather transmits and the other receives. Start by setting up the transmitter.

Transmitter example code

This code will send a small packet of data once a second to node address #1.

Open up the example RadioHead→feather→Feather9x_TX

Load this code into your Transmitter Arduino/Feather!

Once the code is uploaded, you should see the following on the serial console:

Now open up another instance of the Arduino IDE - this is so you can see the serial console output from the TX Feather while you set up the RX Feather.

Receiver example code

This code will receive and acknowledge a small packet of data.

Open up the example RadioHead→feather→Feather9x_RX

Load this code into your Receiver Arduino/Feather!

Now open up the Serial console on the receiver, while also checking in on the transmitter's serial console. You should see the receiver is...well, receiving packets:

You can see that the library example prints out the hex-bytes received 48 65 6C 6C 6F 20 57 6F 72 6C 64 20 23 30 0 20 20 20 20 0, as well as the ASCII 'string' Hello World. Then it will send a reply.

And, on the transmitter side, it is now printing that it got a reply after each transmission And hello back to you because it got a reply from the receiver.

That's pretty much the basics of it! Take a look at the examples so you know how to adapt to your own radio setup.

Feather Radio Pinout

 This is the pinout setup for all Feather 32u4 RFM9X's:

This is the pinout for all Feather M0 RFM9X's:

And for RP2040 Feathers:

Frequency

You can dial in the frequency you want the radio to communicate on, such as 915.0, 434.0 or 868.0 or any number really. Different countries/ITU Zones have different ISM bands so make sure you're using those or if you are licensed, the frequencies you may use.

You can then instantiate the radio object with our custom pin numbers.

Setup

We begin by setting up the serial console and hard-resetting the radio:

Remove the while (!Serial); line if you are not tethering to a computer, as it will cause the Feather to halt until a USB connection is made!

Initializing Radio

The library gets initialized with a call to init(). Once initialized, you can set the frequency. You can also configure the output power level, the number ranges from 5 to 23. Start with the highest power level (23) and then scale down as necessary.

Transmission Code

If you are using the transmitter, this code will wait 1 second, then transmit a packet with Hello World # and an incrementing packet number.

Its pretty simple, the delay does the waiting, you can replace that with low power sleep code. Then it generates the packet and appends a number that increases every transmission. Then it simply calls send to transmit the data, and passes in the array of data and the length of the data.

Note that this does not any addressing or subnetworking - if you want to make sure the packet goes to a particular radio, you may have to add an identifier/address byte on your own!

Then you call waitPacketSent() to wait until the radio is done transmitting. You will not get an automatic acknowledgement from the other radio unless it knows to send back a packet. Think of it like the 'UDP' of radio - the data is sent, but it's not certain it was received! Also, there will not be any automatic retries.

Receiver Code

The Receiver has the same exact setup code, but the loop is different:

Instead of transmitting, it is constantly checking if there's any data packets that have been received. available() will return true if a packet with proper error-correction was received. If so, the receiver prints it out in hex and also as a 'character string'.

It also prints out the RSSI which is the receiver signal strength indicator. This number will range from about -15 to about -100. The larger the number (-15 being the highest you'll likely see) the stronger the signal.

Once done it will automatically reply, which is a way for the radios to know that there was an acknowledgement:

It simply sends back a string and waits till the reply is completely sent.

It's easy to use the RFM9x LoRa radio with CircuitPython and the Adafruit CircuitPython RFM9x module.  This module allows you to easily write Python code that sends and receives packets of data with the radio.  Be careful to note this library is for the RFM95/96/97/98 LoRa radio only and will not work with the simpler RFM69 packet radio.

Design Considerations

One thing to be aware of before you use the RFM9x series of radios with CircuitPython are some of the limitations and design considerations for its module.  Keep these in mind as you think about projects using the RFM9x and CircuitPython:

• You can only send and receive packets up to 252 bytes in length at a time.  The size of the radio's internal buffer dictates this limit so if you want to send longer messages you'll need to break them into a series of smaller send calls in your application code.
• Receiving packets is a 'best effort' in pure Python code.  Unlike the Arduino versions of the RFM9x library there is no interrupt support which means when a packet is received it must be immediately processed by the Python code or it could be lost.  For your application it will work best to only receive small, single packet messages at a time.  Don't try to receive kilobytes of data or else you'll lose packets.  This module is really intended for simple single packet messages like 'ON', 'OFF', etc.
• Sending and receiving packets will 'block' your Python code until the packet is fully processed.  This means you can't do a lot of other things while sending and waiting for packets to be received.  Design your application so the radio usage is the primary scenario and very little other tasks need to happen in the background.
• The module is written to be compatible with the RadioHead RFM95 Arduino library.  This means by default the module will setup the radio with the same modulation and configuration for transmitting and receiving at the maximum distance with LoRa support.  In addition the CircuitPython module uses the same packet preamble (8 bytes) and header (4 bytes) as RadioHead.  If you want to use different modulations or settings you'll need to configure the radio yourself after carefully consulting the datasheet.
• The CircuitPython module supports advanced RadioHead features like the node addressing and "Reliable Datagram". "Reliable DataGram" mode in CircuitPython has some additional parameters to control timing that are not available with the RadioHead library. It may be difficult to get reliable transmission to work between the RadioHead library and CircuitPython.
• Encryption and sync words are also not supported by the LoRa radio module.  You must perform these operations yourself in your application code if they're desired.

Wiring With Breakout

First wire up a RFM9x breakout to your board as shown on the previous pages for Arduino.  Note that the G0/interrupt line is not used by the CircuitPython module and can remain unconnected.   Here's an example of wiring a Feather M0 to the radio with a SPI connection:

• Board 3V to radio VIN
• Board GND to radio GND
• Board SCK to radio SCK
• Board MOSI to radio MOSI
• Board MISO to radio MISO
• Board D5 to radio CS (or any other digital I/O pin)
• Board D6 to radio RST (or any other digital I/O pin)

Upgrading to the UF2 Bootlader

Usage with All-In-One Feather M0

Alternatively you can use the default bootloader on the Feather M0 RFM9x board but be sure you load the adafruit-circuitpython-feather_m0_rfm9x-*.bin version of CircuitPython on your board!  This is very important as the RFM9x build has special pins added to the board module which are used to access the radio's control lines!

For details on how to load a binary circuitpython build, check out our Non-UF2-Install guide

Module Install

If you have the Feather M0 RFM9x and have installed CircuitPython 6.0 or later,  it is not necessary to install the library modules. They are "frozen into" the Circuitpython build. Skip to the "Usage" section below.

If you are using an older version of CircuitPython you will need to install the modules as described.

Next you'll need to install the Adafruit CircuitPython RFM9x module on your CircuitPython board.  Before you do that make sure you are running the latest version of Adafruit CircuitPython for your board too (again be sure to the load the Feather M0 RFM9x version if you're using that board and want to use its built-in radio module).

Next you'll need to install the necessary libraries to use the hardware--carefully follow the steps to find and install these libraries from Adafruit's CircuitPython library bundle.  Our introduction guide has a great page on how to install the library bundle for both express and non-express boards.

Remember for non-express boards like the, you'll need to manually install the necessary libraries from the bundle:

• adafruit_rfm9x.mpy
• adafruit_bus_device

You can also download the adafruit_rfm9x.mpy from its releases page on Github.

Before continuing make sure your board's lib folder or root filesystem has the adafruit_rfm9x.mpy, and adafruit_bus_device files and folders copied over.

Usage

To demonstrate the usage of the radio we'll initialize it and send and receive data from the board's Python REPL.

Connect to the board's serial REPL so you are at the CircuitPython >>> prompt.

Run the following code to import the necessary modules and initialize the SPI connection with the radio:

Now define a few of the pins connected to the RFM9x, specifically the CS and RST pins:

However if you're using the Feather M0 RFM95 board with a built-in RFM9x radio (and you've loaded the special version of CircuitPython just for this board as mentioned above), you instead want to use these pins for the CS and RST lines:

You're ready to import the RFM9x module and create an instance of the RFM9x class inside it.  Before you create the radio module instance you'll need to check if you're using a 433mhz or 915mhz radio module as the initializer requires the frequency to be specified--confirm which frequency your module uses and run one of the following lines.  

For a 915mhz radio use:

Or for a 433mhz radio use:

Notice the initializer takes the following required parameters:

• spi - The SPI bus connected to the board.
• cs - The DigitalInOut instance connected to the CS line of the radio.
• reset - The DigitalInOut instance connected to the RST or reset line of the radio.
• frequency - The frequency in megahertz of the radio module.  Remember this frequency depends on which type of radio you're using and the frequency you desire to use!

In addition there are some optional parameters you might specify:

• baudrate - The baud rate to use for the SPI connection to the radio.  By default this is 10mhz which is as fast as the radio can handle, but in some cases it might be too fast if you're wiring up a breakout to a breadboard (breadboards can be notorious for not working well with high speed signals).  If you run into odd errors like being unable to find the RFM9x radio try lowering the baudrate by specifying a baudrate=1000000 keyword (which sets the speed to a lower 1mhz value).

Once the RFM9x class is created and initialized you're ready to start sending and receiving data.

Remember by default the module will be configured to interface with the "RadioHead" RFM9x setup so you can also send and receive packets with an Arduino running the RFM95 TX/RX examples!

To send a message simply call the send function and provide a string or byte string of data:

Remember you can only send a message up to 252 bytes in length at a time!  Attempting to send a message longer than 252 bytes will fail with an exception error.  If you need to send a longer message it will have to be broken up into multiple send calls and reconstructed on the receiving side.

If you have another RFM9x on the same frequency waiting to receive messages (like another CircuitPython module running receive code below) you should see it receive the message.

You can even have an Arduino running the RadioHead library's RFM95 client example see the message that was sent:

To receive a message simply call the receive function.  This function will wait for half a second for any packet to be received.  If a packet is found it will be returned as a byte string (remember packets are at most 252 bytes long), or if no packet was found a result of None is returned.

You can increase the amount of time the module waits for a packet to be received by specifying the time in seconds as a parameter to the receive call:

Notice this waits longer at the REPL for a packet to be received before returning.  If you have another RFM9x setup try having it send a message while the other is waiting to receive it.  You should see a byte string returned.  You can also have an Arduino running the RadioHead library's RFM95 client example send messages that are received by your code:

One thing to note in Python byte strings aren't exactly like text strings and you might not be able to do all the text processing (like find, replace, etc.) as you expect.  However you can convert a byte string into text by assuming a specific text encoding like ASCII.  For example to receive a packet and convert the contents to an ASCII text string you can run code like:

Notice this code first receives a packet, then checks if one was actually found (the packet is not None check--if no packet is received a value of None is returned), and then converts the packet data to a string assuming an ASCII text encoding.

Beyond RX & TX

Beyond basic sending and receiving there are a few properties of the RFM69 class you might want to interact with:

• tx_power - This is a power level (in dB) to use when transmitting with the radio.  By default this is set to a moderate 13 dB value, however you can increase this depending on the type of radio you're using.  For high power radios (the modules sold by Adafruit) they support a range of TX power from 5 to 23 dB.  Try increasing this to the maximum 23 dB level (however check your local laws for permission to transmit with such power!) to get the most distance and range.
• rssi - The received signal strength indicator is a property you can read to see the strength of the radio signal being received.  This is updated when packets are received and returns a value in decibels (typically negative, so the smaller the number and closer to 0, the higher the strength / better the signal).

That's all there is to the basic RFM9x radio usage!  Remember the CircuitPython module is designed for sending and receiving small up to 252 byte control messages and not large or high bandwidth amounts of data.

Here's a complete example of sending a message and waiting to receive and print any received messages.  Save this as main.py on your board and open the serial REPL to see it print data and any received messages.  If you have two boards and radios setup to run this code at the same time they'll send each other a message on start up!