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
- ASCII: new line (carriage return)
- Roman: XIII
- and so on.
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.