ENCODER AND DECODER
Encoder:
An encoder is a device used to change a signal (such as a bitstream) or data into a code. The code may serve any of a number of purposes such as compressing information for transmission or storage, encrypting or adding redundancies to the input code, or translating from one code to another. In digital electronics this would mean that a decoder is a multiple-input, multiple-output logic circuit(2n-n).
 |
| The back side of the wheel and encoder showing the encoder disk. |
 |
| connect a mechanical relative encoder to make simple experiments |
Decoder:
A decoder is a device which does the reverse of an encoder, undoing the encoding so that the original information can be retrieved. The same method used to encode is usually just reversed in order to decode. In digital electronics this would mean that a decoder is a multiple-input, multiple-output logic circuit(n-2n).
HT12E Features:
· Operating voltage
· 2.4V~5V for the HT12A
· 2.4V~12V for the HT12E
· Low power and high noise immunity CMOS technology
· Low standby current: 0.1_A (type.) at VDD=5V
· HT12A with a 38kHz carrier for infrared transmission medium
· Minimum transmission word
· Four words for the HT12E
· One word for the HT12A
· Built-in oscillator needs only 5% resistor
· Data code has positive polarity
· Minimal external components
· HT12A/E: 18-PIN DIP/20-PIN SOP package
The 212 encoders are a series of CMOS LSIs for remote control system applications. They are capable of encoding information which consists of N address bits and 12N data bits. Each address/ data input can be set to one of the two logic states. The programmed addresses/data are transmitted together with the header bits via an RF or an infrared transmission medium upon receipt of a trigger signal. The capability to select a TE trigger on the HT12E or a DATA trigger on the HT12A further enhances the application flexibility of the 212 series of encoders. The HT12A additionally provides a 38 kHz carrier for infrared systems.
 |
| Universal FSK Decoder - Character Translation Table |
Objectives:
The objectives of this experiment are to:
1. use decoders and multiplexers, and
2. to implement larger decoders/multiplexers from smaller ones
Procedure:
Use Multisim or Electronics Workbench (EWB) to solve the following exercises.
Exercise 1:
(a) In Multisim place a 74S139D (74S Family) 2-to-4 decoder on the breadboard. Then select the component and use the F1 (help file) function to find out information about the component.
(b) Complete Table 1 below with the information provided for the 74S139D. Determine whether the outputs (Y0-Y3) and enable (
Table 1. 2-to-4 decoder truth table with Enable (~G). Active: Low/High.
A
|
B
|
Y0
|
Y1
|
Y2
|
Y3
| |
0
|
0
|
0
| ||||
0
|
0
|
1
| ||||
0
|
1
|
0
| ||||
0
|
1
|
1
| ||||
1
|
0
|
0
| ||||
1
|
0
|
1
| ||||
1
|
1
|
0
| ||||
1
|
1
|
1
|
2. INPUT/OUTPUT DATA
2.1 Input Data
The following data sets serve as input to the SHEF Decoder application:
1) SHEF-Encoded Products - Text files containing the actual SHEF-encoded data to be decoded, processed, and posted to the database. These files are contained in the directory defined by the application token shef_data_dir (tokens are discussed below). A special file, called a stop file, may also be located in this same directory. When present, this file directs the application to cease execution.
2) SHEF Application Settings - A collection of tokens and their settings, which are defined in text files referred to as application defaults (Apps_defaults) files. These token values are expected to change rarely once they are configured for a particular office. Tokens are described in a later section of this document.
3) SHEF Parameters - A text file containing the recognized values of the SHEF attributes associated with each value; e.g. the allowable SHEF physical element codes. This file is provided with the application and is not expected to change. Its name is SHEFPARM and it is contained in the directory defined by the application token shefdecode_input.
The units used for the physical element’s values that are encoded in the raw SHEF products are specified in the 10-944 Directive. The decoded data are stored in these same units for almost all physical elements, with a few exceptions, as discussed in the Data Adjustment operations section.
The units used for the physical element’s values that are encoded in the raw SHEF products are specified in the 10-944 Directive. The decoded data are stored in these same units for almost all physical elements, with a few exceptions, as discussed in the Data Adjustment operations section.
4) IHFS Database - The IHFS database is a relational database implemented in the Postgres database environment provided on AWIPS workstations. The database contains assorted switches associated with a given station or area that control how the decoded SHEF information should be processed by the SHEF Decoder.
Some examples of the input data from the database are: station location and area identifiers and definitions; data ingest switches indicating whether to process this specific data; thresholds used for quality control operations; factors used for numerically adjusting the values; and information on how to retain information on the products themselves. Details on the specific tables read from are presented later in this document.
2.2 Output Data
The following data sets are generated by the SHEF Decoder application:
1) IHFS Database - The IHFS database receives the decoded data and represents the primary output of the SHEF Decoder. The data are organized in the IHFS database based on the SHEF attributes of the data, i.e. the SHEF physical element, duration, type-source, duration, and extremum values, in addition to the station identifier and the time of the data, and possibly the forecast issuance time. Details on the specific tables written to are presented later in this document.
2) Decoded Output - A binary file, for temporary use, that contains the decoded general form of the SHEF data file. It is generated by the parser component of the application and is read by the posting component. After each product=s data are posted, this file is removed. This file is named SHEFOUT, and is stored in the same directory location as the SHEF-encoded data files.
3) Hourly Precipitation Output – A text file containing any precipitation data that can be used to represent hourly precipitation data, assuming this option is enabled.. Specifically, it contains data with a physical element of PP that is one-hour in duration, and data with a physical element of PC that is near the top-of-the-hour. These data are buffered as each product is processed and after processing the product, the file is forwarded to the directory designated for reading by the Gage Precipitation Processing (GPP) server.
4) Daily Program Logs - A text file containing a running daily log that summarizes the application processing. For each product, about a dozen lines are written to the log file which summarize the product processing. Also, whenever the application is started, it writes the values of the control settings it has read to the log file. The log files are named shef_decode_log_MMDD, where MMDD is the month-day, and are contained in the directory defined by the application token shef_decode_log.
a. Product Logs - A text file containing a log that provides a detailed summary of the processing of a single product. This log contains a copy of the input SHEF-encoded data; any errors that may have occurred during the parsing process are written immediately after the line in the product that caused the error. It also includes information regarding the posting operations performed on the data and the same summary information that is logged to the daily log file. The log files are named PRODUCTID.MMDD.HHMMSS, where PRODUCTID is the product id and MMDD and HHMMSS, are the month-day, and hour-minute-seconds of the product as read from the product header. These files are contained in the directory defined by the application token shef_error_dir.
PIN A0-A7: Input pins for address A0~A7 setting
PIN AD8~AD11: Input pins for address/data AD8~AD11 setting
PIN D8~D11: Input pins for data D8~D11 setting and transmission enable, active low
PIN DOUT: Encoder data serial transmission output
PIN L/MB: Latch/Momentary transmission format selection PIN:
PIN : Transmission enable, active low
PIN OSC1: Oscillator input pin.
PIN OSC2: Oscillator output pin.
PIN X1: 455 kHz resonator oscillator input.
PIN X2: 455 kHz resonator oscillator output
PIN VSS: Negative power supply, grounds
PIN VDD: Positive power supply
Functional Description
Operation
The 212 series of encoders begin a 4-word transmission cycle upon receipt of a transmission enable (TE for the HT12E or D8~D11 for the HT12A, active low). This cycle will repeat itself as long as the transmission enable (TE or D8~D11) is held low. Once the transmission enables returns high the encoder output completes its final cycle and then stops as shown below.
Information word
If L/MB=1 the device is in the latch mode (for use with the latch type of data decoders). When the transmission enable is removed during a transmission, the DOUT pin outputs a complete word and then stops. On the other hand, if L/MB=0 the device is in the momentary mode (for use with the momentary type of data decoders). When the transmission enable is removed during a transmission, the DOUT outputs a complete word and then adds 7 words all with the ‘1’ data code.
Address/data waveform
Each programmable address/data PIN can be externally set to one of the following two logic states as shown below.
Address/data programming (preset)
The status of each address/data pin can be individually pre-set to logic “high” or ”low”. If a transmission - enable signal is applied, the encoder scans and transmits the status of the 12 bits of address/ data serially in the order A0 to AD11 for the HT12E encoder and A0 to D11 for the HT12A encoder. During information transmission these bits are transmitted with a preceding synchronization bit. If the trigger signal is not applied, the chip enters the standby mode and consumes a reduced current of less than 1µA for a supply voltage of 5V. Usual applications preset the address pins with individual security codes using DIP switches or PCB wiring, while the data is selected by push buttons or electronic switches.
HT12D FEATURES:
· Operating voltage: 2.4V~12V
· Low power and high noise immunity CMOS technology
· Low standby current
· Capable of decoding 12 bits of information
· Pair with Holtek’s 212 series of encoders
· Binary address setting
· Received codes are checked 3 times
· Address/Data number combination
· HT12D: 8 address bits and 4 data bits
· HT12F: 12 address bits only
· Built-in oscillator needs only 5% resistor
· Valid transmission indicator
· Easy interface with an RF or an infrared transmission medium
· Minimal external components
The 212 decoders are a series of CMOS LSIs for remote control system applications. They are paired with Holtek’s 212 series of encoders. For proper operation, a pair of encoder/decoder with the same number of addresses and data format should be chosen. The decoders receive serial addresses and data from a programmed 212 series of encoders that are transmitted by a carrier using an RF or an IR transmission medium. They compare the serial input data three times continuously with their local addresses. If no error or unmatched codes are found, the input data codes are decoded and then transferred to the output pins. The VT pin also goes high to indicate a valid transmission.
The 212 series of decoders are capable of decoding the information that consists of N bits of address and 12_N bits of data. Of this series, the HT12D is arranged to provide 8 address bits and 4 data bits, and HT12F is used to decode 12 bits of address information.
PIN DESCRIPTION:
PIN A0~A11: Input pins for address A0~A11 setting
PIN D8~D11: Output data pins
PIN DIN: Serial data input pin
PIN VT: Valid transmission, active high
PIN OSC1: Oscillator input pin
PIN OSC2: Oscillator output pin
PIN VSS: Negative power supply (GND)
PIN VDD: Positive power supply
Functional Description
Operation
The 212 series of decoders provides various combinations of addresses and data pins in different packages so as to pair with the 212 series of encoders. The decoders receive data that are transmitted by an encoder and interpret the first N bits of code period as addresses and the last 12_N bits as data, where N is the address code number. A signal on the DIN pin activates the oscillator which in turn decodes the incoming address and data. The decoders will then check the received address three times continuously. If the received address codes all match the contents of the decoder’s local address, the 12_N bits of data are decoded to activate the output pins and the VT pin is set high to indicate a valid transmission. This will last unless the address code is incorrect or no signal is received. The output of the VT pin is high only when the transmission is valid. Otherwise it is always low.
Of the 212 series of decoders, the HT12F has no data output pin but its VT pin can be used as a momentary data output. The HT12D, on the other hand, provides 4 latch type data pins whose data remain unchanged until new data are received.
Specifications:
For this assignment you will make a Decoder class that encodes and decodes messages.
Your class should have three methods:
1. A constructor. This takes one parameter, a key. The type of the key (String? int? Array?) is up to you. The only requirement is that if a message is encoded by an instance of Decoder that was created with a certain key, then an instance created with the same key must faithfully decode the message. However, it must be extremely unlikely that an instance created with a different key can successfully decode the message.
2. An encode method. This accepts a string as a parameter, and returns a String which will be an encoding of the message passed in.
public String encode(String message)
3. A decode method. This accepts a string as a parameter, which will be a message encoded by an instance of the decode class. It returns a string, which should be the decoded version of the message, providing the instance on which decode is called was created with the same key that the instance that decoded the message.
public String decode(String message)
Example:
// Create a decoder with the key 12345
Decoder encoder = new Decoder(12345);
// Encode a message
String message = “I have a dream”;
String encoded = encoder.encode(message);
//Create a new Decoder with the wrong key
//and try to decode the message
Decoder badDecoder = new Decoder(54321);
String decoded = badDecoder.decode(encoded);
System.out.println(decoded);
//Prints S dSIc S ywcSU. Did not successfully decode
//Create a new decoder with the right key and try again.
Decoder goodDecoder = new Decoder(12345);
String decoded = goodDecoder.decode(encoded);
System.out.println(decoded);
//Prints I have a dream. Did successfully decode
Image and Graphics Decoder
When you are decoding an image or graphic you are explaining how an illustrator or photographer has constructed an image for a particular effect. When you decode (deconstruct) an image you need to refer to some of the following features or techniques:
· Body language: examine facial expressions, gestures, stance or position as these features can convey the attitude, feelings or personality of the individual being drawn or photographed.
· Colour and tone: In a black and white image examine the use of contrast, light and darkness. In a colour image, colours are used to signify feelings and evoke a response e.g. red conveys passion, anger, danger, vitality, whereas blue can convey peace, harmony or cold.
· Composition: What is included in a visual is usually deliberately placed there or included. This also applies to what the composer has omitted. Therefore, consider all inclusions and omissions such as: surroundings, objects, clothing, etc. e.g. Ominous, large storm clouds placed strategically behind a boat could signify danger or a wire fence in front of a small child in a detention centre could symbolise imprisonment or even a concentration camp. Size and position of objects is another important consideration e.g. A photograph of a large person looming over a small person could signify the vulnerability of the smaller person.
· Framing: The same camera shots and angles relevant to film are applicable to visuals: close ups, extreme close ups, medium shots, long shots, tilted up or down.
· Intertextuality: some images appropriate (borrow) images or ideas from other texts to entertain or make a satirical comment.
· Rule of thirds: used by the great Dutch painters the rule of thirds can be useful for some images. Divide an image into thirds from the top and sides and look at the placement of people and / or objects. Anything in the top third is empowered whereas anything in the bottom third is disempowered. The correct terminology is background (top third), midground (middle ground), foreground (lowest third).
· Vectors: this refers to the line that our eyes take when we look at a visual e.g. if all of the subjects are tall, long and upright, our eyes follow straight vectors that lead to the top of the frame. This could make the subject seem powerful or inflexible. Look at peoples’ or characters’ eyes: what are they looking at? Is this significant? Direct eye contact can suggest confidence or appealing for help, looking beyond the viewer can mean daydreaming, wondering. It depends on the context, the expression on the face, the expression in the eyes.
1.0 FECC
A digital communication system is depicted in Figure 1. Data is generated at a constant source symbol rate Rs source symbols per second. The source output is encoded by a source encoder such as ASCII code or Hoffman code. The output of the source encoder is fed to the channel encoder for forward error correction coding. A linear block code such as Bose-Hockengham-Chadhuri (BCH), or Reed Solomon (RS), or a convolutional encoder is normally used before the data is sent to the modulator, and out to the antenna. The receiver performs the reverse of the transmitter.
1.1 (7,4) BCH Encoder
In GF(23), there is only one possible BCH code, it is (7,4) with t=1, and its code polynomial generator g(x) is given by:
g(x) = LCM{ m1(x), … m2t -1(x) }=LCM{ m1(x) }
g(x)= x3+x+1
The circuit consists of a shift register-Exclusive OR circuit with taps governed by g(x) in order to generate the third order parity polynomial by diving the k bit polynomial by g(x), then appending the parity bits to the end of the m bits. This is shown in Figure 9 below. The k bits proceed to the output and to the input of the parity generator circuit. After 4 shifts the switch 1 is moved to position B, and Switch 2 is opened, and the computed parity bits are sent to the output. The circuit is then ready for the next input block.
The 15 4-bit data blocks and their respective 15 7-bit BCH encoded blocks for the above single bit error correcting (7,4) BCH encoder are given in Tabl2 4.
m(x)
|
C(x)
| ||||||||||
m0
|
m1
|
m2
|
m3
|
c0
|
c1
|
c2
|
c3
|
c4
|
c5
|
c6
| |
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
| |
0
|
0
|
0
|
1
|
0
|
0
|
0
|
1
|
0
|
1
|
1
| |
0
|
0
|
1
|
0
|
0
|
0
|
1
|
0
|
1
|
1
|
0
| |
0
|
0
|
1
|
1
|
0
|
0
|
1
|
1
|
1
|
0
|
1
| |
0
|
1
|
0
|
0
|
0
|
1
|
0
|
0
|
1
|
1
|
1
| |
0
|
1
|
0
|
1
|
0
|
1
|
0
|
1
|
1
|
0
|
0
| |
0
|
1
|
1
|
0
|
0
|
1
|
1
|
0
|
0
|
0
|
1
| |
0
|
1
|
1
|
1
|
0
|
1
|
1
|
1
|
0
|
1
|
0
| |
1
|
0
|
0
|
0
|
1
|
0
|
0
|
0
|
1
|
0
|
1
| |
1
|
0
|
0
|
1
|
1
|
0
|
0
|
1
|
1
|
1
|
0
| |
1
|
0
|
1
|
0
|
1
|
0
|
1
|
0
|
0
|
1
|
1
| |
1
|
0
|
1
|
1
|
1
|
0
|
1
|
1
|
0
|
0
|
0
| |
1
|
1
|
0
|
0
|
1
|
1
|
0
|
0
|
0
|
1
|
0
| |
1
|
1
|
0
|
1
|
1
|
1
|
0
|
1
|
0
|
0
|
1
| |
1
|
1
|
1
|
0
|
1
|
1
|
1
|
0
|
1
|
0
|
0
| |
1
|
1
|
1
|
1
|
1
|
1
|
1
|
1
|
1
|
1
|
1
| |
Table 5. (7,4) BCH encoded codewords
1.1 BCH codes in GF(24)
The possible BCH codes in GF(24) are (15,11) t=1, (15,7) t=2, (15,5) t=3
For example, the elements of (GF24), generated by a primitive polynomial given by:
P4(x) = 1 + x + x4
There are 16 field elements including 0. The rest of the elements are powers of a. These elements along with their conjugate, 4-tuples, and minimal polynomials are tabulated in Table 4 below.
Elements
|
Conjugates
|
3-tuples
|
Minimal polynomial
|
0
|
0 0000
| ||
a0 = 1
|
20 = 1 0001
| ||
a1 = a
|
a2 , a4 , a8
|
21 = 2 0010
| |
a2
|
a4 , a8, a
|
22 = 4 0100
| |
a3
|
a6, a12 , a9
|
23 = 8 1000
| |
a4 = 1+a
|
a8 , a, a2
|
0011
| |
a5 = a + a2
|
a10
|
0110
| |
a6 = a2+ a3
|
a12 , a9 , a3
|
1100
| |
a7 = 1+ a + a3
|
a14 ,a13, a11
|
1011
| |
a8 = 1+ a2
|
a , a2, a4
|
0101
| |
a9 = a + a3
|
a3 , a6, a12
|
1010
| |
a10 = 1+ a + a2
|
a5
|
0111
| |
a11 = a+ a2 + a3
|
a7, a13, a14
|
1110
| |
a12= 1+ a + a2 + a3
|
a3, a6 , a9
|
1111
| |
a13 = 1+ a2 + a3
|
a7, a11, a14
|
1101
| |
a14 = 1+ a3
|
a7 ,a11, a13
|
1001
|
2.0 BCH Decoder
There three basic operations involved in the decoding of BCH codes.
· Syndrome calculation
· Determination of the error location polynomial s(x)
· Computation of the roots of s(x) for the error location determination
The syndrome calculator involves polynomial division in GF, the error location polynomial is obtained using the Berlkamp algorithm, ant the root location calculations are done using the Chien search algorithm. The decoding process is depicted below.
The decoding process will be described using (15,5,3) BCH example. This triple error correcting code is generated by:
2.1 Syndrome calculator
The syndrome Si is the remainder of dividing the received code word with the corresponding minimal polynomial mi. The syndromes are zero if there are no errors in the codes. So if the intent is to detect error only a syndrome calculator is all that is needed in the decoder.
The transmitted codeword is obtained by appending the parity check bits to the message data bits. The parity polynomial (parity bits) is the remainder of the division of the message polynomial by the BCH code polynomial generator. The minimal polynomials are factors of the code polynomial generator. If no error occurred then the receiver codeword divided by any of the minimal polynomials will result in zero remainder. The remainder of the division of any received codeword by a minimal polynomial is called the SYNDROME. The number of minimal polynomials (number of syndromes) per code is equal to 2t. Where t is the number of error the code can correct. The syndrome calculator will generate the syndrome polynomial given by:
For the (7,4) BCH encoder above, n=7, k=4, and t=1, hence there are 2t =2 syndromes S1 and S2. This (7,4) BCH code has 2 minimal polynomials m1(t) and m3(t). S1 is the remainder of the division of the received codeword by m1 (x). S2 is the remainder of the division of the received codeword by m2 (x). The syndrome circuit is shown below, and the register contents at the end of each code word are the syndrome coefficient and are passed to the Berlkamp algorithm to start the error correction process if they are not all zero.
The Berlkamp algorithm forms the error location polynomial given below and iteratively finds its roots.
The Chien search computes the error locations from the roots of the error location polynomial.
The example shown in Figure 11 is with a single error in the 3rd bit position.
 |
| Add caption |
PRESENTED BY MRIGANK GAUR
EMAIL ID MRIGANKGAUR20@GMAIL.COM
No comments:
Post a Comment