Packet size sent and packet size received differ in size

[beegee-tokyo]

Not sure if it is a bug or a limitation.

I send a structure with the size of 34 bytes

struct dataPckg
{
    char rcvAddr[8];
    char sendAddr[8];
    char type;
    char data[16];
    char term = 0;
} dataPckgStruct;

from a nRF52 with a SX1262 attached with

int state = lora.startTransmit((const char *)&outPckg, 34);

or from an ESP32 with a SX1262 attached with

lora.transmit((const char *)&outPckg, 34);

Log output of the data sent looks like this:

Sending Package:
Rcv:    FF FF FF FF FF FF FF FF
Sender: F7 BC C6 FA A5 6C CB 4E
Type:   0
Data:
12 00 00 00
00 00 00 00
00 00 00 00
00 00 00 ED

Inside the library when the data is written to the SX1262 buffer I put an additional debug output with the buffer content:

FF FF FF FF
FF FF FF FF
F7 BC C6 FA
A5 6C CB 4E
00
12 00 00 00
00 00 00 00
00 00 00 00
00 00 00 ED

So at that point the data is still complete.

CAD is done before sending and the channel is available. For receiving I use interrupt driven method and then

int state = lora.readData((uint8_t *)&inPckg, 34);

to get the data.

For the receiving side I added some debug output into SX126x.cpp into readData()

  size_t length = rxBufStatus[0];
Serial.printf("Receiving %d bytes, wanted %d\n", length, len);
  // read packet data
  if(len == 0) {
    // argument 'len' equal to zero indicates String call, which means dynamically allocated data array
    // dispose of the original and create a new one
    delete[] data;
    data = new uint8_t[length + 1];
  }
  state = readBuffer(data, length);
for(int idx=0; idx<length; idx++)
{
Serial.printf("%02X ", data[idx]);
}
Serial.println("\n===================");

On the ESP32 I receive

Receiving 16 bytes, wanted 34
FF FF FF FF FF FF FF FF F7 BC C6 FA A5 6C CB 4E 
===================

On the nRF52 I receive

Receiving 17 bytes, wanted 34
F7 BC C6 FA A5 6C CB 4E FF FF FF FF FF FF FF FF 01 
===================

And it is always 16 bytes on the ESP32 and 17 bytes on the nRF52.

Kind of lost here. What could be the cause. I know from the datasheet that the Data buffer of the SX1262 is 256 byte large. But I do not know how it is setup by the library. Maybe the RX buffer is set too small???

[jgromes]

I think what's happening is that your data is sent as C-string, so it only sends bytes until the first null character - the RX/TX buffer is always set to maximum size. The receiver only receives 16 bytes - this information comes from the LoRa packet header, it means that the transmitter only sent 16 bytes.

Since you're callling startTransmit(const char*, uint8_t), it uses the overload for string-based transmission with address parameter. You should use the overload startTransmit(uint8_t* data, uint8_t len, uint8_t addr = 0).

Also, I can't guarantee nRF52 will work.

[beegee-tokyo]

Aaaaahhhh, my mistake. I forgot about the String overloads.

Changing from int state = lora.startTransmit((const char*)&outPckg, 34); to int state = lora.startTransmit((uint8_t*)&outPckg, 34); solves the problem.

nRF52 works perfect with your library! Right now I am testing with a custom nRF52832 board and the eByte E22-900M module as a sensor node, but for the final design we will most likely switch to the Insight SIP DS4520 module. Should get the dev kit for the DS4520 today. The ESP32 will be the gateway to the world of IoT.

[jgromes]

nRF52 works perfect

I'm glad it does, but I can't guarantee it will. From what you received on ESP32 vs on nRF52, it looks like there could be some endian-related issues.

[beegee-tokyo]

The data packet is filled with uint8_t values (even the sender/receiver address). So far I did not see a problem.

I am using the nRF52 as well to exchange data packets over BLE with Android devices and didn't get a problem there either.