What does the Overview page for the gateway show?
And for future readers, before you change anything: is there really no clue in the “Trace” part of those uplinks?
Actually I’d argue would be the other way around.
A typical US gateway configuration will quite happily receive messages at SF11 and SF12, I’m not even sure there’s any way to tell the baseband chip not to. In fact I have a system that occasional puts out very short non-LoRaWAN test message at SF12 (even LoRaWAN headers don’t fit, it’s more a partial device address without checksum) and they are picked up just fine.
But these are non-existent data rates in the US915 regional parameters, so quite possibly getting dropped by TTN servers if they are asked to make sense of the packets in the context of a supposedly US915 system.
If your device firmware properly implements the regional paramaters of the region your device is registered with TTN in, then the firmware should not be going to illegal SF’s to begin with. A mismatch or mis-implementation of settings may be at issue.
If SF11 and SF12 are allowed, but you decide strategically not to use them, then either you use an existing capability of the device’s firmware to tell it that there is a maximum SF it is allowed to use, or you modify the device’s firmware to implement such a limit if it did not before.
Note that even if using SF10 you probably want to keep your data packet very compact to keep the airtime short. Make sure you aren’t trying to send too much, or using an inefficient data format or packing scheme.
For point of reference:
in AU915 DR0 is SF12 125 KHz
in US915 DR0 is SF10 125 KHz and the airtime limit of 400 ms means that after adding the LoRaWAN headers only fairly short packets are allowed
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.
Hi! I have the same Gateway and also implement a LoRa network in a field with Dragino sensors, in Chile.
I had the exact same problem. You can deactivate the ADR mode of the sensors to prevent them from acquiring an SF greater than 10 and also adjust the DR for a suitable SF. All by AT commands, you will need a USB-TTL converter + cable to program the sensor.
My network works fine after making those settings. But for a few days I have problems, the data does not reach my application. I suspect the configuration of the Gateway
Did you configure your Gateway with au915.thethings.meshed.com.au?Hi! I have the same Gateway and also implement a LoRa network in a field with Dragino sensors, in Chile.
I had the exact same problem. You can deactivate the ADR mode of the sensors to prevent them from acquiring an SF greater than 10 and also adjust the DR for a suitable SF. All by AT commands, you will need a USB-TTL converter + cable to program the sensor.
My network works fine after making those settings. But for a few days I have problems, the data does not reach my application. I suspect the configuration of the Gateway
Did you configure your Gateway with au915.thethings.meshed.com.au?
Hi Atorres.
Many time without review this forum…
You are rigth! I did the same tasks that you and works.
I deactivated the ADR and set an appropriate one.
i hope this information works for anyone else. Best regards