Yikes! Not that great 
Too bad, the lack of memory space is IMHO biggest LoRa32u4 drawback.
No, a lot is uncertain about the lmic_slim thing but the actual code closely resembles LMiC in the style and naming of functions and structures, making it look like a very stripped down version. It’s also functionally C code of non-Arduino heritage.
TinyLora is fundamentally C++ code of very different internal details. TinyLora also has some degree of history and ownership clarity.
The provided functionality does however seem to be very similar between the two - while lmic_slim has a receive function, it doesn’t actually appear to have the other things needed to receive, like timing or packet parsing and decoding.
2 Likes
Hello Excuse me english, I want to know if the board Lora 32u4 ll v.1.3 supports Class C and if LMIC also supports class C
Thanks.
Those are perhaps interesting questions to research on the commit and issue history of a given LMiC repo.
But as TTN does not support Class C, they are perhaps not very relevant questions to ask here.
To an extent modifying a node firmware for class C is comparatively simple - in effect, instead of going to sleep you just start the radio going with appropriate settings. Mains power is a practical requirement to leave the radio running.
My friend Dennis built this lmic_slim in 2017 from an early copy received from René Harte. It would by nice to collect your suggestions and finally do the work to make it more usable to the community. From all your feedback it seems to me there is so much knowledge missing on my side.
Would it be worth to you to get the lmic_slim to a better level, or did better alternatives become available?
For me, I still love this board, running it as gps tracker, temperature, noise, particle matter measurement. Using this in my monthly training ‘IOT for Beginners’. I want to add training material online, so all of you can give such training to your community as well. Interested?
Recently added some quick and custom map and graphing integration. This is all built serverless with Amazon Lambda and S3. Under the covers this adds a big data feature as well. I like serverless as it changes the way of thinking for many. I want to document this code as well and make it available to all of you. Help is appreciated to set it up correctly to make it improve and grow with your community input.
Temperature graph example: http://junioriotchallenge.nl/graph/?dateStart=20191209&dateEnd=20191212&application=junior-iot-in-a-box-project&device=all&values=BME280_Temp
Please send your guidance on improving the lmic_slim library!
Marco@juniorIOT.nl
1 Like
Hi Marco,
Thanks for your lmic_slim feedback.
In short: My feeling is not really because:
further:
- I’m almost certain that lmic_slim is not LoRaWAN compliant because there is no indication of that whatsoever. It is not even clear what is and what is not supported by the library.
- The library is provided as a ZIP file and you ask for feedback via email.
That is not how open source development works. - What should people give feedback about when nothing is even documented?
That depends on your definition of ‘better’.
While 8-bit AVR MCU’s are still used there is a tendency to shift to 32-bit ARM MCU’s (and things like ESP32) that have (much) more available memory resources, are more powerful and are better able to handle a full LoRaWAN stack implementation.
Multiple LMIC libraries are available for the Arduino framework already. They will not be as small as lmic_slim but are LoRaWAN compliant, are open source and (some) are well-maintained.
In answer to “would it be worth to you to get the lmic_slim to a better level”, I guess not, unless you want to develop for a niche, have much spare time and are willing to maintain it for longer time.
If you really want something LMiC derived but lightweight, your best bet would probably be to work out a series of #ifdef’s to remove what you don’t want at compile time. But keep it based in git and tied back to an actual LMiC. To some extent you don’t even really need to drop code (the linker will do that) but alter the control flow.
Implicit in that would be really deciding and documenting what you aren’t supporting. For example in the current version it doesn’t look like the code has logic to try to receive or to parse received packets, but it still has some of the receive functions even though it’s missing the ones that would be needed for those to be of any use.
Hello, excuse me english I use the lora 32u4 ll v1.3 in AU915 and library mcci-catenna Lmic, my Sketch is very big and I need to reduce the size, I do all the necescesary for reduce the size in the sketch and also I delete some files like the bandplands that I don´t use but still very big. someone knows how can I reduce the size in the library ? Thanks for your help.
Deleting files that aren’t used won’t really do anything, the linker should already be removing code that is never referenced. Try finding the elf output wherever the IDE is dumping it (probably somewhere under /tmp) and using the appropriate avr objdump to analyze the contents and see what is taking space.
I have seen situations on other platforms where strings for debug messages were being included in the build output, even though no code that every referenced them was.
Ultimately though you may need to reduce functionality or change to another chip. This is asking a lot out of an basic-tier ATmega, most users of LMiC are on ARM parts or ESP8266.
In case of changing to another chip, ESP8266 would not be a good choice because of its limited available GPIO pins. Its more advanced successor ESP32 is preferred instead.
Hello bluejedi thanks for your answer. I think should change mi Lora32u4 by the rak811. Do you think its a good idea ?. However I resolved the problem acorrding to your indications using PlatformIO.
thank you very much
I have no experience with RAK811 but it contains a STM32L151 MCU, not ESP32.
It can be controlled via serial interface using AT commands which requires a separate MCU for the application and it can also be used standalone in which case custom sketches can be uploaded.
Development seems to be based primarily on the Arm Mbed framework. Arduino Core STM32 shows (basic) support for RAK811 so it appears possible to program it using the Arduino framework and LMIC (but I am unaware if that is actually being used much).
There is no simple answer to what would be good alternatives for LoRa32u4 because that depends on one’s use case(s) and requirements. (To stay on-topic it is preferred to open a separate topic for discussing possible LoRa32u4 alternatives.)
LoRaWAN and LMiC are complicated enough of necessity, that the first question in choosing a platform generally needs to be “is someone already actively supporting this device for this use?”
Based on that I would strongly discourage someone who doesn’t want to get deep into LMiC internal logic from trying to use an Arduino-based LMiC on an ESP32 as the architecture of timing is just too much of a mess by the time it filters through the Arduino layer’s pretending to be a very different sort of system than it is and gets down to the LMiC code. Unless a repo is explicitly claiming good support and capability, the fact that the code can build and transmit doesn’t mean it’s going to reliably catch downlinks.
In constrast, past posts here suggest that the native ESP32 port might make things clean enough to be reasonable and get the timing right. Given the native port would be exclusive to the ESP32 anyway, it is unique challenges are presumably not going to be shortchanged there.
At any rate, there’s a lot of complexity there that there isn’t with the ESP8266 (and the more extreme ESP8266 pin shortages are with the smaller modules - better modules expose a reasonable number of pins, especially as most IoT sensors are bussed devices anyway) . The ESP32 is not the “better ESP8266” that many first assume, it’s actually a quite different part with a quite complex software stack.
There is no simple answer to what would be good alternatives for LoRa32u4 because that depends on one’s use case(s) and requirements.
A good choice would be the hardware whoever maintains the LMiC branch one wants to use, is focusing on for their own development and testing. For example, for MCCI’s LMiC that would be the (ARM based) Adafruit Feather and their own (Murata module) STM32L0 board, and to a lesser extent the ESP8266. In comparison the ATmega32u4 gets little if any attention there, presumably because it’s short enough on resources to not be worth investing effort in (though as a mature Arduino port that works the way Arduino code expects a platform to, presumably it does work to the degree that it fits)
1 Like
For many applications (battery powered low-power applications included) the number of GPIO pins on ANY ESP8266 (e.g. ESP-12F module) is just too limited for any serious applications (when using a SPI LoRa module).
For example, a battery powered weather station with some I2C based sensors:
- Use SPI for the LoRa module.
- Use shared I2C bus for sensors, FRAM (or whatever that can be connected via I2C).
- Use ADC pin for battery voltage monitoring.
- Use one GPIO for switching peripheral power (e.g. enable/disable battery monitor voltage divider).
- Use deep sleep with auto wake-up from internal timer (requires a dedicated GPIO pin).
This just doesn’t fit on an ESP8266 because it has too little GPIO’s available (and some of the GPIO’s have strict pull-up/pull-down limitations which limits their usability).
Due to limited number of usable GPIO ports the ESP8266 when used in combination with a SPI LoRa module, will be unsuitable for many/most LoRaWAN applications.
If you know a pin mapping for ESP8266 where the SPI LoRa module (with DIO0 and DIO1) and the I2C bus (e.g. using a simple I2C sensor) are both working successfully I would be delighted to know it.
Do you have any references / links to articles where timing issues with ESP32 Arduino Core are confirmed and where that is further explained?
Yet those discussion are very interesting, we are starting to get of topic 
I would emphasize that perhaps the one major LoRa32u4 drawback is its too little memory.
This is something to think about when choosing a devboard.
1 Like
Yes we are indeed, let’s go back on track and stay on topic.
Hello Guys,
I need help disconnecting the LDO by grounding the EN pin in order to conserve more power in deep sleep state.
Story: I’m using a lipo 800mah. And i’m reading my sensors every 2min. I get 1 week of life.
The sensor is always on sucking on 3.3volt rail.
My basic understanding: I though on using a mosfet P Chanel and drive one of the board digital pin high to wake the sensors. Read them and go back to Sleep connecting EN to ground through the mosfet. Can you help. I’m software developer, don’t have much experience with mosfets.
With the EN pin on the regulator low, the 3V3 supply to the processor is off as well. So how is the board going to wake up again ?
Ty for the help @LoRaTracker . Did not think of it. I don’t have resources or time to invest in a external more eficient voltage regulator for now.
So as a stop gap i should cut the power to the sensors only. You have any recomendation on the most eficient mosfet (i think N channel this time). And a wiring diagram if it is not asking too much 
I don’t know how to work with this 3.3v