Exactly that, I think. Peeking into the code (and the Trace part when clicking an uplink) one will see that when receiving an uplink, TTN is already preparing the empty downlinks before delegating the uplink to the broker. The network server may set some confirmation part, and maybe some MAC commands, like for ADR, if applicable. I think that the broker (or whatever is handling the uplink) can then set an application payload and port to those downlinks, if needed. If the downlinks are not used, they’ll be discarded.
I assume that TTN fails to determine the downlink channels when receiving SF11 or SF12 for US915, so will fail to prepare the possible downlinks, and hence will indeed drop the uplink. (Maybe not explicitly, but just running into an error; that’s why I wonder if the Trace parts of the uplinks show anything funny.)
@CxC_IoT, as for why TTN Console shows AU915 above while gateway-data/gateway/eui-a84041ffff1edfcc shows US915, I don’t know. Maybe it was configured wrongly at some point, and changes failed to propagate to all components? Maybe the ttn-router-us-west expects US915? (I hope not, but we’ve seen weird defaults for downlink channels too.)
More fun, ttnctl gateways info shows AU915:
ttnctl gateways info eui-a84041ffff1edfcc
INFO Found gateway
Gateway ID: eui-a84041ffff1edfcc
Frequency Plan: AU_915_928
Router: ttn-router-us-west
Auto Update: off
Owner: greensuperfood
Owner Public: yes
Location Public: yes
Status Public: yes
Placement: indoor
Description: Gateway en caseta riego
…and ttnctl gateways status fails:
ttnctl gateways status eui-a84041ffff1edfcc
INFO Discovering Router...
INFO Connecting with Router...
INFO Connected to Router
FATAL Could not get status of gateway.
GatewayID=eui-a84041ffff1edfcc
error=Gateway eui-a84041ffff1edfcc not found
Please show that Trace part?
If you’re referring to my “the problem is in the gateway’s configuration” then please note I don’t know if that would be in the gateway hardware, or in the TTN settings. But something is off.