Dwm-simple sends \r before every \n. Why is that?

Wireless Connectivity Ultra-Wideband
1

Hi!

I’m using Decawave’s “dwm-simple” example to send formatted (MAVLink v1 protocol with a message size of 101 bytes) position data as unsigned chars to the serial port of the DWM1001 tag module using printf(). The problem is, whenever a new line (\n) command is sent to the port there always is a carriage return ("\r") put in front of \n. Now, sometimes one of the bytes in the message can have the same value as the \n command, which is 0x0A as HEX or 10 as a decimal (E.g. if y-position = 10). In this case, an additional \r byte is sent automatically to the port, which screws up my protocol. How can I get rid of this? Has this been pre-defined in PANS?

As an example, I attached a picture that shows the output of the serial port. It’s just a uint8_t type counter counting from 0 to 254 and then resetting itself. When the counter reaches 10 (which is decimal for \n) it somehow puts a \r (= 13 as decimal, 0x0D in HEX) in front of it.

The DWM1001 has been flashed with PANS 2.0 firmware.

image
image1070×219 11.2 KB

2

Hi @Felix_95
could you send us a pice of your code, with your description it is hard to guess what is wrong. The printf function is not suited for sending binary values - (see printf - C++ Reference ).

However it should not automatically add \r before the \n. Double check that your terminal SW (on PC side) is not adding the \r automatically - some terminal can do it.

Cheers,
JK

3

Hi,
thanks for your reply. I tried several terminals (hterm, CoolTerm, TeraTerm) and a Linux computer to read data from the serial port, but all give me the same result (see picture below).

image
image1070×219 6.56 KB

I added a simple counter, which counts from 0-255 and then resets itself to visualize my problem.
The output shown in the picture can be reproduced by adding the following code to the on_dwm_evt function located in the dwm-simple example provided by Decawave and commenting out every other printf(). In the dwm-simple example, printf() is also used to send data to the serial port (not write()), so I decided to stick with it. Also, using write() instead of printf() gives the same result.

The code has been compiled and flashed to the DWM1001 module using Segger Embedded Studio with the GNU Arm Embedded Toolchain 10 2021.10.

uint8_t sq = 0;
unsigned char count;

void on_dwm_evt(dwm_evt_t *p_evt) {
    
    /* convert byte. (My actual message consists of multiple char arrays) */        
    count = sq & 0xFF;

    /* print counter to serial */        
    printf("%c", count);

    /* Increase sq counter +1 */
    if (sq < 255) {
        sq = sq + 1;
    } else {
        sq = 0;
    }
}
4

Hi Felix,

When using serial devices on Linux to send and receive binary data, they should be put in raw mode to prevent Linux adding these characters to the received and/or sent data.

Likely ocrnl is enabled on the character device you are using. See stty(1): change/print terminal line settings - Linux man page.

To enable raw mode, use e.g:

stty -F /dev/ttyUSB0 raw

Some terminal emulators also have options to do this but most respect the system global settings set by STTY.

5

Hi all,

I have encountered the same issue, and can confirm that the added character is on the send side from the DWM1001. Can we please have this issue looked into? I have tried a number of different file operations on the stdout file descriptor to try open in binary mode, but none have worked.

6

Hi @rdrage
may it is an issue in PANS (it will need to be investigated), but there is not update planed for PANS not will be never fixed if the issue is in PANS.

Cheers
JK