Serial(rs485 etc) communication, end of message(transmission) determination

Status
Not open for further replies.
S

seyyah

Advanced Member level 2
Joined
Oct 7, 2001
Messages
646
Helped
8
Reputation
16
Reaction score
8
Trophy points
1,298
Visit site
Activity points
6,234
I want to design a simple yet robust serial communication protocol over rs485. There will be multiple slaves and one master. What I could not decided is how to determine the end of a message. I may do it like the one in modbus e.g. using a time-out technique but I want it to be more flexible. I may think to use a special end of message character(s) but then how will I separate the real message character from the end of message character. Is there any way that is used in common for this purpose or any idea? Thanks.
 

There are two options in MODBUS, RTU & ASCII. Check out ASCII, it is close to your idea
 

What are you transmitting? If you are using ASCII you could use the characters numbered lower than the alphanumerics (aka 'control characters'). In one of my systems I use the STX (Start of TeXt) character with value 0x02 at the start of the data transfer and CR (Carriage Return) with value 0x0D at the end. If you are transferring binary this may not be be a good method as these values would have othe meaning.

Brian.
 
Reactions: seyyah

    S

    seyyah

    Points: 2
    Helpful Answer Positive Rating
If you want modbus RTU like binary data transfer, then you can use parity error to indicate command code like start of message or end of message.

For example let 8 bit code of start of message is 0xAA and let 8 bit code of end of message is 0xBB, then send 0xAA or 0xBB with parity error. At the receiver side check for parity error. If parity error occured, then do not reject the byte, check for 0xAA or 0xBB. If it is 0xAA or 0xBB then take necessary action. If the error byte is neither of them then flag it as a real error.
 
Reactions: seyyah

    S

    seyyah

    Points: 2
    Helpful Answer Positive Rating
So there is no innovative idea we should stick to these 2 methods basically. I'll be sending binary data. May be parity like method be suitable, adding crc will strenghten the robustness, thanks.
 

One trick that works well is to do <SOH> data <EOT> and whenerver <SOH><DLE> or <EOT> appears in the payload, precede it with a <DLE> character to mark the following character as not being a control code.

At the recever, you just maintain a flag that indicates if the last character was DLE, and if it was you dont consider the following character as being a control code.

Regards, Dan.
 
Reactions: seyyah

    S

    seyyah

    Points: 2
    Helpful Answer Positive Rating
One trick that works well is to do <SOH> data <EOT> and whenerver <SOH><DLE> or <EOT> appears in the payload, precede it with a <DLE> character to mark the following character as not being a control code.
Click to expand...

This method (using escape characters like DLE) is used in a number of field bus protocols, e.g. 3964R and S-BUS. The most obvious disadvantage is that it causes a content dependend data blow-up, worst case upto 100% (for all DLE payload).

9-Bit methods (parity or even/odd marking of control characters) can only be implemented when you have direct access to the UART hardware. They don't work through most standard serial OS drivers (Windows, Linux etc.).

An accurate implementation of the MODBUS timeout is also difficult through OS drivers, but a relaxed timeout specification will usually serve the purpose. In so far I think, MODBUS RTU implements the best trade-off for many applications.
 
Reactions: seyyah

    S

    seyyah

    Points: 2
    Helpful Answer Positive Rating
Status
Not open for further replies.

Similar threads

Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…