ADR with Ursalink UC11-T1 does not make them improve from SF12

I have several Ursalink UC11-T1 devices. They all transmit at SF12 and do not drop even over several days connected to TTN. Tested on another NS the spreading factor drops to SF7 but not on TTN.

Any idea why?

Have seen this too, think there is an ADR issue.
What SF did the sensor join on?

What I got was a join on SF7 then end-device ADR knocked the SF to 12.
Which might imply a timing issue where UC11-T1 is missing ADR acknowledgment from LNS.
What region are you EU/US/AS/AZ ?

I don’t have UC11-T1 anymore so never got to the bottom of it

Hi Lawrence
I have more than 10 of these UC11-T1 devices and plan on deploying more because I like the form factor of the case and sensor. They join at SF12 and stay at SF12.

I raised the issue with Ursalink and they seem to think it is TTN but having just asked TTN it seems to be with the device!

Do I burn them all now or cry then burn them?

I will set a new one up this afternoon and carefully record the initial join request SF and see what happens.

My existing 10 nodes are deployed on several different sites, all with Multitech external gateways and all to TTN. Different applications.

I posted this at a different topic to which you posted the same problem. Please don’t do that. The quotes are a bit out of context:

I’m afraid you’ll need to capture a lot of raw uplinks to see if ADR is indeed set for all of them, and how the device is setting its ADRACKReq bit after not having seen any downlinks for more than ADR_ACK_LIMIT uplinks, being 64 in LoRaWAN 1.0.x (which might be a couple of days, depending on how often the devices transmit). Also, you’ll need to check if TTN is not sending any ADR downlinks at all, or when it is sending them: how those differ from that other network…

You might be lucky: when transmitting uplinks on SF12 TTN will force an ADR downlink even when not yet requested, to avoid the waste of air time.

Also, I assume it’s an OTAA device that last joined after October 2019?

What details did you get from the communication you had with them?

This is what I get:

Assuming hex-encoded packet
0167EA00026864

Message Type = Join Request
PHYPayload = 0167EA00026864

( PHYPayload = MHDR[1] | MACPayload[…] | MIC[4] )
MHDR = 01
MACPayload = 67EA
MIC = 00026864 (from packet) INVALID (tried MSB 0000-FFFF)
= E012602F (expected, assuming 32 bits frame counter with MSB 0000)

( MACPayload = AppEUI[8] | DevEUI[8] | DevNonce[2] )
AppEUI = 64680200EA67
DevEUI =
DevNonce =

0167EA00026864 is not a valid packet (it’s decoded as an incomplete OTAA Join Request; it’s likely not a packet from your device at all, and not even LoRaWAN). Is your gateway forwarding packets that have CRC errors?

(Or it’s only the application payload, not a full LoRaWAN packet as taken from the gateway traffic.)

The 0167EA00026864 is the the uplink data of the UC11-T1 (Temperature&Humidity Sensor).
0167 (Temperature): EA00 => 00EA => 234/10 =>23.4℃ ; 0268 (Humidity): 64 => 100/2 => 50%
I tested the communicate between UC11-T1 and TTN those days, the ADR with TTN works, please contact with Ursalink for any doubt during testing with the nodes.

1 Like