It evolved from the same Ideentron code base on which TinyLoRa is based. I threw away almost everything except the AES routines and implemented large parts the basic parts of the LoRaWAN 1.0.3 spec. Check out the readme to see what’s supported.
The sample project is currently heavily optimized for the ATtiny85 MCU so that a whole LoRaWAN 1.0.3 stack with support for various sensors runs on an ATtiny85 MCU with only 5 data pins, 8K of flash memory, 512 bytes of EEPROM, 512 bytes of SRAM and without an external clock.
It should not be too much work to support Arduinos and other ATtiny or ATmega MCUs. I am happy to create a fork of the SlimLoRa “library” code to make it a real library supporting more MCUs if someone wants to contribute.
Edit: This was originally an answer to Is V3 the end for TinyLora?. It is and was a fun project. I clarified it’s current state in in the README of SlimLoRa.
…and does it support downlinks? - ADR, Downlink MAC commands, etc? or are we looking at another TinyLoRa, possibly even more stripped down? - YALPI? And likely to misbehave/be unresponsive/disruptive under TTN V3?
You clearly did not read the readme. It supports OTAA, downlinks, ADR, integrity checking and the following MAC commands: LinkAdr, RxParamSetup, DevStatus and RxTimingSetup. It’s all listed here: Features.
You clearly posted in a thread about a fairly specific set of concerns, and made no mention of if the software you were promoting actually addressed them.
That you’ve done so now is good, but you should not have left that out of your original post.
Yep thats right…I did not read the read me! Without more information (as you have now posted) on what was being offered why would I, or any other forumite, go off and invest the time? When there are so many other things to do…Hence my question(s). Glad to hear that you are claiming a more complete solution Think I have a few ATtiny85’s in stock somewhere and might even find time to give it a try at some point
Have you tested with TTNV3? What did you find/see? Problems in rest of thread resolved?
I already tried to get SlimLora to work on an ATTiny84. Unfortunately I wasn’t successful. The code is very much build to work for the ATTiny85 and I don’t have the skills to modify it (although I did try and was able to compile). But it would be great if someone is successful in getting this to work on an ATTiny84.
made it pretty clear that it’s not another send and forget library. But I agree that I could have made it clearer. In the end, I just threw it in, in case it helps someone.
I did not go through the whole thread so idk about all the problems discussed. I did not run into any of the problems mentioned in the first post.
The project is tested against V3 and works fine for me. However I can’t guarantee that there are no bugs. I’ve been using it for two years now and for my use cases it works.
I created a fork at https://github.com/novag/SlimLoRa and prepared it for usage with the Arduino std library. It does not work yet since the timing related code has to be adapted to the Arduino libraries. I do not have much experience with Arduinos so this might take some time. There’s still polishing work to do and, given the much looser memory requirements, lots of functionality can be added or rewritten. I will add issues for the things I remember. Since I am quite busy until the end of March, it may take some time.
Contributions welcome.
@rvdvoort This shouldn’t be too hard. Leave me a message with what does not work.
I’m sorry but in the context of this thread ‘implemented large parts…’ has little weight and sounds no better than a statement/assertion such as the earlier
It likely would just as easily still not be LoRaWAN, though I am glad you have provided more information and the fact that it
Sounds promising, but TinyLoRa works for others so I would like to know e.g. whilst working for you does it cause problems for others such as triggering the download avalanche discussed and described earlier…do you have access to a gw? Does it indicate node misbehaviour? If not then sounds promising and I await reports back from other users with their assessments of if plays nicely with V3 please keep posting & help us fill in the blanks…
The library’s name SlimLoRa is a bit misleading as it tries to target LoRaWAN, not LoRa.
SlimLoRaWAN looks more appropriate but the library is not (fully) LoRaWAN compliant.
If it (also) is based on LMIC then SlimLMIC might be a good candidate for a name.
[update]
Based on below responses SimpleLoRa is still the most suitable of the above three names.
Not to start a discussion here but not being (fully) compliant is usually easier. (e.g. mastering only half of the theory required for driving a car in public traffic is easier but will make you a poor driver.)
This library does not implement any kind of event handling. A call to the Join and SendData methods will block for several seconds until the end of the second receive window.
If there is no support for event handling then how do you handle (sequence of) downlinks?
If I remember correctly, when there’s pending data for a class A device, the device has to send another uplink packet to receive the pending data no? While there’s currently no pending data support it would be easy to notify the user of the pending data and ask him to queue for a second uplink packet.
How this exactly happens on protocol level I’m not sure.
When using LMIC and the node receives a sequence of queued downlinks, this will happen automatically without intervention of the application code. This is done by the library automatically (like handling of MAC command like Status request).
The application will handle al downlink messages (payload data) via an event handler. Therefore I was interested in how SimpleLoRa handles downlink messages without supporting event handling.
The author said the code “will block for several seconds until the end of the second receive window.”.
Thus it handles downlinks by not doing anything else while they are possible.
Since TTN only supports class A, a downlink is only possible in direct response to an uplink. Even the FPending bit is just an invitation to send another uplink so that an additional downlink can follow, the additional downlink won’t be sent on its own.
It’s presumably handled by this library too. Though not handling it would not really cause an issue, because the network can’t do anything until the node sends another uplink, and its free to make that minutes, hours, or days later at its discretion.
Perhaps some of the confusion is coming from the way some other codebases try to create a sort of interface between library and application (LMiC does so in a very unclear way, LoRaMAC does so not just there but between layers of itself in a way abstracted nearly to the point of absurdity); I suspect this one is flatter and more directly coupled.
Think I have a few ATtiny85’s in stock somewhere and might even find time to give it a try at some point 
