I’m trying to make sense of MAC data in downlinks from The Things Network.
The reason is that I’m interested to see what MAC commands are arriving.
If port is zero and
nMessageis zero, piggybacked MAC data can be detected and inspected by checking the value of
LMIC.dataBeg. If non-zero, there are
LMIC.dataBegbytes of piggybacked data, and the data can be found at
From the LoRaWAN 1.0.3 Specification (chapter 5 MAC commands):
A single data frame can contain any sequence of MAC commands, either piggybacked in the FOpts field or, when sent as separate data frame, in the FRMPayload field with the FPort field being set to 0.
A MAC command consists of a command identifier (CID) of 1 octet followed by a possibly empty command-specific sequence of octets.
The CID is a single byte and most common MAC commands. Valid CID’s have a value in the range 0x02 to 0x0A or 0x0D.
My test results:
LMIC version: v3.3.0
Network: The Things Network V3
My code is an enhanced version of the standard ttn-otaa.ino example.
Output was printed in the default onEvent() event handler on EV_TXCOMPLETE.
Port: 0 MAC data length: 13 MAC data: 60 34 13 0B 26 85 21 00 03 51 FF 00 01
I expected the first byte to be a valid CID so I could recognize the MAC commands, but 0x60 is not a valid CID however.
How should I read/interprete the MAC data stored in LMIC.frame described in the LMIC docs?
According to the LoRaWAN specification there are two ways a data frame can contain ‘any sequence of MAC commands’:
- Piggybacked in the FOpts field.
- When sent as a separate data frame, in the FRMPayload field with the FPort field being set to 0.
Which of these does MCCI LMIC store in LMIC.frame? Can it handle both and does it store whichever is present in LMIC.frame?