I am confused about the Fcnt value I get upon decoding LoRaWAN packets. I was wondering if someone could enlighten me in understanding them. The Fcnt value in the FHDR is D82E (Big Endian) however I’m not too sure how this value is so large. Upon putting new firmware on a mbed board I presumed it would reset. The counter in TTN resets each time I flash the device with a new program a number like 55342 seems far too large to be my frame count.
_
That’s not a TTN DevAddr. Where did you get this packet? Are you sure it’s a full LoRaWAN packet as received by a gateway?
The decoder you’re using will boldly assume it’s a valid LoRaWAN 1.0.x packet when it does not know the secret keys to validate the MIC. Also, the decoder shows that the packet includes MAC commands in FOpts, 04A9BD1FCEA21BC18CAFCB6A, which I don’t think is valid. 04 would indicate a DutyCycleAns which is an acknowledgement without any payload. The next byte, A9 is not a valid MAC command.
Probably more precisely: whenever the device performs a new OTAA Join.
I got this packet from a LoRa node that I set to receive rx on the same frequency as a LoRaWAN node On 868.3 with the same sf and coding rate and IQ. My lorawan node (not the receiver) is on ttn so it is concerning that this is the case of the devaddr I will have to look into it.
When it does capture my node the address is follows
4060151268010f914c747216e62f86ca026bd885f81654c3f14e4db48087d92e4cb23
The DevAddr of that last packet would be 60151268 (4 bytes, LSB), hence 68121560 (MSB), which does not start with 0x26 or 0x27 which TTN addresses should.
Any chance that in the log you’re not printing leading zeroes for values of 0x0F and lower? Like, any chance the packet actually starts with one of:
That would decode to DevAddr 0x26510160 or 0x26011560, and FCnt 0x0001. In your device’s memory this is probably not an issue, assuming you’re just keeping an array of bytes there, and are not using some hexadecimal string representation when you want to replay it.
In the code buffer size is defined to 48 which I assumed may be asking for buffer overflow, this may be an issue. Maybe as the original ping-pong program was made by Semtech to capture regular LoRa packets between two devices slave and master not mac lorawan packets going to net serv ? . I don’t get how it would not note leading zeros is it the way the array works?
You are correct I am looping through buffer as an array and printing result. When printing the packet to debug in my program I’m am using a %x hex identifier.
In the buffer it’s really just bits, zeroes and ones, which do not have any notion of leading zeroes. The memory contents (or LoRa radio transmission) of binary 0b00001101 can be printed to be read by humans in many ways:
decimal: 13
hexadecimal: 0xD, 0x0D, Dhex, 0Dhex, D16, 0D16, or some lowercase version of that
So, when printing a single byte, both hexadecimal 0xD and 0x0D refer to the very same bit value in memory. But remember that 1 byte of 8 bits needs at most two characters to be printed as hexadecimal, like 0x00, 0x01, …, 0x0F, 0x10, …, 0xFD, 0xFE through 0xFF. So when not printing delimiters between the bytes, you need leading zeroes to enforce each byte to print as exactly two characters, to tell where each byte starts and ends.
By the way: beware not to use that value of 48 as the length of the message, but to use the actual received length that the LoRa module gives you, as otherwise you will not know how many bytes were in a packet. Within a LoRaWAN message there is no indication of its total length. Instead, the LoRa module tells the software how many bytes were received and the LoRaWAN standard specifies that a full LoRaWAN uplink message starts with a specific header, and ends with a 4 byte MIC. So a decoder implicitly knows where the application payload starts and ends.
For fprintf you could try “%02x” to enforce 2 characters for each byte, showing a leading zero whenever needed. Or print a space between each byte.
Nice. I guess you know, but just in case: without decoding the full LoRaWAN packet, you could easily check the first byte to only consider uplinks, and then compare bytes 1 through 4 with some known DevAddr.
That looks like a good idea to filter target packets thanks, some further ideas I have for my project are switching the single channel frequency every 15 seconds to scan other channels.
At the moment though I am having an issue repeating a received frame using SX1272Lib in mbed, In the API Radio.Send (Sends the buffer of size. Prepares the packet to be sent and sets the radio in transmission.) . Each time I try to send it I receive a TxTimeout.
The output I am expecting is OnTxDone but am not sure why it times out each time. If sent just after a Uplink on the same frequency I assumed it would transmit.
