I know in a lot of asynchronous communication, the packet begins starts with a start bit.
But a start bit is just a 1 or 0. How do you differentiate a start bit from the end bit from the last packet?
Ex.
If I choose my start bit to be 0 and my end bit to be 1.
and I receive 0 (data stream A) 1 0 (data stream B) 1,
what's there to stop me from assuming there is a data stream C which contains the same contents of "(data stream A) 1 0 (data stream B)" ?
Isn't it more convenient to have a start BYTE and then check the data stream for that combination of bits? That will reduce the possibility of a confusing between the start/end bit.
Great question! Most asynchronous communication also specifies a stop bit, which is the complement of the start bit, ensuring each new symbol begins with a stop-to-start transition.
Example: let's transmit the characters ABC, which are ASCII 65, 66, and 67:
A = 65 = 0x41 = 0100 0001
B = 66 = 0x42 = 0100 0010
C = 67 = 0x43 = 0100 0011
Let's also assume (arbitrarily) that the start bit is 0 and the stop bit is 1, and the data is transmitted from MSB to LSB. The transmitter will be in the stop (1) state when no data is transmitted. So the receiver might see this:
Data: ....1111 0010000011 111 0010000101 0010000111 11111....
(quiet) ^ A $ ^ B $ ^ C $ (quiet)
With apologies for the ASCII graphics, the data consists of a series of stop (1) bits while the channel is idle. When the transmitter is ready to send a character, it sends a start (0) bit (marked with ^), followed by the character code, and ending with a stop (1) bit (marked with $). It continues to send stop bits until the next character is transmitted, beginning with another start bit.
The reason we use start bits instead of bytes is efficiency. The scheme above requires 10 bits (1start + 8data + 1stop) to transmit 8 bits of data, resulting in an overhead of (10 - 8) / 8 = 1/4 = 25%. If we used start and stop bytes, we'd need to transmit 3 bytes for each byte of data, which would be an overhead of (3 - 1)/1 = 2 = 200%. If the start, data, and stop bytes were each 8 bits, we'd have to transmit 24 bits instead of 10 for each character, so it would take almost 2 1/2 times as long to send the data!
One can always define a start byte as an indication that a message is beginning (and the ASCII SOH, STX, and ETX codes were intended for such purposes). However, the standard hardware and protocols for connection to data-transmission equipment (RS232C and later) operate at a lower level, and it is generally neither possible nor desirable to alter that arrangement (especially via software).
High performance synchronous data transmission schemes, such as those used on local-area networks and wide-area transmission systems do use elaborate frame markers. The frame marker is a distinct pattern of bits that never occurs in the stream for message data. There is typically a special rewriting rule that essentially "escapes" any in-data occurrence of a similar bit pattern so that transmission equipment will not see it as a frame marker. These escaped patterns are reconstructed by the recipient so the sender and receiver never have to pay attention to this. These arrangements make specialized hardware even more important, such as in the typical Network Interface Card (these days, motherboard chip) on personal computers.
BACKGROUND ON ASYNCHRONOUS SERIAL COMMUNICATION
It is useful to think of asynchronous serial transmissions as asynchronous between character/data frames and synchronous within the span of the character frame (including the start bits and initial stop/fill).
With this scheme, there is a constant fill signal between the frames and it is usually at least one data-bit wide, although some arrangements require a 1.5-bit or two-bit stop/fill. The stop "bit" uses the same signal level and can be considered the minimum fill period before another start bit will arrive.
When a frame is arriving, it is necessary to synchronize with the predetermined number of bits it is expected to carry. The transition from the fill to an opposite level signal is accomplished by the start bit which is always opposite to the stop/fill level. The sampling of the bits can be timed to happen in the middle of subsequent bit-arrival periods.
Technically, if frames were being sent at the maximum rate, it would not be necessary to send any stop/fill, proceeding to the start bit of the next frame immediately. However, counting on at least one bit worth of fill before the start-bit transition helps to keep the sender and receiver synchronized.
If you think of the asynchronous streams as being encoded from key depressions using a keyboard, you can see the importance of allowing arbitrary fill between character frames. Once it is known what frame to send next, it can be inserted immediately, with its start bit, at the agreed bit rate, after there has been at least one bit worth of preceding stop/fill.
It is also useful to notice that, in typical low-speed asynchronous transmissions, there are only two kinds of bits/levels, so the only way the presence of data as opposed to fill can be distinguished is by a marker scheme like this where the start of the frame is uniquelly detectable and the end of frame is predetermined (unless there is a more-sophisticated variable-length frame structure generally not used in asynchronous serial communication). It is actually rather difficult for a receiver to discover the bit rate of a transmitter without some additional agreement, such as looking for a recognizable data sequence from which one can estimate the bit rate which would have it arrive correctly when it arrives in incorrect form.
Even though high-speed modems now transmit complex analog signals that aren't described in terms of two simple signal levels, the RS232C (and later-mode) digital communication between a computer UART and the data coupling on the modem is pretty much as described.
High-speed modems also have additional capabilities for synchronizing with a distant end-point, as you can tell by listening to the signal audio while a connection starts up. In addition, There are separate signal lines in the serial cable to the computer that are used for pacing between the computer and the modem so that the sending party does not transmit new data frames faster than the receiving party (either computer or modem) can accept them. But a frame, once started, is always started at the agreed synchronous speed.
Wikipedia has a good description of asynchronous serial communication, what computer serial ports use.
There is a common over-simplification that suggests the stop bit determines the length of the data. That's not the case. The stop bit looks just like a level for another data bit. The way the stop bit and the period until the next start bit, are recognized is by knowing the bit rate at which in-frame data and start/stop bits are being transmitted and knowing how many bits a frame contains. Otherwise, there is no way to distinguish a stop bit from just another bit of that polarity as part of the data frame.
Here is the way start and stop bits usually work:
A start bit is sent, say 1. This indicates to the receiver that a specified number of bits of data will be transmitted, say 8.
8 bits of data are sent.
A stop bit is sent, say 0. This indicates that the 8 bits of data have been sent.
If more data is to be sent, each byte must be initiated with a start bit and terminated with a stop bit. The transmitter and receiver must agree on how many bits of data are sent for each start bit so the receiver will be able to distinguish the stop bit from the data. Sometimes the start bit is actually multiple bits or even a byte, but the idea is the same. The receiver recognizes the end of the data frame when it sees the stop bit after receiving the pre-specified number of data bits. Sometimes a parity bit is sent before the stop bit to provide a simple error-detecting mechanism.
It is all protocol dependent. You can say that after start symbol you will expect N symbols or you will read until you encounter the stop symbol.
Where symbol colud be any n-bit sequence (including bit and byte.)
Indeed, your example with bits exactly apply to a protocol which uses bytes instead of bits.
Say you send 00000000 stream A 11111111 00000000 stream B 11111111. In this case you may still confuse it with stream C = stream A 11111111 00000000 stream B.
Usually a start bit is used because a voltage level change can trigger an event (See edge triggering in flip flops.) On the other hand a start symbol with multiple bits will be used to synchronize clocks of two systems in addition to triggering an event. An example of it would be a PAL signal.
The start and stop bits come from the days of the teletypes. They essentially were pulses that took up time to sort of let the mechanical hardware set. Dos text file lines are ended with CR LF which literally caused the carriage to return to column 1, and the platen to advance one line. I think it is in the order because it takes longer for the CR to occur, and the LF can effectively happen in parallel.
Detecting it is a little bit harder. You sort of have to watch the bit stream go by.
Over time you ought to be able to detect it, as the data is normally ASCII with the start/stop bits around it. Normally this isn't an issue, because it is handled by the UART which runs the COM port.
Related
I'm a little confused about the inter-character gap in Modbus and whether its required when a master sends a message to a slave. The protocol spec says you can't have more than a 3.5 character gap between bytes when transmitting but is there any specific minimum amount of time you must have between bytes?
I've written a Modbus driver (master) that is able to communicate with a variety of devices and most don't seem to care about any gap between characters when receiving messages. However, I've come across a couple of devices where I was unable to communicate reliably without putting in a some kind of delay (measured in microseconds) between bytes, which is determined by the baud rate.
Is the character gap an absolute requirement or does it depend on the manufacture of the device and how the implement the Modbus protocol?
Does Modbus RTU require a gap between characters when transmitting?
No.
In fact the Modbus spec states in section 2.5.1.1 MODBUS Message RTU Framing that "[t]he entire message frame must be transmitted as a continuous stream of characters."
Requiring intercharacter gaps would be contradictory to specifying "a continuous stream".
The protocol spec says you can't have more than a 3.5 character gap between bytes when transmitting ...
You're misquoting the protocol spec.
Only a 1.5 character gap is tolerated between characters in a RTU message.
From the Modbus spec: "If a silent interval of more than 1.5 character times occurs between two characters, the message frame is declared incomplete and should be discarded by the receiver."
A silent (idle) line with a duration of 3.5 characters must precede a message.
IOW a gap of 2 (i.e. more than 1.5 and less than 3.5) characters would prematurely end the current message, and the following characters (of that malformed message) would not be considered the start of a new message and must be discarded (until the line goes idle for at least 3.5 characters).
... is there any specific minimum amount of time you must have between bytes?
The Modbus spec does not mention any such requirement.
Such a requirement would be impractical.
UARTs (typically) do not have a capability to meter its output by inserting a delay between the transmission of character frames.
Adding such a delay is an additional processor burden as well as the use of a timer.
On the contrary UARTs have evolved to transmit characters as fast as the baudrate allows with the least processor intervention, e.g. hardware FIFO and DMA.
A "minimum amount of time you must have between bytes" is simply a reduction in the effective data rate.
Therefore an appropriate reduction of the baudrate would accomplish the exact same data rate.
Is the character gap an absolute requirement or does it depend on the manufacture of the device and how the implement the Modbus protocol?
No, you are probably using too fast a baudrate for the device/circumstances in question.
A microprocessor or microcontroller should be able to keep a UART busy and transmit without any intercharacter gaps.
A UART that requires gaps during receiving is IMO an overloaded system and is broken.
For reliable communication (without flow control) use a baudrate low enough so that metering the transmitted characters is not necessary.
Addendum
Apparently there is at least one UART (from Siemens) that can meter its output by holding the line idle for N bit-times between character frames.
It is at the end of the message that there should be a pause of 3.5 characters or longer.
Usually in the data transmission protocols in the first positions of the byte sequence, the number of bytes that follow is included, but Modbus RTU does not send that length and what determines when a message ends is the pause of 3.5 characters.
If you send the sequence of bytes at once there should never be any pause between characters
If you are writing a Master you should not worry about this, since it is the slave that must wait 3.5 characters to know when the master request is finished.
You from the master side simply wait for the slave to reply since you know how many bytes the slave is going to send, in the request you already sent how many bits or 16bit words you want to read.
And if you have communication problems with some devices, it is probably due to the combination of communication speed and poor quality of the line. Try a lower baud rate, but adding wait between characters for me doesn't make much sense.
I have encountered uarts which require 2 stop bits on receive. If it set for 2 stop bits, this may explain the reqirement for a gap to extend thes# stop period beyond 2 stop bits.
Usually, only the first stop bit is checked on receive to determine framing error regardless of the stop bit setting.
I'm trying to understand asynchronous serial data transmission. I know that the transmitting device sends a start bit (e.g. 1) to the receiver to indicate that transmission has begun; then a stop bit (e.g. 0) afterwards to indicate that the transmission has ended.
What I don't understand: how does the receiving device know which bit is the stop bit? The stop bit is surely no different from the other bits of data. The only way I can think of is if the transmitting device stops sending bits for a significant gap, the receiving device would know that no more bits are forthcoming, and the last bit must have been a stop bit. But if that is the case, then why would a stop bit be required at all, rather than the receiving device simply waiting for a bit, and considering the transmission to be ended when the transmitting device doesn't send any more bits?
That becomes a question of protocol. start and stop bits only have meaning if the communicating devices agree on that meaning (e.g. a frame consists of a start bit, 8 data bits, and a stop bit). Similarly, how to denote when a particular communication is complete needs to be agreed between the participants (e.g. define one or more frames that denote message termination).So for a particular communication either a full frame is received and the listener keeps listening, a partial frame is received with no subsequent data transmission and the connection can be considered faulted after some duration, or a full frame is received and that frame denotes the end of the exchange.
What is the purpose having created three type of parity bits that all define a state where the parity bit is precisely not used ?
"If the parity bit is present but not used, it may be referred to as mark parity (when the parity bit is always 1) or space parity (the bit is always 0)" - Wikipedia
There is a very simple and very useful reason to have mark or space parity that appears to be left out here: node address flagging.
Very low-power and/or small embedded systems sometimes utilize an industrial serial bus like RS485 or RS422. Perhaps many very tiny processors may be attached to the same bus.
These tiny devices don't want to waste power or processing time looking at every single character that comes in over the serial port. Most of the time, it's not something they're interested in.
So, you design a bus protocol that uses for example maybe 9 bits... 8 data bits and a mark/space parity bit. Each data packet contains exactly one byte or word (the node address) with the mark parity bit set. Everything else is space parity. Then, these tiny devices can simply wait around for a parity error interrupt. Once it get's the interrupt, it checks that byte. Is that my address? No, go back to sleep.
It's a very power-efficient system... and only 10% wasteful on bandwidth. In many environments, that's a very good trade-off.
So... if you've then got a PC-class system trying to TALK to these tiny devices, you need to be able to set/clear that parity bit. So, you set MARK parity when you transmit the node addresses, and SPACE parity everywhere else.
So there are five possibilities, not three: no parity, mark, space, odd and even. With no parity the extra bit is just omitted in the frame, often selected when the protocol is already checking for errors with a checksum or CRC or data corruption is not deemed likely or critical.
Nobody ever selects mark or space, that's just wasting bandwidth. Modulo some odd standard, like 9-bit data protocols that hardware vendors like to force you to buy their hardware since you have no real shot at reprogramming the UART on the fly without writing a driver.
Setting mark or space parity is useful if you're generating data to send to hardware that requires a parity bit (perhaps because it has a hard coded word length built into the electronics) but doesn't care what its value is.
RS485 requires 9 bits transmission, as described above. RS485 is widely used in industrial applications, whatever the controlled device 'size' (for instance there are many air conditioners or refrigerators offering a RS485 interface, not really 'tiny' things). RS485 allows up to 10Mbs throughput or distances up to 4000 feet. Using the parity bit to distinguish address/data bytes eases hardware implementation, each node of the network can have their own hardware to generate interrupts only if an address byte on the wire matches the node's address.
Very clear and helpful answers and remarks.
For those who find the concept perverse, relax; the term is a problem of semantics rather than information theory or engineering, the difficulty arising from the use of the word "parity".
"Mark" and "space" bits are not parity bits in those applications, and the term arises from the fact that they occupy the bit position in which a parity bit might be expected in other contexts. In reality they have nothing to do with parity, but are used for any relevant purpose where a constant bit value is needed, such as to mark the start of a byte or other signal, or as a delay,or to indicate the status of a signal as being data or address or the like.
Accordingly they sometimes are more logically called "stick (parity) bits", being stuck in "on" or "off" state. Sometimes they really are "don't cares".
I am writing some code for a microprocessor to communicate with an external device via asynchronous serial communication over a single wire.
I can recognize a transition on the wire from low/high (either way), so I can find the bit boundaries. Given that I know the baud rate the device is using I can then start clocking off bits, so I can read the stream of bits coming from the device.
What I'm struggling with conceptually is recognizing a start bit - finding the start of a byte frame (assuming I'm getting 8 bit, no parity, 1 start bit, 1 stop bit). I understand that each frame begins with a start bit and ends with a stop bit, but it is my understanding that start and stop bits look like any other bits - so there's nothing special about them that identifies them as start or stop bits (other than their position).
The only way I can think of to identify a start bit is that it will be the first high bit after a sustained idle period - that is, since I'm expecting 8 bits no parity, if I get 9 or more low bits then the line is idle, and the next high bit will be a start bit. That's all fine, but what if I start listening to the device mid-bitstream and there is no idle time of 9 bits or more on the wire? I am clocking off bits, but how do I recognize which bit is a start bit so I can read off a byte? If I'm clocking off bits, then anything in between frames can only be integer multiples of bits (so a stop "bit" can't be 1.5 bits for example), so everything just looks like bits.
I hope I'm making sense... thanks for any help.
The start bit is what gets your code to receive a byte going. Best explained with a state machine. You've got 4 basic states:
State "wait": sample the data line. When you see the start bit then start a timer at 1.5 * bit-time and move to state "data"
State "data": wait for the timer then sample the data line to record a bit. Restart the timer to 1.0 * bit-time. Repeat as long as you haven't received all bits. Move to state "stop" when all bits received
State "stop": wait for the timer and sample the data line to check the stop bit. Move to state "error" if it is wrong, add a byte to the receive buffer if it is not. Back to state "wait".
State "error": complain. Wait for deus ex machina to go back to state "wait".
So basic insights from this is that you need the start bit to get the code going that receives a byte. And that the stop bit is important so you can reliably see the start bit for the next byte.
I would make your program read the sequences and decipher patterns at one point or another, moving 9 bits back and forth, the data will make sense, depending on the chains you are transmitting. Once a pattern is recognized, maybe recognizing if the data has one period, then I would look if at any point the line of bits that makes a byte match to the period code (ascii 46) then count spaces back and forth and establish the start and stop bits.
I've got a bit of an odd question. A friend of mine and I thought it would be funny to make a serial port kind of communication between computers using sound. Basically, computers emit a series of beeps to send data, and listen for beeps over a microphone to receive data. In short, the world's most annoying serial port. I have all of the basics worked out. I can filter out sounds of only one frequency and I have sent data from one computer to another. Although the transmission is fairly error free, being affected only by very loud noises, some issues still exist. My question is, what are some good ways to check the data for errors and, more importantly, recover from these errors.
My serial communication is very standard once you get past the fact it uses sound waves. I use one start bit, 8 data bits, and one stop bit in every frame. I have already considered Cyclic Redundancy Checks, and I plan to factor this into my error checking, but CRCs don't account for some of the more insidious issues. For example, consider sending two bytes of data. You send the first one, and it received correctly, but just after the stop bit of the first byte, and the start bit of the next, a large book falls on the floor, which the receiver interprets to be a start bit, now the true start bit is read as part of the data and the receiver could be reading garbage data for many bytes to come. Eventually, a pause in the data could get things back on track.
That isn't the worst of it though. Bits can be dropped too, and most error checking schemes I can think of rely on receiving a certain number of bytes. What happens when the receiver keeps waiting for bytes that may not come?
So, you can see the complexity of this question. If you can direct me to any resources, or just give me a few tips, I would greatly appreciate your help.
A CRC is just a part of the solution. You can check for bad data but then you have to do something about it. The transmitter has to re-send the data, it needs to be told to do that. A protocol.
The starting point is that you split up the data into packets. A common approach is a start byte that indicates the start of the packet, followed by a packet number, followed by a length byte that indicates the length of the packet. Followed by the data bytes and the CRC. The receiver sends an ACK or NAK back to indicate success.
This solves several problems:
you don't care about a bad start bit anymore, the pause you need to recover is always there
you start a timer when you receive the first bit or byte, declare failure when the timer expires before the entire packet is received
the packet number helps you recover from bad ACK/NAK returns. The transmitter times out and resends the packet, you can detect the duplicate
RFC 916 describes such a protocol in detail. I never heard of anybody actually implementing it (other than me). Works pretty well.