Having some problems with the payload

Development Platforms
1

Hello, this may be a very specific question.

I’m currently developing a intregation code with BME280 and a heltec wifi lora 32 v2 board. I’m adapting the code from GitHub - ph2lb/LoRaWAN_TTN_Env_Node: BME280 and Adruino ProMini based enviromental node with LMIC ABP. in order to send the temperature, humidity and pressure to my chirpstack server. I have to change the library used in the original code in order to use the BM280 library from platformio and removed other code that I will not use.

The problem I’m currently having is when the the Lora sends the payload to the server, the data that comes in the uplink is corrupted.

This is how I’m building the data:

int t = (int)(temp); 
        int p = (int)(pressure);
        int h = (int)(humidity);
        unsigned char mydata[5];  
        mydata[0] = h & 0xFF; 
        mydata[1] = t >> 8;
        mydata[2] = t & 0xFF;
        mydata[3] = p >> 8;
        mydata[4] = p & 0xFF; 
        LMIC_setTxData2(1, mydata, sizeof(mydata), 0);

And this is how is comming in the uplink package: * data:"LQAgA+Q=" If you translate from basecode64 it will result in trash-code. Why is happening this?

2

The data looks ok. If you Base64 decode it, you get the 5 bytes – same as in the input:

2d 00 20 03 e4

According to your code, this represents:

  • Pressure: 45
  • Temperature: 32
  • Humidity: 996

I’m not sure how these values should be converted to the real units but it looks as if you are almost there…

1 Like
3

So you translate LQAgA+Q= and get 2d 00 20 03 e4? What program do you use to translate base64 to byte? I’m using the same page I translate a “hello world” in past tests directly from base64, not to byte

imagen
imagen947×855 18.5 KB

According to your code, this represents:

Pressure: 45
Temperature: 32
Humidity: 996

That is the result I need, 45% Humidity, 32 Cº and 996 Pressure, how did you get it?

4

You’re using a Base64 to UTF-8 (“text”) converter, you should decode to a pure byte arry instead.

grafik
grafik1215×678 52.2 KB

1 Like
5

I see, and that Byte translation, how do I translate it to text? Like @manuelbl did?

6

What programming language are you using on the receiver side?

7

None, I’m just using chirpstack in order to recieve the data from the LoRa Device and translating the data manually. I know it may sound weird but this is just for testing the communication between LoRa, Gateway and server.

imagen
imagen1872×900 74.3 KB

8

This is how you pack the data on the sender side:

mydata[0] = h & 0xFF; 
mydata[1] = t >> 8;
mydata[2] = t & 0xFF;
mydata[3] = p >> 8;
mydata[4] = p & 0xFF;

Humidity goes into byte 0 (and is truncated to the range 0 to 255). Temperature goes into bytes 1 and 2 (most significant bits in byte 1, i.e. big endian format). Pressure goes into bytes 3 and 4 (big endian as well).

So to unpack it, calculate:

  • Humidty = bytes[0]
  • Temperature = bytes[1] * 256 + bytes[2]
  • Pressure = bytes[3] * 256 + bytes[4]
9

So… in order to get a text result I need to calculate each byte according to the position in the array.

  • Humidty = 2d
  • Temperature = 00 * 256 + 20
  • Pressure = 03 * 256 + e4

It’s… a bit confusing in order to get a result… I’m sorry but I don’t know how to calculate the result. Where I can learn how to do it?

10

I manage to learn how you did it.

Using Binary decoder: Online binary to text translator - cryptii

You have to text( LQAgA+Q=) - > decode base64 → bytes (2d 00 20 03 e4) → Encode integer decimal format → 45 0 32 3 228

Apply:

  • Humidty = 45
  • Temperature = 0 * 256 + 32 = 32
  • Pressure = 3 * 256 + 228 = 996

Now I understand, thank you very much!

11

Careful, these are numbers denoted in hexadecimal, so you should write a 0x in front of them to signify that it’s not a decimal number. With the hex digit system being (0,1,2,3,4,5,6,7,8,9,a,b,c,d,e,f) corresponding to (0…15). Then see that hex to decimal conversion for 2-digit hex values can be done by writing 16 * left_digit + right_digit, so:

  • 0x2d
  • 0x2 * 16 + 0xd
  • 2 * 16 + 13
  • 32 + 13
  • 45

Since these are just different displayed strings from the same underlying numerical value you won’t have to do that conversion in code. Underlying it’s all just integers.

With chirpstack you can provide your own JavaScript decoding logic to have it displayed nicely in the UI. See e.g. forum posts Receiving (decrypted) device data / FRMPayload - #19 by nanomo - ChirpStack Application Server - ChirpStack Community Forum. There you also already get a byte[] directly and not a Base64 string.

However usually the goal is not to decode the frame payload in Chirpstack anyways, but the integration you have configured in Chirpstack where the data is forwarded to, e.g. a HTTP, InfluxDB, MQTT, Azure, AWS,… (all listed at https://www.chirpstack.io/application-server/integrate/sending-receiving/) server so depending on where the data is pushed to it needs decoding logic in a different language there on the server.

1 Like