Yes, indeed, well, not that obvious as the feedback failed to mention this pertinent detail until I sought clarification. I’ve detailed the problem as I currently understand it in the original post for this topic, as acknowledged by a TTI engineer, a problem I’ve spent time independently verifying and discussing with TTI as to current work-arounds and future amelioration.
When I created a test ABP device with ADR turned off on the console I saw it going to SF12, DR0, as per the database default (of zero) and as reported. I could get the device to stay on the DR I wanted without firmware changes when I updated the settings as detailed above. In some respects the current situation is useful as it effectively allows someone to do ADR to their own algorithm by looking at the signal strength and adjusting the desired DR as they see fit.
But like the original threads that spawned the topic, the resulting feedback is conflicting and confusing. If the OP wants to use ABP in the manner he desires, he’s more than welcome to take it up on Slack with TTI directly.
I’ve tried to document the situation for others so they can take appropriate action but I can neither mandate changes to other peoples firmware nor mandate updates to TTS. And the solution worked for me when I tried it but I do not currently have the capacity to take fragmented reports & piece them together, so the onus is on anyone who needs help to provide a detailed & structured report and even then, I may have my hands full with other things.
Server is responding as mentioned by @descartes. I tried changing the SF to 7, 8 etc. It is working. The server is no more asking SF12 (DR0). (Using CLI as mentioned by @descartes)
This would have been some setup mistake from my side. Along with the mistake my node was not able to receive message from server. So server kept asking status of node along with SF7 DR5 request this time as there was no reply to status query. This is normal procedure when a ABP node joins.
So since the server was not getting the status message back, it kept asking for status messages. (tried for atleast 2000 messages, it doesn’t stop)
So in short:
DR0 request from server was solved using the solution provided by @descartes
I kept receiving status request from server until the node replied with status in mac field.
The details below is not relevant, just an added info.
Somehow the node received one of the status request from gateway (few minutes back).
Request from server:
opts field: 060350FF0001
Meaning:
Server is requesting status of the end device
Data rate: LoRa: SF7 / 125 kHz
Power: Max EIRP
Usable channels with LSB as Channel 0: ff00
The number of transmission for each uplink message 1
The channel mask will be enabled as 0
Reply to server:
opts field: 06FF370307
Meaning:
The device was not able to measure the battery level
The margin (SNR in dB): -9
Power Accepted by the end node
Data rate accepted by node
Channel mask interpreted and all channel states set
This solved everything and I could put up everything together as there was no further request from server.
So there could be one more solution possible in the scenario, if somehow the gateway is not able to make it upto the node and only the node is able to communicate, which is ok for a mapper node, if there was an option to disable status request then it would have been great, to avoid unnecessary TX from gateway. (tried 0 fields in status in console to disable, didn’t work possibly because its a usual join procedure of ABP, minimum one status message back to gateway)