Big LoRa32u4 boards topic

Adafruit Feather 32u4 LoRa and BSFrance LoRa32u4 II boards

LoRa32u4 will be used as a general abbreviation for above family of boards.

The LoRa32u4 boards are a combination of an Atmel ATmega32u4 AVR MCU with a LoRa module and have Li-Ion/LiPo battery support (including charging). The Feather 32u4 LoRa is designed by Adafruit. The LoRa32u4 II board is designed by BSFrance and produced by DIYMall (which is actually a copy of the Adafruit Feather 32u4 LoRa).

The ATmega32u4 has built-in support for USB and does not require a separate USB to serial converter chip. This has advantages but also disadvantages: After a reset the serial port will be temporarily disconnected and switched to programming mode and automatically switches back after some seconds. This sometimes can give issues when uploading and/or when using the Serial Monitor.

These boards have a separate LoRa antenna that connects via a tiny cable to the on-board IPEX/U.FL connector (for versions 1.1 and higher, version 1.0 only supported a wire antenna directly soldered to the board). The battery connector is a 2-pin JST-PH connector. The battery voltage can be monitored via an analog pin.


Currently 5 different versions of the BSFrance LoRa32u4 II board exist.
Below is a brief description of each version:

  • Version 1.0
    Uses an unshielded SX127x LoRa module.
    Lacks a version number on the PCB.
    Has a hole for soldering a simple wire antenna. No IPEX/U.FL antenna connector.
    LoRa DIO0 is permanently wired to digital pin 7.
    LoRa DIO1 has it own board pin but is not connected to any digital pin.
    DIO1 pin must be manually wired to a digital pin (required for LoRa).
    There are soldering pads/holes for DIO2 and DIO3 for manual wiring if needed.

  • Version 1.1a
    Like version 1.0 but in addition has an IPEX/U.FL LoRa antenna connector.
    This model hash a version number on the top of the PCB: V1.1.

  • Version 1.1b
    Identical to version 1.1a but uses a shielded HPDTek LoRa module.

  • Version 1.2
    Like version 1.1b but the DIO1 board pin has been replaced by digital pin 14 (new).
    DIO1, DIO2 and DIO3 now each have solder padson the PCB so they can be easily connected to a digital pin. Using the solder pads DIO1 can be connected to digital pin 1, DIO2 to digital pin 2 and DIO3 to digital pin 3.
    Having the solder pads is great, but unfortunately they use digital pins 1, 2 and 3 for DIO which is a poor design choice because these pins serve other important functions:
    Pin 1: Serial TX + Interrupt #3, Pin 2: I2C SDA + Interrupt #1, Pin 3: I2C SCL + Interrupt #0.

    This model has version numbers on both sides of the PCB: V1.2.

  • Version 1.3
    For information about version 1.3 see post Settings for BSFrance LoRa32u4 II v1.3 further below.


In addition to the hardware, software is needed for implementing the LoRaWAN protocol. The SX127x LoRa tranceiver provides LoRa radio modulation but it does not implement the LoRaWAN protocol. The protocol has to be implemented in software that needs to run on the ATmega32u4 MCU.

The following libraries implement a LoRaWAN protocol stack that can be used with the these boards:

  • LMIC-Arduino aka Classic LMIC is the original Arduino LMIC library but it is no longer maintained and has been deprecated. This library lacks the LoRaWAN compliancy needed for TTN/TTS V3.

  • MCCI LoRaWAN LMIC library aka MCCI LMIC is based on LMIC-Arduino and has been further developed. It contains several improvements, supports more regions and is actively maintained.
    This library is now preferred but it uses more memory. For TTN/TTS V3 use of MCCI LMIC is required because its predecessor Classic LMIC lacks required LoRaWAN compliancy.

Each of these libraries has its own way of configuring (e.g. region/frequency) settings. For details check the readme and other documentation included with each library.

Both libraries contain examples for implementing a node for both ABP and OTAA activation.
Try to get the ttn-abp.ino example working first. If that works continue with the ttn-otaa.ino example. When both these examples work then the LoRaWAN part of your setup works. From there you can start to try more advanced sketches and adding features (e.g. sensors). ABP and OTAA require different keys and settings. See TTN Console and remarks in the sketches for more information.
Try to get the basics working first before asking questions about issues with other sketches.

For more information about available LoRaWAN libraries see:
Overview of LoRaWAN Libraries [HowTo]

LMIC Timing

When using the two common Arduino LMIC libraries on 8-bit ATmega328 and ATmega32U4 MCU’s (especially 8 MHz like on LoRa32U4) it is required to relaxed LMIC timing, otherwise down link messages and OTAA joins on lower spreading factors will likely fail.

LMIC timing can be relaxed with LMIC_setClockError() as shown below where it is
added to the ttn-otaa.ino example.
A value of 3 percent is usually sufficient for LoRa32u4. Different LMIC libraries may need a different value. The 3 percent was empirically determined. During testing of joins and downlink messages my observation was that the classic LMIC-Arduino library needs a little higher value than the MCCI LoRaWAN LMIC library.

    // LMIC init
    // Reset the MAC state. Session and pending data transfers will be discarded.
    // ### Relax LMIC timing ###
    // Required for ATmega328/ATmega32U4 (8MHz) otherwise downlink messages
    // and OTAA joins on lower spreading factors will likely fail.

    // Start job (sending automatically starts OTAA too)


For LoRa modulation the LMIC libraries only need DIO0 and DIO1 to be wired.
For FSK modulation (which is normally not used) DIO0 and DIO2 need to be wired.

Adafruit Feather 32u4 LoRa and BSFrance LoRa32u4 II versions 1.0 and 1.1

DIO0: Is already hard-wired on the PCB to pin 7.
DIO1: Must be manually wired. It is preferred to wire DIO1 to digital pin 5.

Several examples on the web suggest to wire DIO1 to pin 6. Probably because it is next to pin 7 which is already hard-wired to DIO0. But wiring DIO1 to pin 5 instead has the following advantages:

  • It leaves pin 6 available which also provides ADC functionality (which pin 5 does not).
  • On the BSFrance version 1.3, DIO1 is already wired to pin 5 by default. Using consistent wiring for all versions of the board allows that software can run on all versions of the board without having to reconfigure pin mappings.
  • For the Adafruit Feather 32u4 if you want you can still use pin 6 if you prefer. Adafruit tries to keep pin numbers identical on different Feather boards. You will have to change your pin mapping in the software accordingly however.
  • Uses 2.54mm less wire. :grin:

BSFrance LoRa32u4 II version 1.2

DIO0: Is already hard-wired on the PCB to pin 7.
DIO1: Must be manually connected via solder bridge on the PCB or manually wired.

The solder bridge on version 1.2 connects DIO1 to pin 1 which is part of the serial interface. If you plan to use the serial interface (e.g. to connect a GPS module) then connecting DIO1 to pin 1 via the solder bridge is not a good idea. In that case it should be manually wired to pin 5.
Manual wiring will require some solder skills because the wire must be soldered directly to the DIO1 pad of the LoRa module. Version 1.2 does not have a board pin for DIO1 that the older boards had.

BSFrance LoRa32u4 II versions 1.3.

DIO0: Is already hard-wired on the PCB to pin 7.
DIO1: Is already connected to pin 5 via solder bridge on the PCB.

LMIC Pin Mapping


  • LoRa32u4 II versions 1.0, 1.1 and 1.2 where DIO1 is manually wired to pin 5.
  • Lora32u4 II version 1.3 where DIO1 is default connected to pin 5 via solder bridge on PCB.

If you have manually wired DIO1 to a different pin than pin 5 then replace 5 below with the corresponding pin number.

const lmic_pinmap lmic_pins = {
  .nss = 8,
  .rxtx = LMIC_UNUSED_PIN,
  .rst = 4,
  .dio = {/*dio0*/ 7, /*dio1*/ 5, /*dio2*/ LMIC_UNUSED_PIN}

For LoRa32u4 II v1.2 where DIO1 is manually connected to pin 1 via the solder bridge on the PCB.

const lmic_pinmap lmic_pins = {
  .nss = 8,
  .rxtx = LMIC_UNUSED_PIN,
  .rst = 4,
  .dio = {/*dio0*/ 7, /*dio1*/ 1, /*dio2*/ LMIC_UNUSED_PIN}

Useful links


Version 1.0

BSFrance LoRa32u4 II version 1.0 - Top

BSFrance LoRa32u4 II version 1.0 - Bottom

Version 1.1

BSFrance LoRa32u4 II version 1.1a - Top

BSFrance LoRa32u4 II version 1.1b - Top

BSFrance LoRa32u4 II version 1.1 - Bottom

Version 1.2

BSFrance LoRa32u4 II version 1.2 - Top

BSFrance LoRa32u4 II version 1.2 Bottom


Absolutely agree. Having soldering pads is a nice idea. Using pins 1 (TX1), 2 (SDA), 3 (SCL) is not that smart.
Moreover, New board pin “14” is confusing/uneasy : it’s ATMega32U4 PD5 pin, but Arduino pin “14” is another one, MISO.

We can dream about some Version 1.3 improvement

  • Get back to version 1.1 mapping (Adafruit clone);
  • Or simply change DIO1/2/3 wiring to wiser ATMega pins.

Right now, I have two 1.2 boards with a wire directly soldered to RFM95 DIO1.

I already was wondering why two ‘14’ pins. I had checked with a multimeter before but they are not connected to each other. So this is PD5. In ATmega 32U4 Arduino Leonardo Pin Mapping PD5 is defined as pin 22.
When looking in BSFrance-avr arduino core in variants\lora32u4II\pins_arduino.h
in the comments PD5 is listed as D30.

I have not tried this yet but I think we can conclude that the label ‘14’ for this pin is bogus.

I’ll go for the second option (but I don’t expect a V1.3 soon).

I missed that one, so D30 it is!
As I use those boards as Adafruit clone, I prefer avoiding this difference, for now.

BSFrance support is very kind, I will ask for info :slight_smile:
Whatever, soldering DIO1 pin is not that hard, that was my first.

OTA sketch is working perfectly, with sleep.

Couin, bluejedi,

I’m having an issue with LoRa32u4 v 1.2. It sends join request to server, server replies with join accept, but the board seems never receive that message.

I connected DIO1 with IO1 with solder like you told, but I’m afraid of that IO1 is used by Serial TX. Can it cause a problem and interfere with LoRa functions if I turned verbose logs output to serial in LMIC settings?

Also, what is the right port mapping for LoRa32u4 v 1.2 with DIO1 and IO1 connected?

Is this correct:

const lmic_pinmap lmic_pins = {
.nss = 8,
.rst = 4,
.dio = {7,1,2},

Thank you!

If you wait some 5 to 10 minutes you will probably see it joining at SF9 (maybe SF10).

The AVR 8MHz microcontrollers can be a bit too slow for LMIC. To fix this OTAA JOIN ACCEPT timing issue try to relax LMIC timing, see:

For LoRa32u4 II v1.2 if you have connected DIO1 with the solder pads to digital pin 1 and have not connected DIO2 (which is not needed for LoRa) use this:

// Set pin mapping for SX127x/RFM9x.
const lmic_pinmap lmic_pins = {
  .nss = 8,
  .rxtx = LMIC_UNUSED_PIN,
  .rst = 4,
  .dio = {/*dio0*/ 7, /*dio1*/ 1, /*dio2*/ LMIC_UNUSED_PIN}

I reproduce this issue when my power supply is not powerfull enough.
If connected to VBat, Battery connector or +5V, your voltage can’t drop below 3.5V.

One pin can’t share two functions (Serial + LoRa) that easily.
As I said, I soldered a wire directly on HDP13 DI01… to plug it on board pin 6.

On a side note, I’ve seen a strange behavior when using Reset.
As stated on Adafruit Feather 32u4 Lora thread, a reset put you in “Bootloader Mode”.

I did some testings with the same LoRa OTA Sketch.
It’s working fine either before or after a reset. There is a power consumption difference in deep-sleep though :

  • First boot : Around 170µA
  • After a reset : Around 230µA

I guess Bootloader mode forces USB to Serial on… Forever.

PS: To make a “normal” reboot, you can short EN pin

1 Like

Thanks for your replies!

It finally joined. I guess the problem was in IO1= Serial TX issue as the join actually happened right after I closed my Arduino IDE serial terminal window.

As to power supply, Couin, I didn’t plug any external supply at all. I used only the power provided by USB cable while looking into serial terminal output. Can this be an issue with join difficulties, how do you think?

I’m discovering this board since last week… The more I do, the more I have to dig :confused:

Pin 1 is TX1 pin, used with “serial1.[…]” in Arduino IDE.
I suppose you only plug USB and use serial.[…] aka serial0, It should not interfere.

I first tested my boards pair with LoRaReceiver and LoRaSender sketches (in BSFrance archive), with serial (and power) Over USB.

Hope it will help!

Propagate from where to where? Once you create a device in the TTN console it can be used immediately. No delays…

That was a bad supposition, I remove that sentence :zipper_mouth_face:
Still, it didn’t worked immediately for me, for an unknown reason.

Has anyone found a schematic for the BDFrance LoRa32u4 II v1.2?
It’s reading ~4.6v for a battery level of 3.99v so I’m wondering if the resistor divider is not just two 100k resistors.

Your 4.6v for 4.0v is fearly high, even with a bridge of 100k resistors with a +/-10% tolerance.
I personally get 3.6v for 3.3v.

Have you tried using a capacitor between D9/ADC12 (BAT divider) and GND pin, it may help?
I will ask support for v1.2 documentation.



I’m using Adafruit LoRa M0 with LiMC library and it works perfectly with the TTN. I’m using Laird RG1XX Gateway.
I would like to learn more about the Sleep mode and I’m having difficulties finding information about that. If you have any tutorials, links or website, I appreciate if you could share.
Thanks in advance.

If you are interested in the mechanics behind, I suggest you to read this topic, a great start.

Then, you can tinker your own or directly use an existing library, like this one.

It’s worth mentioning that if you do solder DIO1 to digital pin 1 on the BSFrance LoRa32u4 II version 1.2, then you MUST close the serial connection on your computer or the sketch will not run.

Just to be clear.
USB Serial is Serial0.
RX/TX (0/1) pins is Serial1.
If you use pin 1 for LoRa, you won’t be able to use onboard serial (Serial1). You still will be able to use Serial0 (Serial and programming with USB).
With a bit of soldering, you can use any other pin (I use pin 6).
Furthermore, ATMega32u4 is sometimes tricky to program. Best tip is to activate verbose upload option, to manually reset board when IDE starts uploading. This way, it works everytime.

On this topic, for the last week I have been battling to get my Adafruit LoRa feather board to communicate with my desktop and after doing a lot of research and asking intelligent folk for help, finally managed to get it working.

The issues that I found are as follows:

  1. Make sure the ancillary power supply to the board is at least 5v. If this is not the case Windows is constantly reporting that the USB device is not recognized. I use LM2596 DC-DC stepdown Adjustable Power supply board to do so.
  2. Use the “latest” version of the IBM Limc libraries in my case it is “IBM_LMIC_framework-1.5.0+arduino-2”.
    By the way this zipped library can not be added to the Arduino environment in the normal way, you will have to install it manually.
  3. On the Arduino Boards side use version 1.4.11 for the Adafruite Feather 32u4 library.
  4. Solder the jumper on the bottom of the Feather board from pins IO1 to Pin 6
  5. Use the ttn-otaa example from the IBM LMIN code to start with.
  6. Make sure that the Lmic pin mapping is as follows;
    const lmic_pinmap lmic_pins =
    .nss = 8,
    .rxtx = LMIC_UNUSED_PIN,
    .rst = 4,
    .dio = {7,6,LMIC_UNUSED_PIN},
  7. I added the following code just under the case EV_TXCOMPLETE: to print out the download output:

if (LMIC.dataLen)
Serial.print(“Received “);
Serial.println(” payload bytes”);
for(int i=0;i< LMIC.dataLen;i++)
Serial.print(" ");
Serial.print((LMIC.frame+LMIC.dataBeg)[i], HEX);

I can use OTAA to join the Thingpark network very quickly.
I can upload hex data and see the results on the Thingpark backend.
I can send download hex data to my application from Postman - but it is encrypted!

Does anyone know or can point me in the right direction on how to:

  1. Prevent the download payload from being encrypted
  2. How to decrypt the download payload using the existing LMIC libraries?

It looks like you are not using TTN but another provider, why do you search for answers regarding downlink issues with that providers setup on the TTN forum? Please use the forum of that provider for questions regarding your issue… (the combination of LMIC and TTN provides the data unencrypted on the node)