Agree, it would be great to have this nice feature integrated in the “mainstream” stack from @matthijs
I guess that’s what the pull request by @charles was meant for 
UPDATE: Simpler now and worked right away:
I used Arduino 1.8.5 on a Mac - your milage may vary.
1 Get an Adafruit Feather 32u4 lora with the right frequency range for your region (866 for Europe)
2 Follow instructions on the adafruit site to hook up antenna and power supply
3 Connect pin 6 with IO1 (as labeled on the feather)
4 In Arduino 1.8.5 IDE do not use the built-in support for finding and downloading the lmic library - instead rather download the zip file from github instead at https://github.com/matthijskooijman/arduino-lmic
5 Open the apb example from this library from the examples menu and change the following lines:
const lmic_pinmap lmic_pins = {
.nss = 8,
.rxtx = LMIC_UNUSED_PIN,
.rst = 4,
.dio = {7,6,LMIC_UNUSED_PIN},
};
6 Get an account on the things network, create a new application in it and create a new device. Change the device to use abp instead of otaa. Copy all of the settings required from the device to your source code.
7 reset the frame counter for the device (you might need to do this again once you reset your device)
→ It worked at first attempt with a Gateway now installed at the top of my house to serve my local community in Heidelberg-Schlierbach.
8 Do whatever you want to hook up any sensor and send its data
One day I will dare to go back to otaa - but not now.
1 Like
I have similar problems with LoRa32U4 and OTAA.
Setup:
LoRa32U4 II by BSFrance (868MHz) (with LoRa module replaced, see my next post).
Using LMIC-Arduino library version 1.5.0+arduino-2
RAK831 based gateway.
Distance between node and gateway is around 4m (with a concrete floor in between).
Activation using ABP just works.
Activation using OTAA first fails, but after waiting several minutes the OTAA join succeeds (on a different spreading factor).
t0: First OTAA join attempt (SF7) failed.
t1: Second attempt (SF7) failed.
t2: Third attempt (SF8) failed.
t3: Fourth attempt (SF8) failed.
t4: Fifth attempt (SF9) SUCCEEDED.
From there communication went as expected.
What causes this?
The LoRa32U4 contains an ATmega32U4 3.3V MCU.
I then tried the same test with a board with a similar (not identical) MCU: Arduino Pro Mini 3.3V connected to a Hope RFM95 LoRa module.
This setup showed problems with OTAA identical to the LoRa32U4, but the join succeeded only at SF 10 (SF 9 failed).
What’s happening here? What causes this?
When I used the exact same RFM95 module with ESP8266 and ESP32 based boards the issues with OTAA did not occur and OTAA just succeeded using SF 7.
Maybe power / speed of the MCU is at play here. But in that case I would have expected others to have similar problems and this to be a know issue.
Pin mappings used for LoRa32U4:
LED - 13 (LED_BUILTIN)
RFM9x/SX127x LoRa module
NSS - 8
MOSI - 16/MOSI
MISO - 14/MISO
SCK - 15/SCK
RST - 4
DIO0 - 7
DIO1 - 6 (Not wired onboard, must be explicitly wired).OLED display
SDA - 2/SDA
SCL - 3/SCL
1 Like
The SX1276 LoRa module on my LoRa32U4 II (by BSFrance) was very poorly aligned. Soldering pads of the LoRa module almost seemed to shortcut neighbouring pads on the LoRa32U4 PCB.
Because I was having unexpected OTAA issues (described above) where OTAA join requests failed, the misaligned LoRa module appeared a plausible cause. So I removed the LoRa module from the LoRa32U4 board.
I was told that my LoRa32U4 II was a 868MHz version.
The bottom of the removed SX1276 LoRa module was marked 915MHz however. This also appeared a possible cause for OTAA requests.
To fix it I mounted a compatible Hope RFM95 868MHz module onto the LoRa32U4 board. I hoped this would fix the OTAA join issues but it did not.
After some further testing I experienced the behavior described in my previous post: that the join succeeds only starting at SF 9.
(I did not wait minutes when the original SX1276 LoRa module was still mounted, so I cannot comment on if the original module would have joined on higher spreading factors).
Have you relaxed the timing by using
LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100);between the LMIC reset and the join attempt?
3 Likes
Thanks. I had not, but adding it fixed the issues for both the LoRa32U4 and the Pro Mini setups. 
1 Like
WARNING
When buying pre-wired JST-PH connector plugs for the LoRa 32U4 battery connector:
Be aware that polarity may not be what you expect.
DON’T BE FOOLED BY THE WIRE COLORS.
When looking at the red and black wires coming out of the connector one can easily assume that red is +3.7V and black is ground and then wire the battery correspondingly (at least I did).
But how the connector is wired may not correspond to how the board is wired. The red and black wires may be reversed on the connector.
If that is the case connecting the battery/connector will toast the LoRa 32U4 board.
When noticing the smoke (and smell) I quickly disconnected the battery, but it was already too late.
The battery controller chip was toasted. The LoRa 32U4 is still working but the power led does not light and the battery controller is damaged (will have to replace it).
So be careful with pre-wired battery connectors, they can toast your board unsuspectingly.
Check first if the connector wiring matches the board before trusting the wire colors.
I used these: JST-PH connectors with wires from AliExpress.
They have red and black wires reversed for LoRa 32U4.
It is not difficult to switch the wires on the connector but better do it before, not after.
2 Likes
Thanks for the heads-up @bluejedi, I have some of these wires sitting in our postal system somewhere!
Just a question for other LoRa 32U4II users…?
Range? Is it universally poor?
I have only set up one board which uses LMIC and OTAA. The antenna is one of the small (about 50mm SMA type) 868MHz jobs that ship with some of the AliExpress products. I am finding that the node only connects to my (RAK831) gateway when within say 300m and then with SF7 or occasionally SF8. I am sure I read that ADR doesn’t adjust SF if I am TTNMapping for example but even getting the node to connect with a SF that will work over a few hundred metres seems to be a trick?
I know I should try to eliminate possibly poor antenna and I guess the pig-tail also before I condemn the LoRa 32U4II but any consensus among us or hints to get a more robust connection for longer range?
G
https://www.google.de/maps/dir/49.415783,8.7598985/In+der+Aue+20,+69118+Heidelberg/@49.4142399,8.7599525,17z/data=!3m1!4b1!4m8!4m7!1m0!1m5!1m1!1s0x4797c1d88a12d833:0x8bb7f33bf0819a5!2m2!1d8.76404!2d49.41265?hl=de - on this stretch of 500m with no clear line of sight from the gateway at the top of my house to the node with a 8.2cm wire antenna (bent twice) I did get data from the device in average 2 times out of 3 over a 4 day period every 3 minutes. I used the default settings from the apb example ino file. it sometimes did take 20 minutes for the first one to come through (I assume this is where ADR and other channel hoping magic happens between the node and the gateway) but then it was quiet reliable. I’m sure with line of sight I could go much further.
Hello,
I am testing a piece of similar code and I can see extra 30 seconds of delay on top of my sleep cycle.
Is it related to my version of LMIC library: “1.5.0+arduino+2” ?
Thank you! But it looks like nothing can be done (easily)…
I’ve not used it, but one of the posts in the topic I linked above claims:
(Emphasis mine. Please post any discussion about that piece of code to that linked topic, not here. I will delete this reply later on.)
FYI: The LiPo/Li-ion Battery Charge Management Controller chip on the SBFrance LoRa32U4 is the following type: MCP73831T-2ACI (available here).
I blew it up by accidentally reversing the battery pins. It now works fine again after replacing the chip.
1 Like
anyone else seeing that LMIC_setClockError-correction having no effect anymore lately?
my BSFrance-node just activated fine and nearly instantly for weeks, now it’s again taking a ~dozen or more tries till it’s getting activated - didn’t change anything… 
Last week I had issues with joins as well, the backend was sending join replies minutes after the request. The window isn’t that large 
I’m not saying that is your issue but just want to point out that a node not joining might have several causes.
1 Like
Hello everyone!
I’m writing you guys because regrettably after reading different topics related to the Adafruit Feather 32u4 LoRa radio and making some tests, I’m no able to getting it work.
My goal is have multiples nodes ( Adafruit Feather 32u4 LoRa) sending data over LoRa to a Multitech Conduit Gateway. As I could read in the other topics, I need to build a LoRaWAN stack in the feather and regrettably it takes a huge part of the capacity of the board; this point was not enough clear to me, if someone can give me a little bit more context related to this or can suggest me another way to build the LoRa network using the devices mentioned I would really appreciate it!
From another hand, as first I tried to connect the Feather to TTN following the instructions provided in this repository @wklenk (thanks for sharing it with the community), but the board is not joining properly. The behavior presented in the built-in LED is one blink per second and after a while stop blinking, I’m not sure where can be the issue here. The following steps are the ones that I did:
- Setup of the board in the Arduino IDE.
- Download & Installation of the library required.
- Wire pin connection - IO1 to 6.
- Modification of the
config.hfile:
// Uncomment this to disable all code related to ping
#define DISABLE_PING
// Uncomment this to disable all code related to beacon tracking.
// Requires ping to be disabled too
#define DISABLE_BEACONS
Also, I modified the frequency zone to 915:
//#define CFG_eu868 1
#define CFG_us915 1
// This is the SX1272/SX1273 radio, which is also used on the HopeRF
// RFM92 boards.
//#define CFG_sx1272_radio 1
// This is the SX1276/SX1277/SX1278/SX1279 radio, which is also used on
// the HopeRF RFM95 boards.
#define CFG_sx1276_radio 1
- Register a device in TTN.
- Assign the Device EUI, App Key, APP EUI generated in the device previously created in TTN to the Arduino Script. The APP EUI and Device EUI are specified in “little endian format”.
- Upload the code in the Feather
- LED status = once per second, then stop.
I hope all of these points make the issue presented easy to find, I would appreciate any suggest! 
Thanks,
Maria C.
Hello,
I suggest you enable the Serial Monitor in the Arduino IDE at 115200 bps and let us know what the output is. If you do so, it is also a good idea to uncomment these lines in the mentioned sketch: But be aware: The sketch won’t continue if you don’t have the Serial Monitor window open.
/*
while (!Serial) {
// wait for serial port to connect. Needed for native USB
delay(100);
}
*/
If the LED blinks with a rate of 1 blink/second this makes me think everything works as expected and the application tries to join TTN, but after it has joined it should change to a blink rate of 5 blinks/second. But you tell us that it stops blinking? So possibly something weird is returned from the gateway with the “join” response that the LMIC stack cannot handle? Just a guess …
1 Like
Hey @wklenk,
Thanks for the quickly response. I reviewed all the configurations in the TTN side, and I noted that had a wrong configuration in the gateway. Now the device is joining properly!
Other thing that I noted is that the the payload sent by you in the example is static uint8_t mydata[] = "\0", this is properly received in the TTN side. Then, I modified the payload to the message: hello! but I’m just able to received the first byte (see the image below). Do you have any idea about this behavior?
Thanks,
Maria C.
That’s easy. Check line 180
LMIC_setTxData2(1, mydata, 1, 0);
The third parameter specified the number of bytes to send. In this case, it is set to a fixed value of 1 byte. Change it to
LMIC_setTxData2(1, mydata, sizeof(mydata)-1, 0);
If you wonder why 1 is subtracted: It is because of the \0 that is added to strings in C.