This is a shortened translation from Russian of my article published in Радиомир (Radio World) magazine, no. 1 (2011) pp. 16-19 and no. 2 (2011) pp. 13-14. Due to numerous devices that may cause a danger in your house the owners usually install many sensors that raise alarm reporting various problems. However, most of the commercial devices indicate a trouble by just generating certain alarm frequency. If you have more than, say, 5 sensors, it becomes unclear which one went up and what does its buzz mean. It would me much better if a sensor could explain an alarm reason by playing back a pre-recorded phrase. This design uses some ideas from [1] and [2].
This device is intended to playing back a phrase recorded in advance as it senses water. The phrase can be recorded from built-in microphone or downloaded as a WAV file from computer via USB interface. Maximum duration of recording depends on installed memory chip and with the one shown on the schematic is about 16 sec. The device is very low power and draws just about 1.5 μA from the battery in the monitoring mode. The speaker amplifier mounted in a computer acoustic system is turning on only for the duration of playing phrase. Turning it on and off is accomplishes by a solid state relay K1 which powers off the entire electronics of the speaker box in the monitoring mode. Using a computer speaker provides necessary loudness to the alarm.
| Schematic | System view | |
Phrase recording from microphone starts with pressing the button SB1. This way the microphone amplifier DA1 gets power and the voltage on its output pin 8 raises from 0 to about 1.3V. The amplifier bandwidth of 4 kHz is provided by a low-pass filter R7-C8. The amplified signal is then digitized by the microcontroller ADC at sampling rate of 32 kHz. The digitized signal is further filtered out by a low-pass digital filter implemented in the microcontroller and decimated down to 8 Ksps. The decimated byte stream is loaded into the memory chip DD3.
To record a phrase from microphone one should first turn the device off, then push button SB1 and turn the device on by holding it. This was the microphone amplifier DA1 is activated and the DC voltage at its output raises up to ca, 1.3V (set by R2, R5). This voltage is measured by the ADC and if it above 1V, the microcontroller send an erase instruction to the memory chip DD3 and performs other initialization to prepare the device for recording. The recording itself starts by pushing the button SB2 and finishes upon its release. This way both buttons must be on for the entire recording time.
| Main board | Board in enclosure | Board layout | ||
If button SB1 is off right by powering the device up (which corresponds to a low level voltage at the output of DD1, the program checks for a request for recording via the USB interface. For this the user should push button SB2 prior to turning the device on. This leads to setting a logic 1 level on pin P1.0 which forces the microcontroller to wait for release of that button that signals a permission for a file transfer via USB. For this one needs (by holding the button) to plug in a USB cable to the device, whose other end should be attached to a working computer. This leads to initialization of the USB controller DD1 resulting to a 5V voltage at its output. This voltage is lowered down to 3.3V by R8, R9 voltage divider. Now, one can release the button and select a file for recording (more on the later). In either case - after recording from microphone of via USB - the device makes a control play of the recorded phrase and enters a waiting mode for a signal from sensor.
If none of the buttons SB1 and SB2 is on by powering the device up the microcontroller sets a logic 1 level at pin P1.1 which is used to activate the water sensor based on VT1. If there is no water presence the circuit draws just about 0.1μA from the battery. As soon as water appears at contacts of header XS1, the voltage at R12 raises from 0 up to 3.3V which generates an interrupt. This results to powering on the memory chip, reading the PCM data from it, and converting it into a PWM waveform at pin P2.6. This signal is then further processed by the low-pass filter on DA1 and is forwarded to the amplifier built into the computer speaker box.
After playing an alarm warning the device enters a water monitoring mode. In this mode it periodically (T=12sec) checks the water presence by powering the sensor up for a short time (about 0.1 sec) and checking its output. If the water is still present, it plays the alarm message again and waits for another check in 12 seconds. This time interval is provided by the watch dog timer. If the water is no more present, the device enters the main mode of waiting for a sensor interrupt.
The audio samples are extracted from memory at 8 kHz rate corresponding to the decimation rate. The microcontroller then raises this rate up to 32 kHz by using a linear interpolation as described in [1]. This way the PWM generator frequency is about 8 MHz, which is achieved by running the microcontroller at 16 MHz from internal oscillator.
The device is powered from a charge pump DC/DC converter DA4 whose quiescent current is just about 1.5 μA with no load. This way the entire current consumption in the main mode practically matches the one of the DC/DC converter. In this mode the op-amp and memory chip DD3 are switched off by the transistors of DA2. It is important to shut DD3 down, since it draws about 15 μA in sleep mode. By playing the alarm message the microcontroller sets logic 1 level at its output pin P1.4 which forces the solid state relay K1 to turn on. This relay is mounted inside the computer speaker box and is used to turn its electronics on and off. In this mode the device draws about 50 mA from the battery, from which about 30 mA are needed to control the relay. This way the current through the relay photo-diode is about 11 mA.
| Sensor module | Sensor layout | |
The device is assembled on a PCB designed with the help of Eagle system. Components of the water sensor are mounted on a small separate board which is connected to the main box by using an aluminum tube. The wire connecting the sensor board to the main one is layed out inside the tube. The microcontroller code is developed with IAR Embedded Workbench Kickstart version. The microcontroller is programmed by TI MSP-FET430UIF tool. However, a less expensive tool MSP-EXP430G2 could be used instead. In either case a special adapter is needed to adapt the device programming connector XS2 and the one of the programmer. If no USB interface is required, the chip DD2 with all related parts (excluding R10) can be omitted. Similarly, the voice amplifier could be attached to the circuit just for the time of recording. No changes to the microcontroller code are needed this way. The amplifier should provide a peak-to-peak AC signal of 2.5 V at the output.
The audio WAV files to be recorded via the USB interface should be in mono 8-bit uncompressed PCM format. The files must be first processed by the supplied convertWAV.exe utility. This utility checks the files for satisfying the above mentioned format requirements, extracts from them the "data" chunk and writes it to another file, which can then be transferred to the device via USB. More info on WAV files can be found in [3]. The utility is written on C and compiled in Visual Studio 2008. It has only a text-based interface. To use it one should place the EXE file to the folder on disk containing the audio file to record, and enter the following instruction in the text console window (cmd.exe):
convertWAV.exe file.wav file.dat
where file.wav is WAV file name with the phonogram and file.dat is desired output file name. The obtained file file.dat can be transferred to the device by using the standard Hyper Terminal utility in "Send Text File" mode. The virtual COM port must be configured for speed rate 38400 bod with 1 stop bit and no parity and no hardware control. Then one needs to setup a delay of 1 msec in Settings -> ASCII tab. The delay is needed to give the device a chance to record a received byte to memory before reading another one. Of course, the recording takes much less time, but Hyper Terminal does not support shorter delays. The actual file transmission speed will not be that high this way, but acceptable for short files.
One should mention that the output files of convertWAV utility are not text ones. Anyway, the Hyper Terminal can successfully manage them up to one exclusion. It turns out that if a transferring file contains a byte with numeric value 13 followed by one or more bytes with value 10 then the later ones are just dropped by Hyper Terminal ?!... To work around this issue the convertWAV changes the value of such bytes from 10 to 11, which is not noticeable in practice.
Last modified:Mon, Jan 23, 2023.