Reading time : Less than 30 minutes
Its been a while I was thinking to post an article about broadcast receivers. I have done a number of projects which makes extensive use of broadcast receivers. There are a number of use cases where broadcast receivers are highly usable as well. Lets see how broadcast receivers can be made use of in Android. In layman terms, broadcasts are like a message that is sent across the entire system. Anyone with the appropriate address and permission can read the broadcast-ed message. For the sake of simplicity, I’m dropping out the concept of permissions. Basically you can catch broadcasts using a Broadcast Receiver with correct address or action as called by Android guys :). The word address in the context of broadcast receivers refers to an Intent Filter, by means of which, anyone can receive broadcasts that comes under that filter. Lets start with Intent Filters. Intent Filters can be defined in your Android application in two ways.
Note, that you cannot typically use an Intent Filter defined in the manifest through any Java files or vice versa. Or atleast I don’t know if that is possible. Anyway, it is safe to say that, you can use Intent filters defined in your java files to create broadcast receivers that has an Activity scope, and you can use manifest based filters to create receivers that has the Application context. So it turns out that, you can create two types of broadcast receivers.
To enable a broadcast receiver, you need to register it per se. As explained above, you can register it for the entire application by registering it through the manifest file, or you can register it inside any activities you need to receive broadcasts. Before going into depths of the same, lets see how to send a simple broadcast.
Ok, there is a hell lot of variants for the broadcast sending function. For now, lets check out the simplest one, that is sendBroadcast(Intent intent). This method takes an intent as the parameter. Lets see how this can used in a typical condition.
This is simple huh? It sends a simple broadcast with an action string ACTION_HELLO as the so called address. This simply means that, any broadcast receiver with intent filter set to ACTION_HELLO can receive this broadcast. Lets create such a broadcast receiver.
Ok, it still doesn’t says what intent filter this receive is planning to use. So we have to enable or register this broadcast receiver to do that. As we have seen earlier, we can register it for the entire application or we can register it for just one activity. For registering it for the entire application, you need to add the corresponding entry into the manifest, inside the <application> tag.
And for doing the same inside an activity, you can do it simply as follows. Remember, this particular receiver will work only if the activity is visible and it cannot receive any broadcasts if the activity is not in the foreground.
Ok, this part needs a little bit of explanation. We may simply register this receiver in the onCreate() itself. But in that case, there is a risk of leaking memory if the activity is killed or has moved to the background. To avoid this, I register the receiver inside the onResume() and safely unregister the same from inside the onPause(). As you might know, onPause() will be triggered when the activity is about to go to the background. A complete sample project is available here for downloading and testing out broadcast receivers.
Reading Time : Less than 10 minutes
Lately I was onto more experiments with the 433Mhz serial communication modules. I have purchased two different pairs of 433 modules which is shown in the image below.
My initial plan was to use a pair of encoder and decoder from Holtek to connect the two end-points to peripherals. Infact, that is just a cost effective method to implement remote controlled applications such as car-locks or automatic-gates. Those ICs are indeed not very flexible in the sense that, if we want to connect a large number of devices through this channel, it is quite difficult. Holtek’s (en)decoders provides upto 12 bits to be transmitted over to the other end. Out of which atleast 8 bits are address bits, and the remaining can be used as data bits. Generally these ICs provides, 2^12 = 4096 devices to be linked through this channel. But the problem with this implementation is that, if all the 12 bits are used to address devices, then there is no room for sending the actual data. If we take N bits out of 12 for sending data, the number of devices that we can handle, shrinks to 2^(12-N). That is, suppose if we send 4 bits of data in every trigger, the number of devices we can handle at the same time is, as small as 256.
One way to get around this problem, when we use N bits for data, is to keep the address bits the same, and send the actual data in chunks of N bits. Say for example, suppose we have to send the following stream of bits to a remote device,
1010 1010 1000 0101 1110
Say we have N = 4, the idea is to send it as follows. Please notice that the first 8 bits are the address of this particular device.
This looks promising, but one question remains. How these chunks of data will be concatenated at the receiving end? So basically, it turns out that we need a Microcontroller for doing this. Well, then another question pops up, If we have a Microcontroller, then why should we use these limited 12-bit junk from Holtek?
This is exactly what I’m thinking right now. I have done some preliminary experiments with the 433Mhz modules and an Arduino here. Generally we can send square waves through these modules as it is. I have tried running the following simple sketch on it and I got the exact same signal on the other end,. It is worth noting that, there is some minor noise bursts observed in one receiver module’s output. No big deal, just a side note.
There is one more significant problem remaining here to be solved. When there is no signal available at the receiving end, the 433Mhz receiver produces garbage square wave. So, how do we find when to listen for the actual data and how it is interpreted? The simplest answer to this problem is that, We implement a protocol for it! Ok, we need a protocol to send the signal over to a device, so that it can identify actually when it receives a command and what exactly is the command it just received. I’m going through different serial protocols right now. I will surely pickup one of them, or in the worst case “invent” one of my own. Either way, I will post about it in the next article.
Reading time : Less than 5 Mniutes
Holtek produces a number of encoders and decoders to be used in minimal remote control applications. I’m about to work on a project that involves some basic RF remote control circuit. As the preliminary research starts, I came across an RF transmitter module which does not support direct serial data transmission. We have to use encoders like the HT12E for giving proper input to the module. The RF transmitter I have just uses 433Mhz ASK. For it, to be used as a remote control, we need to encode our parallel data into serial burst data. HT12E just got my attention because it was known to me long before. With an oscilloscope here, I wired up and tested the following circuit.
The output includes 8 address bits and 4 data bits. As per the data sheet, a logical ZERO is represented as one part low and two part high out of 3 timing cycles, and logical ONE is represented as two part low and one part high out of the same.
The output as observed on the oscilloscope follows. For the testing purposes, I have give 1010 as the 4-bit test data through the Arduino. Please note that, I pulled off one of the address lines (bit number 3) to ground to just check if the code gets transmitter properly. First bit in the burst is the start bit.
HT12E has a variant named HT12A, which does also have a 38Khz carrier frequency. Although it makes 12A ideal for infrared remote control applications, it requires external oscillator to provide timing signals. If possible, I will be posting some 12A experiments and the decoder series ICs (HT12D/F) from the same manufacturer. Decoder ICs are required at the receiver end of this particular RF link.
Have a nice day!