serial communications – protocol_considerations
If you design a new serial protocol, here are some ideas and suggestions you may want to consider:
- Say your receiver is busy for a few microseconds and drops a character or two. You might be able to check for a FIFO buffer overrun hardware flag.
- When you turn on a device, how does it know when to start talking ? Who talks first ?
- The bit-synchronization problem:
When a receiver is first turned on, how does it know where one transmitted bit ends and the next starts ? Also, what is the bit rate ? Pretty simple for clean RS-485 (and most other hard-wired communications hardware) where you can just watch the edges; more difficult when there is noise (as in nearly all wireless hardware).
Often dedicated hardware synchronizes things to the nearest byte; then higher-level protocols in software deal with frame synchronization.
- The frame-synchronization problem:
Say the device that is *supposed* to talk first starts talking, but the other device doesnt get turned on until the middle of a “sentence”. How does the receiver know to throw away the (incomprehensible) rest of the “sentence”, and re-synchronize at the start of a new sentence ? (Same thing applies to buffer overrun).
Typically one re-synchronizes by transmitting a unique byte sequence (a “header” or “start-of-message”) that will not (or “probably will not”) be embedded in the middle of a sentence.
Including the newline and/or carriage return ( suggested by Dmitri Katchalov Date: 27 Jan 2000 ) in this byte sequence helps make it more human-readable.
- Robert Morris http://www.pdos.lcs.mit.edu/~rtm/ claims that “the Grid routing protocol lets collections of radio-equipped nodes automatically configure their own cooperative network, without relying on any pre-installed infrastructure. He also suspects “a power-saving scheme for an ad-hoc net, that allows radio receivers to spend most of their time turned off. … [perhaps] elect one node per region to buffer messages, so that other nodes can wake up from time to time and poll. Batch traffic, use geo routing to improve batching effectiveness by favoring batching over shortest path. Overall point: we will actually save you battery power, so dont worry about battery used by forwarding for others. [FIXME: link to low-power electronics]
- http://members.tripod.com/~mdileo/ “The Tiny Embedded Network is an Open Protocol I designed to interconnect embedded devices in a local area network. The protocol specifications are free and open and I plan to make available the basic routines as well. Is this a power + data bus ? Lots of other PIC stuff. [FIXME: PIC]
- CO149s Fundamental Dicta(TM) http://muppetlabs.com/~chris/dicta.html lists lots of protocol design tips, including:
- 1. The packet has to know how to get back, too.
- 3. The network you are using is experimental technology and always will be.
- 5. The network is constructed of physical components.
- Subject: Embedded RS-485 Protocol Needed! Newsgroups: comp.arch.embedded
- [FIXME: summarize]
On Newsgroups: comp.arch.embedded , sometime before 1999-01-29, Edward K asked: >I need a small (low C code size), simple protocol to drive a proprietary
>network based on RS-485. I dont want to get into TCP/IP for obvious reasons.
>The clients on the RS485 bus would be based on a small 8 bit micro so speed
>and efficiency are important.
In response, Robert Reimiller 1999-01-29 suggested:
I have a small network (about a dozen nodes right now) using PIC processors. Although it doesnt use RS-485 voltage levels, the operation is about the same. It uses a very simple message packet : Length – 1 byte
Source ID – 1 byte
Destination ID – 1 byte
Message Type – 1 byte
<variable length message>
Additive Checksum – 1 byte
Exclusive-OR Checksum – 1 byte
This is a binary protocol so I used SLIP framing characters to determine the packet boundaries, very simple to implement.
A practical next step would be to use UDP/IP Packets, that way you could interface the system to router that supports SLIP.
In response, Ian Wilson 1999-01-29 commented:
Length as the first byte can cause all sort of mess in a noisy environment – consider what would happen to the when it receives noise. It would read the noise as a length and go off happily looking for the next x bytes before trying to crack the packet and seeing a back checksum. If the channel is very noisy so that you are getting continuous transitions at you receiver you can completely lock out you network. A better header for a noisy channel is a header sequence that is fixed. I does add overhead but will minimise the amount of false packets.
We use a time passed poll response system quite often. The master polls a slave and the waits for a response – if the reply has not started in a few milli-seconds the master assumes no reply is going to happen. Since replies are longer than a few ms this increases throughput on networks with lots of devices (128 or 250) where the most common reply is “nothing to report”.
Also consider adding a sequence number to the packet. If a slave sees the same sequence number it saw on the last poll it knows the master did not receive its last reply – saves having a seperate ACK reply from the master to the slave. the master holds a differenet seq number for each slave and only increments it on a successfully decoded reply. Keep seq number = 0 as a special case that forces the slave to reset its seq number. Let the seq number increment wrap around from 255 to 1.
Ian Wilson ——————————– Considered Solutions email@example.com (do the no spam thing to make a valid email address)
Mark Odell 1999-01-29 commented:
Xmodem sends the length byte followed by the ~length byte. Then a checksum at the end. It was unlikely that the length and ~length would screw up randomly to still work. Besides, a practical max. packet size can help prevent you from going too far off in the weeds.
My RS-485 protocol ran on 8051s with a single master that polled all 20 slave devices for status. I think the packet was destAddr, len, ~len, payload[len], 8-bit checksum. Worked okay for me over about a mile of total network distance.
Subject: Re: Embedded RS-485 Protocol Needed!
Date: 31 Jan 1999 00:00:00 GMT
From: Ian Wilson
<notjimbob at worldnet.att.net> (James Meyer) wrote:
>On Fri, 29 Jan 1999 04:15:07 GMT, leafs at ozemail.com.au (Ian Wilson)
>>back checksum. If the channel is very noisy so that you are getting
>>continuous transitions at you receiver you can completely lock out you
> One would think that if the channel were getting continuous
>transitions because of noise, that the channel would be completely
>useless and *no* combination of packet parameters would be any better
>than any other.
No – this is not the case. Many RF receivers do not squelch (turn
off) their outputs when the is no transmission – as the carrier detect
circuit is often more complex and less reliable and more power hungry
than the receiver (in micopower applications). So you have continuous
streams of noise induced transitions. When a transmission arrives it
is much higher than the noise level and so the receiver behaves
correctly. What you dont want is the noise induced stuff to bugger
up your network throughput.
This sort of thing can happen even on wired networks – where you have
heavy machines turning on and off or thyristor circuits nearby. Maybe
not to the same degree but you can get false transitions. If a packet
is not designed well then the network can fail. This is where:
1) fixed header sequences,
3) error detection/correction codes,
4) Ack/nack protocols
make the difference between a system that works in good conditions
only vs one that is truely robust. In designing for volume making a
system robust at the expense of a few weeks of software and protocol
design is definitely the way to go.
(do the no spam thing to make a valid email address)
Subject: Re: Embedded RS-485 Protocol Needed!
Date: 01 Feb 1999 00:00:00 GMT
From: Bill Gatliff <gatliff at haulpak.com>
Organization: Komatsu Mining Systems
SAE has a standard called J1708. Basically, all it says is that an idle period of ten or more bit times between bytes marks the end/begin of a packet, packets are at most N bytes in length, and that each packet starts with a destination byte and ends with a checksum. For the most part, you can put whatever you want inside.
In a noisy environment or one where collisions can occur (like RS485), you *do not* want to depend on receiving a length byte. Idle timing is the best way to go.
Likewise, you dont want to deal with a negative acknowledgement (where the receiver tells the sender that the packet was corrupted). Instead, only acknowledge the correctly received ones, and let the transmitter resend a packet if it doesnt get a response.
To do it right all you need is about 50 lines of C code– I think even the timer is optional if youre clever.
Heavy-duty trucks arent the worst network environment in the world, but theyre pretty bad. Despite this, J1708 works very well– nearly every truck on the road today uses it.
Just my $0.02.
— William A. Gatliff Senior Design Engineer Komatsu Mining Systems
- “An additional timeout on the receiver end to stop it from hanging within a packet”
- S.N.A.P. Scaleable Node Address Protocol http://www.hth.com/snap/ “a free and open network protocol.” has free source code for AVR, PIC, Palm Pilot, and other popular processors.
Entry filed under: Communications.