Contents
Packet Format & Serial transmission/Reception
Tynetec Ltd have over 20 years experience of design and manufacture of microprocessor based communication, control and security systems.
Nowadays they primarily make electronics products in reasonably large numbers. They are based in Blyth and have design facilities, engineers and manufacturing facilities under the same roof. This not only proves to be highly cost effective, but is also highly efficient.
The main products of Tynetec Ltd. Include Fire Detection Systems, Lift monitoring Systems, Warden Calls, Access Control Systems, Intercoms and Control Systems for Closed Circuit Television.
Because all of these devices have separate ‘Controller’ units and several external ‘receiver’ units, the devices must communicate with each other.
This communication is done by using a data bus*. Electrical signals are passed through these buses and are received by the smaller units. But now we meet a problem. If the information is to be sent over long distances through these buses, how do we know that the data being received is the same data that is being sent?
That is the problem that we were set.
Through a little background research, we found that the information is sent in a form known as RS-485 (there is more information on this further on in the booklet).
A data bus is a series of wires used in communication applications to transfer data from one place to another.
Commonly there
will be a positive, negative and common return (earth) wire.
Basically,
this signal is susceptible to corruption by Electro Magnetic Radiation.
One way to try to combat this problem is to use a twisted pair. This
is when two or more wires are twisted together so that if one wire receives
a distortion of any kind, this distortion is also applied to the other
line. Then, when the data is received at the smaller unit, the distortion
can be filtered out of both lines and we should be left with a cleaner
signal.
However, this does not always work, and if it does not, we are left with the problem of trying to view the extent of the problem. Currently, an engineer must visit the site where the unit is fitted and remove the unit, he must then take the unit back to a testing station and find the fault, this is not only expensive, but also takes a lot of time and resources.
It would therefor be more useful to both Tynetec and the customer, if it were possible to test the units on site without having to remove them.
Our task is therefor to develop a handheld unit which can be used by an engineer to conduct on the spot testing of units. This testing will enable the engineer to decide whether or not the unit is functioning properly, if not, the unit can be removed and replaced. If it is, then the engineer knows that there must be a fault elsewhere.
As well as this, the unit will also have to be able to indicate the voltage level of the received signal so that the engineer can determine whether or not the signal needs to be boosted in order for the unit to function properly.
Since we now know that the problem lies with viewing the data between the sender and receiver unit, we know that we need to develop a portable, hand-held unit. This unit can be carried and operated by an engineer at the site of the unit.
The unit must
have clear display so that it can be read easily by the engineer.
Tynetec have proposed
that we use
a two line liquid crystal display (LCD), as this is the standard type of
display that they use. This will mean that the unit will be in line
with the rest of their product range when it is complete.
The unit should also include a battery-low indicator and should be relatively uncomplicated to use. It must also have some kind of facility to display the actual voltage of the data being transferred.
To keep the operation of the unit simple, it should be easy to connect up to the unit being tested. Again, Tynetec have proposed that we use one of their standard components for this application, in this case a 9 pin D-type connector (The type used at the end of a serial mouse lead on your home PC)
Wires cost money
and are typically unreliable. The telegraph was the first electric device
intended for long distance communication. The earliest versions used 5
wires, each of which deflected a compass needle at the receiving end. An
early binary code (the first four needles deflecting left and the last
going right means "z") let signallers send messages over distances approaching
a kilometre.
It wasn't long before engineers managed to compact the code into a single stream of data, recognizable on a single compass needle. By 1838 Von Steinheil realized a single wire was enough; the earth would make a good return circuit.
Samuel Morse created a standard set of codes for each character. He tried to minimize the code's "cost" (in characters). The more frequently used letters used shorter codes. This was one of the first steps towards our modern fixation with compression.
Today, Morse's original code is no longer used. Modern code is properly called "International Morse" to seperate it from it's ancient relation.
Morse took the first critical steps towards modern data transmission. A complex message could be encoded onto a single wire by representing a character as a string of components, each of which was transmitted one after the other (now called "serial transmission").
A long time ago, the military and weather services, later followed by the news agencies, sent text data between sites using various versions of a device called the teletype.
These beasts
were purely mechanical, somewhat like early electric typewriters and converted
keystrokes to series of ones and zeroes representing each character.
Early models encoded characters into Baudot, a 5-bit code, resulting in
a maximum possible 32 characters. Needless to say, you can't even encode
all of the letters and numbers in a 32 bit space, so "shift up" and "shift
down" characters, which toggled character sets were added, essentially
doubling capacity to 64 characters (minus the two allocated to shifting).
The 5-bit code used by these early teletypes was quite a
bit different
than Morse code.
Each bit could be only a one or a zero, and always occupied the same amount of time.
Samuel Morse used a different combination of characters (dots and dashes) in each string, and seperates the two possible elements by length (a dash is three times as long as a dot).
A 5 bit code just isn’t complex enough for modern computing applications. Baudot was eventually replaced by ASCII, though this took a very long time and a lot of other failed attempts.
Thankfully the CRT (an old operating system) terminal was soon devised, it's screen behaved as a digital version of the outdated mechanical teletype.
RS-232 defines signal levels, transfer parameters, and cabling for serial communications over short (under about 15 metre) distances. RS-232 communications is always serial, taking place one bit at a time. Each of the 8 bits of a byte are purposely sent out over a single pair of wires in a specific order: the least significant bit goes first, followed by bit 1, etc. If we look at it, we realize that our modern communication method is no more than a slight upgrade over the Von Steinheil's ancient compass needles.
All RS-232 communications takes place at a baud rate agreed on by both the driver(sender unit) and receiver. 9600 baud means that each bit of the character stream takes 1/9600 second to transmit - about 100 microseconds. Since the transmitter doesn’t use a clock or other timing information, it's up to the receiver to figure out when to sample the stream to determine if an individual bit is a one or a zero.
This means that if the transmitter and receiver are each set to different baud rates, the receiver will never sample the input stream at the correct time. Every character starts with a "start" bit - the transmitter drives the line to a logic one state for exactly one bit period (e.g., at 9600 baud, 1/9600 second). Bit zero follows. To prevent one character running into another a stop bit - a logic zero - follows the character.
Stop bits look like an idle line and give the receiver time to recover before the next character starts. The RS-232 protocol defines 25 signals used to transmit data and control the communications channel. It is uncommon to use all of these, which is one source of grief with connecting serial devices – it seems that each device requires a different number of the signals.
Many embedded systems save wiring by using a simple three-wire connection: ground, transmit data, and receive data. Software handshaking (integrating so that it works) uses the X-on and X-off characters, transmitted by the receiver to throttle the transmitter.
You can even feed both data directions onto a single phone line pair (data bus), permitting world-wide communications over the existing phone system. There's only one problem. Computer busses are wide. Even a small computer moves data around in 8 bit chunks. This means that to do this, either the processor must painstakingly convert each character to and from a bit stream, or we have to add hardware to do the work automatically.
In fact, virtually every system does use hardware. The UART (Universal Asynchronous Receiver/Transmitter) or USART (Universal Synchronous/Asynchronous Receiver/Transmitter) is a chip that does this conversion for you. Asynchronous transmission is what we've just been looking at: the characters move at a pace determined by the baud rate. Therefor both baud rates must match (sender and receiver) in order for the system to work.
Synchronous transmission needs an external clocking source, one that is often transmitted on an additional wire. UARTs were some of the earliest integrated devices. They are complex components (thousands of transistors), this is not something that would be easy to create out of ordinary components. A single UART handles both transmission and reception of data. Shift registers convert between the parallel computer data and the serial stream, with start, stop and parity bits. Most of the trouble with shift registers lies in figuring out exactly when to take a sample from a received data stream. We can say that the chips generate the timing signals that allow them to do this.
Now that we know a little about the history of electronic communications, we can look at the specific type of data that we will be dealing with. This is know as RS-485 and is similar to RS232. There are a few main differences which are explained within the next few pages.
Display
An LCD display
will be incorporated into the design, this display will show the packets
of data that have been received as well as the voltage levels on the bus.
For our prototype we will be using a 2-line 16-character display which
will work on the Warden call systems (A TyneTec product). However if the
RS-485 data integrity inspection unit is to be universal a larger display
will be necessary to allow viewing of the larger packets used by the door
entry and fire detection systems. The screen will be a standard TyneTec
component
Microcontroller
TyneTec will
specify the Microcontroller, however, for development purposes a stamp
MCU will be used to develop the software.
RS-485 data reception
The standard
TyneTec RS-485 data reception setup will be incorporated into the design,
this includes RS-485 serial data conversion and transient protection.
RS-485 Voltage level detect
A circuit will
be designed that will have a very high input impedance (around 1M) that
will allow data to be read into the MCU without detrimental effects to
the RS-485 bus. This input is analogue so will first be passed through
an Analogue to Digital converter to allow the voltage to be read by the
MCU.
Battery Monitor
Tynetec’s standard
battery and charger circuit will be used. A battery voltage monitor will
also be necessary that will warn the user if the battery voltage drops
to an unacceptable level.
Keypad
A keypad will
be needed to allow the user to perform functions on the RS-485 data integrity
inspection unit i.e. capture and hold facility. This keypad will be supplied
by TyneTec and will be one of there standard components.
RS-485 Voltage level indicator
This will be
displayed on-screen from the voltage level detector showing the voltage
levels of the RS-485 bus.
Data memory
A small amount of non-volatile memory will be required on the unit to allow data settings to be stored permanently. TyneTec will supply this.
Packet Format & Serial transmission/Reception
Below is the standard 8-byte data packet that we will be receiving with our unit, the format is the same for both poll and acknowledge packets.
SOH cmd id id id csum csum EOT
All data within the byte format is in ASCII file format (i.e. 9-39)
Each poll packet to the intercom will comprise of 8 bytes made up as follows:
Start byte:
01(SOH)
Command byte:
A,B,C,D,E,F,H,-& - (Command byte function codes)
3 id bytes:
0-256(intercom id)
Stop byte:
04(EOT)
Each acknowledge packet is the same with the one exception of the command byte which is in lowercase.
The packet being
transmitted down a RS-485 bus will look like the diagram below.
This diagram is of 1 packet (8 bits being transmitted using RS-485 protocol)
As you can see from the diagram above each bit is transmitted one after the other (serially) and each bit is transmitted for the same length of time (1 bit time) this bit time frequency is called the BAUD Rate. Typical baud rates are 1200, 2400, 4800, 9600, and 19200.
If for example,
the baud rate were 9600 for a system, each bit time would be equal to:
1/9600 = 104.16667microseconds
So the baud
rate itself is the amount of bits that can be transmitted in one second
and the reciprocal of that value is the bit time.
Every byte
that is transmitted has a start bit and a stop bit (Marked as S and E on
the diagram) these conditions are used by the device receiving the data
in the following way.
Start bit:
When the receive
line drops low the receiving device knows that data is about to be received
and therefore allows enough time for the receiving device to synchronize
itself with the data.
Stop bit:
When the receiving
device has received all 8 bits and the receive line is driven high again
the receiving device knows that this byte is complete and uses the time
of the stop bit to prepare itself for the next byte that will be received,
if there is one. It should be pointed out that if more than one byte is
being transmitted the time between the final bit transmitted and the next
start bit may be more than one bit time i.e. the stop bit may be longer
than one bit time.
Home
Acknowledgements
Design Brief
Technical Details
Residential
Pictures