@johnmiddleton, It’s an interesting issue, but on the other hand, I don’t use OTAA and I am not sending any data upstream to the mote, so I don’t know if that timing issue on the rx window could be the problem on my device.
Hi @iot-partners, @johnmiddleton, The problem is that DIO1 is NOT connected to pin 6 on the board (according to the schematic of Adafruit). This bit is used to check ‘ready for the next transmission’. So, only one transmission, and then it will stop. The text from Adafruit:
#8 - used as the radio CS (chip select) pin
#7 - used as the radio GPIO0 / IRQ (interrupt request) pin.
#4 - used as the radio Reset pin
Since these are not brought out there should be no risk of using them by accident!
There are also breakouts for 3 of the RFM’s GPIO pins (IO1, IO2 and IO3). You probably wont need these for most uses of the Feather but they are available in case you need 'em!
So connect IO1 (DIO1) pin to pin 6. Do not use pin 11, not needed, so LMIC_UNUSED_PIN there.
Cheers
Hi Galagaking,
But that is exactly what I wrote: I wired up DIO1 to D6 ! 
So now I uncoupled IO2 - D11 and put LMIC_UNUSED_PIN in the pin connections instead of D11, but the result is still the same… hanging after the first transmission
Just checking :-). Look at Adafruit LoRa Feather -> Gateway , i saw you posted your question also there. But my advice remains the same. I use OTAA, the mentioned library ( https://github.com/matthijskooijman/arduino-lmic ) , and the ‘out of the box’ example. Blinking a led on the digital port has solved many problems (interconnection, wrong pin numbers etc). The symptoms look so familiar, i solved it by checking the DIO connections (only DIO0 and 1 are needed).
I have very similar results with the M0 version: Adafruit LoRa Feather -> Gateway
If both the M0 and 32U4 platforms have the same or similar issues, then i suspect the LMIC library might be to dependent on the Atmega328P. Has anybody got it working on an non Atmega328P processor?
I have some issues with the M0 and outputting to serial port. This makes it very hard to debug. I have spent many hours trying to figure it out, but no luck.
Same here @sillevl 
very hard to generate debug info on the serial interface, and also tried blinking the onboard LED to see where things get stuck but that only makes it more unstable…
But then @Galagaking has got it working on this architecture, so there is hope. There is only very little configuration to do to get it running out of the box, so where do we go wrong…?
To create even more mystery on it for you guys: the same setup is working for me on a M0 feather! I got messed up with several LMIC versions, I have cleaned up all my libraries, did a re-install of Arduino IDE. I did have problems with Visual Studio to create a working setup. May be you can look at that? Downloaded the library from @matthijs as mentioned above , change pin numbers, and it works. I use a breakout board for the RFM95, so I connected in another way. M0 / 32u4 setup is the same:
// Pin mapping
const lmic_pinmap lmic_pins = {
.nss = 10,
.rxtx = LMIC_UNUSED_PIN,
.rst = LMIC_UNUSED_PIN,
.dio = {5, 6, LMIC_UNUSED_PIN}, //
};
The first OTAA cycle will last long (3-4 mins), but then I sent every minute a frame without a problem. Hope this can be helpful.
@sillevl , The M0 serial port IS terrible. I switched to Serial1, connecting via a normal FTDI connector and not through this USB simulation stuff. Replace all the Serial statements with Serial1 and (debug) life is a lot easier!
1 Like
@Galagaking I will try if your pinmapping makes the difference (this weekend). Will update with the results.
Did you change the spi fequency in the hal.cpp file? I have some FTDI breakout boards, will try that again as well.
Yes !!! Success
I have the ABP demo working using the following pinmap.
// Pin mapping
const lmic_pinmap lmic_pins = {
.nss = 8,
.rxtx = LMIC_UNUSED_PIN,
.rst = LMIC_UNUSED_PIN,
.dio = {3, 6, LMIC_UNUSED_PIN},
};
The SPI frequency is set to 8Mhz in the hal.cpp (will try default 10Mh value later).
The only extra connection I needed was to connect DIO1 to pin D6.
I will try the OTAA example later on.
Congrats! Had some thoughts about your problems. I use 10E6 (default) in hal.cpp, because i did a new start with the clean LMIC library. The Serial / USB port emulation was driving me mad. So I changed everything to Serial1 (connect FTDI to RX0, TX0). For experimenting my ‘wifi FTDI’ ESP8266 Serial to Wifi setup was extremely helpful (https://github.com/jeelabs/esp-link). By debugging this way, things were much more stable. I think there is some interference between the USB / Serial code and LMIC. At this moment my node only stops when the LIPO is empty! Cheers
For me still no luck, while I seemingly have totally identical setup to @sillevl : same pin mapping, same HW connection from DIO1 to D6, using ABP, SPI clock changed to 8E6… And still it only sends data once and then stalls… Driving me nuts! 
@iot-partners did you remove all the references to Serial? I changed them all to Serial1 and used an FTDI breakout board as external Serial to USB converter. I am not sure, but I think this makes the difference.
I did not change to serial1 yet but I did take out all references to serial. No effect…
I have a rather short connection from DIO1 to D6. Could crosstalk from the RF-signal be a problem?
Victory!!!
Out of frustration, I bought an M0, and I got it running within a minute! So there is definitely a problem with this software running on the 32u4 architecture. It’s not the serial interface, because I took all of that out already and it gives the same issue.
After a lot of debugging and trial and error (and some expletives), I finally got it working on a Feather 32u4 as well:
-
According to the schematics of the Feather 32u4, DIO0 is connected to digital pin 7. For the M0 version, DIO0 is connected to digital pin 3. So in the initialization for the Feather 32u4, I used .dio = {7,6,LMIC_UNUSED_PIN}. I have connected IO1 to digital pin 6 with a wire bridge.
-
My first statement in void setup() is delay(1000). Without this delay, I get the same results as @iot-partners
4 Likes
I got my 32U4 to work as well with this tip!!!
Who would have thought it to be an initialization problem! 
1 Like
Thank’s a lot for this short, but very usefull post !