As with all of my experiments/posts, I research and hack in order to learn. In one of my side projects, and a future post to be, I was tinkering with RF wireless broadcasting and discovered an interesting pair of ICs that I wanted to share with you. The ICs are the HT12A and HT12D. Individually, they are concerned with serializing and deserializing data respectively. Together they enable the transmission and reception between specific addresses which in the world of machine-to-machine is significant.

These ICs are commonly utilized with 433Mhz RF transmission, however for the purpose of this article, I will remove the extraneous components and instead tether the two ICs together directly using lead wires.

The encoder/decoder that I am using is part of the 2^12 series from Holtek, which are labeled HT12A and HT12D respectively. The 12 refers the number of reserved bits that are used for communication. 4 bits are used to represent the transmitted data while, 8 bits convey the intended address.

The circuit shown below comprises our HT12D decoder, ( located on the left), an HT12A encoder (located on the right), a 5 volt linear regulator to drive the ICs, 4 LEDs and 3 DIP switches.

The 5 Volt Linear Regulator has little to do with the communication between these two ICs, and more to do with ensuring a steady and maximum flow of 5 Volts to the circuit as the ICs have a maxim rating of 5 Volts.

The two Blue dip switches are there to specify an address. From the perspective of the broadcaster, the HT12A, the address does not represent its address but rather the address for which decoder the data is intended. The use of 8 bits enables our HT12A to broadcast data to a total of 256 (2^8) unique devices or networks of devices. Needless to say that is quite a bit. Contrary to the HT12A, and from the perspective of the Decoder, the HT12D, the dip switch is used to specify its address or 'identify' if you will. In order for the HT12D to receive a message from the HT12A, the address specified by the HT12A must match that of the HT12D. If the message sent by the HT12A is intended for a decoder not shown here, then those two addresses must match and so forth.

The remaining components in the circuit, the 4 LEDs, are used solely to visualize the transmitted 4 bits of data.

An important thing to note, is that the HT12D latches data, meaning that the data received will be retained until that data is replaced or flushed. This will be apparent in the shakey BlairWitch esque found footage demonstrating the behavior of the HT12A & HT12D.

You may have noticed that the setup in the video varies slightly from what was in the image above. This is due to the fact that at the time of recording I did not have a 4 bit DIP, requiring me to use a second 8 bit DIP to represent the data. Regardless of the difference in presentation the behavior is exactly as previously mentioned. The video begins with all DIPs in the OFF position or more technically in the 0 position. This is a critical distinction because while the LEDs are currently off, our HT12A and HT12D are not. In fact they are actively communicating over address 0, and what they are communicating to one another is 0 for all 4 bits.

The video proceeds to display LEDs being toggled the moment I change the state on the first of the two DIP switches on the right. This DIP represents the DATA to transmit. Making a change here is encoded by the HT12A and then communicated to the HT12D that possesses the address 0. As long as the address specified by the encoder match that of the receiver, then the data will be received. This behavior can be witness around 21 seconds into the video where I flip the very last bit to that of 1 on the encoder specifying a different address than that of the decoder. This causes the next data update to have no immediate effect on the LEDs. That is until I update the decoder address to match the transmitted address. While this demonstration made use of 1 decoder, I certainly could have added 256 or even more. Due to the addressing behavior of the components the HT12A can transmit to a singular device or even a cluster of devices.