EP2461299B1

EP2461299B1 - Alarm device testing using time-encoded acoustic messages

Info

Publication number: EP2461299B1
Application number: EP11394025.8A
Authority: EP
Inventors: Michael Byrne; Fergus Flynn; Brendan Barry; James Duignan; Michael Guinee
Original assignee: EI Technology Ltd
Current assignee: EI Technology Ltd
Priority date: 2010-12-06
Filing date: 2011-12-02
Publication date: 2021-02-24
Anticipated expiration: 2031-12-02
Also published as: EP2461299A3; IE20110538A1; DE202011110746U1; EP2461299A2

Description

INTRODUCTION

The invention relates to alarm devices such as smoke alarm devices.
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.
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.
CA1,116,284 describes use of coded alarm signals in an alarm system in order to avoid interconnect wiring. US2004/0217857 describes a smoke detector which provides an RF coded signal. EP2003632 describes adjusting sensitivity of an acoustic sensor.
The invention is directed towards providing an improved interface for alarm devices to address these issues.

SUMMARY OF THE INVENTION

According to the invention, there is provided an alarm device as set out in claim 1.
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.
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.
In one embodiment, the user interface is a remote control interface.
In one embodiment, the processor is adapted to include in the message a device serial number. The processor may be adapted to include in the message a sensor contamination level and/or a date of alarm device installation.
In one embodiment, the processor is adapted to generate the message after a pre-determined rise time.
In one embodiment, the sound emitter is a piezo emitter.
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.
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.
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.
In one embodiment, the processor is adapted to receive said acoustic messages on installation, and to store data encoded in the messages.
In one embodiment, the information includes an alarm device serial number.
In one embodiment, the processor is adapted to act upon decoded information received in said acoustic messages.
In another aspect, the invention provides an alarm system as set out in claim 10.
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.
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.
In one embodiment, the testing device processor is adapted to generate a user alert according to decoded messages.
In one embodiment, said processor is adapted to generate a user instruction according to the decoded messages.
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.
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.
According to another aspect, the invention provides a method of testing an alarm device as set out in claim 17.
In one embodiment, the testing device uploads the status data to a remote host.
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.
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 long 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

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.

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.
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.
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).
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 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.
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.
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.
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.
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.
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 installed, 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

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.
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.
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.
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.
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.
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.
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.
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.
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.
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 as mobile phones in various embodiments.
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

An alarm device comprising:
a user interface,

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

a sound emitter (5),

characterized in that

the processor (2) is adapted to generate an acoustic status message by automatically encoding in the sound emitter (5) output at least some binary encoded status information upon detection of a user instruction at the user interface, said information including a battery status indication and alarm event data,

in which the encoding is time or frequency encoding suitable for machine decoding.
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.
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.
An alarm device as claimed in any preceding claim, wherein the processor is adapted to include in the message a device serial number, and/or a sensor contamination level, and/or a date of alarm device installation.
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.
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.
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.
An alarm device as clamed in claim 7, wherein the detector is a piezo disc adapted to act as a tuned microphone.
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.
An alarm system with at least one alarm device according to claim 1, wherein:
a testing device microphone is adapted to pick up the acoustic message,

a testing device processor is adapted to decode said acoustic message to determine alarm device status data, and is adapted to generate a user status output, and

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.
A system as claimed in claim 10, wherein the system comprises a central host for communicating with the testing device and receiving and storing status data uploaded by the testing device.
A system as claimed in claims 10 or 11, wherein the testing device is a PDA, a laptop computer, or a mobile phone.
A system as claimed in any of claims 10 to 12, wherein at least one alarm device comprises 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 device.
A system as claimed in any of claims 10 to 13, wherein the testing device processor is adapted to generate a user alert or instruction according to decoded messages.
A system as claimed in claim 14, 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.
A system as claimed in any of claims 10 to 15, 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.
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 binary encoded status information to provide an acoustic status message, said information including a battery status indication and alarm event data, 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 in which said testing device comprises a portable electronics device having said microphone and said processor, said processor being programmed to perform said decoding.
A method as claimed in claim 17, wherein the testing device uploads the status data to a remote host.
A method as claimed in claims 17 or 18, 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.
A method as claimed in any of claims 17 to 19, 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.