How to send payload in Hex-format?

Hello everyone,

is it possible to send the payload to the application not encrypted.
For example, that the payload comes as Hex value?

What configurations has to be made within the application and node?

Thanks in advance

The payload is binary data. Hexadecimal is just a way to show bytes in a human-readable way, just like, for example, Base64. But when being sent as radio waves, it is neither hexadecimal nor Base64.

See Working with bytes.

Also, the payload is always encrypted, but your node’s library should take care of that automatically, and when TTN knows your keys (that is: when you use TTN Console, not some private Handler) then you’ll get the decrypted value.

See also My node data is undecodable, What to do with the raw payload via MQTT? and Advantage of Base64 encoding in MQTT?

1 Like

Hello arjanvanb,

thanks for the response. That helped me a lot to explain my problem more precise.
You mentioned the topic “My node data is undecodable”.
In this topic the user asked about data_raw.
Your answer was, that “data_raw” is always Base64 encoded.

What do I have to do that “data_raw” doesn’t get Base64 encoded?

Do you know the answer or can point me to someone who could know the answer?

Thanks in advance

You cannot change that. But why would you? Just decode it, and you’ll get the binary data, exactly as the node has sent it.

Like, for example, the 32 bits binary data 00001001 10100110 00001100 110100102:

  • cannot be printed on the screen as plain text, as in the ASCII standard binary 000010012 is the tab character, 000011002 is a form feed, and 101001102 and 110100102 are too large and not defined (but in ISO/IEC 8859-1 could be ¦ and Ò, or in ISO/IEC 8859-2 would be Ś and Ň, and in ISO/IEC 8859-5 be І and в; even for “plain” text, one would need to agree on the exact encoding that is used)

  • could be two unsigned 16 bits integer numbers 2470 and 3283, when assuming MSB (or 247010, or 2470dec to make it very explicit it’s decimal)

  • could be four unsigned 8 bits integer numbers 9, 166, 12 and 210

  • could be four signed 8 bits integer numbers, 9, -90, 12 and -46

  • could be a single 32 bits integer number 161877202 for MSB, or either 3524044297 or -770922999 for LSB

  • could be a 32 bits floating point value 3.997510e-33, or 0.0000000000000000000000000000000039975

  • could be any combination of the above, like one 16 bits signed integer, a 8 bits unsigned integer, and a signed 8 bits integer, and in any order

  • could be written as hexadecimal 09A60CD216, 09a60cd216, 09a60cd2hex, or 0x09A60CD2 and so on (much shorter and easier to read than ones and zeroes, isn’t it?)

  • could also be written in Base64 as CaYM0g==, and that is what TTN uses

  • …and could be written in many other ways in many more encodings

But no matter how you print it on the screen, when being transmitted and in your computer’s memory it’s still the binary ones and zeroes 00001001 10100110 00001100 110100102.

Decoding the Base64 value will give you the binary data again, which you can then decode into, for example, the two integer numbers 2470 and 3283 (which could be temperature and humidity).

Like to see the hexadecimal representation of the Base64 encoded binary data, on a Mac one could type:

echo -n CaYM0g== | base64 --decode | xxd
0000000: 09a6 0cd2                                ....


echo -n CaYM0g== | base64 --decode | hexdump -C
00000000  09 a6 0c d2                                       |....|

…or to see it in bits:

echo -n CaYM0g== | base64 --decode | xxd -b
0000000: 00001001 10100110 00001100 11010010                    ....

The 4 dots .... indicate that the Mac cannot print the given bytes as plain text. That would be different if your node would send plain text (which it should never do):

echo -n MjQ3MDszMjgz | base64 --decode | xxd
0000000: 3234 3730 3b33 3238 33                   2470;3283


echo -n MjQ3MDszMjgz | base64 --decode | hexdump -C
00000000  32 34 37 30 3b 33 32 38  33                       |2470;3283|

How the Base64 decoding is done in your application depends on the programming language you’re using; Google Search is your friend for that.


Hello @arjanvanb

thank you very much for this explaination. But I have another question regarding the encryption/decryption.

Is the a way to stop the decryption between the node and TTN Backend?
For example: I want that the information from the node gets saved encrypted in the TTN Backend. The decryption should be made somewhere else.

Do you know if there is a way to do that?

Thank you in advance

That would need additional payload encryption in the node, or Setting up a Private Handler connected to the Public Community Network.

Where the node’s LoRaWAN library would encrypt it again before transmission, and TTN would still decrypt the LoRaWAN payload, but that encrypted LoRaWAN payload itself would already have been encrypted on the application level in the node as well.

1 Like

Hello @arjanvanb,

thank you very much for your help.
This helped me a lot.

Thank you many times!!!

My payload is raw and my API received only Base64, how do I encode my raw payload to have it in Base64? Via the payload format…