In an earlier post on my website I detailed a PIC microcontroller project that allowed me to capture information about a variety of RF security system sensors I have. In this post I have taken the information I collected for a cheap 433-MHz motion detector I bought on ebay and turned it into a usable circuit. In addition to the PIC, I use an RF receiver module and a solid state voice recorder/player. All of the parts, including the motion detector, cost less than $15 total so you can have some cheap fun with this project.
The motion detector module I used looks like the picture above. It uses a 12 volt battery and has an extendable whip antenna. The RF signal it puts out is strong enough that I didn’t even have to add an antenna to my RF receiver board for use in my house. I used a sensor logger circuit (detailed in another project on my website) to determine the sync and bit times for the sensor as well as the actual data bytes. The sensor outputs 24 bits (3 bytes) of data and each sensor has a different pattern. There is also one stop bit. The sync time turned out to be 10ms and the bit times were about 320us and 970us. I verified this with a second sensor and also by capturing the RF receiver output on my oscilloscope. There are many examples online that detail how to capture this information using a PC audio card.
The RF receiver module I prefer is a super heterodyne receiver called the RXB6. It has much better range than the cheaper receivers that commonly get paired with an RF transmitter module. In fact, when I was trying to buy a few extra RF transmitters I ended up buying them with the cheap receivers for less than 60 cents a set from a USA seller. I’ve kept the bad receivers for now but will likely never use them.
The sound recorder/player module is commonly listed as ISD1820. That’s actually the chip part number but it’s also the module designation. The particular version I bought is shown in the picture but pretty much all of them work the same. It’s convenient to have the push buttons on the module so you can do the recording and verify the playback before embedding it into your circuit. These modules are typically set up for a maximum of 10 seconds of recording but the manual shows how to modify them for shorter or longer times. The maximum time is 20 seconds but the tradeoff is lower quality. It’s probably not a problem for simple voice messages. I was pleasantly surprised at the clarity of the recording.
The schematic is shown above. The sound modules are often advertised as being able to run on 5 volts but the recommended range for the chip is 2.7-4.5 volts. Just to be safe I’ve added a cheap 3.3 volt regulator (LM1117) to drive the sound module. That also means that the play trigger from the PIC needs to be reduced in voltage so a simple resistor voltage divider is used. The resistor values are not critical. Just try to get the ratio of values to about 2:3.
There are some defines in the first part of the software that may need adjustment for your application. There are defines for the sync time (in milliseconds) and the 0/1 bit times. The bit times are actually for the OFF part of each bit because that is how the software does the measurement. The bit times are not in milliseconds but are the expected count for the upper half of Timer1. Each count in TMR1H represents 128 microseconds based on the 8-MHz clock frequency of the PIC. This simplification works because the shorter bit time will always exceed 256 microseconds but never exceed 384 microseconds. Likewise, the longer bit time will always exceed 896 microseconds but never exceed 1024 microseconds. Again, this is based on measurements I made for my sensors. Yours may be different. Another set of defines is included to represent the byte values transmitted by the sensor. These will be different for your sensor.
The software uses the 16-bit Timer1 to measure the sensor bit durations by counting only during the low level part of each bit. That meant that I needed to use the T1G (Timer1 Gate) input of the PIC. I also wanted to check on the pulse counts when they completed so I used the INT (external interrupt) input and set it to trigger on a rising edge. Each bit (including the stop bit) always starts with a rising edge. The bit value (0/1) is determined by the duration of the high part of each bit but we actually measure the low part because we also want to measure the low level time between data messages for the sync.
The interrupt handler is triggered by the rising edge of each bit. At that point the upper half of Timer1 is read. If the Synced flag is not yet set, then the software determines if we have measured a sync pulse. The math is easy because all we do is round up (add 4) and then right shift three times (divide by 8). That gives us the integer number of milliseconds. If the value matches our required sync time then the Synced flag gets set. That allows us to skip directly to the bit measurement part of the code for subsequent interrupts. If a bit time matches, then it is packed into RF_Byte and the Bit_Found flag gets set. If a bit time doesn’t match then everything previously collected is discarded and we wait for a new sync pulse.
After the return from an interrupt, the main part of the software checks the Bit_Found flag to determine if it needs to take action. If a complete byte has been received then the software checks the value against the expected value for the sensor. That is done by calling a simple lookup table with the indices for the table being the variable Byte_Count. If a byte doesn’t match, then everything is discarded and we wait for a new sync pulse. If all three bytes have been received and match, then the software sends a high-level pulse to trigger the sound module. An Alarm LED is also turned on and remains on until power is cycled. The reason I added that is to facilitate testing and as an event memory. That way I can position the sensor and receiver at different locations and verify successful operation without having to use a second person to listen for the sound. I can also test sensor locations to make sure that heater/cooler air flow or one of our cats doesn’t cause a false trigger. That’s it for this project. be sure to check out my other projects on my website: boomerrules.com