Keep in mind you are allowed only 10 acks of other downlinks a day.
Yes, I have it clear, it is only to see the operation without ADR. Still this doesn’t answer my question.
Realistically:
-
Use an up-to-date LMiC especially if you want ADR without OTAA; there were bugs that made that combination not work
-
DO NOT USE AN ATMEGA328 - you don’t have the resources in that chip to do things properly
-
Do not use confirmed uplink, the design of that in LoRaWAN is basically broken
Ok, my library is update such as https://github.com/mcci-catena/arduino-lmic.
I dont use ATMEGA, I use Arduino Pro Mini.
It is NOT possible to use ACKS?
Likewise, the reason why the SF changes when no MAC command comes inside FOpts in dowlink is not understood.
Arduino Pro Mino does use ATmega328P
1 Like
Indeed, that is pretty much the case, practically speaking
For uplink you need to just accept that packets will be lost, and use the data from the next that gets through instead.
For downlink, what you should probably do is have the receipt of a downlink make a small modification to the uplink packet, and if you get uplinks that lack that, eventually re-try the downlink. But be patient… this is not a system designed to promptly downlink things.
Ok I understand this point about ACks, but I dont understand why downlinks (or ACk) modify SF without MAC commands in FOpts. Is this a bug of my end node? In which fields of the frame do the SF adjustment commands come? Does the node by itself make the determination to vary its SF? or its the algorithm?
Thanks!!!
Yes. No. Whatever.
Read the spec. Read the code.
Add debug output.
1 Like