EP2581891B1 - Réseau maillé de dispositif d'alarme RF à faible courant - Google Patents

Réseau maillé de dispositif d'alarme RF à faible courant Download PDF

Info

Publication number
EP2581891B1
EP2581891B1 EP12188123.9A EP12188123A EP2581891B1 EP 2581891 B1 EP2581891 B1 EP 2581891B1 EP 12188123 A EP12188123 A EP 12188123A EP 2581891 B1 EP2581891 B1 EP 2581891B1
Authority
EP
European Patent Office
Prior art keywords
cluster
devices
messages
monitoring
message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
EP12188123.9A
Other languages
German (de)
English (en)
Other versions
EP2581891B8 (fr
EP2581891A2 (fr
EP2581891A3 (fr
Inventor
Michael Byrne
James Duignan
Michael Guinee
Rona Doyle
Fergus Flynn
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
EI Technology Ltd
Original Assignee
EI Technology Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by EI Technology Ltd filed Critical EI Technology Ltd
Publication of EP2581891A2 publication Critical patent/EP2581891A2/fr
Publication of EP2581891A3 publication Critical patent/EP2581891A3/fr
Application granted granted Critical
Publication of EP2581891B1 publication Critical patent/EP2581891B1/fr
Publication of EP2581891B8 publication Critical patent/EP2581891B8/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G08—SIGNALLING
    • G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
    • G08B25/00—Alarm systems in which the location of the alarm condition is signalled to a central station, e.g. fire or police telegraphic systems
    • G08B25/009—Signalling of the alarm condition to a substation whose identity is signalled to a central station, e.g. relaying alarm signals in order to extend communication range
    • G—PHYSICS
    • G08—SIGNALLING
    • G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
    • G08B25/00—Alarm systems in which the location of the alarm condition is signalled to a central station, e.g. fire or police telegraphic systems
    • G08B25/003—Address allocation methods and details
    • G—PHYSICS
    • G08—SIGNALLING
    • G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
    • G08B29/00—Checking or monitoring of signalling or alarm systems; Prevention or correction of operating errors, e.g. preventing unauthorised operation
    • G08B29/02—Monitoring continuously signalling or alarm systems
    • G08B29/06—Monitoring of the line circuits, e.g. signalling of line faults

Definitions

  • the invention relates to networks of RF alarm devices, such as fire, smoke, or intrusion alarm devices.
  • a problem with such devices is that when there are several in a network one or more might not communicate adequately, despite the controllers performing message repeating in a manner such as described in EP1903523 . There are many reasons why a device may not be able to communicate, such as:
  • the conventional mechanism for monitoring status is that each device sends an RF status message to the panel (or other monitoring device) directly at the required intervals. This works if all of the devices are well within the range of the panel, such that the panel receives the signals with a good "fade" margin.
  • a fade margin is usually specified, which can be in the range of 3dB up to 30dB, to allow for the signal being attenuated due to factors such as those mentioned above.
  • the RF signals being received by the panel are not sufficiently strong, then at least one repeater will be needed.
  • systems are now often configured as "mesh" networks, where some or all of the devices repeat the RF messages, such that all devices receive the RF messages through at least two or ideally more different paths.
  • the status messages are normally very short, for example, in the range of 2 to 50 ms long.
  • the invention addresses these problems.
  • WO2010/076072 A1 discloses a wireless alarm device network according to the preamble of claim 1 and a wireless alarm device according to the preamble of claim 12.
  • each device is adapted to generate an alert only if:
  • the monitoring cluster size is preferably two or three, with each device having only one or two cluster members.
  • the devices are synchronised with a time clock so that they communicate in pre-set time periods.
  • length of an intra-cluster status message is at or below 100ms.
  • a device is adapted to broadcast a trigger intra-cluster status message which triggers the other devices in its cluster to respond.
  • at least one device is adapted to transmit a status message in a specified sequence, to prevent clashing, upon receipt of a status message.
  • the specified sequence includes both when to transmit the status message and when to listen for the other messages.
  • said broadcasts are in a defined pattern.
  • At least one device is adapted to stop monitoring another device in its cluster if its messages are becoming intermittent, provided it is being monitored by another device.
  • the network includes a monitoring system and at least one device is adapted to download to the monitoring system, upon a monitoring system request, data concerning devices it is monitoring in its cluster.
  • said data includes latest RSSI level data.
  • the monitoring system is adapted to generate a two-dimensional table indicating devices that are in direct communication and the level of repeat between those not in direct communication.
  • the monitoring system is adapted to generate a display based on said table, the display indicating to an installer an assessment of the network reliability
  • At least some devices are adapted to piggyback on a first status message by transmitting their status messages after it in a specified sequence, to prevent clashing.
  • the specified sequence includes both when exactly to transmit the short status message along with when to listen for the other messages, to prevent a device needing to both listen and transmit at the same time.
  • At least some devices are adapted to send messages including their own serial numbers, and if a device fails to hear its own serial number, to send an alert message indicating that it is not being monitored by at least one other device.
  • each device is adapted to first send a request command asking which devices are monitoring a particular device, and to determine from responses if at least one other device is monitoring said device.
  • At least some devices are adapted to directly receive and process inter-cluster messages from devices which are outside of its cluster, and to avoid raising an alert if it does not receive a message from a cluster member device if it determines from said inter-cluster messages that another device has received a message from said cluster member device.
  • said devices are adapted to process only inter-cluster messages received during a pre-defined immediately-preceding time period.
  • said alarm devices include smoke, heat and toxic gas alarm devices.
  • the invention provides a wireless alarm device as claimed in claim 12.
  • the device is adapted to generate an alert only if:
  • the device is adapted to directly receive and process inter-cluster messages from devices which are outside of its cluster, and to avoid raising an alert if it does not receive a message from a cluster member device if it determines from said inter-cluster messages that another device has received a message from said cluster member device.
  • a wireless RF smoke alarm network 1 comprises alarm devices or "units" A to J and L located in a three-storey building with a two-storey annex.
  • Each device has conventional architecture in hardware terms, with a micro-controller, output LEDs, output sounder, condition sensor (for example for smoke, toxic gas, heat, or intruder presence), and an RF transceiver.
  • the invention lies mainly in the manner in which the micro-controller is programmed to process received messages, generate output messages, and control the light and sound output devices.
  • Each device learns its neighbouring devices during a learning phase. It automatically, on an ad hoc basis, forms clusters which are overlapping. In this example the devices A - L have automatically formed four clusters 2, 3, 4, and 5.
  • each device monitors each other using, as a key, parameter strength of the received signal. Values for the Receive Signal Strength Indicator (RSSI) parameter cross-references for one example are given in the table of Fig. 2 .
  • RSSI Receive Signal Strength Indicator
  • each device activates an LED to indicate that it has found at least one device ("buddy") with which it is in a cluster.
  • each device in a cluster monitors at least one device in the cluster and is itself monitored in return.
  • a device in a cluster only generates an alert (such as activating the LEDs in a particular manner, and/or sending a signal to the monitoring device K) if it identifies a problem. Faults are exceptional so they only occur rarely - this means that the repetition of fault messages normally has an insignificant effect on battery life.
  • one device if one device does not receive an RF status message at the required time (possibly after re-trying to contact the "missing" device a number of times) it sends out a 3.5 second long message, saying “device missing with serial number "XXXXX” and this is repeated by the appropriate devices. The message is therefore heard by all of the devices.
  • the monitoring device K or a panel can then show that a device is missing and/or relay the message to external devices or servers via GSM or WiFi, for example.
  • Item (b) has the following advantageous features:
  • the network there are 12 devices in the network and if there is a fault message an alert must be generated after at most 4 hours.
  • the alert may be displayed on a monitoring panel (such as the monitoring device K), or no such device then the device will flash its blue LED once every 45 seconds; if two devices are missing they flash their blue LED rapidly twice every 45 seconds and so on.
  • the horns could also be made beep at the same time if required.
  • While in the monitoring cluster mode devices could also possibly store the RSSIs (Receive Signal Strength Indicator) levels at which they received the various serial numbers from the other devices, for downloading subsequently if needed, so that the RF signal strengths and multiple paths can be analysed to assess the potential system robustness and reliability.
  • RSSIs Receiveive Signal Strength Indicator
  • Fig. 4 shows the distribution of signal strengths received by a test receiver over a period in the order of hours, all from the same device at the same position.
  • the horizontal axis is signal strength in dBm and the vertical axis is number of occurences.
  • the received signal strengths range from 72dB to 92dB.
  • each monitoring cluster size is kept to two or three devices, and so each device may be regarded as having one or two "buddy" devices in its cluster. While, in this case the monitoring cluster size is only 2 or 3, each device will also receive some messages from other devices in direct communication. These messages include status updates for the device itself and it also includes the serial numbers of up to three other devices whose status message it has heard in the previous 20 minutes. These are the three strongest status messages this device will have heard. Therefore a particular device will not raise an alert if it does not receive a message from a buddy, if it knows from these messages that another device has received a message from it, thus confirming that it is operational and in communication. This deals with the situation where there is a temporary block in the RF path between buddy devices.
  • the message table format in the micro-controller's memory between buddies may be as follows for some embodiments:
  • the network may not include a dedicated monitoring device such as the device K in Fig. 1 . This is because each device can raise its alert without need for such a device, for example by activating LEDs and/or a sound emitter as appropriate.
  • the devicess are then "told" (in some way e.g. by pressing the house code button or by an RF transmitter) to re-broadcast all of the serial numbers they have learned.
  • they can automatically after a suitable time interval of say 15 minutes, go on to re-broadcast all the serial numbers they have learned. They would flag the serial numbers to indicate repeat level - 0 is a device itself, 1 is received directly, 2 is received after one repeat, 3 is received after two repeats, and 4 is received after three repeats.
  • All the devices store the house code numbers in the usual fashion, except that they add a flag to identify the devices(s) in their cluster that they must monitor. Assume say 3 are within range and so form a cluster of 4. Now, after four hours each in turn will transmit a 3.5 second status message. This will be received by the other 3 and they will note that they have received the three messages. If at some stage a device misses one of the three devices it is monitoring, it will send out a 3.5 second "device missing" message with the missing device's serial number. This will be repeated by all the other repeater devices and will therefore be heard at the panel (or other fault indicating device).
  • a device If a device "hears” the message with its own serial number, saying it is missing, it can send out (or re-send out) its status message.
  • the device which sent the original device-missing message, or any device that heard the "device-missing” message can now send a new message saying "device restored” serial number XXXXX" (if it receives the new status message). This allows the fault indicator to be quickly cancelled.
  • the system can also re-configure which devices are monitoring which in a particular cluster so as to eliminate non-genuine fault signals being sent. This would be done in such a way as to prevent "orphans" being generated, that is a device being left such that it is not monitored by any other device.
  • One way to do this is for a device Y which is getting intermittent signals from say device X and wants to stop monitoring it, first sending out a request command WDMX (Which Device Monitors X) asking "which devices are monitoring device X”. All the relevant devices reply and the messages are repeated. Therefore as long as device Y hears that at least one other device is monitoring device X it can safely stop monitoring it.
  • the devices would respond with the message code and their own serial number indicating that they are monitoring the device mentioned in the request command. For this to work, only one device can be requesting this information on a particular device at a time. The protocol would allow for this by forcing devices wanting to use this command to wait for sufficient time for the initial request command WDMX to be fully answered including all the repetitions.
  • the second term is to allow for the receiver being on for 0.2 seconds (to receive the messages from the other 3 devices) and that it draws 15mA during that time.
  • Supplying 7.5 ⁇ A for a year requires 65.7mAh. With a 1500mAh battery, and ignoring other drains, this would last 22.8 years. Allowing for the additional currents such as to power the smoke alarm and also to turn on the RF receiver every 3 seconds, a 10 year battery life can be feasible. Extending the monitoring period from 4 hours to for example 24 hours or longer, would significantly reduce the drain on the battery.
  • each device has an accurate clock crystal, each with a tolerance of say 20 ppm, and the status messages are being transmitted precisely every 4 hours then the following could be done.
  • the status message length could be reduced to 100ms (i.e. 10 packets of the 10ms message). To detect this, all the devices would need to increase their sampling i.e. turning on their receivers, from once every 3 seconds to once every 50ms (to give about 2 chances of detecting the RF status message) as it comes up to the time when the message is due.
  • the 25 in the denominator is because the duty cycle is roughly 2ms/50ms for the sampling.
  • the total current is just 0.239 ⁇ A. To supply this for 1 year requires 2.09 mAh. This is a very big improvement over the 65.7mAh required when the message transmitted is 3.5 seconds long.
  • the accurate timing crystal clock could possibly draw an additional 0.5 microamps in addition to the above.
  • the following can be done to reduce the current drawn - just one device, every four hours broadcasts for 3.5 seconds and the others broadcast for just 50 ms each in sequence afterwards., as all the receivers turn on at the end of the 3.5 second transmission, while they are not transmitting.
  • the monitoring panel K knows that a particular device was being monitored by at least 2 devices, it would not show a fault unless it heard it from two different devices. Unfortunately with a simple protocol having just a single serial number in the message there is no way for the panel to know it received the device message from two different devices, or if it was just the original message being repeated. To avoid this problem, if a device misses another device it broadcasts the 3.5 second message that it is missing. If another device has heard from the "missing" device, in say the previous 15 minutes, then it broadcasts a "device restored message". The panel then knows that at least one device is in contact so it does not show a fault. Also the panel can send the request command "WDMX" asking "which devices are monitoring device X", to establish the reliability of the monitoring of a particular device.
  • the device that missed this device can now delete it from its cluster (say if this happens twice for confirmation that it was not just one-off RF blocking event), to stop the panel showing intermittent faults, but more importantly not to reduce the battery life on the devices which would be transmitting the repeated 3.5 second "device missing" message every 4 hours along with the repeated 3.5 second "device restored” message every 4 hours. This should not leave any device unmonitored, and hence the two commands:
  • RF devices are installed in a three storey house with a two-storey annex.
  • a panel or other RF monitoring device is included.
  • the circles show the RF devices that are in direct range of each other.
  • all of the devices are put into the cluster mode, where they just broadcast their own serial numbers.
  • cluster 1 units A, B and C will flash their blue LEDs six times (every 10 seconds) to show there are 6 devices in range (including the device itself).
  • Units D, E and F will flash their LEDs 9 times as they are members of both cluster 1 and 2.
  • cluster 2 as well as D, E and F flashing their LEDs 9 times, units G and H and will flash their LEDs 6 times.
  • Unit I will flash its LED 7 times as it is in contact with 5 units in cluster 4 and one in cluster 3 (which including itself gives 7).
  • cluster 3 I will flash its LED 7 times and J will flash its LED 4 times (for I, L, K and itself).
  • J will flash its LED 4 times and L and K will flash their LEDs 3 times.
  • the devices in each of the clusters will now monitor the rest of the devices in the cluster. If for any reason a device stops transmitting its status message (or if it cannot be heard) every 4 hours the other devices in the cluster will broadcast messages (with the missing device's serial number) indicating that the device is missing. In the illustration it is assumed that device A has become defective. Device B now sends out a "device missing with A's serial number" message. This is relayed to E, I, J and eventually to the monitoring device K.
  • the invention provides a straightforward method for establishing the actual signal strength between all the devices and how many multiple paths there are through the repeaters. This information can then be used to predict the reliability of the system and so help decide whether measures such as adding a repeater, re-orientating antennas, or re-locating a device are needed.
  • the installer goes around to each RF device in turn and asks it to download data concerning all the devices with which it is in direct communication along with the RSSI levels in (dBm) that it received the communication at, to an electronic data logger (usually hand held). Alternatively this information can be broadcast by each device in sequence and repeated so it is received by the panel or other monitoring device.
  • the data received from all of the devices can then be compiled into a table as shown in Fig. 2 , for a configuration such that in Fig. 1 .
  • This table shows if all the devices are in communication with each other and whether they are receiving the message directly (along with the RSSI level) or after being repeated once (digit 2), twice (digit 3) or three times (digit 4). Digit 1 would indicate direct communication.
  • the data in this table can be used to construct diagrams such as those in Fig. 1 to facilitate the installer viewing the multiple paths and signal strengths and potentially vulnerable links.
  • This data clearly shows that the communication between the devices in clusters 1 and 2 will be extremely reliable due to the strong signal strengths and the myriad of multiple paths.
  • the weakest link is clearly cluster 3 as this links cluster 4 to clusters 1 and 2.
  • One possible way of ensuring the reliability of this link would be to increase the acceptable fade margin in this situation from say 6dB to 10dB (or even 30dB as is recommended in some standards).
  • devices will receive down to -100dBm and as Fig. 2 shows, the signal strength between I to J and between J to I are both -80dBm, so this shows that there is a 20dB fade margin.
  • the software can be used to set the relevant criteria such that it can tell the installer how reliable the system is. If a 20dB margin was deemed to be inadequate, then the software could be used to tell the installer to take the appropriate corrective action such as adding a further repeater in the vicinity of I and J.
  • the acceptable fade margin between devices could be varied depending on the number of multiple paths between the devices such that with three or more multiple paths the acceptable fade margin is low (possibly 3 dB), with 2 paths it is medium (possibly6 dB) and with just a single path it is high (possibly 10 dB).
  • the cluster size may be restricted to only 2 or 3.
  • the devices may be put into a monitoring set-up mode. This can be done by a unique sequence of button presses, such as pressing the house code button and holding it until a tri-colour LED turns green; alternatively it could be done by pressing the house code button and at the same time pressing the device's test button. Or, it could be put into monitoring set-up mode by simply transmitting the required RF coded message from an RF installation/diagnostic tool.
  • each device now transmits its own house code serial number in a 50 ms long message, (these messages are not repeated by any of the other devices) every 5 seconds.
  • Each device now measures the RF signal strength (RSSI) of each device that is in range. Over the 5 minutes it will receive about 60 messages from each device in range and it will calculate the average RSSI from the 60 readings.
  • RSSI RF signal strength
  • Each device now has a table showing the signal strengths of all of the devices in direct range.
  • a device processor now looks through its table and selects the device which sent it the strongest signal. Provided this signal is strong enough (e.g. has a specified fade margin of 15 dB or more above the minimum RF reception level) it now requests this device to be its "buddy". When the potential buddy receives the request, it consults its table and once it is also receiving this device with sufficient fade margin, it sends a message to be the first device that it agrees to be its buddy. Similarly, all the other devices seek to set up such clusters. If a device is not receiving any other device with sufficient margin, then it cannot buddy and will continue to flash its blue LED twice rapidly every 40 seconds. The installer now has to take remedial action such as adding another device closer to it, rotating the device, extending the antenna, or re-locating it. The RF installation/diagnostic tool gives the signal strength etc. which can help resolve this.
  • a device requests another device to be a buddy but the proposed buddy is not receiving the requester's RF signal with sufficient margin it will not reply stating it will be a buddy.
  • the first device now looks at its RSSI strength table and picks the next device with the second strongest RSSI. It now requests this device to be a buddy as above.
  • Each device continues in this manner until it has found at least one buddy.
  • one device can be a buddy of two or more other devices. With an odd number of devices, at least one device will have to monitor two buddies. In an extreme case, one device at the centre might have to be the buddy of all the devices on the periphery (if all the other devices were not within range of each other). So, when all the devices have found buddies, they stop flashing their blue LED twice every 40 seconds, so the installer now knows everything is satisfactory.
  • each device Every 20 minutes (when on mains power) each device sends out its short (typically 50ms) status message. The buddy hears it and takes no action. If a device fails to receive such a message from a particular buddy 6 times over 2 hours it flashes its blue LED twice every 40 seconds to indicate to the user that a buddy is not in communication. It can additionally or alternatively beep if required. It can also send a 3.5 second long message, which is repeated by all the other devices, stating "device xxxx is missing" and this can be picked up by a monitoring device. This monitoring device can give a visual warning that an identified device is missing and also send this information to a call centre, smart phone or any other appropriate device.
  • a monitoring device can give a visual warning that an identified device is missing and also send this information to a call centre, smart phone or any other appropriate device.
  • the status messages are only sent once every 12 hours (to conserve power). In this case the message lengths have to be increased from 50ms (0.05s) to 3.5 s. Battery powered devices in standby turn on their receivers once every 3 s, whereas on mains they turn on their receivers every 20ms (0.02s)). In this case if two of the status messages are missed from a buddy, the warnings as above are given after 24 hours.
  • a device could lose communication with its buddy because the RF path between them was blocked by renovations, furniture being moved etc. However, the network could still be perfectly satisfactory as other devicess in the mesh can repeat the alarm and other messages, by-passing the obstructed path. With the scheme as outlined alone, the user would be informed that one device was out of communication whereas the network could be perfectly capable of operating as required.
  • Warnings are only given if all of the paths in the mesh network are disrupted as follows.
  • Each device sends out its status message (every 20 mins or 12 hours). However, along with its own serial number, it now also adds on up to three other status message serial numbers. These are from the devices it has received the strongest RSSI status signals previously (within the required interval). Now, a device monitoring a buddy, if it misses the direct buddy status message, will check to see if some other device has reported that it has heard its status message. This will therefore only report a buddy missing if it misses all the required status messages itself and also if no other device has reported hearing that device's status message..
  • This scheme will mean that the time before a fault is given will be extended. Say a device is removed. The direct buddy will miss the direct status messages. However, other devices may still have the "memory" of the previous received status message, so until this is cleared, the original buddy "monitor" will not report a fault.
  • a particular device keeps track of the status messages from all the different devices it is monitoring by setting a different timer for each to time out in 2 hours when on mains. Every time it receives a status message, either directly or through another device, it resets the timer to zero. If a timer times out for a device that is one of its buddies, it gives the "buddy missing" warning of two rapid flashes every 40 seconds and sends the 3.5 second message to any monitoring device.
  • the installation or diagnostics tool in one embodiment consists of an RF transceiver with software for the RF protocol configured in a USB stick format. This would be plugged into a laptop, PDA, or other appropriate device.
  • House code mode entry will clear all previously stored RSSI levels and buddy settings.
  • Factory mode restore will clear all RSSI levels, buddy settings, learn mode repeat levels, and all stored serial numbers.
  • the device will keep a log of the repeat level that the first valid house code message has been received at from each of the devices in the system A total of four different repeat levels are allowed.
  • This log is stored in the EEPROM, one location for each device, adjacent to the serial number location.
  • the original house code message will be sent at repeat level F0 (level 3 - the maximum level).
  • This code is pre-programmed into the location adjacent to the device's own serial number. This level will be then decremented by the receiver before being stored in the EEPROM. This will thus be stored as E0, D0, or C0.
  • the minimum received repeat level stored will be C0.
  • House code messages received at this level will be stored in the EEPROM as '00'.
  • this level When the house code table is being repeated, this level will be retrieved and included in the outgoing message as the repeat level, except if the stored level is '00' the house code message will not be transmitted. This will ensure that house code messages can be repeated a maximum of three times.
  • Monitor Mode Entry will clear all previously stored RSSI levels and buddy settings.
  • Monitor Setup mode devices will send 50ms Monitor Setup messages every 5 seconds. These messages are not repeatable, thus are sent with a repeat level of C0. At the start of this mode, the green LED will be flashing 3 times every 5 seconds.
  • the RSSI level (after deducting a base level of -95dBm) will be added to a running total, and a counter will be incremented. These running totals are kept for each device (in RAM). When the device has been in Monitor Setup mode for 3 minutes, the running total is divided by the counter for each device to give an average receive level. If enough direct Monitor Setup messages have been received, the average is divided by 16 and added to E0 and the result stored in the EEPROM monitor level location. This table is used to decide which devices can become "buddies", i.e. which have a direct path with a received signal margin of at least 15dB. The device will only monitor at least one of these devices.
  • the device After another 30 seconds (to allow all the other devices in the system to calculate their “buddy” tables), the device looks down its table of RSSI levels, and picks the device with the strongest signal. If this signal is strong enough to be a "buddy”, a "buddy request” message is transmitted to that device. This message will contain both the sending and destination serial numbers. If the receiving device has also made a buddy of the sending device, it will reply with a "buddy confirmed” message, also with two serial numbers. Both these devices will now set a "Buddy” flag in their EEPROMs across from the corresponding serial number. Thus, buddies will be formed in pairs. At this point, the LED will stop flashing.
  • the device If the device receives a "buddy request” message, even though it has already paired off with another device, it will still reply with a "buddy confirmed” message. This is to ensure that all other devices can find a buddy if one is available. All devices should have paired off after 5 minutes. If any device has not found a buddy by this time, the LED will remain flashing. This will indicate that it will need to be re-sited or a repeater fitted.
  • Each device in the network has a timer associated with it. These timers are pre-loaded with the timeout value (216 for a 24 hour timeout) at Monitor Setup Mode exit - as they share registers with the Monitor Setup mode RSSI averaging function. At regular intervals (every 18-20 minutes), the "buddy" timers are decremented by 1, and the non-buddy timers are restarted. Each device sends out a 3.0 second long "Monitor" message every 10 hours, with a repeat level of C0. This will prevent the message from being repeated. This will add approx. 2.5 ⁇ A to the average current consumption.
  • Monitor Fail mode the blue LED on the monitoring device will flash twice every 2 minutes. In this mode, it will send a 3.5s Check message with the serial numbers of both the missing device and the sending device every 4 hours for 2 days. The device receiving this message will immediately broadcast another Monitor message. Monitor Fail mode will be terminated immediately if the missing device returns. At the end of the 2 days, i.e. if the timer has reached zero, if the missing device is still missing, the blue LED flashing will cease at this time but the timer will still remain at zero, thus acting as a monitor fail flag. This timer will be restarted if the missing device returns at any later time.
  • Monitor Fail mode If a device is button tested after Monitor Fail mode has ended and any monitor timers are zero, after the alarm cancel transmissions are finished, the device will enter this Monitor Fail mode, this time for 4 hours. This will act as a memory feature for identifying any monitoring failures later.
  • Monitoring faults are most likely to be due to degradation of one of the radio links between two buddy devices. If this is the case, the buddy network can be reformed by placing the system into Monitor Setup mode again. Entry into House Code mode or Monitor Setup mode erases all the buddy settings in the EEPROM. If a device is now no longer able to find a buddy, due to the degraded link, it will be flashing 3 times after Monitor Setup mode exit.
  • this device can broadcast a "Tell Missing” command. This command is fully repeatable, so it can be heard across the entire network. Flashing devices receiving this command will broadcast a "Missing" or “Tamper” command with the serial number(s) of the missing device, which is also fully repeatable. Thus, the monitoring system can identify which device is missing. This command would only be sent by an engineer troubleshooting the network.. Also, if the missing device receives this command, it will broadcast a fully repeatable "Monitor” message. This will restart all the clocks and end the LED flashing. The monitoring system will also indicate that the fault has been resolved.
  • the blue LED flashes on a nearby device to warn the user (within 2 hours if on mains power, and within 24 hours if on battery power). Disruption could be due to a device fault or RF barrier blocking/attenuating signal A comprehensive radio survey should be done before monitoring is enabled. Marginal devices may be excluded from the monitoring system.
  • the time and date of the last and number of the following events are recorded in the device's own RF module (or device's own microcontroller).
  • the Time column above is given within 4 hours with a 10% clock tolerance. The clock stops when all power is off for battery voltage.
  • 10 is an un-depleted battery and 4 is the low battery level.
  • 10 is a clean chamber and 4 indicates need for replacing or cleaning.
  • USB device plugged into a PC or plugged into a WiFi, router communicating with the Internet. It sends RF commands to configure devices such as:
  • Periodically devices transmit analogue data and every 50 seconds when they are halfway to alarming in order to:
  • RSSI Test 1 RSSI Test 3 RSSI Difference 4 (Hall) -75 dBm -75 dBm 0 2 (Kitchen) -71 dBm -67 dBm 4 5 (Bedroom 1) -87 dBm -87 dBm 0 3 (Utility room) -67 dBm -79 dBm -12 7 (Bedroom 3) -87 dBm -87 dBm 0 6 (Bedroom 2) -95 dBm -91 dBm 4 8 (Bedroom 4) -79 dBm -91 dBm -12
  • RSSI Test 3 RSSI Difference 4 (Hall) -71 dBm -71 dBm 0 1 (Sitting room) -67 dBm -67 dBm 0 5 (Bedroom 1) -83 dBm -83 dBm 0 3 (Utility room) -51 dBm -59 dBm -8 7 (Bedroom 3) -75 dBm -75 dBm 0 6 (Bedroom 2) -79 dBm -79 dBm 0 8 (Bedroom 4) -71 dBm -71 dBm 0 1 (Sitting room) -67 dBm -67 dBm 0 5 (Bedroom 1) -83 dBm -83 dBm 0 3 (Utility room) -51 dBm -59 dBm -8 7 (Bedroom 3) -75 dBm -75 dBm
  • a monitoring device may incorporate alarm condition sensing and so be a combined alarm device and monitoring device.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Emergency Management (AREA)
  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Alarm Systems (AREA)
  • Selective Calling Equipment (AREA)
  • Mobile Radio Communication Systems (AREA)

Claims (14)

  1. Un réseau de dispositifs d'alarme sans fil (1) comprenant :
    une pluralité de dispositifs d'alarme (A-L), chacun d'eux comprenant un processeur, une interface de communication sans fil et un capteur d'état, les dispositifs étant adaptés de façon à communiquer par la transmission de messages de manière non filaire,
    où chaque dispositif est adapté de façon à, dans un mode d'apprentissage, s'enregistrer automatiquement dans une grappe de surveillance (2-5), et
    où chaque dispositif est adapté de façon à surveiller chaque autre dispositif ou dispositifs dans sa grappe et à générer une alerte s'il détermine qu'un dispositif dans sa grappe n'envoie pas de messages,
    caractérisé en ce que
    chaque dispositif est adapté de façon à, dans le mode d'apprentissage,
    s'enregistrer automatiquement dans une grappe en fonction de puissances de signal reçues, RSSI, dans lesquelles il est adapté de façon à reconnaître un dispositif comme étant dans sa grappe si au moins la puissance de signal reçue correspondant au dispositif dépasse un seuil,
    chaque dispositif est adapté de façon à, au cours du mode d'apprentissage, radiodiffuser des messages et déterminer une puissance de signal en fonction de messages de radiodiffusion reçus, où au cours du mode d'apprentissage,
    chaque dispositif est adapté de façon à apprendre des codes d'identifiant de dispositifs communiquant directement, et
    les dispositifs sont adaptés de façon à exécuter les opérations suivantes au cours du mode d'apprentissage :
    un premier dispositif (A-L) demande à un deuxième dispositif à partir duquel il reçoit des messages le plus fortement de le surveiller,
    le deuxième dispositif (A-L) accepte uniquement s'il reçoit des messages provenant du premier dispositif avec une marge d'évanouissement suffisante,
    si le deuxième dispositif accepte, il enregistre le premier dispositif en tant que membre de sa grappe,
    si le premier dispositif échoue à obtenir un accord de surveillance du deuxième dispositif, il demande à un dispositif suivant avec le signal le plus puissant suivant de le surveiller, et il répète cette opération jusqu'à ce qu'il soit surveillé, et
    les autres dispositifs se comportent de manière similaire jusqu'à ce que tous soient surveillés.
  2. Un réseau de dispositifs d'alarme sans fil selon la Revendication 1, où chaque dispositif est adapté de façon à générer une alerte uniquement si :
    il ne reçoit pas directement des messages provenant d'un dispositif dans sa grappe, et
    il n'apprend pas qu'un autre dispositif a reçu des messages provenant dudit dispositif dans un délai spécifié.
  3. Un réseau de dispositifs d'alarme sans fil selon l'une quelconque des Revendications précédentes, où un dispositif est adapté de façon à radiodiffuser un message d'état intra-grappe de déclenchement qui amène les autres dispositifs dans sa grappe à répondre, et où au moins un dispositif est adapté de façon à transmettre un message d'état dans une séquence spécifiée, de façon à empêcher un conflit, à la réception d'un message d'état, et où la séquence spécifiée comprend à la fois le moment auquel transmettre le message d'état et le moment auquel écouter les autres messages.
  4. Un réseau de dispositifs d'alarme sans fil selon l'une quelconque des Revendications précédentes, où au moins un dispositif est adapté de façon à interrompre la surveillance d'un autre dispositif dans sa grappe si ses messages deviennent intermittents, sous réserve qu'il soit surveillé par un autre dispositif.
  5. Un réseau de dispositifs d'alarme sans fil selon l'une quelconque des Revendications précédentes, où le réseau comprend un système de surveillance et au moins un dispositif est adapté de façon à télécharger vers le système de surveillance, suite à une demande du système de surveillance, des données concernant des dispositifs qu'il surveille dans sa grappe, où lesdites données comprennent des données de niveau RSSI les plus récentes.
  6. Un réseau de dispositifs d'alarme sans fil selon la Revendication 5, où le système de surveillance est adapté de façon à générer une table à deux dimensions indiquant des dispositifs qui sont en communication directe et le niveau de répétition entre ceux qui ne sont pas en communication directe, et où le système de surveillance est adapté de façon à générer un affichage en fonction de ladite table, l'affichage indiquant à un installateur une évaluation de la fiabilité du réseau.
  7. Un réseau de dispositifs d'alarme sans fil selon l'une quelconque des Revendications précédentes, où au moins certains dispositifs sont adaptés de façon à se superposer sur un premier message d'état par la transmission de leurs messages d'état après celui-ci dans une séquence spécifiée, de façon à empêcher un conflit, et où la séquence spécifiée comprend à la fois le moment exact de transmission du message d'état court ainsi que le moment auquel écouter les autres messages, de façon à empêcher un dispositif d'écouter et de transmettre au même moment.
  8. Un réseau de dispositifs d'alarme sans fil selon l'une quelconque des Revendications précédentes, où au moins certains dispositifs sont adaptés de façon à envoyer des messages comprenant leurs propres numéros de série, et si un dispositif échoue à entendre son propre numéro de série, envoyer un message d'alerte indiquant qu'il n'est pas surveillé par au moins un autre dispositif.
  9. Un réseau de dispositifs d'alarme sans fil selon la Revendication 8, où chaque dispositif est adapté de façon à d'abord envoyer une commande de demande demandant quels dispositifs surveillent un dispositif particulier, et à déterminer à partir des réponses si au moins un autre dispositif surveille ledit dispositif.
  10. Un réseau de dispositifs d'alarme sans fil selon l'une quelconque des Revendications précédentes, où au moins certains dispositifs sont adaptés de façon à recevoir et à traiter directement des messages inter-grappes provenant de dispositifs qui sont à l'extérieur de sa grappe, et à éviter de déclencher une alerte s'il ne reçoit pas un message provenant d'un dispositif membre de grappe s'il détermine à partir desdits messages inter-grappes qu'un autre dispositif a reçu un message provenant dudit dispositif membre de grappe, et où lesdits dispositifs sont adaptés de façon à traiter uniquement des messages inter-grappes reçus au cours d'une période temporelle immédiatement précédente prédéfinie.
  11. Un réseau de dispositifs d'alarme sans fil selon l'une quelconque des Revendications précédentes, où lesdits dispositifs d'alarme comprennent des dispositifs d'alarme de fumée, de chaleur et de gaz toxiques.
  12. Un dispositif d'alarme sans fil comprenant un processeur, une interface de communication sans fil et un capteur d'état, le dispositif étant adapté de façon à communiquer par la transmission de messages de manière non filaire, où le dispositif est adapté de façon à :
    dans un mode d'apprentissage, s'enregistrer automatiquement dans une grappe de surveillance,
    surveiller chaque autre dispositif ou dispositifs dans sa grappe et générer une alerte s'il détermine qu'un dispositif dans sa grappe n'envoie pas de messages, caractérisé en ce que
    le dispositif est adapté de façon à, dans le mode d'apprentissage, s'enregistrer automatiquement dans une grappe selon des puissances de signal reçues, dans lesquelles il est adapté à reconnaître un autre dispositif comme étant dans sa grappe si au moins la puissance de signal reçue correspondant à l'autre dispositif dépasse un seuil, et
    le dispositif est adapté de façon à, au cours du mode d'apprentissage,
    radiodiffuser des messages et déterminer une puissance de signal en fonction de messages de radiodiffusion reçus, où, au cours du mode d'apprentissage, le dispositif est adapté de façon à apprendre des codes d'identifiant de dispositifs communiquant directement, et
    le dispositif est adapté de façon à exécuter les opérations suivantes au cours du mode d'apprentissage :
    fonctionner en tant que premier dispositif (A-L) de façon à demander à un deuxième dispositif à partir duquel il reçoit des messages le plus fortement de le surveiller,
    fonctionner en tant que deuxième dispositif (A-L) de façon à accepter une demande provenant d'un dispositif fonctionnant en tant que premier dispositif uniquement s'il reçoit des messages provenant du premier dispositif avec une marge d'évanouissement suffisante, et s'il accepte la demande, il enregistre le premier dispositif en tant que membre de sa grappe,
    en cas de fonctionnement en tant que premier dispositif, s'il échoue à obtenir un accord de surveillance d'un deuxième dispositif, il demande à un dispositif suivant avec le signal le plus puissant suivant de le surveiller, et il répète cette opération jusqu'à ce qu'il soit surveillé.
  13. Un dispositif d'alarme sans fil selon la Revendication 12, où le dispositif est adapté de façon à générer une alerte uniquement si :
    il ne reçoit pas directement des messages provenant d'un dispositif dans sa grappe, et
    il n'apprend pas qu'un autre dispositif a reçu des messages provenant dudit dispositif dans un délai spécifié.
  14. Un dispositif d'alarme sans fil selon l'une quelconque des Revendications 12 ou 13, où le dispositif est adapté de façon à recevoir et à traiter directement des messages inter-grappes provenant de dispositifs qui sont à l'extérieur de sa grappe, et à éviter de déclencher une alerte s'il ne reçoit pas un message provenant d'un dispositif membre de grappe s'il détermine à partir desdits messages inter-grappes qu'un autre dispositif a reçu un message provenant dudit dispositif membre de grappe.
EP12188123.9A 2011-10-12 2012-10-11 Réseau maillé de dispositif d'alarme RF à faible courant Active EP2581891B8 (fr)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
IE20110457 2011-10-12

Publications (4)

Publication Number Publication Date
EP2581891A2 EP2581891A2 (fr) 2013-04-17
EP2581891A3 EP2581891A3 (fr) 2014-05-07
EP2581891B1 true EP2581891B1 (fr) 2015-10-28
EP2581891B8 EP2581891B8 (fr) 2015-12-30

Family

ID=47010391

Family Applications (1)

Application Number Title Priority Date Filing Date
EP12188123.9A Active EP2581891B8 (fr) 2011-10-12 2012-10-11 Réseau maillé de dispositif d'alarme RF à faible courant

Country Status (2)

Country Link
EP (1) EP2581891B8 (fr)
IE (1) IE20120451A1 (fr)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2843636B1 (fr) 2013-08-23 2018-06-13 E.I. Technology Surveillance et commande de systèmes d'alarme
FR3013143B1 (fr) * 2013-11-14 2017-07-21 Finsecur Dispositif et procede de securisation d'un site
WO2015071606A1 (fr) * 2013-11-14 2015-05-21 Finsecur Procédé et dispositif de déploiement d'une liaison entre au moins un système de sécurité et une centrale d'alarme
US9609399B2 (en) 2015-05-12 2017-03-28 Honeywell International Inc. Automatic reporting of prognosis data from wireless mesh sensors to cloud
WO2017072559A1 (fr) 2015-10-30 2017-05-04 Ebs Sp. Z O.O. Système d'alarme et transmetteur d'alarme
GB2557992B (en) 2016-12-21 2021-08-18 Texecom Ltd Frequency hopping spread spectrum communication in mesh networks

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5587705A (en) 1994-08-29 1996-12-24 Morris; Gary J. Multiple alert smoke detector
EP1501060B1 (fr) 2003-07-25 2007-11-21 E.I. Technology Limited Un dispositif d'alarme de fumée
EP1903523B1 (fr) 2006-09-21 2008-12-31 E.I. Technology Limited Systèmes d'alarme
DE102008063454B4 (de) * 2008-12-17 2012-05-31 Siemens Aktiengesellschaft Verfahren zum Überwachen von Netzwerkknoten
GB201003826D0 (en) * 2010-03-08 2010-04-21 Texecom Ltd An improved alarm system

Also Published As

Publication number Publication date
EP2581891B8 (fr) 2015-12-30
EP2581891A2 (fr) 2013-04-17
IE20120451A1 (en) 2013-05-08
EP2581891A3 (fr) 2014-05-07

Similar Documents

Publication Publication Date Title
EP2581891B1 (fr) Réseau maillé de dispositif d'alarme RF à faible courant
US10966154B2 (en) Master slave wireless fire alarm and mass notification system
US11425897B2 (en) Wireless notification systems and methods for electronic rodent traps
KR100328853B1 (ko) 무선 단말기를 이용한 중계기 감시 시스템 및 방법
US8707075B2 (en) Adaptive network and method
US8115593B2 (en) Adaptive network and method
KR101217989B1 (ko) 무선 측정 수집 방법 및 무선 단말
CN101395868B (zh) 在无线网络中报告无干扰信道以及帮助孤立节点
JPH07170583A (ja) 遠隔データ取得及び通信のシステム
EP2826279A1 (fr) Procédé pour synchroniser des informations d'état d'un système sans fil domestique
US20190226873A1 (en) Node communication with unknown network id
EP2843636A1 (fr) Surveillance et commande de systèmes d'alarme
US20190073895A1 (en) Alarm system
EP3836107A1 (fr) Système de surveillance de sécurité
CN106060857A (zh) 无线通信系统、无线通信设备和无线通信方法
JP6481918B2 (ja) 無線通信システム
JP2015014986A (ja) 警報器及び警報システム
WO2020039042A1 (fr) Système de surveillance de sécurité, nœud et unité centrale associée
JP2014204423A (ja) 無線通信システム
JP5707558B2 (ja) 無線通信システム、無線信号のデータ構造、受信器、及び送信器
JP2006018769A (ja) 無線検針装置

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

PUAL Search report despatched

Free format text: ORIGINAL CODE: 0009013

AK Designated contracting states

Kind code of ref document: A3

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

RIC1 Information provided on ipc code assigned before grant

Ipc: G08B 29/06 20060101ALI20140403BHEP

Ipc: G08B 25/00 20060101AFI20140403BHEP

17P Request for examination filed

Effective date: 20141008

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

INTG Intention to grant announced

Effective date: 20150612

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: AT

Ref legal event code: REF

Ref document number: 758313

Country of ref document: AT

Kind code of ref document: T

Effective date: 20151115

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

RAP2 Party data changed (patent owner data changed or rights of a patent transferred)

Owner name: E.I. TECHNOLOGY

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602012011931

Country of ref document: DE

REG Reference to a national code

Ref country code: NL

Ref legal event code: FP

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG4D

REG Reference to a national code

Ref country code: DE

Ref legal event code: R081

Ref document number: 602012011931

Country of ref document: DE

Owner name: E.I. TECHNOLOGY UNLIMITED COMPANY, IE

Free format text: FORMER OWNER: E.I. TECHNOLOGY LTD., SHANNON, COUNTY CLARE, IE

Ref country code: AT

Ref legal event code: MK05

Ref document number: 758313

Country of ref document: AT

Kind code of ref document: T

Effective date: 20151028

Ref country code: DE

Ref legal event code: R082

Ref document number: 602012011931

Country of ref document: DE

Representative=s name: MITSCHERLICH, PATENT- UND RECHTSANWAELTE PARTM, DE

REG Reference to a national code

Ref country code: NL

Ref legal event code: HC

Owner name: E.I. TECHNOLOGY; IE

Free format text: DETAILS ASSIGNMENT: VERANDERING VAN EIGENAAR(S), VERANDERING VAN NAAM VAN DE EIGENAAR(S); FORMER OWNER NAME: E.I. TECHNOLOGY LIMITED

Effective date: 20151215

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20151028

Ref country code: IT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20151028

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160228

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160128

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20151028

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20151028

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: AT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20151028

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160229

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20151028

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20151028

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20151028

Ref country code: RS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20151028

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20151028

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20160129

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20151028

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602012011931

Country of ref document: DE

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 5

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20151028

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20151028

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20151028

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20151028

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20151028

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

26N No opposition filed

Effective date: 20160729

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20151028

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: BE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20151028

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20151028

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20161031

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20161031

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20161011

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 6

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HU

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT; INVALID AB INITIO

Effective date: 20121011

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20151028

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MT

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20161031

Ref country code: MK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20151028

Ref country code: TR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20151028

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20151028

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 7

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: AL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20151028

REG Reference to a national code

Ref country code: DE

Ref legal event code: R082

Ref document number: 602012011931

Country of ref document: DE

Representative=s name: MITSCHERLICH, PATENT- UND RECHTSANWAELTE PARTM, DE

Ref country code: DE

Ref legal event code: R081

Ref document number: 602012011931

Country of ref document: DE

Owner name: E.I. TECHNOLOGY UNLIMITED COMPANY, IE

Free format text: FORMER OWNER: E.I. TECHNOLOGY, SHANNON, IE

REG Reference to a national code

Ref country code: NL

Ref legal event code: HC

Owner name: E.I. TECHNOLOGY UNLIMITED COMPANY; IE

Free format text: DETAILS ASSIGNMENT: CHANGE OF OWNER(S), CHANGE OF OWNER(S) NAME; FORMER OWNER NAME: E.I. TECHNOLOGY LIMITED

Effective date: 20190226

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230420

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: IE

Payment date: 20230731

Year of fee payment: 12

Ref country code: GB

Payment date: 20230801

Year of fee payment: 12

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: NL

Payment date: 20231020

Year of fee payment: 12

Ref country code: FR

Payment date: 20230829

Year of fee payment: 12

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20230911

Year of fee payment: 12