i had a weird issue with some end devices, it seems that somehow the server is issuing a control over ADR that makes my end devices turn down the output power too much, had the same issue with Winext sensor box and many Elsys sensors, i’m using my own gateway to connect to TTN and it is just a few meters away, join packets are received with extremely good RSSI (-20dBm) but after the first ADR downlink command the end devices turn unresponsive or transmit with very poor signal (.118dBm) at the same distance to the gateway. the weird thing is that this only happens when using AU915 freq. plan. under US915 everything works normal with the same end devices and ADR works fine with good signal levels., if i disable ADR on the node side then the devices transmit with good signal even at AU915 SF7 but i can’t seem to be able to get them to work with ADR enabled.
I suspect the issue is not what you think it is.
You can’t actually turn down the power far enough on a Semtech radio chip to produce -118 as an RSSI reading for a nearby node.
Rather, what is likely happening is that your node is being received weakly on a frequency other than the one it is actually transmitting on, because it is so close that it is overloading the receiver front end and producing distortion products within.
It is possible that the channel map being sent tells it to use channels other than the ones the gateway is configured for, so you don’t actually receive the node properly, but only via such weak off-channel bleedthrough.
at first my theory was the same as yours but i ruled that out because:
-while i am close to the gateway, there is still some distance (about 5 meters)
-my nodes using no ADR and SF12 at the same location work properly
-it is only after a downlink ADR update message that the nodes work wrong. i ran a test on which i did not create a node definition inside my application so the node only was able to send OTAA join requests and every one of them was received with good RSSI.
-that would also not explain why the same setup works fine on US915 and not on AU915.
ADR is inseparable from channel selection, as the two are packed together in the same MAC command. If you have ADR you are getting a channel list as well, wanted - or not.
Actually, it would explain it, because the channel rules are different in the two cases, and so an error in their setup is probably unique to one.
If you really want to know what is going on, figure out what your node is doing before and after the change. Put serial logging of settings in your firmware just before it transmits. Or get a USB logic analyzer on the signals to the radio.
tried to put more distance between a node and the gateway (about 30m distance and a few concrete walls) but it is the same story, -80dBm join request and 10.3 SNR then after the first downlink packet i hear no more activity from the node, i have a sensor transmitting to the same gateway without ADR and i have no issues, sadly i can’t disable ADR for this specific sensor (Elsys ERS) it baffles me because i know there should be more people using those sensors on AU915 and my gateway isn’t a DIY solution either (Winext GW5000) so there should be no problems between them
If you can capture and post the actual ADR downlink packets being sent and provide a list of what frequencies your gateway is configured for, this can probably be explained.
this is the only downlink message i managed to send before the node stopped transmitting correctly as seen from gateway traffic.
60D3280626AA00000360020071036500FF019961EF28
and this is the list of frequencies my gateway and end node are configured to use
first uplink packet after the node joined the network was sent on SF8BW500 on 915.9MHz, i’m not sure about the content though since the payload does not correspond to anything described on the payload structure of that device and it was 94bytes in lenght! the usual data packet for that node is about 20bytes long, maybe it is some kind of status update message from the node, i’m not sure to be honest.
TTN AU915 uses channels 8 - 15. Maybe that is the problem.