How does the Sync.field synchronize slave nodes in a serial communic?

[marellasunny]

Serial communication:Following the Break is the Sync.field. The literature says that as there are no quartz or ceramic resonators in the slave nodes,the sync.field is transported before the protected ID field.I do not understand 2 things here:

1.What does it actually mean for the slave nodes to be "synchronised" in layman terms?
2.How does the sync.field go about in achieving this?

A really simple layman explanation would help.I am a mechanical engineering learning how to use the ARDUINO in a serial interface.
http://www.freepatentsonline.com/6959014-0-large.jpg

 

[mjhilger]

The receiver is constantly looking at the incoming stream. When the stream shows a constant level longer than the "break" period, on the next stream transition an internal tracking clock starts. Typically this clock is 16 times the the baud rate, so inside the smallest bit stream transition (a single bit) the tracking clock transitions 16 times. During the sync bit, the internal circuitry looks at the stream value at clock 8, or the middle of the bit stream, there after it looks every 16 clocks. Having an odd number of bit slots allows a system with baud clocks slightly different to keep in sync more reliably over a long transfer sequence. <- This is for typical serial communications as used between PC & terminal and such.

Then to confuse matters, some serial communication protocols that transmit packets use a sync field (number of bits defined by the protocol as opposed to a single sync bit of ASYNC SERIAL) which tells the circuitry that this is the beginning of a packet. I believe since you are describing a "protected ID" field, you may be looking at the sync of a packet and not necessarily the bit stream. But a basic understanding of the way the underlying circuitry uses the faster clock to lock onto the incoming bit stream is similar in most protocols.

Serial streams have many protocols that have evolved over the years and may require reading and much staring at diagrams like the one above and longer ones that include entire packets to sort out in one's head the pattern.

 

[mjhilger]

I fear I answered the wrong question (I specified how the RS-232 syncs the bit stream of each character passed). Please specify the communications protocol you are using (I2c, SPI, microwire, 1-wire...).

As I said protocols can be confusing and require an underlying understand of the basic ASYNC capture as well as the protocol packet structure as well.

mitch

 

[meBigGuy]

It looks like you are sending RS-232 UART data to an external device. The sync character might have one of two applications. Either the device needs it to reset its higher level protocol, or, after a break, the receiver determines the baud rate from the sync character. (most likely)

 

[marellasunny]

meBigGuy:After reading through the text,I found its the latter-the receiver determines the baud rate from the sync character.The receiver in my case is a slave node(a signal wire from the buttons on my steering wheel),how does a slave node figure out the baud rate from the sync character? Does it have a onboard computer or something?

mjhilger:Your explanation gave me new insight into the structure of the serial data sent from the master node,but I still can't figure out how the slave node practically syncs with the "heart beat" clock from the master node just by calculating the time for 1 single bit.

Thanks.

 

[mjhilger]

Ok, as I suspected, you are confusing protocols and the underlying sync mechanism (easy to do considering both have sync and other terms in common). Vehicles utilize CAN protocol and you may read about it from the wiki http://en.wikipedia.org/wiki/CAN_bus. Look there and see if that answers some of your questions. If you have specific questions, post them here on this thread and we will try to answer. (I'm not very familiar with this protocol, but I will look it over and try to help).
mitch