hex measurement data via UART is misplaced by LoRa-E5 module.

[thonghatmit]

Source code formatted - please see How to insert source code for future reference

---

For example, I want to send NTS(net status): Dspic33 will send Hex string 4E 54 53 12 00 03 10 00 00 06 10 00 00 01 10 00 00 96 90 00 0D 0A (this is correct Hex data string should be received in stable). But I will get a Hex string in the wrong position on RxBuffer of lora-e5 chip like this: 02 10 00 00 96 90 00 0D 0A 4E 54 53 12 00 03 10 00 00 05 10 00 00, or sometimes it will be like this 00 96 90 00 0D 0A 4E 54 53 12 00 03 10 00 00 05 10 00 00 02 10 00 The Hex strings received by lora will not be consistent in order even if I use DMA or send via regular UART
In main.c of lora-e5 chip i write in while loop and interrupt uart callback like this:

while (1)
{
  HAL_UART_Receive_DMA(&huart1, RxBuffer1, sizeof(RxBuffer1));
  MX_LoRaWAN_Process();
}

void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) {
  //stop DMA
  HAL_UART_DMAStop(&huart1);

  //process data and send the copy to TTN
  for (int i = 0; i < sizeof(RxBuffer1); i++) {
    copy_RxBuffer1[i]=RxBuffer1[i];
    RxBuffer1[i]=0;
  }

  //start DMA again
  //MX_USART1_UART_Init();
  HAL_UART_Receive_DMA(&huart1, RxBuffer1, sizeof(RxBuffer1));
}

I have tried write in interrupt function HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) in main.c to reset DMA with HAL_UART_DMAStop(&huart1); or with MX_USART1_UART_Init(); but everytime UART data on lore-e5 chip is misplace in wrong order

I have tried to send Hex measurement data from dspic33 for my Arduino board and it receive perfectly in order, so i think the problem is in configuration of LoRa-E5 chip

Do you guys know how to fix ?

[Andrew Neil]

---

@thonghatmit wrote:

For example, I want to send NTS(net status): Dspic33 will send Hex string 4E 54 53 12 00 03 10 00 00 06 10 00 00 01 10 00 00 96 90 00 0D 0A

---

So your receiving-end code needs to recognise where that string begins, and where it ends.

Presumably, the 4E 54 53 sequence (ASCII "NTS"?) is intended to mark the start, and 0D 0A (ASCII CRLF) to mark the end.

I don't see anywhere in your code which handles that?

---

@thonghatmit wrote:

But I will get a Hex string in the wrong position on RxBuffer

---

If you don't take care to start reception at the correct place then that is exactly what will happen!

---

@thonghatmit wrote:

I have tried to send Hex measurement data from dspic33 for my Arduino board and it receive perfectly in order

---

So maybe show that code.

---

@thonghatmit wrote:

i think the problem is in configuration of LoRa-E5 chip

---

No, it's your software - it doesn't synchronise to the data stream.

BTW: Your start & end markers seem to be ASCII text, but the data between them is binary - so how do you ensure that the markers can't "accidentally" appear in the binary data?

PS:

Note that the LoRa-E5 is not a chip - it's a 3rd-party module, based on the STM32WE5 chip:

[Tesla DeLorean]

The bulk reception will start at whatever arbitrary time you initiate it. You're going to need to be more judicial about when you start and recognize gaps in transmission or resynchronize based to data patterns.

You might want to receive a byte at a time, time stamp reception, and process content to maintain synchronization or recover it when lost.