HK1124469A - System bridge and timeclock for rf controlled lighting systems - Google Patents

Description

System bridge and clock for RF controlled lighting system

RELATED APPLICATIONS

The present application claims the benefit of U.S. application No.10/681,062 entitled "System Bridge and timing For RF Controlled Lighting Systems" filed on 8/10/2003, which claims the benefit of U.S. application No.60/477,505 entitled "System Bridging and timing For RF Controlled Lighting Systems" filed on 10/6/2003, the entire contents of which are hereby incorporated by reference.

Technical Field

The present invention relates generally to lighting control systems. In particular, the invention relates to interconnected lighting control systems, wherein the lighting control systems operate at the same Radio Frequency (RF). More particularly, the present invention relates to apparatus and methods for such interconnections.

Background

Lighting applications may be realized with a combination of predetermined lighting devices operating at predetermined light intensity levels. For example, residential lighting applications may require multiple lighting situations or "scenes". The first scenario may be required when the resident is at home and active in the room. In such a scenario, full intensity light is illuminated at various locations to achieve safe movement within the room. The second scenario may be needed when the resident is out. For example, outdoor light and indoor light may be illuminated at different intensity levels for safety or other reasons. Likewise, other scenarios may be configured for residents on vacation, entertainment, or performing any other type of activity. As lighting devices and/or scenes increase, it would be more convenient to control the lighting devices from a central location rather than individually controlling each lighting device.

There are a number of systems in lighting applications that enable remote control of lighting devices. Wireless lighting control is common in residential and commercial applications because it is easy and low cost to install compared to wired systems. Wired systems have a number of disadvantages due to the need for hard-wired lighting control devices in lighting applications. For example, renovating an existing building to provide a wiring system may involve routing wires through a wall or other structure, installing cable trays or ducts, and/or passing wires through existing ducts. If the building in which the cable system is to be installed is still in the planning stage, it is necessary to incorporate the supply lines into the design plan for the building if the above-mentioned renovation problems are to be avoided. In either case, planning and installation of the wired system requires labor, which increases costs.

In contrast, wireless systems are generally a more economical option than hardwired lighting control systems because the need to install and connect wires is greatly reduced, which is particularly important for existing buildings. Without having to plan for installation of lighting control devices during the design of a building, or having to retrofit an existing building, the owner or operator of the building can simply place the lighting control devices where such devices are desired. Such devices may be battery powered or may simply be connected to a power outlet. The cost savings of wireless systems are particularly significant in older existing buildings that would otherwise require complex and/or cumbersome renovations. Wireless systems are also a preferred choice for home applications, as such applications are generally more cost-intensive than commercial applications.

One way to implement a wireless lighting control system with wireless lighting control devices is to enable the devices to communicate with each other through Radio Frequency (RF) transmissions. An example of such an RF system is manufactured by Lutron Electronics of Coorpersburg PAProvided is a system. Push buttonProtocol, all devices in a subnet operate at the same frequency, wherein a subnet is a single oneProvided is a system. The single frequency can avoid the interference with other devices in the building, meet the FCC standard, reduce the cost and the like. However, as a result of this, it is possible that devices within the sub-network may interfere with each other due to simultaneous transmissions on the same frequency. In addition, in existing RF lighting control systems, there is a limit to the number of devices that can be controlled on a single network. Too many numbers of devices may conflict with FCC regulations, as these regulations only allow transmission on a particular frequency for a certain length of time. Current systems, e.g.Allowing a maximum of 32 devices to be controlled.

In some applications, more lighting control devices than a single subnet can control must be used. Thus, a second subnet may be needed to control all desired devices. It will be appreciated that placing two wireless lighting control systems close to each other can cause serious problems when both are operating at the same frequency, especially when the lighting scene involves two sub-networks. In particular, it is possible that the various subnets communicate simultaneously and thus interfere with each other by causing message collisions and unnecessarily generating RF. Although the chance of interference within one subnet may be small due to the relatively short RF transmission times used within a single subnet, in a multi-subnet scenario, the RF transmission times are increased due to the greater number of devices that must receive and transmit RF transmissions.

For example, when two unrelated subnets are located close together, each subnet risks interfering with the other. However, since each subnet is irrelevant, the timing of lighting events (e.g. scenes) in each subnet will only occur at the same time by coincidence. Conversely, when two or more subnets are functionally combined, a lighting scene involving more than one subnet may intentionally cause each active subnet to communicate at the same time. As a result, in the multi-subnet system, the RF transmission time increases for a point where interference may occur.

Therefore, there is a need for a method for increasing the number of devices that can be controlled by a lighting control network that uses a single RF. In particular, there is a need for a method of linking multiple subnets that can coexist as a single entity operating at the same RF and interact and communicate with each other globally without data collision. More specifically, there is a need for a method of initiating a programmable lighting event involving multiple subnets through a central control.

Disclosure of Invention

In view of the above, a bridging device and method is described which provides links between lighting networks, called sub-networks, which operate at the same RF, while being close to each other. In embodiments of the present invention, a bridge is provided between two or more subnets that allows each subnet to receive and transmit RF signals or messages to devices within the subnet or to other subnets while minimizing message collisions. Thus, an embodiment allows controlling a programmable lighting scene involving lighting devices controlled by a plurality of subnets. Another embodiment of the invention is directed to a communication method for communicating information between a plurality of subnets.

In an embodiment of the present invention, two or more closely located subnets are provided, wherein each subnet operates at the same RF. One embodiment enables each subnet to communicate with each other while allowing some overlap control between subnets through the master controller. Accordingly, one embodiment of the present invention provides global performance through, for example, programming and operation of imaginary buttons that are operatively connected to the bridge device. An embodiment also minimizes the possibility of subnets communicating simultaneously, thereby avoiding data collisions.

Embodiments of the present invention extend the number of devices that can be controlled and operated using the main control panel. For example, inIn the system, controllable devices can be increased from 32 to 64 controllable devices. In other embodiments, a different number of devices may be controlled.

Drawings

The foregoing summary, as well as the detailed description of the preferred embodiments, will be better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, there is shown in the drawings exemplary embodiments of the invention; however, the invention is not limited to the specific methods and instrumentalities disclosed. In the drawings:

FIG. 1 is a block diagram illustrating an exemplary RF lighting control system;

FIG. 2A is a block diagram of an exemplary bridging device in accordance with one embodiment of the present invention;

fig. 2B is a block diagram of an exemplary RF lighting control system operatively interconnected by a bridging device according to one embodiment of the present invention;

FIG. 3 is a flow diagram illustrating a method of bridging two RF lighting control systems according to an embodiment of the present invention;

FIG. 4 is an exemplary timing diagram of a bridging system according to one embodiment of the present invention;

FIG. 5 is an exemplary timing diagram of a communication protocol for overcoming a crosstalk situation, according to one embodiment of the present invention;

6A-C are exemplary timing diagrams of communication protocols for executing sequential commands in a single subnet, according to one embodiment of the invention;

figures 7A-C are exemplary timing diagrams of a communication protocol for executing successive commands across two subnets according to one embodiment of the present invention.

Detailed Description

Embodiments of the present invention relate to operatively interconnecting two or more RF lighting control systems that operate in close proximity to each other at the same RF. In such embodiments, proximity refers to the ability of at least one device in one RF lighting control system to transmit RF signals that can be received by at least one device in a second RF lighting control system. It should be appreciated that the RF signal used by such a lighting control system may be any frequency suitable for the intended location and use of the lighting control system. For example, the frequency may be selected to comply with FCC regulations, avoid conflict with other devices in the area in which the lighting control system is operating, or based on other considerations.

As described above, one embodiment of the present invention relates to a lighting control system that can be employed in a building or the like. Examples of such lighting control systems are described in U.S. Pat. nos. 5,982,103, 5,905442, 5,848,054, 5,838,226, and 5,736,965; all of which are assigned to Lutron Electronics, inc, and are incorporated herein in their entirety by reference. Reference may also be made to the website of Lutron Electronicshttp://www.lutron.comMore aboutImplementation and usage of the system. Based on the incorporated references, one skilled in the art should be familiar with methods of implementing RF lighting control systems, and therefore, a detailed discussion of these topics is omitted herein for the sake of brevity.

One embodiment of the present invention includes a bridging device, such as a system bridge or system bridge and clock (SBT) linking independent RF controlled networks, and a communication method employed by such a bridging device. In one embodiment, such a device and method may be used to bridge two subnets of, for example, an RF lighting system. In such an embodiment, all control functions within the subnet are accomplished by RF signals between the master control device, the lighting control device, and/or (if desired) the repeater. The master control device provides a plurality of control buttons designated for controlling various lighting devices and a status indicator reflecting the status of the lighting control system. The repeater is used to ensure that all devices can receive communications transmitted over RF signals for the purpose of controlling the devices, when required. In combination withIn one embodiment of the system, the lighting control devices communicate with each other via RF (e.g., 390, 418, or 434 MHz).

Turning now to fig. 1, a system is provided illustrating an exemplary RF lighting control system (e.g., for example)System, etc.). The system 100 includes a master controller 11 for enabling a user to input commands to the system 100 and to view lighting status information that may be displayed on an indicator 16, which indicator 16 may include, for example, an LED, an LCD screen, or the like. Further, the system 100 includes a lighting control device 12, such as a dimmer. The repeater 13, as its name implies, receives signals from the master controller 11 and/or the lighting control devices 12 and forwards the signals to provide an increased range of RF transmission. It will be appreciated that the relay 13 is optional, as in some applications the master controller 11 and/or the lighting control devices 12 are arranged such that they can communicate directly without the relay 13. The master controller 11, the lighting control devices 12 and the optional repeater 13 are operatively connected to each other by a wireless communication link 15. As described above, all devices of system 100 operate at the same RF on each communication link 15.

The user selects to activate a particular lighting scene, which is started by operating the master controller 11. The signal is then passed to the appropriate lighting control device 12 to perform the functions required for the scene. It will be appreciated that the signal may be forwarded through the repeater 13 to ensure that the lighting control apparatus 12 receives the signal. It should also be appreciated that the signal may contain various pieces of information. For example, the signal may contain an identifier corresponding to the master controller 11 and/or the lighting control apparatus 12, etc., in addition to a command for performing a specific function. Additional formatting information may be provided, such as a room address for uniquely identifying the system 100. Any type of formatting or configuration of the signal is consistent with embodiments of the present invention.

Once the signal has been received by the lighting control device 12, which then controls the lamp 14 if required, the lighting control device 12 transmits the signal back to the master controller 11. The main controller 11 indicates confirmation by illuminating the indicator 16 light, confirming that the task was successfully completed. The indicator 16 may represent any type of information such as the intensity level of the light 14, the on/off status, and/or the like.

It should be understood that the user may directly operate the lighting control device 12 if the user wishes to affect only one lamp 14, for example by changing the light intensity of the lamp 14. In such an embodiment, the lighting control device 12 may send a signal to the master controller 11 informing the master controller 11 of the changed intensity. In such an embodiment, the changed state will be updated by the indicator 16. Alternatively, the lighting control device 12 may wait until the master controller 11 transmits a signal, thereby updating the status of the lighting control device 12 only when the master controller 11 polls (poll). It should be understood that the RF lighting control system of fig. 1 is merely exemplary, and any number or configuration of devices is consistent with embodiments of the present invention.

It should be appreciated that in the system of fig. 1, a "subnet" includes at least one master controller 11 and at least one lighting control apparatus 12. As described above, the presence of the repeater 13 is only required when it is required that it is necessary to ensure successful transmission and reception of signals between the main controller 11 and the lighting control device 12. In contrast, in embodiments of the present invention, subnets linked by a bridge need only comprise a single device, as will be discussed below in connection with fig. 3 to 7. As will be seen below, a bridge according to an embodiment of the present invention includes the functionality of the master controller 11. Thus, the subnet in one embodiment need only include a single master controller 11 or a single lighting control device 12, although a greater number of devices is equally consistent with embodiments of the present invention.

Bridging method

As described above, in applications with more than one closely related functionally-related subnet, the chances of encountering interference due to simultaneous transmissions by more than one device (e.g., master controller 11) increase. Accordingly, in an embodiment of the present invention, a bridging device is provided. Turning now to fig. 2A, a block diagram of an exemplary bridging device is shown, in accordance with one embodiment of the present invention. The bridge 200 includes a transmitter 205 and a receiver 210 adapted to operate at the RF used by each subnet (not shown in fig. 2A for clarity). Operatively connected to the transmitter 205 and the receiver 210 is a processor 215, which may be a general purpose or special purpose computing device, adapted to control the functions of the bridge 200. It should be understood that processor 215 may comprise a single processor, or it may comprise multiple processors operating in parallel. For example, in one embodiment of the invention, processor 215 includes a first processor for controlling RF transmission and reception and some input/output (I/O), and a second processor for controlling I/O, display, and memory.

Operatively connected to processor 215 are memory 240, I/O225, and display 250. The memory 240 may be any type of data storage device, such as RAM, flash memory, ROM, etc. I/O225 may be any combination of devices for inputting data or instructions to bridge 200, or for displaying status information, instructions, or the like. Additionally, I/O225 may include a data connection, such as an RS-232 connection or the like, for connecting to an external data source. For example, in one embodiment, bridge 200 receives timing information from an external device through I/O225. Memory 240 may contain information that may be used in conjunction with such timing information. For example, the memory 240 may contain sunrise and sunset information for one or more geographic locations, which are then processed by the processor 215 in the case of received timing information, so that the bridge 200 can perform predetermined actions at sunrise and sunset. In another embodiment, such timing information may be generated internally within bridge 200.

It should be appreciated that a user may interact with bridge 200 through I/O225 and display 250. In one embodiment, display 250 is an LCD display screen that displays menu-driven prompts to a user, who is able to interact with such menus via I/O225. It should be appreciated that any type of display may be used while remaining consistent with embodiments of the present invention. Additionally, I/O225 may include, for example, a rocker switch, a keyboard port, one or more buttons, etc., which a user may manipulate to enter information and make selections in response to prompts displayed on display 250. It should also be appreciated that bridge 200 has a housing (not shown in fig. 2A for clarity) that is formed so that bridge 200 can be placed in a variety of positions. For example, the bridge 200 may be placed in an invisible area, such as a storage room, or may enhance its decorativeness for placement in a visible area of a room or building.

The bridge 200 of one embodiment links multiple independent RF networks or subnets that operate at the same frequency, as shown in fig. 2B. For example, fig. 2B is a block diagram of two exemplary RF lighting control subnets 220 and 230 operatively interconnected by a bridge 200, according to one embodiment of the present invention. Although subnets 220 and 230 are shown with master controller 11, lighting control devices 12, repeaters 13, and lighting devices 14, it should be appreciated that subnets 220 and 230 according to embodiments of the present invention need only include a single device, as described above.

As can be seen in fig. 2B, subnet 220 is operatively connected to subnet 230 through bridge 200 via wireless connections a and B. As discussed below in connection with fig. 3 through 7, the use of such a bridge 200 provides this capability for subnets 220 and 230: close running without message collisions on the shared RF when the bridge 200 is transmitting. In other words, when the bridge 200 transmits, it eliminates RF collisions between subnets 220 and 230 by keeping the other, non-communicating subnet 220 or 230 stationary during communication with subnet 220 or 230. In addition, bridge 200 also provides a means for subnets 220 and 230 to communicate with each other without one subnet disrupting the communication of the other subnet. Bridge 200 also allows subnets 220 and 230 to operate as independently operating systems while also providing global operation between independent subnets 220 and 230.

In one embodiment, the lighting scene involving functionally related subnets 220 and 230 is implemented by means of "phantom" buttons of the bridge 200. The phantom button is a virtual button programmed to have a specific function. Such imaginary buttons may be programmed via, for example, I/O225. In a single or multiple subnets 220 and 230, specific phantom buttons may be programmed to create a customized lighting scheme involving lighting devices such as the lamps 14 described above in connection with fig. 1. At one endIn such an embodiment, global operations include ALL ON (ALL ON, ALL luminaires ON), ALL OFF (ALL OFF, ALL luminaires OFF), and other programmable settings that may involve any number of luminaires from any number of subnets. In a using the aboveIn an embodiment of the system, 15 programmable settings are provided in addition to full on and full off. Although some embodiments (such as those described below in connection with fig. 4 through 7) use two subnets, it should be appreciated that the use of any number of subnets is equally consistent with embodiments of the present invention. Thus, the phantom button of the bridge 200 affects both systems of devices and can be used to control the subnets 220 and 230 from the master controller 11 or through another device (e.g., an RS-232 device).

In a single unitIn the subnet, the user activates the lighting scene by, for example, pressing a button on the master controller 11 that represents the lighting scene. In response, the master controller 11 sends RF signals to one or more lighting control devices 12 according to predetermined settings for the lighting scene. Instead, in one embodiment of the invention, the master controller 11 sends an identifier representing the selected lighting scene. The bridge 200 compares the received signal with imaginary buttons corresponding to the lighting scenes stored, for example, in the memory 240. The bridge 200 then transmits the appropriate RF signals to one or more lighting control devices 12 in one or more subnets 220 and/or 230. Therefore, the master controller 11 in one subnet can control the lighting device controlling apparatuses 12 in all the subnets 220 and 230.

In another embodiment, the bridge 200 may be used with a master controller 11, the master controller 11 to interact with an existing single subnetThe system operates in a consistent manner. For example, in some embodiments, bridge 200 may be added to pre-existing subnets 220 and/or 230, in conjunction with one or more devices, including additional subnets. It will be appreciated that this situation may arise when, for example, an existing subnet has reached its capacity and one or more additional subnets are required. As a result, one or more master controllers 11 may not be configured to send a scene identifier only in response to a button press. In such an embodiment, as discussed below in connection with fig. 3 through 8, the bridge 200 waits for the transmitting master controller 11 to end the transmission, identifies the corresponding imaginary button, and then transmits the appropriate RF signal to the appropriate lighting control device 12. In such an embodiment, although commands may be transmitted twice to some lighting control devices 12, once through the master controller 11, and once through the bridge 200, it should be appreciated that the bridge 200 is equally compatible with both types of master controller 11RF transport protocols.

In the embodiment of the present invention, use is made ofRF transmission protocol. In this protocol, devices attempt to avoid RF collisions through latency and transmission delay (backoff). Latency is the amount of time a device receiving an RF signal should wait after the signal ends before transmitting the signal. The latency is specified by the transmitting device to the receiving device. Transmission delay is also the amount of time a device receiving an RF signal should wait after the end of the signal before transmitting the signal. However, the transmission delay differs from the latency in that the transmission delay is assumed by the receiving device and not specified for the receiving device. A device receiving an RF signal, upon detecting the signal, assigns itself a transmission delay waiting after the end of the signal in order to avoid interference with any further RF signal. Once the transmission delay expires and if no other RF signal is received, the device is free to transmit if desired. In one embodiment, the length of the transmission delay is randomly determined so that devices waiting to transmit are less likely to transmitUpon expiration of the delay, the RF signals are simultaneously transmitted.

Turning now to fig. 3, a flow diagram is provided illustrating an exemplary method of bridging two RF lighting control subnets 220 and 230 in accordance with an embodiment of the present invention. In step 301, the bridge 200 detects an event. The event may be an RF transmission from the master controller 11 or the lighting control devices 12 in a subnet (e.g., subnet 220 in fig. 2 described above). Additionally, the event may be a button press action on the bridge 200 itself via the I/O225, or the like. As can be appreciated, if the event is an RF transmission, the transmission can include a lighting scene identifier, a command to a lighting control device, and/or the like. In one embodiment, the bridge 200 may also set a random transmission delay to avoid interfering with the RF transmission before proceeding to step 303 and 309.

At step 303, bridge 200 sends subnet activity (subnet) to subnets 220 and 230 to "reserve" the working RF. As discussed below in connection with fig. 4-8, subnet activity is typically initiated with a link claim. The link claim informs subnets 220 and 230 that a command is to be issued, and once each subnet 220 and 230 receives the link claim, each device in each subnet 220 and 230 stops sending and waits for a transmission from bridge 200. As described above, each device assumes a transmission delay when receiving an RF signal including link requirements. In one embodiment, the transmission delay is a random value within a predetermined range. In addition to the link requirements, subnet activity may include one or more commands to one or more devices. Thus, subnet activity enables all or part of a lighting scene. As can be appreciated, subnet activity can also include a home identifier, a device identifier, and the like. It should also be appreciated that in some embodiments, subnet activity repeats the subnet activity one or more times to ensure secure receipt of commands. Also as discussed above, in one embodiment, the bridge 200 sends a random wait time to the devices in the target subnets 220 and 230.

In step 305, an acknowledgement is received from a device, e.g., the master controller 11 and/or the lighting control device 12. As can be appreciated, in some embodiments, block 305 may be optional if the acknowledgement is not sent as part of the communication scheme of the embodiment. At step 307, a determination is made as to whether the bridge 200 will perform another subnet activity on any of the subnets 220, 230. If so, the method returns to step 303 to send another subnet activity. After completing all necessary subnet activities, the bridge 200 waits during the device transfer latency at step 309. After this time, other devices are free to transmit RF signals as needed.

Turning now to FIG. 4, an exemplary timing diagram of a bridging system in accordance with one embodiment of the present invention is provided. In system 400, block 405 represents user activity, block 410 represents master controller 12 activity within subnet 220, and blocks 415 and 420 represent bridge 200 activity in subnets 220 and 230, respectively. Block 425 + 460 illustrates an exemplary activity sequence according to one embodiment of the invention. It should be appreciated that the embodiment of fig. 4 provides an example of a global button in which one or more devices, such as lighting control devices 12, lights 14, etc., are affected in two or more subnets 220 and 230. Examples of such global buttons are the full on and full off buttons, such as described above in connection with fig. 2A-B.

In block 425, the user presses the button, and in response, the master controller 12 transmits a signal in block 430 indicating that the button is pressed. In block 435, the bridge 200 sends a global button signal in the subnet 220. It should be apparent that block 435 corresponds to blocks 706-708, 714, 720, and 726 in FIG. 7A, and block 725-756 in FIG. 7B, which are discussed below. As can be appreciated, the processor 215 or the like of the bridge 200, upon receiving the signal of block 430, may look up the hypothetical button of the corresponding lighting scene in the memory 240 or the like. In other words, the global buttons on the master controller 12 in the subnet 220 may correspond to any preprogrammed scenario of imaginary buttons in the bridge 200. The bridge 200 determines whether the button pressed by the user is local to the subnet 200 or a button affecting both subnets 220 and 230, and in the local case, then performs the process described below in connection with fig. 6A-C, and in the case of affecting both subnets 220 and 230, then performs the process described below in connection with fig. 7A-C.

In the embodiment of fig. 4, a global button is sent by bridge 200 in subnet 220 at block 435, as described above. As discussed below, in one embodiment, blocks 435 and 460 include link requirements, commands, and time periods for receiving acknowledgements therein. At block 460, a global button is sent by bridge 200 in subnet 230. Additionally, it should be appreciated that block 460 corresponds to blocks 710, 712, 716, 718, 722, 724, and 728 in FIG. 7A, and block 758 and 794 in FIG. 7C, which are discussed below. At block 445, subnets 220 and 230 wait for the link to clear. Block 445 may include waiting during a transmission delay, such as described above in connection with step 309 of fig. 3. At block 450, the display 250 of the bridge 200 illuminates, for example, the indicator 16 of the master controller 12 via an LED. As can be appreciated, the process of illuminating LEDs, etc. (as represented by block 450) may also include signaling according to the method of fig. 3.

At block 455, other LEDs or display devices, such as display 250 and/or indicator 16, are activated. It should therefore be appreciated that embodiments of the present invention allow lighting control commands and the like that are part of a global button to be executed first, with confirmation of the LEDs and the like being delayed until the end of the commands. In this way, the response time of the lamp 14 or the like, which is most concerned by the user, is reduced at the expense of a slight delay in the status indicator update, which is less noticeable by the user.

Crosstalk

The method of fig. 3 above may be better understood in an example of implementation of the method. Although fig. 5 through 7 below show only two subnets 220 and 230, it will be appreciated that any number of subnets 220 and 230 may be operatively interconnected through bridge 200. While the time required to control a large number of subnets may increase, it should be appreciated that the timing diagram is for exemplary purposes only, and that an actual timing diagram may have more or fewer blocks and/or functional blocks that execute to implement the desired commands. Accordingly, embodiments of the present invention provide a communications framework upon which a lighting control system may be implemented.

Turning now to fig. 5, an exemplary timing diagram of a communication protocol for overcoming a crosstalk situation in accordance with one embodiment of the present invention is shown. As can be seen from fig. 5 and 6 to 7 below, time advances in the direction of the time axis. As can be appreciated, none of fig. 5 through 7 are precisely to scale, as any time, communication protocol, or frequency may affect the exact spacing of these blocks.

A crosstalk situation exists where devices communicate with each other only in one sub-network, but another, adjacent sub-network operating at the same frequency, can cause interference or "crosstalk". Fig. 5 thus illustrates a basic communication event initiated by the subnet 220 for the devices contained therein, while the second subnet 230 is also present. The timing diagram illustrates crosstalk avoidance communication according to bridge 200. In fig. 5, 3 bitstreams are shown, each of which indicates the timing of subnets 220 and 230 during communications involving bridge 200.

In an embodiment of the present invention, the random wait time discussed above in connection with steps 307 and 313 is specified by the initiating subnet 220. Thus, in the crosstalk example of fig. 5, subnet 220, including the devices contained therein, assigns itself a random latency, while assigning a maximum random latency to subnet 230. Likewise, each device in each subnet 220 and 230 assumes a random transmission delay when receiving an RF signal. Thus, the "worst case" in fig. 5 is to assume the largest possible transmission delay, while the "best case" is to assume the smallest possible transmission delay. Thus, as can be appreciated, the "worst case" timing of subnet 220, as illustrated by blocks 502-518, occurs when the random wait time is the largest possible value. It should be appreciated that fig. 6B, 6C, 7B, and 7C, discussed below, illustrate such a worst case timing.

In one embodiment of the invention, there are four possible random wait and five propagation delay values, which may be specified or assumed separately. As can be appreciated, any number of latency and/or transmission delay values are equally consistent with embodiments of the present invention. Additionally, in one embodiment, the value of latency/transmission delay is a number of amounts of time necessary for the link requirements. The link claim (link container) may be any amount of time, such as five or 14 half cycles. According to one embodiment, only one timing diagram is needed when specifying the maximum latency for subnet 230, as indicated by block 520 and 534. As can be seen from fig. 5 and fig. 6 to 7 below, the solid line boxes represent actual RF transmissions and the dashed line boxes represent RF timing.

When bridge 200 transmits, bridge 200 assumes that the propagation delay is zero, thus allowing bridge 200 to transmit as soon as the command is complete. As can be appreciated, this configuration enables bridge 200 to maintain control of subnets 220 and 230, as bridge 200 is always able to transmit first after a command is executed. Once the propagation delay expires, if there is a second command to execute, the link claim may be retransmitted to subnets 220 and 230 to ensure that the RF remains free. The command is then retransmitted to the requesting subnet 220 and executed accordingly. Thus, although both subnets 220 and 230 have received the message from the command, only the requesting subnet 220 actually receives and executes the command.

Thus, upon receiving a command from subnet 220, bridge 220 transmits a link claim to both subnets 220 and 230 to "reserve" the working RF. As can be appreciated, and as described above, the command received from subnet 220 can include a scene identifier. Alternatively, such commands may comprise commands to devices in the subnet 220 (e.g. lighting control devices 12) in order to achieve a desired lighting scene. The initial link claim to subnet 220 is represented by blocks 502 and 502' and the link claim to subnet 230 is represented by block 520. Blocks 504 and 504' represent the state of subnet 220 while waiting for commands according to link requirements. By subnet 220 retaining the RF, subnet 230 temporarily suspends its communication capability so that bridge 200 can communicate with subnet 220 without interference.

Blocks 506 and 506' represent commands transmitted by the subnet 220 while the subnet 230 continues to wait at block 522. For example, block 522 represents subnet 230 waiting for a command based on the link claim that has been received at block 520, but as can be appreciated, the command has not arrived. As a result, subnet 230 remains stationary, which enables the devices in bridge 200 and subnet 220 to communicate without the threat of message collision. At blocks 508 and 508', a worst-case and a best-case random latency is assigned to subnet 220, respectively, and a maximum latency is assigned to subnet 230 at block 524. As discussed below in connection with fig. 6 and 7, in this example, the worst-case random wait for subnet 220 is any amount of time less than the maximum possible random wait time.

In the exemplary communications event of fig. 5, the command is automatically reissued to ensure that it is properly received by all devices, thereby communicating the second link claim to subnets 220 and 230, respectively, at blocks 510, 510', and 526. At blocks 512 and 512', the command is retransmitted to subnet 220, while at block 528, subnet 230 waits for the command. The command is then acknowledged by all devices in subnet 220, as represented by blocks 514 and 514'. Any method of sending, receiving, and collecting device acknowledgements is equally consistent with embodiments of the present invention.

As can be appreciated, the worst-case acknowledgement of block 514 corresponds to, for example, a subnet having a large number of devices. As described aboveIn the case of a system, a longer acknowledgement time may be obtained as the maximum number of 32 devices is approached. Meanwhile, subnet 230 continues to wait at block 530. At blocks 516 and 516', the bitmaps are exchanged to ensure that the display 16 of the master controller 11, e.g., subnet 220, is updated. At block 532, subnet 230 continues to wait. At the completion of the command sequence, subnet 220 waits for the duration of its assumed transmission delay at block 518' (representing the minimum transmission delay) and at block 518 (representing the maximum transmission delay). Also, at block 534, theThe network 230 waits for the duration of its transmission delay.

As can be appreciated, and as described above, the functionality of one embodiment of the present invention is to disable subnet 230 from communicating at this RF during the time that subnet 220 receives and executes its command. According to this embodiment, subnet 230 must wait until its transmission delay expires and the RF is open and available before it can attempt to communicate.

Successive commands to the same subnet

In some embodiments, and as described above, the bridge 200 is also able to maintain control of the RF in multiple subnets by assuming that the duration of the transmission delay is zero. This allows the bridge 200 to transmit successive commands to the same subnet or to different subnets. For example, when two global buttons are pressed, the process of transmitting one command is repeated in order to transmit the second command. As in the case of fig. 5, the bridge 200 blocks the unsolicited subnet (e.g., subnet 230) from transmitting while successively transmitting the two commands to the soliciting subnet 220.

Turning now to FIG. 6A, an exemplary timing diagram of a communication protocol for implementing sequential commands in a single subnet is shown, in accordance with one embodiment of the present invention. Fig. 6A shows the process of transmitting successive commands into the same subnet, which for exemplary purposes is subnet 220. Blocks 602 and 612 represent RF transmissions for subnet 220, blocks 614 and 616 represent RF timing for subnet 220, blocks 618 and 620 represent RF transmissions for subnet 230, and blocks 622 and 624 represent RF timing for subnet 230.

At block 602, a home button is pressed on, for example, the host controller 11 or the bridge 200. At block 604, a random transmission delay occurs until a link claim is sent to subnet 220 at block 606, and to subnet 230 at block 618, while subnet 220 waits for a command at block 614. At block 608, a first command to implement the exemplary global button is sent while limiting the maximum latency to less than 4 units as an example, as discussed in more detail below in conjunction with FIG. 6B. It should be appreciated that block 608 is functionally equivalent to block 506 and 516 described above in connection with fig. 5. Meanwhile, subnet 230 waits at block 622. Because a second command will be issued, the link claim is sent at blocks 610 and 620, where block 620 occurs when subnet 220 waits for a command at block 616. At block 612, a second command to implement exemplary global button 2 is sent, as discussed in more detail in connection with FIG. 6C. Meanwhile, subnet 230 waits at block 624.

In a similar manner to the single command processing described above in connection with fig. 5, after receiving the signal from the subnet 220, a link claim is transmitted through the bridge 200 to both subnets 220 and 230 to reserve RF for the requesting subnet 220. Upon completion of the first command, a maximum random wait time is specified for the non-requesting subnet 230 while a random wait time is specified for the requesting subnet 220. Because the requesting subnet (subnet 220) has less latency, another link claim may be communicated to subnet 230 to be able to handle any queued button press actions. This specification of the maximum random latency to subnet 230 is a means for bridge 200 to provide the ability to maintain control of the RF and continue communication with subnet 220. Then, the execution of the command is completed accordingly. Once the final command is executed and completed by bridge 200, random transmission delays are assumed by the devices in subnets 220 and 230.

Thus, turning to FIG. 6B, details of global button 1, blocks 606, 608, 614, 618, and 622 in FIG. 6A are shown. As can be seen in fig. 6B, RF transmission for subnet 220 is illustrated by blocks 625-640 and for subnet 230 is illustrated by blocks 642-656. The first and second link claim occurs at blocks 625, 626 and 642, including the time that subnet 220 waits for a command while issuing the second link claim in subnet 230. The command is transmitted to subnet 220 at block 628, while subnet 230 waits for the command at block 644. Then, at block 630, the subnet 220 is assigned a random wait time, which in the exemplary embodiment of FIG. 6B is some amount of time less than the maximum random wait time, shown as "max-1" in FIG. 6B, to indicate one wait time less than the maximum value. It should be appreciated that any amount of time less than the maximum wait time is equally consistent with embodiments of the present invention.

At block 646, a maximum wait time is specified for the subnet 230. Then, as discussed above in connection with fig. 4, another link request is issued at block 632-. The bitmap is collected at block 638 while subnet 230 waits at block 654. Finally, at blocks 640 and 656, subnets 220 and 230 wait for the duration of their assumed transmission delay, respectively.

Turning now to FIG. 6C, as can be appreciated, the details of global button 2, corresponding to blocks 610, 612, 616, 620, and 624 in FIG. 6A, appear in the same manner as described above in connection with FIG. 6B. As can be seen in fig. 6C, RF transmission for sub-network 200 is illustrated by blocks 658-. The first and second link requests occur at blocks 658, 660, and 676, which include the time required for subnet 220 to wait for a command to issue the second link in subnet 230. At block 662, the command is issued to subnet 220 while subnet 230 waits for the command at block 678. Then, a random wait time is assigned to subnet 220 at block 664, which in fig. 6B is an amount of time less than the maximum random wait time, while a maximum wait time is assigned to subnet 230 at block 680. Then, as discussed above in connection with FIG. 4, at block 666-. As was the case in fig. 6B above, the bitmap is collected at block 672 while subnet 230 waits at block 688. Finally, at blocks 674 and 690, subnets 220 and 230 wait for the duration of their assumed transmission delay, respectively.

Sequential commands in different subnets

As was the case for implementing successive commands in the same subnet as described above in connection with fig. 6A-C, in the two subnet system embodiment, the bridge 200 will respond to a button press action from the master controller 11 by transmitting a link claim to subnets 220 and 230 to reserve the RF for communication. The difference between switching subnets 220 and 230, compared to the method illustrated above in connection with fig. 7A-C, is the location where the second command is executed and the additional link requirements added before transmitting the second command. As discussed below in connection with fig. 7A-C, this additional link requirement is to ensure that the RF is clear before the next command is transmitted. An open RF-like bridge 200 has the flexibility to transmit another command to either subnet 220 or subnet 230.

Turning now to fig. 7A, an exemplary timing diagram of a communication protocol implementing sequential commands across two subnets 220 and 230 is shown, according to one embodiment of the present invention. Fig. 7A illustrates the process of transmitting successive commands to two different subnets, which for exemplary purposes are subnets 220 and 230. Block 702- > 712 represents RF transmission of sub-network 220, block 714- > 718 represents RF timing of sub-network 220, block 720- > 724 represents RF transmission of sub-network 230, and block 726- > 728 represents RF timing of sub-network 230. As was the case with block 602 in fig. 6A described above, at block 702, a home button is pressed on, for example, the master controller 11 or the bridge 200. At block 704, a random transmission delay occurs until a link claim is sent to subnet 220 at block 706 and to subnet 230 at block 720 while subnet 220 waits for a command at block 714.

At block 708, a first command to implement exemplary global button 1 is sent while limiting the random wait time to less than the maximum random wait time. Meanwhile, subnet 230 waits at block 726. Since the second command will be issued into subnet 230 at this point, a link claim is sent to both subnets 220 and 230 at blocks 710 and 722, wherein block 722 is performed while subnet 220 waits for a command at block 716. At block 712, unlike the example of fig. 6A, a second link claim is issued to subnet 220 to prevent the maximum wait period from expiring before bridge 200 completes all commands into subnet 230 at block 724. Thus, at block 728, subnet 230 waits for a command. In addition, the second link requirement ensures that any pending RF traffic from the subnet 220 or 230 is queued in that subnet to avoid message collisions. Thus, the bridge 200 ensures that it will maintain control of each subnet 220 and 230 while sending new commands and/or switching between subnets 220 and 230.

It should be appreciated that the necessity of sending the second link claim into the subnet 220 is a result of creating the smallest possible latency after the link claim. When bridge 200 is communicating with only one subnet, e.g., subnet 220, as was the case in fig. 6B-C above and fig. 7B below, the latency period of subnet 230 will not allow it to begin transmitting on the RF link while subnet 220 is active. However, as is the case in fig. 7C below, when subnet 220 receives a link claim, then waits for subnet 230 to receive a link claim and command, then waits for a maximum random wait, if subnet 230 is assigned a long random wait close to the maximum random wait, then it is likely that subnet 220 may begin transmitting RF signals before subnet 230 completes. Thus, the second link to subnet 220 requires that the RF link remain clear. Referring again to FIG. 7A, at block 724, a second command for implementing an exemplary global button is sent, as discussed in more detail in connection with FIG. 7C. Meanwhile, subnet 220 waits at block 718.

Turning now to FIG. 7B, details of the global button are shown, corresponding to blocks 706, 708, 714, and 720 in FIG. 7A. As can be seen in fig. 7B, RF transmission for subnet 220 is shown by blocks 725-. The first and second link claim occur at blocks 725, 727 and 742, including the time that subnet 220 waits for a command while issuing the second link claim in subnet 230. At block 728, the command is issued to subnet 220, while at block 742 subnet 230 waits for the command. Then, at block 730, a random wait time is assigned to subnet 220, which in the exemplary embodiment of FIG. 7B is one unit of time less than the maximum random wait time, while at block 746, a maximum random wait time is assigned to subnet 230. Then, as discussed above in connection with fig. 5 and 6B, another link request is issued at block 732-736, the command is repeated, and an acknowledgement is collected from subnet 220 while subnet 230 waits at block 748-752. At block 738, the bitmap is collected while at block 754, subnet 230 waits. Finally, at blocks 740 and 756, subnets 220 and 230 wait for the duration of their assumed transmission delay, respectively.

Turning now to FIG. 7C, it should be appreciated that the details of global button 2 correspond to blocks 710, 712, 716, 718, 722, 724, and 728 in FIG. 7A, and appear in the same manner as described above in connection with FIGS. 7A-B. As can be seen in fig. 7C, RF transmission for subnet 220 is illustrated by blocks 758-. The first and second links are to be found at blocks 758, 760, and 778, which includes the time required for subnet 220 to wait for a command to issue the second link in subnet 230. As described above in connection with fig. 7A, a third link claim (second in subnet 220) is sent at block 762 while subnet 230 waits for a command at block 780. At block 782, the command is issued to subnet 230, while at block 764, subnet 220 waits for the command. Then, at block 784, a random wait time is assigned to subnet 230, which in FIG. 7B is an amount of time less than the maximum random wait time, while at block 766 a maximum wait time is assigned to subnet 220. Then, as discussed above in connection with fig. 5, another link request is issued at block 786- > 790, the command is repeated, and an acknowledgement is collected from subnet 230 while waiting at block 768- > 772 subnet 220. The bitmap is collected at block 792 while the subnet 220 waits at block 774. Finally, at blocks 776 and 794, subnets 220 and 230 wait for the duration of their assumed transmission delay, respectively.

Accordingly, methods and systems for bridging one or more RF controlled lighting systems have been provided. While the present invention has been described in connection with the exemplary embodiments of the various figures, it is to be understood that other similar embodiments may be used or modifications and additions may be made to the described embodiment for performing the same function of the present invention without deviating therefrom. For example, those skilled in the art will recognize that the invention described in this application is applicable to any type of electronic device that communicates wirelessly over the same RF, and is not necessarily limited to lighting applications. Thus, the present invention should not be limited to any single embodiment, but rather should be construed in breadth and scope in accordance with the appended claims.

Claims (45)

1. A wireless lighting control system, comprising:

a first lighting control subnet operatively connected to a first lighting device;

a second lighting control subnet operatively connected to a second lighting device, wherein the first and second lighting control subnets operate on the same Radio Frequency (RF); and

a bridge in wireless and operative communication with the first and second lighting control subnets and the first and second lighting control devices, wherein the bridge transmits subnet activity to the first and second lighting control subnets such that the first and second lighting control subnets wait for a transmission from the bridge.

2. The system of claim 1, wherein the subnet activity is a link claim.

3. The system of claim 1, wherein the bridge transmits the subnet activity in response to detecting an RF signal.

4. The system of claim 3, wherein the bridge further waits for a transmission delay and sends a command for the first lighting device to the first lighting control subnet.

5. The system of claim 3, wherein the RF signal includes a lighting scene identifier associated with a lighting scene stored in the bridge.

6. The system of claim 5, wherein the RF signal comprises a lighting command related to a lighting scene, and wherein the bridge determines the lighting scene related to the lighting command.

7. The system of claim 5, the detected RF signal being transmitted by the first lighting control subnet in response to a button press on a master controller in the first lighting control subnet.

8. The system of claim 8, wherein the bridge further comprises a display, wherein the display indicates the status of the first and second lighting devices.

9. The system of claim 1, wherein the first lighting control subnet comprises a master controller.

10. The system of claim 9, wherein the master controller comprises an indicator, wherein the indicator displays a status of the first lighting device.

11. The system of claim 50, wherein the first lighting control subnet comprises lighting control devices.

12. The system of claim 11, wherein the lighting control device is a dimmer.

13. The system of claim 1, wherein the bridge is operatively connected to an external device.

14. The system of claim 13, wherein the bridge is operatively connected to the external device through an RS-232 connection.

15. The system of claim 13, wherein the bridge receives time information from the external device and transmits subnet activity in response to the received time information.

16. The system of claim 13, wherein the bridge transmits subnet activity in response to an alert received from the external device.

17. The system of claim 1, wherein the bridge receives time information, determines when sunrise and sunset times are reached based on the bridge's location, and transmits subnet activity relative to the sunrise and sunset times.

18. A method, comprising:

transmitting subnet activity to first and second lighting control subnets operating on the same RF, wherein the subnet activity indicates that the first and second lighting control subnets are waiting to receive transmissions from the bridge.

19. The method of claim 18, further comprising: a lighting control command is sent to the first lighting control subnet.

20. The method of claim 68, further comprising: a first latency is specified for the first lighting control subnet and a second latency is specified for the second lighting control subnet.

21. The method of claim 18, wherein the sending step is in response to a button press on the lighting-control bridge.

22. The method of claim 18, wherein the transmitting step is in response to detecting an RF signal transmitted by a master controller of the first lighting control subnet.

23. The method of claim 22, wherein the RF signal includes a lighting scene identifier associated with an imaginary button stored on the bridge.

24. The method of claim 22, wherein the RF signal comprises a second lighting control command associated with a lighting scene.

25. The method of claim 22, wherein the RF signal is transmitted by the master controller in response to a button press.

26. The method of claim 24, further comprising: determining a hypothetical button associated with the lighting scene based on the lighting control command.

27. The method as recited in claim 18, further comprising: based on the confirmation, the status of each subnet is displayed on the bridge.

28. The method as recited in claim 18, further comprising:

receiving time information;

determining sunrise and sunset times based on the stored information and the received time information; and

transmitting subnet activity according to the determination.

29. The method as recited in claim 18, further comprising: receiving time information and transmitting subnet activity in response to the time information.

30. The method as recited in claim 18, further comprising:

receiving an alarm signal; and

transmitting subnet activity in accordance with the alert signal.

31. A bridge, comprising:

a transmitter for transmitting messages to first and second lighting control subnets, wherein the first and second subnets operate at a predetermined RF;

a receiver for receiving messages from the first and second subnets on a predetermined RF;

a memory for storing information;

an input/output device for receiving or transmitting information; and

a processor, wherein the processor is operatively connected to the memory, the transmitter, the receiver, and the input/output device, and wherein the processor causes the transmitter to transmit subnet activity to the first and second subnets to instruct the first and second lighting control subnets to wait for a lighting command.

32. The bridge of claim 31, wherein the processor further causes the transmitter to transmit a first command and a random wait time to a first subnet and a maximum random wait time to a second subnet.

33. The bridge of claim 31, wherein the processor further receives an acknowledgement from the first subnet via the receiver.

34. The bridge of claim 31, wherein the subnet activity is a link requirement.

35. The bridge of claim 34, wherein the processor sends the link claim in response to receiving a signal from the master controller in the first subnet via the receiver.

36. The bridge of claim 34, wherein the processor further transmits a second link claim to the first and second subnets through the transmitter, transmits a third link claim to the first subnet, transmits a second command and a second random wait time to the second subnet, and transmits a second maximum random wait time to the first subnet, and receives a second acknowledgement from the second subnet through the receiver.

37. The bridge of claim 34, wherein the input/output device is adapted to receive an alarm signal and the processor is adapted to communicate the link requirement in response to the alarm signal.

38. The bridge of claim 31, further comprising a display device for presenting information to a user.

39. The bridge of claim 38, wherein the display device presents status information related to the first and second subnets.

40. The bridge of claim 38, wherein the display device is an LCD screen.

41. The bridge of claim 38, wherein the display device is an LED display.

42. The bridge of claim 31, wherein the RF is one of 390MHz, 418MHz, or 434 MHz.

43. The bridge of claim 31, wherein the input/output device is an RS-232 connection.

44. The bridge of claim 31, wherein the processor further transmits the command to the first subnet over a predetermined RF via the transmitter.

45. The bridge of claim 38, wherein the first subnet comprises a first master controller and a first lighting control device, and the second subnet comprises a second master controller and a second lighting control device.