Home/Support/Support Forum/Uart communication via USB
Welcome to Digi Forum, where you can ask questions and receive answers from other members of the community.

Uart communication via USB

+1 vote
Hello,

I am using the Xbee SMT groove development Board and building a C++ app on a linux embedded dev board.

The Xbee board is plugged on a USB port (detected as ttyUSB0 without any problem) and I am accessing the port without any problem through my C++ app.

But when I read on the serial port, the data appear in this form

~\x00-\xEF\xBF\xBD\x00\x13\xEF\xBF\xBD\x00""A\xEF\xBF\xBD\xEF\xBF\xBD&\xEF\xBF\xBD\xEF\xBF\xBD\xEF\xBF\xBD#X'VOH07300017';7643;542;A;B;C;D\r\x10

what bother me is that I should only read: #X'VOH07300017';7643;542;A;B;C;D\r
since this is what I send from my distant node

Is there something to do with encoding/decoding? (I am using QtQuick so I can use std::string as well as QString or QByteArray) So how could I read my datas so I have only what I want?
asked Feb 26 in USB Serial by Romain.Donze New to the Community (1 point)
I also need a solution for this.
Hello,

So firstly you have to know that it is normal to have more bytes than just what you want to send. It is due to the frame format (more infos here https://www.digi.com/resources/documentation/DigiDocs/90002002/Default.htm#Reference/r_frame_0x90.htm%3FTocPath%3DFrame%2520descriptions%7C_____10)

Then for the right way to read it is to not read your bytes as char but as unsigned int, because each byte could go from 0 to 255

I hope it is understandable

Please log in or register to answer this question.

1 Answer

0 votes
Romain,

This looks like it is more of a baud rate miss match. The XBee products by default are configured at 9600 baud, 8 data bits, 1 stop bit.

Digi Support
answered Feb 26 by mvut Veteran of the Digi Community (12,834 points)
I don't think it is a baud rate miss match since I can make it work with a python app on ubuntu.

I think that the hex byte I have are just the byte from the frame format (start frame, frame length, frame type) problem is that it does not correspond with the bytes I can read with XCTU (FYI the distant node is in python mode and transmit a frame every 500ms and my "master" node is in API mode)

Here is again a complete frame as I read it. as you can see, it starts with '~' wich is equal to \x7E for the start byte. But next I can't recognize any byte like the adresse or the frame type byte

~\x00,\xEF\xBF\xBD\x00\x13\xEF\xBF\xBD\x00""A\xEF\xB
F\xBD\x18\xEF\xBF\xBD\xEF\xBF\xBD\xEF\xBF\xBD\xEF\xB
F\xBD#X'VOH07300012';473;561;A;B;C;D\r\x1D

In XCTU, the frame start with \x7E but for instance, the fourth byte (which represent the frame type) is equal to \x90 which as you can see does not correspont to the byte I am reading with my app

Here is the frame as I read it in XCTU:
7E 00 2C 90 00 13 A2 00 41 98 18 F8 FF FE C1 #X'VOH07300012';762;557;A;B;C;D\r 17
Well the XBee uses the Intel Hex format for the API. Is your application looking at Intel Hex characters?
Well but why is my payload and the first chat (~ or \x7E) would be correct if I am not looking for the right characteres?
Romain,

it is showing up as a ~ because your display does not support Intel Hex characters.  It is showing ASCII only.
Thank you all for your replies. I managed to make it work by reading my serial port as a Byte array and note as a string. I can now write my library to deserialize xbee frames
Good for you.
...