Clarity on on-air downlink payload size: once and for all, double or not?!

1

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.

2

I fear, I am amazed, I am dismayed :scream:

3

If you take a minute to read up on the interface between a micro controller and the RN2483 you will notice is ascii based. When sending bytes (uplink) you specify a payload by supplying it in ascii hex string to the module, when receiving (downlink) you get the payload in ascii hex string from the module. On air the data is binary.

4

Thank you, very much, Jac.