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:

 

[thonghatmit]

this is my code for Arduino receive HEX string from dspic33

void setup() {

  // Start Serial to connect to console and receive data from dsPIC33

  Serial.begin(115200);

}

void loop() {

  // Check if there is data from dsPIC33 on Serial

  static bool newLine = false; // Flag to mark when line breaks are needed

  while (Serial.available() > 0) {

    // Read a byte from Serial

    byte receivedByte = Serial.read();

     if (newLine) {

      Serial.println(); // Add new line before printing next data

      newLine = false;

    }

    // Display bytes in hex to console

    if (receivedByte < 0x10) {

      // Add a 0 in front if the value is less than 0x10 to get a 2 digit form

      Serial.print("0");

    }

    Serial.print(receivedByte, HEX);

    Serial.print(" "); // Add spaces between bytes

    if (receivedByte == 0x0A) {

      newLine = true; // Set flag to add new line

    }

  }

 

}

[Tesla DeLorean]

Ok, so that's managing a byte at a time and watching for a terminating character.

Perhaps do something similar on the STM32

Continually submitting a HAL_UART_Receive_DMA() in a while loop, with no attention to if a similar operation is already in progress, nor doing any frame synchronization, is clearly not going to work well.

Perhaps build an equivalent to the Ardunio code, where you build a holding buffer via UART IRQs, review it's depth via a proxy for .available(), and put bytes via a proxy for .read()

[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.