Sorry if this is already answered. I may have even seen an (attempt at an) answer but I remain confused. Can a friend please help me here?
In the TTN console downlink message page for a device, one can schedule/send downlinks with a hex string such as: FF 00 55 …(exhibit A).
I have done such a download and receive (from the RN2483) the ASCII (!) string): “FF0055” … (exhibit B)
We know that exhibit A (FF 00 55) is/can be represented with three bytes.
In contrast, of course, exhibit B (string “FF0055” requires double the bytes (6 bytes) to represent as such a string.
Since I receive this as a 6-byte downlink “string” from my RN2483 node I fear that the 6 bytes for the string are going over the air rather than the shorter 3-byte sequence. (I have the same question in the other [uplink] direction as well … how do I stay within on-air constraints and count the on-air bytes when I send a string-encoded hex sequence with the RN2483?)
IF 6 bytes is the answer, I am amazed/dismayed that we would be halfing our effective bandwidth on such a resource-constrained system.
Thank you, in advance, for setting me straight on this.