I am learning about serial communication, and I just can't understand why the start bit and the stop bit(s) are necessary.
I mean say I have two devices connected via serial ports, and the bit 1 is represented by +15V and the bit 0 is represented by -15V.
So for device 1 to send the 4 bits 0110 to device 2, device 1 should send the following voltages: -15V +15V +15V -15V.
What am I missing here, because it seems like it can work without the start bit and the stop bit(s)!
The scenario that you seem to be talking about (with start and stop bits), is likely UART (of which RS232 is a type of). UART stands for Universal Asynchronous Receive Transmit, the key part of which is Asynchronous. There is no clock line, only data.
In this sort of system you have two devices (TX and RX) which don't necessarily share a common clock. Both systems might for example agree on 9600 Baud, but without a common clock, one might produce 9601 Baud while the other gets 9599 Baud. Clocks are not perfectly accurate, which means over time the two will drift out of alignment.
Additionally because the communication is asynchronous, it can start whenever the transmitter feels like it (ignoring flow control). The transmitter and receiver might will turn on at different times, and the receiver has no way of knowing when it starts to transmit.
The key requirement then is known as synchronisation. The protocol must include some way of the transmitter to signal to the receiver that it has just started transmitting. Additionally there must be some way to synchronise the clocks at both ends.
In the case of UART, this synchronisation is done in the form of a high to low transition on the data line. The line will idle high, then drop low when transmit starts. This transition acts to synchronise the timing between both devices. The receiver then knows to clock in enough cycles of data based on its baud clock. There are however two problems with this scheme:
The single high to low transition is not enough to synchronise timing over a long period of time. Remember the two devices will have slightly different internal clock rates. As long as those two clocks are within a certain % of each other, the transition will provide enough information to synchronise the devices for at most a few clock cycles. That means you need periodic resynchronisation.
If your line is idling high, and the first bit of data you want to send is also represented by a high level, then you don't have a transition. If your line is idling low and the first bit you want to send is low, you have the same problem. That means you need some way to distinguish the first bit.
Both of these problems are solved in the case of UART by using start and stop bits. The data that is being sent is split into packets of a few bits (e.g. 8 bit). Each packet is preceded by a start bit of "low" and followed by a stop bit of "high". That means that between every few bits there is a known high to low transition - the stop bit of the last packet and the start bit of the current packet. You can now resynchronise every packet.
This is by no means the only way of solving the problem. There are many other schemes - Manchester coding is one example. In that scheme a low to high transition signifies a logic 1 while a high to low transition signals a logic 0. That means that every bit you send encodes clock information within it meaning you can resynchronise every bit you send.
You could have other signalling methods such as using ternary - three voltage levels. For example you might use +5V for a 2, 0V for a 1, and -5V for a 0. You could send binary via this system using one of those states to signify idle. However in that example you have simply replaced a start and stop bit with a period of time at a third voltage. You won't change the need for periodic resynchronisation, so it doesn't really save you anything, and it just adds complication to the circuitry.
You say -15V +15V +15V -15V. which is 0110, you are right a receiver could receive that properly.
But what if you send 15V 15V 15V -15V how would you know what that is. As the listener the first thing you would hear is the first -15V, you would have no idea how many 15V signals came before that.
The listener would hear the same thing no matter whether the sender sent 1110, 1101, 1011, or 0111.
Without any time reference, they all look alike as a voltage signal.
Because time matters with asynchronous signals you need to send a "LISTEN UP" signal. In RS232 that listen up signal is a high to low transition on the line. It tells the receiver "I am about to send N bits of data at my baud rate, starting NOW!"
Notice, in this example 4 bit UART, each pattern now has a unique signature.
The stop bit ensures the line goes back to the idle state at the end of the transmission and also gives the receiver a time window to handle the bytes just received, reset, and get ready to listen for the next start bit.
In the image below the first trace has no stop bit. Notice since the last bit of the first data is zero the line is already low when the next start bit arrives and there is no transition to start the UART. In the second trace that does have a stop bit, you are guaranteed high before low.
In fact most UARTS give you the ability to send more than one stop bit to further open that window for the receiver. This was more important in the early days of serial transmission where the RS232 signal actually directly drove mechanical motors and relays, but it can still has it's uses today.
Further, most UARTS actually check for the stop bit being high at the appropriate bit time. If it is not, a framing error is flagged to the receiver.
Startbit is a wake-up at the end of the idle state. Stopbit ensures there's a known transition at the beginning of new byte. The system was developed at the era when there was no possiblitiy to be sure that the motors in mechanical data transmission devices (=teleprinters) run in sync at both ends. Start-and stopbits were the resyncing method.
Today much longer bit sequences than one byte can be transmitted without a need for resyncing. But finally all clocks drift apart and synchronization is needed. There are developed numerous coding systems that carry the needed sync data much more effectively than start&stopbits which needed +25% extra capacity.
For one payload sure... maybe... possibly. But what if you are sending a stream of data. How can the receiver be sure when the last payload ended and the new payload starts?
The idle state of an RS232 bus is -12V. How will the reciever know it is to receive a stream of 0's or when transmission is to start ?
Such serial communication is also asynchronous. The receiver needs to see an edge to determine aspects of the transmission
You are confusing the voltage levels (RS-232 we assume) and the serial protocol (lets just say uart as it came from a time before everyone was obsessed with naming things).
Using your example you cannot tell 0110 from 001100 for example. With the uart protocol you need to sample ideally the middle of the bit cell, in order for the receiver to know where the middle is, being on different time sources and not exactly the same the first edge from idle gives you a reference to be able to hit the middle of the next N bits how big N is depends on the accuracy of each side, 8 or so data bits you can be pretty sloppy, and if you want can re-sync on any edges you do find (in your example how would you receive 00000000? or 11111111?)
The start bit gives us an edge do distinguish from idle, to tell is when the message starts and a reference to sample the bits. The stop bit insures we go back to idle at least for one bit cell or two. When saturated with data, no gaps, no idle other than the stop bit, then you have another problem which the uart protocol doesnt solve necessarily (well parity helps) if you come in in the middle (someone plugs then thing in while data is moving, or any other reason) the start and stop bits help to frame the data without parity you may still be able to figure out where you are, with parity you have an even better chance but not perfect.
Now there are other protocols. Many other protocols. go look up irig-106, instead of a start bit you have a sync pattern which can be followed by hundreds of bits before another pattern, no dead periods. The irig document has a nice chart of various encodings where NRZ-L is what we are used to with a simple uart (non return to zero level) an interesting one is bi-phase-l Where there is a state change mid bit cell so your 0110 would be transmitted at 2x the frequency of the data and would be 01101001, worst case you can never have more than two half bit cells in a row at the same level, many edges with which to bitsync.
Another interesting one is mil-std-1553, where they use bi-phase-L (which is a popular encoding with many different names just biphase or manchester, etc) but it is not continuous data, it is a burst of one to many words. they use an intentional biphase-l error of three half bit cells and three half bit cells as the sync pattern then go into the message encoded in biphase-l.
No reason why you couldnt use RS-232, RS-422, etc voltage levels with a different than uart protocol. But you still need edges every so often in the data in order to synchronize the clocks (if you carry the clock along then then that is another story) and you need some way to know determine where the groups of bits that make bytes or words are so you have to have a sync pattern or start bit or other. or do something like spi or i2c to mark the beginning. classic ethernet used a long square wave with some bits to indicate the end of that and the start of the packet. MDIO has something similar.
At the end of the day you cannot have a reliable single signal serial protocol without some way to know where word/message boundaries are in the bitstream, likewise cannot do it without knowing where/when to sample for each bit. Even if a continuous bitstream and perhaps you think you knew when time zero was and you can just count to 8 and mark off another byte, you might get lucky but you have to still sync with the sending clock as your clock is based on a different reference and will drift relative to the senders clock. So you can try to pull this off so long as you periodically look at th edges you find, and insure that there is an edge every N bits based on the math related to the accuracy of the clocks.
