Correct. There is no application payload; this is only a network MAC command.
Hexadecimal 0x8A in
FCtrl equals binary 0b10001010, hence indeed indicates it’s ADR (I wonder if that’s needed), and that
FOptsLen = 10, so
FOpts holds 10 bytes for MAC commands:
Those 10 bytes
indeed start with 0x03 are actually two MAC commands, both starting with 0x03, both denoting a LinkADRReq, in which the server is requesting the device to adjust its settings:
See the LoRaWAN 1.0.1 specifications on how to decode the 10 bytes.
For AU915-928†, the first 5 bytes, 0x0360020071:
- 0x03 = LinkADRReq
- 0x60 = DataRate_TXPower: data rate 6
(reserved for future use?); TX power 0 = 30 dBm
- 0x0200 (LSB) = 0b00000000 00000010 (MSB) = ChMask: index 2
- 0x71 = 0b01110001, so ChMaskCntl = 0b111: all 125 kHz OFF, and ChMask applies to channels 64 to 71, so index 2 only enables channel 65, being 917.5 - 500 kHz BW at DR4
…and the second part, 0x035500FF01:
- 0x03 = LinkADRReq
- 0x55 = DataRate_TXPower: data rate 5
(reserved for future use?); TX power 5 = 20 dBm
- 0x00FF (LSB) = 0b11111111 00000000 (MSB) = ChMask: index 8 to 15
- 0x01 = 0b00000001, so ChMaskCntl = 0b000: ChMask applies to channels 0 to 15, so index 8 to 15 enables channels 8 to 15, being 916.8 - 918.2 MHz, 125 kHz BW at DR0 to DR3
This indeed matches the 9 channels that TTN uses for AU915-928. (
I’m not 100% sure I got the decoding right; I don’t understand the data rates. I should have used 1.0.2 for the decoding; see subsequent posts.)
The ADR request is needed for AU915 (and US915) because LoRaWAN 1.0.1 does not support these settings to be provided in the Join Accept response. (It does support that for EU868.) For LoRaWAN 1.0.3 and 1.1 this is supported, like the ADR documentation I quoted above already mentioned. I don’t think TTN supports 1.0.3, but it will support LoRaWAN 1.1 as of V3.
So, all as expected, and hopefully your version of LMIC will handle the ADR request. If it does, then the next uplink should include the LinkADRAns MAC command, to tell the server it handled it. So, the second uplink should show some values for
FOpts as well.
† For an EU868 example, see ADR problems - node of the same type have different ADR behaviour.