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

  • Thread starter Thread starter marellasunny
  • Start date Start date
  • Tags Tags
    Nodes Serial
Click For Summary

Discussion Overview

The discussion revolves around the synchronization of slave nodes in serial communication, specifically focusing on the role of the sync field and how it enables synchronization without quartz or ceramic resonators in the slave nodes. Participants seek to clarify the concept of synchronization in layman's terms and the mechanisms involved in achieving it.

Discussion Character

  • Exploratory
  • Technical explanation
  • Debate/contested

Main Points Raised

  • One participant asks for a layman's explanation of what it means for slave nodes to be "synchronized" and how the sync field achieves this.
  • Another participant describes how the receiver monitors the incoming stream and uses an internal tracking clock to maintain synchronization, noting that this clock typically operates at a multiple of the baud rate.
  • A different participant expresses concern about potentially misinterpreting the question and requests clarification on the specific communication protocol being used.
  • One participant suggests that the sync character may serve to reset the higher-level protocol or help the receiver determine the baud rate after a break.
  • Another participant inquires about how a slave node determines the baud rate from the sync character and questions whether it has an onboard computer to facilitate this process.
  • One participant points out the confusion between different protocols and suggests looking into the CAN protocol for further understanding.

Areas of Agreement / Disagreement

Participants express varying degrees of understanding regarding the synchronization process and the role of the sync field, with no consensus reached on the specifics of how slave nodes synchronize with the master node's clock.

Contextual Notes

Participants mention different serial communication protocols, indicating that the discussion may be limited by the specific context of the protocols being referenced and the assumptions made about their operation.

marellasunny
Messages
245
Reaction score
3
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
 
Last edited by a moderator:
Engineering news on Phys.org
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.
 
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
 
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)
 
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.
 
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