Alarm device testing using time-encoded acoustic messages

Abstract

 A smoke alarm device has an interface (1) with a microprocessor (2), and transistors (3, 4) controlling a piezo horn (5). The microprocessor (2) is programmed to generate a test output record including various items of data such as the device's serial number, the battery level, a contamination level if it is an optical alarm, an event log, and an installation date. This information is encoded by control of the transistors (3, 4) in an acoustic output from the piezo horn (5) using an encoding technique akin to Morse code. The data is decoded by any electronic testing device having a microphone and a processing capability, such as a PDA, a laptop computer, or even a mobile phone. Devices with stereo microphones can also be used for better performance. If the device has a camera then it could both capture the acoustic signal and take an image of the alarm device to provide a more comprehensive record. In one example, a mobile phone downloads over a mobile network an application to do this processing. In order to do an audit it is only necessary for the technician to press a test button upon which the microprocessor (1) generates the acoustic signal with audit data. This acoustic signal is captured by the testing device and either decoded by that device or uploaded to a central host for decoding and further processing and storage.

Description

INTRODUCTION

[0001] The invention relates to alarm devices such as smoke alarm devices.

[0002] There is a need in such devices for regular testing for peace of mind and compliance with various regulations. This preferably involves gathering a good deal of information about the device including its serial number and date of installation for audit purposes, in addition to testing information such as battery level and extent of contamination of an optical alarm.

[0003] If the manufacturer were to provide an interface with a display for such information it would add considerable expense to cost of the device, would be awkward for the user to operate as they would not be using it on a very regular basis, and it would itself introduce potential faults.

[0004] CA1,116,284 describes use of coded alarm signals in an alarm system in order to avoid interconnect wiring.

[0005] The invention is directed towards providing an improved interface for alarm devices to address these issues.

SUMMARY OF THE INVENTION

[0006] According to the invention, there is provided an alarm device comprising:

a user interface,

a processor adapted to store device status information, and

a sound emitter,

wherein the processor is adapted to generate an acoustic status message by automatically encoding in a sound emitter output at least some status information upon detection of a user instruction at the user interface, and

in which the encoding is time or frequency encoding suitable for machine decoding.

[0007] In one embodiment, the user interface is a test button, and the processor is adapted to automatically generate the message upon user pressing of the test button.

[0008] In one embodiment, the processor is adapted to automatically generate the message upon user pressing of the test button in a pre-defined pattern. The pattern may be duration of pressing.

[0009] In one embodiment, the user interface is a remote control interface.

[0010] In one embodiment, the processor is adapted to include in the message a device serial number, a battery status indication, and alarm event data. The processor may be adapted to include in the message a sensor contamination level and/or a date of alarm device installation.

[0011] In one embodiment, the processor is adapted to generate the message after a pre-determined rise time.

[0012] In one embodiment, the sound emitter is a piezo emitter.

[0013] In one embodiment, the processor is adapted to time encode the message with a combination of a preset on duration and off duration being a binary 0, and a combination of a different preset on duration and off duration being a binary 1. In one embodiment, each of said durations is in the range of 5ms to 100ms. In one embodiment, the on duration is in the range of 10ms to 30ms and the off duration is in the range of 30ms to 50ms.

[0014] In one embodiment, the processor is adapted to frequency encode the information, and frequency levels are in the range of 2000 Hz and 4000Hz, and the time ranges for frequency levels are in the range of 10ms to 50ms.

[0015] In one embodiment, the device comprises a sound detector, and the processor is adapted to receive acoustic messages and to decode them. In one embodiment, the detector is a piezo disc adapted to act as a tuned microphone. Preferably, the piezo disc is tuned at a frequency in the range of 2000Hz to 3500Hz.

[0016] In one embodiment, the processor is adapted to receive said acoustic messages on installation, and to store data encoded in the messages.

[0017] In one embodiment, the information includes an alarm device serial number.

[0018] In one embodiment, the processor is adapted to act upon decoded information received in said acoustic messages.

[0019] In another aspect, the invention provides an alarm system comprising a plurality of alarm devices as defined above in any embodiment, and a testing device comprising:

a user interface,

a sound detector adapted to detect said acoustic messages, and

a processor adapted to decode said acoustic messages and provide a testing user output.

[0020] In one embodiment, the testing device comprises a portable electronics device having a microphone, the processor of which is programmed to decode acoustic signals picked up by a microphone.

[0021] In one embodiment, the system comprises a central host for communicating with the testing device and receiving and storing status data uploaded by the testing device.

[0022] In one embodiment, at least one of the testing devices is adapted to generate acoustic signals to communicate information to an alarm device, and at least some of said alarm devices comprise a sound detector and the processor is adapted to decode received acoustic signals.

[0023] In one embodiment, the testing device processor is adapted to generate a user alert according to decoded messages.

[0024] In one embodiment, said processor is adapted to generate a user instruction according to the decoded messages.

[0025] In one embodiment, the testing device comprises a camera, and the processor is adapted to generate a user instruction to capture an image of an alarm device, and to correlate a captured image with decoded data for a particular alarm device to provide a test record.

[0026] In one embodiment, the testing device sound detector comprises two or more microphones and the testing device processor is adapted to extract information from the signals received at all of said microphones.

[0027] According to another aspect, the invention provides a method of testing an alarm device having a user interface, a sound emitter, and a processor adapted to generate an acoustic status message by control of the sound emitter,
wherein the method comprises the steps of:

the alarm device processor receiving a user test instruction,

the alarm device processor automatically encoding in the sound emitter output at least some status information to provide an acoustic status message, and

a testing device microphone picking up the acoustic message,

a testing device processor decoding said acoustic message to determine alarm device status data, and generating a user status output.

[0028] In one embodiment, the testing device uploads the status data to a remote host.

[0029] In one embodiment, the testing device comprises a camera, and the testing device processor generates a user instruction to capture an image and subsequently correlates a captured image of the alarm device with the associated status data.

[0030] In one embodiment, the testing device sound detector comprises two or more microphones and the testing device processor is adapted to extract information from the signaLs at iong range, and/or in noisy environments, and/or in areas with multiple paths that would smear the sound received by one microphone.

DETAILED DESCRIPTION OF THE INVENTION

Brief Description of the Drawings

[0031] The invention will be more clearly understood from the following description of some embodiments thereof, given by way of example only with reference to the accompanying drawings in which:-

Fig. 1 is a circuit diagram of an interface of the invention;

Fig. 2 shows a sample coding scheme;

Fig. 3 shows a sample sound output;

Fig. 4 shows a sample bit pattern; and

Fig. 5 shows a data packet.

[0032] Referring to Fig. 1 an interface 1 for a smoke alarm device comprises a microprocessor 2, and transistors 3 and 4 controlling a horn 5. The horn is conventional. The microprocessor 2 is programmed to generate a test output record including various items of data such as the device's serial number, the battery level, a contamination level if it is an optical alarm, an event log, and an installation date. This information is encoded by control of the transistors 3 and 4 in an acoustic output from the piezo horn using an encoding technique akin to Morse code. The signal illustrated in Fig. 2 shows an example of how the information can be encoded, with a 40 ms sound pulse followed by a 20 ms off period indicating a '1' and a 20 ms sound pulse followed by a 40 ms off period indicating a '0'. These pulses are generated by turning transistor 4 ON and OFF as appropriate with the drive from the microprocessor as shown in Fig. 1. In this case the transistor 3 is configured to let the piezoelectric disc self resonate at its natural frequency, which is typically 3000 Hz for smoke and CO alarms.

[0033] Fig. 2 shows the modulation scheme; period 60 ms, with a 0 being 20 ms on and 40 ms off and a 1 being 40 ms on and 20 ms off. The piezo disc (and hence the emitted sound) response/decay time is of the order of 3 ms, hence the minimum piezo on time is set to 20 ms. This is shown in Fig. 3.

[0034] Fig. 4 shows a bit pattern of one embodiment, and Fig. 5 shows a data packet. A typical message includes preamble/start bits, serial number, contamination level, battery, voltage, event log information (about 60 bits are available with a 4 second message).

[0035] An alternative scheme is to use frequency modulation instead of, or in addition to, time-based "on-off" modulation. In this case the frequency could typically be changed by 400 Hz i.e. for a piezoelectric disc with a natural resonant frequency of 3000 Hz the modulation would be 2800 Hz and 3200 Hz. In this case the coding scheme may be for example :2800 Hz for 40 ms followed by 3200 for 20 ms could represent '1' and 2800 for 20 ms followed by 3200 Hz for 40 ms could represent '0'. The circuit to do this would be similar to that in Fig. 1 but now the microprocessor would drive transistor 3 directly to generate the two frequencies and transistor 4 would be removed. The emitter of the transistor 3 would be connected to 0 Volts instead. The base of transistor 3 would be disconnected from the piezo disc feedback terminal.

[0036] Where the processor and piezo drive circuits can perform both time-based and frequency modulation it may be configured to do both in succession automatically so that the testing device is able to decode irrespective of its decoding capabilities.

[0037] The data is decoded by any electronic device having a microphone and a processing capability, such as a PDA, a laptop computer, or even a mobile phone. If the device has a camera then it could both capture the acoustic signal and take an image of the alarm device to provide a more comprehensive record. In one example, a mobile phone downloads over a mobile network an application to do this processing.

[0038] On installation, the installer would plug into a socket in the rear of the alarm device and enter the smoke alarm's serial number for that residence (9 digits max, for example), the date of installation, and a code for the location (for example, room) of the alarm.

[0039] In order to do an audit it is only necessary for the technician to press a test button (not shown) upon which the microprocessor 1 generates the acoustic signal with the audit data as it is programmed to do. This acoustic signal is captured by the user device. It may be decoded locally by the device, and the decoded data may be uploaded to a remote host. Alternatively a representation of the acoustic signal may be uploaded to a central host for decoding and further processing and storage.

[0040] In more detail, whenever the test button is pressed the horn will send out a coded signal with information such as the following. This could be done immediately, or 5 seconds after the horn has reached full volume.
Preamble bits e.g. 010101
Identification number e.g. 123456789
Unit status 1 Everything is OK (so rest of data need not be decoded) 0 Further analysis needed.
Battery status, for example 0 to 10 relates to voltage with 10 being a fresh battery and 0 being a battery below its specified range.
Contamination status, for example 0 to 10 with 10 being clean chamber and 0 being a fully contaminated chamber.
Alarm in previous 24 hours, for example between 0 and 1. This could give further information, such as the number of alarm events.
Alarm since button was pressed, for example between 0 and 1. This could give further information such as the number of alarm events since the last button press.
Faulty smoke sensor, for example a value between 0 and 1
Date instal led, for example 081110 - day/ month /year
Location, for example. 0 hallway, 1 main 1^st bedroom, 2 2^nd bedroom, 3 3^rd bedroom, 4 4^th bedroom, 5 child's bedroom,6 living room, 7 kitchen, and 8 garage.
Unit status, for example 0 in standby, 1 in hush, 2 in alarm. While in alarm the unit could periodically give out the coded signal.
Type of alarm, for example 1 for heat, 2 for CO, and 3 for natural gas.
End bits 010101

[0041] The "Unit Status" is to allow very rapid testing because with a good smoke alarm, the serial number and the "Test OK" is received by the checker in less than 1 second. This time is important because a checker is expected to check hundreds of smoke alarms in a day and time is of the essence. The vast majority of units will be "Test OK", with much less than 1% requiring further analysis and therefore the additional bits to be decoded which can take about 4 seconds.

[0042] During the annual check the person presses the test button of the alarm device and holds the testing device near the alarm device to pick up the sound. The testing device then shows the above items on a display and/or transmits them to a web site or company database. This proves the alarm device has been inspected and tested. The testing device can also tell the checker what to do, for example, replace battery or replace alarm device, or clean alarm device. Or if it had been "false" alarming, ask the checker if it could it be steam from a shower, or if it could be cooking fumes from a kitchen. It then generates an output indicating the appropriate action to take. The checker could be asked if the alarm device is clean or has contamination, and if so, the type of contamination e.g. cobwebs or grease, and to key this information in.

[0043] The checker could be asked to photograph the unit within a time duration of say 30 seconds of testing, hence providing a visual record of the state of cleanliness of the alarm device at that time.

[0044] The checker could be a building resident, with a maintenance company operator only checking it every second year or every 5 years for example. If there is a fault or alarm and the resident contacts the maintenance company for a call out - the resident could be asked to hold the phone near the alarm, so the issue could be diagnosed remotely and the tenant then advised what to do.

[0045] From the identification code and the original phone GPS location when it was being installed, a picture of the property can be brought up through satellite mapping software or other database for the person trouble-shooting the issue remotely.

[0046] The testing (for example annually, as required by the legislation in some countries) can be done very quickly. When the button is pressed the horn sound is low (to protect the tester's ears) and on release it gives out the full digital information. Alternatively, it may only give out the digital information if the button is held for 1.5 seconds; or possibly if the button is pressed twice in 3 seconds, for example. The results would be shown immediately by the logging device, with a simple pleasant sound ("ding") indicating a pass and a raucous sound indicating a fail.

[0047] The acoustic link could also be used just to analyse suspect units that fail a basic button test, if there was insufficient time to analyse all units.

[0048] A unique serial number (using for example 20 bits) may be pre-programmed into the alarm device at manufacture. This can then be associated with the address and room where it is installed, by interfacing with the installer's database. Alternatively, a serial number could be programmed into the unit at installation, using a socket in the rear of the unit. Having a unique serial number greatly helps with the tracking of smoke alarm devices - the devices can be sent back to the manufacturer for analysis and the subsequent report will clearly identify the unit and allow the maintenance company to relate it to the apartment from which it was removed. For example, if the unit was heavily contaminated or damaged, and it was clear that this was caused by a tenant, then the tenant (or landlord) could be billed for the replacement costs of fitting a new unit.

[0049] A further aspect of the invention is that the link can be made duplex. The piezo disc in the alarm device can act as a tuned microphone at for example about 3000 Hz and this can therefore be used to easily and quickly program information into the smoke alarm on installation such as the serial number. For example, after a button test an acoustic receiver amplifier connected to the smoke alarm piezo disc could be turned on (for just 10 seconds to minimise the current drain on the battery) to check for messages for the smoke alarm and if there were some the microcontroller would decode them and act on the information or store it as appropriate.

[0050] Such communication could also be used during testing to for example reset the event log. For example, if the checker's PDA device receives a serial number and a "status OK" message, it could immediately send back an acoustic message to get the smoke alarm to reset its event log and for it to record that it had been tested by an official checker.

[0051] It will be appreciated that the invention allows very fast and convenient testing of alarm devices, with minimum additional cost or complexity. It makes use of existing hardware components in many conventional alarm devices, and indeed in user devices such a mobile phones in various embodiments.

[0052] The invention is not limited to the embodiments described but may be varied in construction and detail. In another embodiment, the testing device may include two or more microphones, to generate stereo signals. This would assist with decoding the acoustic signals at long range, and/or in a multipath environment. The signal processing can be used to make the microphone assembly directional as is well known. The signal processing could also be used to mimic the signal processing done by a human being, where the signals from the two ears are used to decode conversations even in noisy environments.

Claims

1. An alarm device comprising:

a user interface,

a processor (2) adapted to store device status information, and

a sound emitter (5),

wherein the processor (2) is adapted to generate an acoustic status message by automatically encoding in the sound emitter (5) output at least some status information upon detection of a user instruction at the user interface, and

in which the encoding is time or frequency encoding suitable for machine decoding.

2. An alarm device as claimed in claim 1, wherein the user interface is a test button, and the processor (2) is adapted to automatically generate the message upon user pressing of the test button.

3. An alarm device as claimed in claim 2, wherein the processor (2) is adapted to automatically generate the message upon user pressing of the test button in a pre-defined pattern such as duration of pressing.

4. An alarm device as claimed in any preceding claim, wherein the processor is adapted to include in the message a device serial number, a battery status indication, and alarm event data, and/or a sensor contamination level, and/or a date of alarm device installation.

5. An alarm device as claimed in any preceding claim, wherein the processor is adapted to time encode the message with a combination of a preset on duration and off duration being a binary 0, and a combination of a different preset on duration and off duration being a binary 1, and wherein each of said durations is in the range of 5ms to 100ms.

6. An alarm device as claimed in any preceding claim, wherein the processor is adapted to frequency encode the information, and frequency levels are in the range of 2000 Hz and 4000Hz, and the time ranges for frequency levels are in the range of 10ms to 50ms.

7. An alarm device as claimed in any preceding claim, wherein the device comprises a sound detector, and the processor is adapted to receive acoustic messages and to decode them.

8. An alarm device as clamed in claim 7, wherein the detector is a piezo disc adapted to act as a tuned microphone.

9. An alarm device as claimed in claims 7 or 8, wherein the processor is adapted to receive said acoustic messages on installation or manufacture, and to store data encoded in the messages, and wherein the information includes an alarm device serial number.

10. An alarm system comprising a plurality of alarm devices of any preceding claim, and a testing device comprising:

a user interface,

a sound detector adapted to detect said acoustic messages, and

a processor adapted to decode said acoustic messages and provide a testing user output.

11. A system as claimed in claim 10, wherein the testing device comprises a portable electronics device having a microphone, the processor of which is programmed to decode acoustic signals picked up by the microphone, and wherein the system comprises a central host for communicating with the testing device and receiving and storing status data uploaded by the testing device.

12. A system as claimed in either of claims 10 or 11, wherein at least some alarm devices comprise a sound detector and the processor is adapted to decode received acoustic signals, and the testing device is adapted to generate acoustic signals to communicate information to said alarm devices.

13. A system as claimed in any of claims 10 to 12, wherein the testing device processor is adapted to generate a user alert or instruction according to decoded messages.

14. A system as claimed in claim 13, wherein the testing device comprises a camera, and the processor is adapted to generate a user instruction to capture an image of an alarm device, and to correlate a captured image with decoded data for a particular alarm device to provide a test record.

15. A system as claimed in any of claims 10 to 14, wherein the testing device sound detector comprises two or more microphones, and the testing device processor is adapted to extract information from the signals received at all of said microphones.

16. A method of testing an alarm device having a user interface, a sound emitter, and a processor adapted to generate an acoustic status message by control of the sound emitter, wherein the method comprises the steps of:

the alarm device processor receiving a user test instruction,

the alarm device processor automatically encoding in the sound emitter output at least some status information to provide an acoustic status message, and

a testing device microphone picking up the acoustic message,

a testing device processor decoding said acoustic message to determine alarm device status data, and generating a user status output.

17. A method as claimed in claim 16, wherein the testing device uploads the status data to a remote host.

18. A method as claimed in claims 16 or 17, wherein the testing device comprises a camera, and the testing device processor generates a user instruction to capture an image and subsequently correlates a captured image of the alarm device with the associated status data.

19. A method as claimed in any of claims 16 to 18, wherein the testing device sound detector comprises two or more microphones and the testing device processor is adapted to extract information from the signals at long range, and/or in noisy environments, and/or in areas with multiple paths that would smear the sound received by one microphone.

Drawing