Problems getting Adafruit Feather M0 LoRa (RFM95) running

I received my LoRa Feather M0 yesterday and started playing around. Unfortunately I did not get far. I struggled a lot with the flashing of even very simple firmwares. Most of the time the process gave errors on the /dev/ttyACM0 port. The device never opened a /dev/ttyUSB0 serial port. I’m not 100% sure if the device is fully functional from the hardware side at all. At lest and on very rare occasions I got the example firmware transferred successfully.

@clemens would you mind sharing your devEUI detection and OOTA sketches with me? That would help me a lot to figure out what goes wrong. The TTN Quick Start only returned the “-- STATUS” line. nothing more.

I assume that you have installed the according Arduino SAMD Boards and the Adafruit SAMD package as described in the Adafruit Tutorial under Using with Arduino IDE. There is also an advice to install some drivers.

The most helpful advice in the FAQ section was to “double click” the reset button on the Feather M0 in case uploading does not work properly!

An also enlightening part was the information that the M0 has two com ports

Theres two COM ports you can have with the 32u4/M0, one is the user port and one is the bootloader port. They are not the same COM port number!
When the user COM port disappears, Arduino will not be able to automatically start the bootloader and upload new software.
So you will need to help it by performing the click-during upload procedure to re-start the bootloader, and upload something that is known working like “Blink”

So my advice would be to double click / press the reset button on the Feather, select your COM port in the IDE and then upload your code as mentioned in my initial post under “Some Hints”.

Some USB cables seems to be for charging only, but in case you upload worked one time this should not be your problem.

yes, I installed the boards according to the guides. I already got familiar with the double klick reset action. I also added the udev rules. The status detection sket now gives

EUI: $�
Battery: $��
AppEUI: �|���
DevEUI: $��
Data Rate: $��
RX Delay 1: $~���
RX Delay 2: $~����

how to make this human readable?

I’m using the Arduino IDE on Windows, so I can not say anything to the udev rules.

I did not use the OTAA example code but the ttn-abp.ino from arduino-lmic/examples at master · matthijskooijman/arduino-lmic · GitHub.

Think the OTAA example needs an back channel so it could be that your gateway did not support this or your node can send (gateway can receive) but your node did not get the answer. What gateway do you use?

Are you sure that your linked source (TTN Quick Start) is running with the Feather, I think it’s for The Things Uno? What lib did you use? This one? arduino-device-lib/QuickStart.ino at master · TheThingsNetwork/arduino-device-lib · GitHub

I used the LMIC lib from Matthijs Kooijman

trying this now.

A Potsdam based freiFunk member has a gateway at home but he’s not entirely sure about full functionality. This morning I tried connecting in front of his house with the OOTA example sketch without success. I will try the ABP version later today. There’s another gateway which I will also visit. Unfortunately, due to the distance and shielding circumstances, I can not connect to both gateways from home.

Looking at all the forum threads around it’s probably not. Although the behavior of the board looked very promising. The join procedure triggered the yellow LED in a way that looked like TX attempts: irregular blinking, longer and shorter breaks. That made me believe the firmware is interacting with the hardware.

Since I’m using the example sketches I’m on this library as well. And yes, I made all the necessary configs in the library and sketch as well as the proper wiring and checking the keys multiple times.

No connection with both gateways using the ABP method. The freiFunk gateway, which I have console access to, doesn’t show any transmissions.

This is the only output I get on Serial port. I’m running out of ideas.

Packet queued
380882: EV_TXCOMPLETE (includes waiting for RX windows)
Packet queued
1761743: EV_TXCOMPLETE (includes waiting for RX windows)

and so on…

Could it be that the gateway is a single channel gateway? In this case the (only) channel has to be configured in your sketch and both channels - on the gateway and on the node must be the same! Also the SF parameter must be set in both devices and has to be the same.

So it would be great to figure details about the gateway out. Do you have any information?

The freiFunk gateway is an iC880a connected to a RasPi. That solution runs the LoRaWAN stack and is made for multi-channel transmissions.

The other node is listed offline as of today. I sent a request for more details on the gateway to the owner via TTN.

Debugging the firmware during runtime didn’t work for me either. #define LMIC_DEBUG_LEVEL [1|2] and uncommenting #define LMIC_PRINTF_TO Serial in config.h result in an error while compiling the firmware.

iC880 sounds good and should support all nodes.

In case you are sending always the same data the gateway will not forward the data. I have not fully understood this but as information:

You can disable this in the console under device > settings disable “Frame Counter Checks”

But nevertheless the data must show up in the gateway’s dashboard.

Using a greedy full-fledged printf is always an expensive problem on small machines with limited ressources. However, the lib started made for AVR, and as you run this on a Cortex M0+ and not an AVR, #define LMIC_PRINTF_TO Serial won’t work for you:

lmic_printf is defined platform-dependent in oslmic.h (L224-L263), and it reflects to hal.cpp .

For debugging on your processor I’d suggest using the non-avr-printf branch of Matthijs’ LMIC repo rather than master.

"Software efficiency halves every 18 months, compensating for Moore’s Law.” - David May’s law


Hmm, just that we do not miss some initial step(s) Did you follow this tutorial: Getting Started with AdaFruit Feather M0 LoRa - Telenor Start IoT


  • the two additional wires on the board and soldering the antenna
  • change the SPI clock frequency in the library
  • check/change the config.h in the library
  • change the SPI clock error in the ino file
  • change the pin mapping in the ino file, see Using the Adafruit Feather M0 LoRa (RFM95) and TTN

I did all the changes except

But, according to TTN console the device was seen in the network (back then without the missing SPI clock fix) on Friday while I drove through Berlin. Unfortunately, both Potsdam nodes are offline at the moment.

Thanks for you support

It turned out that the node successfully transmits the test payload with the ABP method even without the change for the SPI clock error. Instead it was the local gateway that troubled me.
Thanks for your support.

1 Like