Well, it’s a headache to set up; but regression tests are run for the 32u4 as part of CI testing for the LMIC. So maybe we’re talking about different things. You must disable “Class B” support (Ping and Beacon) – which is not really a problem because Class B still doesn’t work in the LMIC.
Although Adafruit Feather 32u4 and other ATmega32xx based boards are (due to limited memory) much less suited for new LMIC based LoRaWAN applications, the statement “adafruit 32u4 feather does not have enough RAM to run the LMIC software” is not correct however.
The MCCI LMIC library will run just fine on ATmega32xx based boards like Arduino Pro Mini, Adafruit Feather 32u4 and BSFrance 32u4 II. The only problem is that there will not be much room left for larger, more advanced sketches due to the (nowadays) limited memory resources on these 8-bit controllers.
Over time LoRaWAN versions have changed, new features have to be supported and the memory footprint of MCCI LMIC has grown accordingly. For this reason the LMIC-node example application cannot use MCCI LMIC with these boards. The ttn-otaa.ino example included with the library will run fine however.
As @terrillmoore already mentioned: to use MCCI LMIC with these 8-bit controllers it is best to disable Ping and Beacons to minimize the memory footprint. It is also necessary to relax LMIC timing by setting LMIC ClockError, otherwise downlinks and OTAA joins will commonly fail with these boards.
For setting LMIC ClockError see here and here for an example.
LMIC-node does not (directly) support the Adafruit Feather 32u4 (because support for this board was not yet added). LMIC-node does support some other ATmega32xx based boards however.
Due to the ATmega32xx’s memory limitations, LMIC-node cannot run in combination with MCCI LMIC (preferred) on these 8-bit boards. Instead it will use the Classic LMIC library for these boards which is smaller. Classic LMIC is deprecated however and (much) less LoRaWAN compliant which is/can be an issue for TTN/TTS V3.
I have this problem for Adafruit Feather 32u4 at 868 frequency when I try to connect to TTN.
“No response from RN module” would suggest you’re running a sketch intended for a board with a Roving Networks module on it, rather than the bare radio found on the Adafruit board and being discussed in this thread. For the Adafruit board you need to use a recent version of LMiC such as MCCI’s.
Or a Microchip RN29xx(915Mhz)/28xx(868Mhz) LoRaWAN module?
Because Microchip bought Roving Networks - but kept the numbering scheme
IIRC it was only ever launched as a ‘Microchip’ module, not under the Roving Networks brand so trying to avoid confusing OP… original core team behind the development of original LoRaMAC & LMIC, and then the pre-cursor push into what we eventually launched as the LoRa Alliance was always listed as Semtech, IBM, added Microchip and later others…etc. No ref to Roving Networks so if OP started googling for that it could waste a lot of time/effort 
Otherwise we might as well start saying a module using Cycleo Silicon/IP! 
Do you recommend the MCCI library?
Not really relevant to your hardware - you have a LoRaWAN module that does all the work that LMIC would do.
1 Like
Other way around. They’re trying to use software for the RN module, but their Adafruit board has a bare radio
Doh! 
In that case, @arlx07, you should use MCC LMIC to be found on GitHub and as that’s flying without the safety net of LMIC-node, you need to go through the instructions line by line.
Or replace the device with an Adafruit Feather M0 RFM95 which is directly supported by both LMIC & LMIC-node.
@arlx07 It looks like you are wasting our time!
You were already advised to read the instructions in the Big LoRa32u4 boards topic.
Instead of following the instructions in that topic you tried to run other, unsuitable software for your board (for RNxxxx module which your module does not have).
Then you come back and ask for help because you don’t get that working, confusing other users with errors about RN module. And now you are asking if we recommend the ‘MCCI library’…
YES! and this was/is already documented at the start of the Big LoRa32u4 boards topic.
With the current TTS CE V3 (aka TTN V3) network you do not have (many) other options than using the MCCI LMIC library with your board.
1 Like
Where can I find APPEUI, DEVEUI, APPKEY for the adafruit feather 32u4 868MHz boards?
When you register the node on the Console, under you application, it can create you one.
I know this is an old thread, but I recently got two Adafruit Feather 32u4 US915 boards. Also this is my first experience with LoRa and TTN. And also C++.
I’ve been able to make them talk to each other with some TX/RX sketches, but I am having a heckuva time trying to get it to work with the mcci-catena/arduino-lmic library.
Also I’m a bit of a noob and I’m not sure I’m using the sketch properly.
At least, I am confident that I’m not getting anything out of the radio when i run that ttn-otaa-feather-us915.ino file.
I’ve put in my keys for eveui, appeui, and appkey, but I dont think that would have to do with nothing coming out of the radio.
I do have a connection going from pin 6 and DIO1.
At the top of ttn_otaa_feather_us915.ino, i have added
#define ARDUINO_AVR_FEATHER32U4 1
I’m not 100% sure what the right way to do this is. Its been a long time since I’ve done much with C++.
On the serial monitor in the arduino ide, I get:
Starting
Packet queued
315705: EV_JOINING
316285: EV_TXSTART
My dad is a ham, and he used one of his receivers to listen to 915MHz, and he didn’t hear anything.
He DID hear something when I tried the TX/RX demo programs before.
Its just, when I try to use that lmic.h library, nothing happens.
Regardless of whether or not I can hit a TTN node (theres supposed to be one very close to me), at least i would like to confirm some traffic leaving the radio.
Is this worth putting a ton of time into or should I go with a different board with better software support?
Thanks!
-Travis
Yes, if only because it takes Ninja level LMIC skills to get it in to an ATmega328P aka Uno, I’m not even sure how you got it in to a ATmega32u4 which has even less flash.
However you also have some gaps in knowledge to resolve - devices don’t talk to each other, they transmit, are heard by gateways in range which relay the uplink to the LoRaWAN servers, process it and pass that message on to your end point / integration.
Other (smaller) libraries are available that do enable individual devices to talk to each other, known as point to point, but this is the TTI funded TTN LoRaWAN forum so is not discussed or supported here.
The other fallacy to address is using “Other Peoples Gateways”. Yes, the TTN is about communal use of each others gateways, but that only works if they are in range and the discussion of range has already been covered this week for you to read - there are many variables but mostly when developing devices owning your own gateway is somewhat essential as you can control coverage and debug device transmissions. The US915 band covers 902.3 - 914.9MHz with the device randomly choosing channels on each transmission and the nature of LoRa spread spectrum chirps need some prior understanding to be able ‘hear’.
Most of the Arduino C is pretty basic - as in no more than BASIC or Python or PHP or Java. Early days it’s mostly about having the right kit, following the instructions and reading the Learn section (linked top of this page).
A more straightforward system is LMIC-node to start with and that has a list of boards that are known to work with it. To recommend a specific board it always helps to know what your end goal is.
Thank you so much for the response!
Yes, if only because it takes Ninja level LMIC skills to get it in to an ATmega328P aka Uno, I’m not even sure how you got it in to a ATmega32u4 which has even less flash.
I guess in its current state its still small enough to fit? Or at least the bits of it I’m trying to use. In the output during the upload, it does come pretty close to filling it up completely.
However you also have some gaps in knowledge to resolve - devices don’t talk to each other, they transmit, are heard by gateways in range which relay the uplink to the LoRaWAN servers, process it and pass that message on to your end point / integration.
Other (smaller) libraries are available that do enable individual devices to talk to each other, known as point to point, but this is the TTI funded TTN LoRaWAN forum so is not discussed or supported here.
Yes, using other libraries like here Using the RFM9X Radio | Adafruit Feather 32u4 with LoRa Radio Module | Adafruit Learning System, I have confirmed that the two boards do have functional radios.
With regard to gateways, I’ve been window shopping those pretty hard. I don’t have an outdoor requirement for a gateway, so I’ve been looking at
- TTN Indoor Gateway
- HT-M7603 Indoor LoRa Gateway – Heltec Automation
- Raspberry Pi LoRaWAN Module SX1302 SX1303 Mini PCIe 868M 915M Lora Gateway Hat Expansion Board (from waveshare)
- your fav gateway here
As far as an ‘end goal’, I’m not really sure yet. Currently a solution in need of a problem. But at least making something hit TTN properly would definitely be an accomplishment.
If not these Adafruit 32u4 things, what do you suggest? Lots of interesting hardware from LILYGO (especially that T-Deck). Also Heltec and Waveshare. I just got the Adafruit boards because they were on the rack at my local MicroCenter.
Curious for non-ESP32 things, as youtuber celebrity Andreas Spiess has some complaints about how the ESP32 behaves when it wakes from sleep. Though its not a deal breaker if that’s the best platform to develop on right now.
Thanks and hope you’re having a great day!
-Travis
A ‘no sensor’ out-the-box sketch usually just about fits but as soon as you add something it grows quickly. You need to also ensure you have at least 900 bytes of free RAM.
This:
And if you search the forum, you’ll understand why.
Given our propensity for battery powered devices, ESP32 is rarely the best platform to develop on. Which circles back to using the forum, the Learn section and the LMIC-node info to cross reference your lists to see what is recommended & how people get on with them.
2 Likes
To me LMIC is a beast that I can’t tame. In my testing it seems that latest LMIC is too big for feather-32u4. I had LMIC mismatch probably due to a memory corruption. I have success with feather-32u4 (deep sleep) and SlimLoRa + GPS + IMU + EEPROM. Even with power down the device does not need to rejoin. But I didn’t added support for US915. You can try, adapt and submit PR (pull request) to add support for US915.
I think the official name us US902. I didn’t tested the freqs. Maybe it’s working out-of-the-box.