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.

[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()

[Andrew Neil]

---

@thonghatmit wrote:

this is my code for Arduino receive HEX string from dspic33

---

Again, please see How to insert source code for how to properly post source code - it should look like this:

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
    }
  }
}

As @Tesla DeLorean said, that include some synchronisation to the input stream - by looking for the newline.

So that's why your Arduino code "worked".

Your STM32 code didn't do it - that's why it didn't work.

But I think your Arduino code is still going to be unreliable: it will see any & every occurrence of the value 0A as a newline  - can you guarantee that 0A will never occur in the (binary?) payload data?

It would be safer to look for the 4E 54 53 sequence (ASCII "NTS"?) to mark the start of the packet, and the 0D 0A (ASCII CRLF) pair to mark the end...

[Andrew Neil]

---

@Andrew Neil wrote:

---

It would be safer to look for the 4E 54 53 sequence (ASCII "NTS"?) to mark the start of the packet, and the 0D 0A (ASCII CRLF) pair to mark the end...

---

perhaps as a simple State Machine; eg,

Here's a quick Arduino tutorial on State Machines:

https://forum.arduino.cc/t/state-machines-a-short-tutorial/580593/2

PS:

Just spotted that I've missed handling "anything other than 0A" in the ENDING state.

As for 0A received in the RECEIVING state, that would indicate a mal-formed message - so should be handled as an error.

PPS:

Of course, using a state machine doesn't fix the (potential?) issue of a 0A or 0D value in the payload being misinterpreted as a terminator - it seems that is a fundamental flaw in the protocol?

(maybe the message is fixed-length, so it would be sufficient just to verify that the final 2 bytes are 0D 0A?)