OK, so this is mainly an issue with the ESPEasy template?
What should I do now? (apart from upgrading the FW)
I guess the preferred settings are: RX2 freq. at 869.525 and Rx2 data rate at DR3
The rest is OK I guess?
Just to be sure, I will also call out all mac get command on an OTAA node to see what is set during OTAA and compare it with the settings I am now using to make sure I don’t miss anything.
I took a bit more time to look at your device and actually it seems that the problematic part is the RX1 delay at boot time. Your device actually never received downlinks because of this mismatch.
If you look at the original picture of your MAC settings that you have posted above, both RX1 delay and Desired RX1 delay were set to 5 seconds, but your firmware I think actually has at boot time RX1 delay set to 1.
After I have edited out your RX1 delay to 1 (second) and resetted the MAC state I finally got responses to the RxTimingSetupReq and RxParamSetupReq, so the end device really is capable of answering these, provided that it hears them out at the right time.
I think that the current settings that are set on your end device should be good. In general I recommend trying to get the boot MAC state of the end device and compare it with the MAC settings - if the parameters don’t match, you get issues like these where the downlinks are sent too late because the end device expects them to arrive 1 second after the uplink, while the Network Server schedules them 5 seconds afterwards.
OK, and what are the “current” settings? After your post I noticed you have made some more changes to them.
So I need to double check that I am setting the correct RX1 delay (code seems to suggest it though) to 5 sec.
RX2 should be DR3 for sure as we want to use SF9 for RX2.
RX2 freq. should be 869.525 MHz (I noticed it is wrong in the ESPEasy template as is (was?) in many others due to an error in the sample config back when the vendor templates were introduced)
Anything else?
I’m not sure the mac state is actually saved on the RN2483 module, so I’m not sure if the module will return in the current state if I power cycle it.
So better to make sure the correct values are set to the module at boot by my software.
N.B. I already made a PR for updating the RX2 frequency for the ESPEasy vendor template.
I will tomorrow look at my code to see why the RX1 delay apparently is not being set at 5 seconds.
I’m also receiving a downlink message on the device when I send an “UNCONFIRMED_UP” message. Some notes:
These are most likely requests from the server for your device (what is it, what firmware) to adjust it’s settings.
We recommend OTAA as that is more able to set settings.
Further reading available here:
Commands from the server in section 5 …
They seem to be LINK_ADR_REQ downlinks from the gateway. Apparently for > v1.0.4 the device needs to answer the request even if ADR has been disabled on the device. Odd though esp when trying to minimize downlinks.
Link ADR Req has other uses.
Totally impossible to comment as you’ve not said what the device is beyond to say that there aren’t that many devices around with 1.0.4 and virtually none >1.0.4
To recap:
ADR features recently introduced to TTS March 2022
Whereby the one work-around suggestion of “setting the DR before each uplink” seems a bit ambiguous or is it assumed to require TXParamSetupReq, RXParamSetupReq and various DR offsets etc.
To recap:
How so ambiguous? You use a function call to the MAC to set the DR you want before each uplink.
Since TTN currently ignores ADR=0 and ADRACKAns 0, and continues to spawn a bunch of downlinks on every message send – it would be worthwhile to confirm the various data rate mac commands patches required by network prior to every uplink message. This seems to apply across all devices & lorawan v.
For now I’ll assume it’s a refresh to the data rate transmit and receive parameters: TXParamSetupReq & RXParamSetupReq.