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
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.
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.
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).
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.
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.
Yes that is the LMIC library to go with. This is actively maintained and is the most LoRaWAN compliant of available open source LoRaWAN libraries for the Arduino framework.
You can also use it with 8-bit MCU like ATmega328 and ATmega32u4.
The problem with these ATmega32x MCUs however is that they have very limited memory resources compared to more modern 32-bit MCUs.
LoRaWAN has progressed and the newer versions have more requirements. The MCCI LMIC library has grown in size accordingly. It can still be used on ATmega32x but you will not be able to run very large sketches in combination with MCCI LMIC on these MCUâs.
Check the ttn-otaa.ino example included with the MCCI LMIC library. It will run on ATmega32x and it should also be possible to add support for BME280 in addition.
Be aware that when using MCCI LMIC with ATmega32x you will have to:
Disable PING and BEACONS to save memory (and they are not needed for LoRaWAN Class A devices anyway).
Adjust the LMIC ClockError (otherwise downlinks and joins will fail).
Search the forum for more information about these subjects. Check the BSF for the Pro Mini board in LMIC-node for how to set ClockError with an approriate value.
LMIC-node does not directly support the Uno but you can use the Pro Mini as example which will not be much different (except for some pin mappings maybe).
Be aware that LMIC-node uses the predecessor of MCCI LMIC which is called âClassic LMICâ. It uses Classic LMIC for ATmega32x because there is too little memory to use LMIC-node with the MCCI LMIC library on these boards. But Classic LMIC is now deprecated because it is not LoRaWAN compliant and can cause certain issues with TTN (TTS CE V3).
LMIC-node is a rather extensive example application that uses many text messages to make clear to the user what happens. It supports multiple MCU platforms and was to certain extent optimized for use on ATmega32x. However, over time the MCCI LMIC library has grown in size and modern LoRaWAN applications just require/prefer use of MCUs with more memory resources.
LMIC-node uses MCCI LMIC for all supported boards except for the ATmega32x based boards. For these boards LMIC-node uses the older Classic LMIC which is now deprecated (for valid reasons) but it still works and therefore LMIC-node uses it to make it possible to run on these ATmega32x MCUs so you can still have an example that âworks out of the boxâ experience.
When LMIC-node uses Classic LMIC for these MCUs it gives a warning that the Classic LMIC library is deprecated, but it will still run.
If you still want to use ATmega32x my advice is to start with the ttn-otaa.ino example and build from there. You can look at the code of LMIC-node for code examples of how certain things are implemented/solved that you donât find in ttn-otaa.ino.
Another option is to start with LMIC-node and strip it from everything you donât need to make it fit on ATmega32x while using MCCI LMIC but that requires (much) more knowledge.
Power saving and LoRaWAN is a more complex topic and LMIC-node currently does not provide support for it (because different per MCU platform and the MCCI LMIC library currently still does not support save/restore LMIC-state features).
Look at Atmega328 / ATmega32u4 / Arduino Pro Mini and deep sleep elsewhere on the forum for more information.
It is indeed a very good little MCU which I use for very simple non-critical nodes running off a couple of AA batteries and it works fine with the MCCI LMIC 4.1 if you turn off the pings & beacons as suggested. I use decent Pro Miniâs so havenât had a need to adjust the clock as yet.
I have a work-in-progress board that has an ATmega4808 48KB flash, 6KB RAM) and RFM95 on it which will give me far more latitude for cheap & cheerful devices because âŚ
the only place with good availability for anything right now is somewhere over the rainbow, way up high. Iâm struggling to get electrolytic capacitors and my Raspberry PI CM4 gateway project is dead in the water as pretty much anything with a Raspberry is Unobtainium.
But I can usually get a few ATmega4808âs here and there and Iâve got other boards in the works to give me options.
In some random ideal world, probably over the same rainbow, we could port MCCI LMIC to being a bit less reliant on the Arduino bits and a little less bloated in areas (OS Jobs, Iâm looking at you) so we all have more options.
You may find this repro useful as a starting point. I may get around to updating it to LMIC 4.1 shortly.
Iâm not afraid to use another mcu (then atmega328P), but I must be able to get them. And it is not problem of Covid etc, it is problem somewhere else. And good community around these mcuâs is important too.
My problem with new libraries will be maybe, that I underclocked Arduino Mini to 1MHz to save some power ;). LMIC-Node was tested on regular Arduino Uno 16Mhz.
