THANK YOU! You give me hope. Still trying to undestand MCCI LMIC code, TinyLoRa style is easier for me.
Already opened an issue with some PR from TinyLoRa that’s maybe helpful.
@Jeff-UK @cslorabox I don’t get the rush to criticize him. One click away is the repos. After reading his message, the first thing I did, was to click.
If you can find an evening to give us some pointers at what needs looking at, it’s certainly something worth taking forward …
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.
I am fine with both names 
brevity vs precision
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.)
No event handling
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?
That will also trigger the Lora Alliance as it infringes on their rights. Nothing wrong with the current name.
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.
With (MCCI) LMIC this is handled automatically by the LMIC library.
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.
After changing the sleep commands to the correct ATTiny84 version and selecting the correct port for tne RFM95 NSS I only had 1 error during compiling regarding the timer TIMSK in the timing.cpp file.
I made the following change in timing.cpp file
TIMSK |= (1 << OCIE0A); ====> TIMSK0 |= (1 << OCIE0A);
After that I was able to compile but no result when trying to connect to TTN
Than I changed
TCCR0B |= (0 << CS02) | (0 << CS01) | (1 << CS00); ===> TCCR0B |= (1 << CS01) | (1 << CS00);
This resulted into 1 activation message as per below. So I believe it has something to do with how the timer has been set-up. However I am not familiar with how to correctly set-up the timer for the ATTiny84 using registers. Maybe you can help me setting up this part of the code correctly.
Appreciate any help you can give me.
Seems likely the timer issues may be preventing firing up the receiver at the correct time to catch the join accept message
On my fork / branch: try-to-compile I adapted some code and compiles with arduino IDE.
Only the first time I had a successfull join (!) and afterwards an uplink. I was excited and moved forward and added SetPower, SetDataRate, debugging options, but after that I never joined again. Tested with V3. I abandoned OTAA and tried ABP. It works since it does need downlinks, but it seems that also the downlinks are not working.
In other words, it seems that the timing creates problem with downlinks. I didn’t investigate it further. I have the impression that instead of 5 seconds it opens the window at approx 1 sec.
The code is here.
@novag thanks for sharing.
TTN V3 absolutely requires proper downlink and MAC command support, even for ABP.
The reality is that trying to make a minimal LoRaWan implementation which actually works correctly is extremely hard, because LoRaWan is not a simple protocol at all.
There’s been talk / an effective feature request that TTN have a way to register nodes with only partial LoRaWan support, but so far it does not - unless or until such a thing is added “incomplete” nodes must not be registered on TTN. because they will trick the network into sending unanswered downlinks over and over and over again, each of which blocks the gateway’s ability to receive other properly functioning nodes.
I know. That’s the reason for my report and my effort to port it to arduino. To enable support for downlinks. At current state it’s the same with TinyLoRa.
Today I saw two examples for timing. I hope I will try those days.
Forgot to add, that maybe the problem is with my GW. That’s one more reason I want people to test SlimLoRa. Maybe it’s already listening for downlinks at right time (default 5 secs to my understanding).
Still no functional library for Arduino?
What do you mean?
Of course there is a very functional LoRaWAN library for the Arduino framework: MCCI LMIC. Just search the forum for more information.
I mean easy to use straightforward library for Atmega328P (for example Arduino Uno, Mini). Tinylora was perfect goal. I have made well tuned fw.
Why to use veeery old and limited Atmega328P? Because can run on 1.8V, rfm95W can run on 1.8V too. Can be used with LiSOCl battery, 2x AA (rechargeable) battery etc. No need to step up, sted down circuit… Low power consumption max 2mA (mcu) working, 5uA sleeping (mcu, transceiver and sensor).
I have not find simillar micro controller that has these features, can be easy programmed and has good avaiability in Czech Republic (or to Czech Republic from Ali etc). Probably the closest mcu is ESP32 underclocked to 10MHz.
I have try LMIC-node | One example to rule them all
Add support for Arduino Uno and I get warning, that used library is deprecated. I don’t exactly known where to add power saving features. I have ended with join loop and high battery drain (poor signal). With good signal example works fine, but fw is close to fill all avaiable resources and maybe I’m not sure if is possible to add BME280 sensor.
You mean this library?
Looks like it is only for 32b mcu’s. I got lost in all the *mic; *cci libraries - all have same name.
