Lora Feather 32u4 Node packet format problem


(Rustie0125) #1

Im trying to send int values from my node to TTN but does not matter what i try it seems the packets get cut off or does not understand the data type.

the Node test code is below

void do_send(osjob_t* j)
{

  // Init declaration
  int val0 = 0;
  int val1 = 9999;
  int val2 = 9999;
  int val3 = 9999;
 
  byte buffer[10] = { val0, val1, val0, val2, val0, val3};

  // Prepare upstream data transmission at the next possible time.
  LMIC_setTxData2(1, buffer, sizeof(buffer) / sizeof(buffer[0]), 0);

  //Serial output of message
  //Serial.println(F("Sending: "));
  for (byte b = 0; b < (sizeof(buffer) / sizeof(buffer[0])); b++) {
    //Serial.print(buffer[b]);
  }


}//do_send()

and the resulted answer after decoding looks like this

0 28675 0 28672 0 0

I have tried different spreading factors, data types they always come out the same...


(Phang Moh) #2

int is 16-bit wide data type and byte is 8-bit wide data type. You are trying to fit 16-bit of data into 8-bit variable array.


(Rustie0125) #3

Correct, cause byte is 255 max so then i try this code and look at the result.

void do_send(osjob_t* j)
{

// Init declaration
int val0 = 9;
int val1 = 254;
int val2 = 254;
int val3 = 254;

byte buffer[10] = { val0, val1, val0, val2, val0, val3};

// Prepare upstream data transmission at the next possible time.
LMIC_setTxData2(1, buffer, sizeof(buffer) / sizeof(buffer[0]), 0);

//Serial output of message
//Serial.println(F("Sending: "));
for (byte b = 0; b < (sizeof(buffer) / sizeof(buffer[0])); b++) {
//Serial.print(buffer[b]);
}

}//do_send()

Result
9 57982 9 57344 0 0


(Rustie0125) #4

have also tried
this

void do_send(osjob_t* j)
{
int myArray[4];
myArray[0] = 9;
myArray[1] = 999;
myArray[2] = 9;
myArray[3] = 999;
// Prepare upstream data transmission at the next possible time.
LMIC_setTxData2(1,myArray[4],4, 0);

}//do_send()

but i get compile error

cannot convert 'int*' to 'xref2u1_t {aka unsigned char*}' for argument '2' to 'int LMIC_setTxData2(u1_t, xref2u1_t, u1_t, u1_t)'


(Arjan) #5

You're not showing us the result of the Serial.print(buffer[b]) (probably 9 254 9 254 9 254 0 0 0 0), nor how you're decoding. That doesn't give us enough to go by.

Until then, I'd recommend reading Working with Bytes.


(Rustie0125) #6

The serial has never worked in this library, i have removed it since. the whole LMIC library is a mess when it comes to the Serial window. Im not encoding anything i get the packet from ttn and convert from base 64 to decimal. the problem the is LMIC library does not allow you to send larger then 255 numbers as hinted at here {aka unsigned char*}


#7

That is right, the LMIC library sends bytes. Everything needs to be converted to one or more bytes to be able to send it.

To send an integer value you need to convert it to two bytes. Code to send vol0 .. val3 could become:

byte buffer[8] = {   (val0 >> 8) & 0xff, val0 & 0xff, 
                     (val1 >> 8) & 0xff, val1 & 0xff, 
                     (val2 >> 8) & 0xff, val2 & 0xff, 
                     (val3 >> 8) & 0xff, val3 & 0xff
                 };

In the console payload function you can reconstruct the values with:

function Decoder(bytes, port) {
  var decoded = {};
  decoded.val0 = bytes[0] * 256 + bytes[1];
  decoded.val1 = bytes[2] * 256 + bytes[3];
  decoded.val2 = bytes[4] * 256 + bytes[5];
  decoded.val3 = bytes[6] * 256 + bytes[7];
  return decoded;
}

(Arjan) #8

Beware that this does not handle negative values, for which sign extension is needed to give the JavaScript decoder the 4 bytes it expects.


(Rustie0125) #9

Hi Kersing

Thank you for the detailed reply.... I dont think iv ever been this shocked about a limitation of a library like this..... I can not understand a reason why one would do this... you spend all that time and effort to write a library for one type of data....

is there any other libraries someone knows of that i can use ?


(Arjan) #10

As nodes often have limited capabilities (like internal memory) and often have very specific needs (like reading specific sensors), it's good that libraries take care of one specific task. The (nice!) LMiC takes care of all ins and outs of LoRaWAN, that's all. LoRaWAN uses bytes. And bytes are not as hard as LoRaWAN or as getting values from some sensors; did you read Working with Bytes?

That said, there are many libraries for specific tasks, but they won't do LoRaWAN. Like: