I am developing an application using I-CUBE-LRWAN1 and a set of my own sensors to read humidity and ambient temperature, together with a ground humidity sensor.
What I would like is to send these two values via LoRa to an application I have developed. I receive the values fine, but they are not correct.
I can get the data from the soil moisture sensor without problems, but the ambient sensor gives me both data in a variable that I can separate, but the I-CUBE-LRWAN example does not allow me to show them separately. It shows me by Putty a value (Temperature or humidity) and the other gives me “128” without varying.
I thought of grouping both values by multiplying them by 100 and adding them in the following way:
Temperature=25Âş, Humidity=30% ------> Result = (25*100)+30;
This way I have the two values in a 4 digit variable, which I can then decompose, but it turns out that the example application does not send me the values.
I found a detail, and it is that the application when passing the variable of a weight of 256 bits, modifies the value to 1. When passing 256 again, it changes it to 2 and so on.
I have also modified the LORAWAN_APP_DATA_BUFFER_MAX_SIZE looking for something to change, but nothing.
I don’t know what can happen.
This looks like an data encoding problem to me. I think I would try to address the data encoding first, and only after getting that under control, you can start to worry about transferring the data over TTN to your application.
While in principle it is a good idea to combine several values into one consolidated block of data, I think in this case there is not much benefit.
You could (for example) encode temperature in one byte (temperature in celcius directly as a number, assuming you don’t have negative temperature), encode air humidity in one byte (0-100), encode ground humidity (0-100) in another byte. So every item has its own byte. This takes only 3 bytes.
A little more advanced could be to encode it as Cayenne LPP on the node, say air temperature on channel 0, air humidity on channel 1, ground humidity on channel 2. This has the advantage that you can then use the built-in Cayenne payload decoder from TTN, and see the decoded measurement values directly on the TTN application console. Cayenne is a standard format, but a little less efficient (probably still efficient enough) than direct binary encoding.
In addition to trying to send a single 4 digit value, I also tried to create two tasks to be able to send ambient temperature, ambient humidity and soil moisture in 3 different values. That is, send the 3 values separately as you say.
The problem with this methodology is that the STM example code is not able to read the sensor in the third task. It always shows and sends me the value 128 in the third byte. While in TTN 2 of the 3 values arrive well, the last one sends the value 128.
Sorry to have bothered you the past day. I found the solution the next afternoon. The code was wrong and made the wrong call to the sensor reading function. It was a bad implementation on my part.