serial communications – protocol_considerations

July 7, 2009 at 12:00 am Leave a comment


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 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]
  • “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) 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 (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.

    – Mark

    Subject: Re: Embedded RS-485 Protocol Needed!
    Date: 31 Jan 1999 00:00:00 GMT
    From: Ian Wilson
    Newsgroups: comp.arch.embedded

    <notjimbob at> (James Meyer) wrote:

    >On Fri, 29 Jan 1999 04:15:07 GMT, leafs at (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,
    2) timeouts,
    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.

    Ian Wilson
    Considered Solutions

    (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>
    Organization: Komatsu Mining Systems
    Newsgroups: comp.arch.embedded

    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 “a free and open network protocol.” has free source code for AVR, PIC, Palm Pilot, and other popular processors.

Entry filed under: Communications.

A-301 High Voltage Amplifier/ Piezo Driver and Modulator2

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed


  • 137,319 hits

من محتويات الموقع

كثرت إصدارات الماسنجر وتبعثرت بتشاتها وبرامجها .. فالبعض يبحث عن جديد الماسنجر .. والبحض يبحث عن ماسنجر 7.5 .. ماسنجر هوتميل والبعض يبحث عن ماسنجر 7 نحن نوجهك إلى تحميل برنامج ماسنجر بلس مسنجر 9 برنامج الماسنجر الجديد هوتميل تسعة ... برنامج ماسنجر هوتميل بلس لاصدار ماسنجر لايف 9 ماسنجر,ماسنجر بلص,تحميل الماسنجر,ماسنجر 8,صور ماسنجر,اصدارات الماسنجر و ما قبله من اصدارات.. تحميل مسنجر مسنجر بلس مسنجر 9 مسنجر ياهو مسنجر لايف تنزيل مسنجر messenger اقلاع سوفت messenger + msn + hotmail download msn messenger hotmail msn web messenger hotmail msn messenger without hotmail msn messenger und hotmail telecharger msn messenger hotmail msn hotmail messenger mac Internet turbo 2009 ,جديد البرامج و الإنترنات , ,Download parameg FOR MOBILE TORRENT ,كشف الملفات التالفه في الويندوز ,فضل برنامج للصور المتحركة عربي ,فتح محطات ART الفضائية ,Firefox ,برامج تشغيل الملفات ,تحميل أقوى مشغل ملفات flv ,تحميل برنامج مجانا internet download manager ,Fotos+do+sound+forge ,NLite ,كول اديت ,Free arc لفك الضغط ,تنزيل ساعة على سطح مكتب الكمبيوتر ,برنامج تحويل الفيديو يوتيوب الى 3gp ,تنزيل برنامج لفتح الاناشيد ,Fotos+do+sound+forge ,برامج كمبيوتر للفيروسات ,Six free mp3 ,تحويل pdf الي word ,نوع الفيديو للبرو جولد ,تحميل برنامج Passware Kit Enterprise ليش نسخة Demo ,Ares+tube ,Image banner maker ,Kmp 2007 ,تنزيل برنامج لتشغيل اناشيد mp3 ,برنامج مشاهدة القنوات الفضائية ,موقع تحميل الانتي فايروس 2010 ,تنزيل المتصفحات الجديدة ,Download free Revo Uninstaller ,تشغيل كاميرا nokia pc suite ,Zib password remova l برنامج ,تحميل برامج تشغيل الفيديو ,تحميل برنامج عن طريق الجوال لمشاهده التلفزيون ,افلام يوتيوب للهاتف المحمول مجانا ,تسريع الانترنت ,Ares+tube ,برامج حماية من الفيروسات مجانية ,Antivir free download ,برامج نت ,كيفية التعامل مع الملفات المضغوطة ,كول اديت ,Kis key ,برنامج الالة الحاسبة ,برنامج تغيير الأصوات للكمبيوتر من برامج نت ,برامج مشغلات الفيدبو كمبيوتر ,برنامج youtube لنوكيا 73

%d bloggers like this: