How does SODAQ LoRaBee.sendReqAck() encoded the payload?


I am facing a small issue while sending my data through Sodaq one. I am sending a
hexadecimal string which is defined either as a String or char string ( I only send one of those but with the same outcome so far)

String packet = "025555AD4148E1BE4100A06E421954C5BB";
//char data[] = "025555AD4148E1BE4100A06E421954C5BB";

Nevertheless, when I receive it at the back end, the string looks like this in base64.

that is actually different from a base64 string received from a TTUNO, which looks like AquqakFSuMRBAMSAQgAABwk=

If I decoded SODAQ and TTUNO in nodejs with

var b = new Buffer(msg.payload,'base64')

I get the following bunch of characters that are not my hexadecimal string

30326162616136613431353262386334343130306334383034323030303030373039 <= SODAQ
02ABAA6A4152B8C44100C4804200000709 <= TTUNO

So what I think is happening here is that the original hexadecimal string is
being split into chars and sent through Lora. Thus what I get is the
ascii representation of the hexadecimal, am I right?

The next question would be, how can I get my original hexadecimal string?

Thanks in advance



As my educated guess was suggesting, the issue seems to lie on the way the payload is process before being sent and not in the base64 encode/decode

    payload = 'MDJhYmFhNmE0MTUyYjhjNDQxMDBjNDgwNDIwMDAwMDcwOQ==';
    b = new Buffer(payload,'base64')
    console.log("Buffer b raw ");
    console.log("Buffer b stringfied ");


    Buffer b raw 
    <Buffer 30 32 61 62 61 61 36 61 34 31 35 32 62 38 63 34 34 31 30 30 63 34 38 30 34 32 30 30 30 30 30 37 30 39>
    Buffer b stringfied 

Looking into macTransmit function in the code that is being used to transmit in the device, it can be seen that they are converting the packet into HEX chars

    for (int i = 0; i < size; ++i) {
1 Like