Systems and methods for implementing lighting schemas for a lighting device

Abstract

A lighting device includes a lighting element, a communications interface, a processor, and a memory. The memory includes a first data structure defining a first lighting schema and instructions for causing the processor to: receive a first identifier via the communications interface, the first identifier corresponding to a first data structure, select the first data structure based on the first identifier, and operate the lighting element according to a first set of parameters defined in the first data structure.

Description

SYSTEMS AND METHODS FOR IMPLEMENTING LIGHTING SCHEMAS FOR ALIGHTING DEVICECROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent App. No. 63 / 634,804, filed April 16, 2024, which is incorporated herein by reference in its entirety.BACKGROUND

[0002] The present disclosure relates generally to safety lighting systems and methods. More specifically, the present disclosure relates to systems and methods for providing portable safety lighting, for example, which can be visible from at least three hundred sixty degrees around a particular location, or other features.SUMMARY

[0003] Systems and methods for implementing customizable lighting schemas in lighting devices are provided herein. These lighting devices may be configured to emit light visible from multiple directions, including up to three hundred sixty degrees around the device. The systems and methods described herein may allow for the selection, implementation, and modification of various lighting schemas, which can define specific lighting patterns, colors, intensities, and sequences for one or more lighting elements of the device.

[0004] In some aspects, the lighting devices may include a memory for storing multiple lighting schemas, a processor for implementing the schemas, and a communications interface for interacting with remote control devices. The systems may utilize different types of remotes, including static remotes that can activate pre-stored schemas and programming remotes that can introduce new, user-defined schemas to the lighting device. The lighting schemas may be selected and activated based on specific identifiers received from the remotes, allowing users to easily switch between different lighting configurations for various applications such as emergency signaling, recreational activities, or adherence to specific safety regulations.

[0005] In some aspects, a lighting device can include a lighting element, a communications interface, a processor, and a memory including a first data structure defining a first lighting schema and instructions for causing the processor to: receive a first identifier via the communications interface, the first identifier corresponding to the first data structure, select thefirst data structure based on the first identifier, and operate the lighting element according to a first set of parameters defined in the first data structure.

[0006] In some examples, the communications interface can be configured to pair with a first remote and to receive the first identifier from the first remote.

[0007] In some examples, the memory can include a default data structure and further include instructions for causing the processor to: determine if a remote is paired with the communications interface, and responsive to a determination that a remote is not paired with the communications interface, operate the lighting element according to a default set of parameters defined in the default data structure.

[0008] In some examples, the memory can further include instructions for causing the processor to receive a second data structure via the communications interface, write the second data structure to the memory, and operate the lighting element according to a second set of parameters defined in the second data structure.

[0009] In some examples, the set of parameters defined in the second data structure can include at least one of a color of the lighting element, an intensity of the lighting element, and a flash pattern of the lighting element.

[0010] In some examples, the lighting element can be one of a plurality of lighting elements and the set of parameters can include a button map that maps buttons of a control interface to corresponding sets of the plurality of lighting elements.

[0011] In some examples, the communications interface can be configured to pair with a second remote and to receive the second data structure from the second remote.

[0012] In some examples, the memory can further include instructions for causing the processor to determine if the second remote is paired with the communications interface, and responsive to a determination that the second remote is not paired with the communications interface, remove the second data structure from the memory.

[0013] In some examples, the lighting element can be one of a plurality of LEDs.

[0014] In some aspects, a method of operating a lighting system can include receiving a first identifier at a lighting device, selecting one of a first data structure and a second data structure based on the first identifier, the first data structure and the second data structure stored in a memory of the lighting device, and receiving an operating instruction to cause operation of a lighting element of the lighting device according to a set of parameters defined in the selected one of the first data structure and the second data structure.

[0015] In some examples, the method can include sending the first identifier via a first remote that is in wireless communication with a communications interface of the lighting device, wherein the first identifier is received at the communications interface.

[0016] In some examples, the first identifier can be received at a control interface provided on the lighting device.

[0017] In some examples, the first remote can include a first set of buttons that represent a corresponding second set of buttons of the control interface.

[0018] In some examples, the first remote can include a third set of buttons that correspond to a set of operating instructions that is locked to the first remote.

[0019] In some examples, the method can include: pairing the first remote with the lighting device, determining whether a third data structure corresponding with the first remote is stored in the memory of the lighting device, and upon determining that the third data structure is not stored in the memory, storing the third data structure in the memory of the lighting device.

[0020] In some examples, the method can include disconnecting the first remote from the lighting device, and removing the third data structure corresponding with the first remote from memory.

[0021] In some examples, the method can include receiving a signal to turn off the lighting device, and upon receiving the signal to turn off the lighting device, removing the third data structure corresponding with the first remote from the memory.

[0022] In some examples, the method can include sending a third data structure to the lighting device, and storing the third data structure in the memory of the lighting device.

[0023] In some examples, storing the third data structure in the memory of the lighting device can include overwriting one of the first data structure and the second data structure.

[0024] In some aspects, a non-transitory computer-readable medium can store instructions that, when executed by a processor, cause the processor to: determine whether a first schema corresponding with a remote device is in a set of schema, upon determining that the first data structure is not in the set of schema, store the first schema in the set schemas, activate a schema of the set of schema based on an identifier, and operate a lighting element according to a set of parameters defined in the activated schema based on an operating instruction.BRIEF DESCRIPTION OF THE DRAWINGS

[0025] FIG. 1 is an example schematic representation of a system for providing customizable lighting schemas for a lighting device, according to some aspects of the present disclosure.

[0026] FIG. 2 is a top, front, and left isometric view of an exemplary safety light according to aspects of the present disclosure.

[0027] FIG. 3 is a diagrammatic view of an example remote according to the system of FIG. 1.

[0028] FIG. 4 is an example of hardware that can be used to implement a system for providing customizable lighting schemas, including the system shown in FIG. 1 according to aspects of the present disclosure.

[0029] FIG. 5 is an example schematic illustrating a flow of data between components of the system shown in FIG. 1.

[0030] FIG. 6 is a flowchart showing an example process that can be performed by remotes and a lighting device of the system of claim 1, according to some aspects.

[0031] FIG. 7 is an example schematic illustrating a flow of data between components of the system shown in FIG. 1.

[0032] FIG. 8 is a flowchart showing an example process that can be performed by remotes and a lighting device of the system of FIG. 1, according to some aspects of the present disclosure.DETAILED DESCRIPTION

[0033] Before any embodiments of the invention are explained in detail, it is to be understood that the invention is not limited in its application to the details of construction and the arrangement of components set forth in the following description or illustrated in the following drawings. The invention is capable of other embodiments and of being practiced or of being carried out in various ways. Also, it is to be understood that the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. The use of “including,” “comprising,” or “having” and variations thereof herein is meant to encompass the items listed thereafter and equivalents thereof as well as additional items. Unless specified or limited otherwise, the terms “mounted,” “connected,” “supported,” and “coupled” and variations thereof are used broadly and encompass both direct and indirect mountings, connections, supports, and couplings. Further, “connected” and “coupled” are not restricted to physical or mechanical connections or couplings.

[0034] The term “about,” as used herein, refers to variations in the numerical quantity that may occur, for example, through typical measuring and manufacturing procedures used for articles of footwear or other articles of manufacture that may include embodiments of the disclosure herein; through inadvertent error in these procedures; through differences in the manufacture, source, or purity of the ingredients used to make the compositions or mixtures or carry out the methods; and the like. Throughout the disclosure, the terms “about” and “approximately” refer to a range of values ± 5% of the numeric value that the term precedes.

[0035] The following discussion is presented to enable a person skilled in the art to make and use embodiments of the invention. Various modifications to the illustrated embodiments will be readily apparent to those skilled in the art, and the generic principles herein can be applied to other embodiments and applications without departing from embodiments of the invention. Thus, embodiments of the invention are not intended to be limited to embodiments shown but are to be accorded the widest scope consistent with the principles and features disclosed herein. The following detailed description is to be read with reference to the figures, in which like elements in different figures have like reference numerals. The figures, which are not necessarily to scale, depict selected embodiments and are not intended to limit the scope of embodiments of the invention. Skilled artisans will recognize the examples provided herein have many useful alternatives and fall within the scope of embodiments of the invention.

[0036] The present disclosure relates generally to lighting devices, and in particular, lighting devices that can be configured as a portable safety light configured to couple to a variety of support structures. Safety lights may include an emergency beacon, construction lighting, police or fire lighting, ambulance lighting, or any of a variety of personal lighting. For example, personal lighting may include lighting worn on a person or integrated into clothing or otherwise mounted on a person. This may include lighting mounted to hats, including hard hats. Personal lighting may also be integrated with or mounted on personal transportation, such as on bicycles, kayaks, snowmobiles, off-road vehicles, boats, or other transportation systems. Personal lighting may also be integrated with specialized equipment, for example, such as skiing or snowboarding equipment, camping hiking, or fishing equipment.

[0037] In some cases, a lighting device can be configured (e.g., can be programmed) to implement a particular light operation that can correspond to safety standards or conventions for given operations. For example, state or federal authorities can require that kayaks operated at night include lights of a particular color. In some cases, regulations can require that lights operate continuously (e.g., without flashing or blinking). In some cases, a regulation orstandard can require lights of a device to flash at a particular frequency with a particular color pattern. In some cases, a light operation can require multiple colors of light, and can implement a sequence of operations (e.g., color changes, blinking, etc.) as can communicate a desired message or adhere to a desired standard in a particular context. Light emitted from a lighting device (e.g., the safety light 100) can be configured to be light of one or more colors, including both visible and non-visible light (e.g., infrared light and UV light) and the light can be emitted constantly or intermittently. For example, a lighting device can be configured to flash or blink to cause light can be emitted in regular patterns and / or in irregular patterns. In some cases, light can be emitted to provide a signal to others. In particular, light can be emitted in accordance with Morse code to send a variety of messages, included by not limited to, an SOS signal. The emission of a light can also be used to convey messages to a user, for example, to indicate a battery level. Moreover, a lighting device can be configured to provide light with different characteristics, for example, beams (e.g., columnated beams) of light, diffused or scattered light, and any combinations thereof. Similarly, a lighting device can be configured to produce light of one or more intensity (i.e., brightness). In that regard, a lighting device can be configured to produce light at discrete intensities, or over a continuous range of intensities. The characteristic of light emitted by a lighting device can be selectable by a user and can therefore be adjusted in accordance with operating conditions and the needs of the user.

[0038] In this regard, as used herein, a “schema” or a “lighting schema” refers to one or more lighting operations that a lighting device can be programmed to perform (e.g., continuously, intermittently, in response to a user input, etc.). For example, a schema can include blinking a white light at a first frequency. In another example, a schema can include repeatedly flashing light in Morse code to transmit a desired message (e.g., an SOS signal). In yet another example, a schema can include alternately flashing first lighting elements with a first lighting property (e.g., color, intensity, sequence, polarization, direction, diffusivity, collimation, etc.) at opposing corners of a lighting device, and second lighting elements with a second lighting property at other corners of the device. The first and second lighting properties can be different from one another. In still other examples a first schema can include emitting light three-hundred-sixty degrees about a lighting device, while a second schema can include emitting light along a particular direction or range of angles about the lighting device that is less than three hundred sixty degrees (e.g., about one hundred eighty degrees, ninety degrees, etc.). In some examples, light can be emitted at different angles from a device. For example, a lighting device can emit light in a vertical direction, additionally or alternatively to emittinglight at a perimeter of the device. The examples provided herein are not intended to limit the schemas that can be implemented according to this disclosure, rather, schemas can include any number of light colors, frequencies, lighting sequences, and the like.

[0039] As used herein a “static remote” is a remote capable of communicating a signal to a device to control an operation of the device according to information stored on the device. A static remote, for example, can communicate a signal that prompts a device to implement an operating mode according to data pre-stored on the device. In some cases, a static remote can communicate a signal that is interpretable by the device according to known (e.g., pre-stored) data and algorithms on the device. For example, according to some aspects of this disclosure, a static remote can communicate an identification parameter (e.g., an ID), and a device can perform a lookup using the ID to select a corresponding operating mode for the device. In some cases, a static remote can communicate a signal that can be decipherable, or otherwise interpretable by the device according to algorithms stored on the device to access and implement data structures and operating modes pre-stored on the device. Data received from a static remote can be non-persistent (e.g., can be temporarily stored on the device when the device is interacting with the remote).

[0040] As used herein, according to some aspects of the disclosure, a “programming remote” is a remote that can communicate information to a device to operate the device according to parameters not previously stored on the device. A programming remote, for example, can have stored thereon data structures and / or instructions defining an operating mode for a device, and those data structure or instructions can be unknown to the device (e.g., are not stored in a memory of the device) prior to a communication with the programming remote. A programming remote can communicate the data structures and / or instructions to a device, and the device can store the data structures and / or instructions (e.g., in a volatile or non-volatile memory). The data structures and instructions received at a device from a programming remote can be used to control an operation of the device. For example, according to some aspects of the present disclosure, and as described below, a programming remote can have stored thereon, a table defining operating parameters for a device, and when the programming remote and the device are in communication, the programming remote can communicate the table to the device, and the device can store the table in a memory and operate according to the operating parameters defined in the table. For example, the data structure and corresponding schema can be sent to the device where they are added to the set of data structures and set of schema (e.g., by appending to an existing set or by overwriting an elementin an existing set). In some cases, a programming remote can receive an input from a user to define the data structures and / or instructions to be communicated to a device.

[0041] FIG. 1 is an example schematic representation of a lighting system 10 for providing customizable lighting schemas for a lighting device, according to some aspects of the present disclosure. As shown in FIG. 1, the lighting system 10 includes a lighting device 12. In the illustrated example, the lighting device 12 is configured as a portable safety light that can be attached to a variety of support structures, as generally described above. Magnets, fasteners (e.g., threaded inserts, etc.), or other attachment points can be provided to removably couple the lighting device 12 to a support structure. Mounting accessories, including magnets, straps, clips, buckles, etc. can be used to couple the safety light 12 to a support structure.

[0042] The lighting device 12 can be generally configured to emit light. Light can be emitted from the safety light 12 in multiple directions. For example, light can be emitted from around at least a perimeter (i.e., an outer perimeter) of the lighting device 12. Accordingly, a lighting device can be configured to direct light around an entire perimeter (i.e., a periphery) of the lighting device. In some cases, the light being emitted from the lighting device can be viewed from about three hundred sixty degrees around the lighting device. In some examples, light can be emitted from the lighting device along an axis that is transverse to a perimeter of the lighting device 12. For example, light can be emitted from a lighting element configured to emit light from a top surface or a bottom surface of the lighting device 12, additionally or alternatively to light emitted at a periphery of the lighting device 12. As described further below, the lighting device 12 can include one or more lighting elements (e.g., configured as LEDs) that are configured to emit one or more frequencies (e.g., colors) of light. The lighting elements can be placed along a perimeter of the lighting device 12 to allow light to be emitted out of the periphery of the lighting device 12. In some examples, lighting elements can be positioned to emit light in other directions, such as through a lens provided in a cap. The lighting elements can be operated based on a selected (e.g., activated) lighting schema for the lighting device 12. In other examples, other types of light emitting elements can be used (e.g., incandescent bulbs, xenon bulbs, infrared bulbs, etc.).

[0043] As further shown in FIG. 1, the lighting device can include a memory 14, which is further shown and described with respect to FIG. 4. The memory 14 can have stored thereon a default data structure (e.g., a default table) defining a default lighting schema. The default schema can define a default lighting operation of the lighting device. For example, a default schema of a lighting device 12 can include a continuous emission of a white light from aperiphery of the lighting device 12. In other examples, a default schema can be any schema defined by a manufacturer. In some cases, a schema can include a behavior upon engagement of one or more controls of the lighting device 12. For example, the default schema can define a first lighting sequence to be performed upon powering up the lighting device, a second lighting sequence (e.g., a slow blinking) to be performed when a particular button of the lighting device 12 is pressed a first time, and a third lighting sequence (e.g., a rapid blinking) to be performed when the button is pressed a second time, with a third press of the button returning the lighting device 12 to the first lighting sequence. In some cases, a lighting schema only includes one lighting sequence, and pressing a button does not cycle the lighting device 12 to a next lighting sequence defined in the lighting schema.

[0044] In some cases, a memory of a lighting device (e.g., memory 14 of lighting device 12) can have multiple schemas stored thereon. For example, as further illustrated, the memory 14 further includes Schema 1, Schema 2, and Schema 3. In some examples, a lighting device 12 can include a button that allows a user to cycle through schemas stored in a memory of the lighting device 12 to select a desired schema. For example, a user may primarily use the lighting device 12 for kayaking at night and may thus opt to select a schema that adheres to regulations for lighting for kayaking, however, the user may change the light to a schema reflecting a need for roadside assistance if required.

[0045] A lighting system can include one or both of additional hardware and software external to a lighting device to facilitate a process for implementing lighting schemas. For example, as further shown in FIG. 1, the system 10 includes static remotes 16a, 16b, and programming remote 18. Each of the remotes 16a, 16b, 18 can be configured to communicate with the lighting device 12 to provide an instruction or select a lighting schema for the lighting device 12. In an example, one or more of the remotes 16a, 16b, 18 can include radio frequency identification (“RFID”) tags and can communicate with the lighting device 12 when within a range of the lighting device 12. The remotes 16a, 16b, 18 can communicate over low frequency, high frequency, or near-field communication. In other examples, the remotes and the lighting device 12 can communicate via a peer-to-peer network, (e.g., a local peer-to-peer cellular network connection, such as a 5G sidelink connection, a peer-to-peer Wi-Fi connection, a Bluetooth network, etc.), or a wired network (e.g., directly through ethernet or fiber cable). As further shown, in some examples, a remote (e.g., programming remote 18 as illustrated in FIG. 1) can communicate with the lighting device over a communication network 20, which can include a local area network (“LAN”), a wide area network (“WAN”), a cellular network, aWi-Fi network, etc. When one of the remotes 16a, 16b, 18 are in proximity to the lighting device 12, a pairing operation can be performed to link the remote and the lighting device 12. In some cases, a pairing occurs automatically when a remote 16a, 16b, 18 enters within a specific range of the lighting device 12. In other examples, a pairing operation can be initiated at one or both of the remote 16a, 16b, 18 and the lighting device 12. While the illustrated example shows each of the remotes 16a, 16b, 18 operatively connected to the lighting device 12, it is also possible that only one remote is paired to the lighting device 12 at a particular time.

[0046] In some cases, communication within a system (e.g., system 10) can include communication across different network types, or between devices. For example, in some cases, a remote (e.g., any or all of remotes 18, 16a, 16b) can communicate with another device (e.g., another remote, a computing device, an internet of things device, a cell phone, a tablet, etc.) and can receive a signal from the other device. For example, a remote can be in communication with another device over a cellular network, a LAN, a WAN, a Wi-Fi network, etc., and can receive a signal from the other device over the network. In some cases, a programming remote (e.g., programming remote 18) can receive a lighting schema over a network (e.g., communication network 20) and can operate a lighting device (e.g., lighting device 12) according to the lighting schema. In some cases, a lighting device can communicate with a remote or other device. For example, a lighting device can send an acknowledgment signal to a remote upon receipt of a communication or instruction. In some cases, a lighting device can communicate a status (e.g., an error status, an operating mode, whether the device is on or off, a lighting schema in operation, a lighting schema in memory, etc.) with a remote (e.g., remotes 16a, 16b, 18) over a radio frequency, and the remote can relay that information to another device (e.g., a computing device, a cell phone, a tablet, etc.) over a communications network (e.g., communications network 20). In some cases, a lighting devices can communicate with other lighting devices over one or more of the communication networks or communication methods described above. For example, a lighting device can operate as a remote for other lighting devices within a communication range of the lighting device. In some cases, a first lighting device operating as a remote can cause other lighting devices within a communication range of the lighting device to operate according to an identical schema as the first lighting device. In some cases, lighting devices can be operated in tandem. For example, a first lighting device can issue a signal to another lighting device within a communication range to blink alternately with the first lighting device.

[0047] In some examples, a remote can communicate with a lighting device when the remote device is within about 100 meters of the lighting device. In some cases, a static remote can communicate with a lighting device when the static remote is within 20 meters, or within 10 meters, or within 1 meter, or within 20 centimeters of the lighting device. In some cases, a range of a communication between a remote and a lighting device can correspond to a communication method. For example, in some cases, a lighting device can communicate with a GPS system, and can receive a signal from a remote at distances of about 1 mile, about 2 miles, about 3 miles, about 10 miles, etc. In some cases, a lighting device can be GPS locatable, and a remote can pair with the lighting device from any range, based on an identified location of the lighting device.

[0048] As further shown in FIG. 1, each of the remotes 16a, 16b, 18 can correspond to a schema in the memory 14 of the lighting device 12. For example, as shown, static remote 16a corresponds to Schema 1, static remote 16b corresponds to Schema 2, and programming remote 18 corresponds to Schema 3. When a remote is paired with the lighting device 12, the lighting device 12 can be configured to implement the lighting schema corresponding to the remote. For example, as described above, when the lighting device 12 is powered on, it can emit light according to the Default Schema, but when remote 16a comes into proximity and pairs with lighting device 12, the lighting device 12 can emit light according to Schema 1 (e.g., the schema corresponding to remote 16a). In some cases, remotes can be provided for particular activities having specific lighting requirements. For example, static remote 16a can be a kayaking remote and can allow the safety light 12 to implement a lighting schema that adheres to regulations for lighting for kayaking. Remote 16b can be a biking or running remote, and, once paired with the lighting device 12 can cause the lighting device 12 to emit light according to Schema 2 to adhere to lighting regulations for biking or running. In some cases, a lighting schema can be stored on the memory 14 but is not accessible without a corresponding remote. Further, a remote (e.g., static remotes 16a, 16b) can be a hardware remote, or can be implemented as a software remote (e.g., can exist in a program or application of a computing devices such as a smart phone, tablet, etc.).

[0049] In some cases, lighting schemas can be “pre-stored” in a memory of a lighting device. For example, the Default Schema, Schema 1, and Schema 2 can be loaded onto the lighting device 12 by a manufacturer, and the lighting device 12 can be sold to an end consumer including Default Schema, Schema 1, and Schema 2. In some cases, the end consumer can only access the schemas for which the consumer has a corresponding remote (e.g., one of remotes16a, 16b). Additionally, or alternatively, a lighting device can allow a user to define one or more lighting schemas. For example, in some cases, a lighting schema can be generated at a user device (e.g., the programming remote 18) and can be sent to a lighting device upon pairing of a programming remote with the lighting device. For example, in the illustrated example, the programming remote 18 comprises a user device (e.g., the programming remote 18 is implemented in an application of a smart phone of a consumer). The memory 14 can initially include the Default Schema, Schema 1, and Schema 2 at a first time, while Schema 3 can be generated on the programming remote 18. When the programming remote 18 is paired to the lighting device 12, the programming remote 18 can load (e.g., can communicate to the lighting device 12) Schema 3 onto the memory 14 of the lighting device 12, and the lighting device 12 can implement the user-defined lighting schema (i.e., Schema 3). In some examples, as further described below, a user-defined lighting schema can be deleted from a memory of a lighting device when a corresponding remote is no longer paired with the lighting device.

[0050] While, in the illustrated embodiment, a single lighting device 12 is illustrated, it should be understood that the disclosed systems and methods are applicable to a plurality of lighting devices. For example, a plurality of lighting devices can be assigned to a cluster of lighting devices, the cluster of lighting devices being programmed to operate in a tandem or identical mode. In some cases, a lighting device can be assigned to a cluster through a pairing operation, or through an engagement of a control (e.g., a button) on the device. In some cases, a cluster to which a lighting device belongs can be switched by engagement of a control on the device. A cluster of lighting devices can include any number of lighting devices, including, for example, tens of lighting devices, hundreds of lighting devices, or thousands of lighting devices. In some cases, lighting devices of a cluster of lighting devices can form a communication chain through communication between lighting devices. For example, a first lighting device in the cluster can be within a communication range of both a remote and a second lighting device, and the second lighting device can be out of range of the remote. In that case, the first lighting device can receive a signal from the remote, and can operate according to the instruction from the remote, according to the disclosure herein. The first lighting device can further communicate to the second lighting device to issue an instruction to the second lighting device based on the signal received from the remote. In some cases, the first lighting device can relay the signal from the remote to the second lighting device to control the second lighting device in an identical mode to the first lighting device. In some cases, the first lighting device can issue a different signal to the second lighting device to operate thesecond lighting device in tandem with the first lighting device, in response to the signal received from a remote. In some cases, a cluster of lighting device can include a plurality of lighting devices placed along an edge of a roadside, a route of a race, an airport runway, etc.

[0051] FIG. 2 is a top, front, and left isometric view of a safety light 100 according to aspects of the present disclosure. The safety light 100 shown is an example of a lighting device 12 usable with the lighting system 10 shown and described with respect to FIG. 1. In the illustrated example, the safety light 100 is configured as a portable light. In some situations, the safety light 100 may be a wearable or mountable light that can be worn by a user during use or otherwise carried with user equipment. In other situations, the safety light 100 may be integrated with or mounted on a vehicle, including a car, boat, construction equipment, or other motorized and non-motorized vehicles. Irrespective of the particular use or configuration, the safety light 100 is a portable light that can be moved or mounted to a desired location by a user. That is, the safety light 100 can be mounted to a variety of support surfaces and / or structures, for example, a piece of equipment, a vehicle (motorized or unmotorized), or other type support surface.

[0052] As shown, the safety light 100 generally includes a housing 104 and a lighting assembly 108 (e.g., having one or more lighting elements), which produces light that is emitted by the safety light 100. More specifically, the housing 104 generally defines an interior space 112 and the lighting assembly 108 can be retained within the housing 104. The lighting assembly 108 can be positioned inside the housing 104 of the safety light 100 to emit light through one or more lenses of the safety light 100. The lighting assembly 108can be positioned within the housing in a variety of ways to achieve a desired output. For example, lighting elements of the lighting assembly 108 can be positioned to emit light directly through a lens (e.g., lens 128) and along a desired emission direction, or to emit light in a direction to be reflected by a lens or other reflective surface to exit a lens along a desired emission direction. Further examples of lighting arrangements and lighting devices are described in U.S. Patent No. 10,677,450, U.S. Patent No. 12,066,178, U.S. Patent Application Publication No. 2025 / 0020853, and International Patent Application Publication WO2024 / 254609, each of which is incorporated herein by reference in its entirety.

[0053] The housing 104 can provide protection to the comparatively sensitive and fragile components of the lighting assembly 108, allowing the safety light 100 to be used in variety of harsh environments, for example, construction sites, factories, mines, and more generally, outdoor environments. To that end, a lighting device can withstand impacts, elevated andbelow-freezing temperatures, and ingress from water, particulate matter (e.g., dust and debris). Further, depending on the specific use, a lighting device can be configured to be resistant to various chemicals (e.g., types of chemicals). Moreover, a lighting device can be configured to meet or exceed various industry safety standards. For example, a lighting device can be certified as “Intrinsically Safe,” in that the lighting device is explosion proof and / or ATEX certified. Such certifications and industry standards may be particularly relevant for use in the oil & gas, energy, and subterranean mining industries.

[0054] In the illustrated embodiment, the housing 104 is configured as generally cuboid body, and more specifically, a rectangular cuboid. Put another way, the housing 104 can have sides that may not be perfectly flat, but rather have a curvature, which may aid in the emission of light from the housing 104. In that regard, the housing 104 generally defines six sides (collectively, the sides 116 of the housing 104), namely, a top or first side 116A opposite and substantially parallel a bottom or second side 116B, a front or third side 116C opposite and substantially parallel a back or fourth side 116D, and a left or fifth side 116E opposite and substantially parallel a right or sixth side 116F. Each of the third side 116C, the fourth side 116D, the fifth side 116E, and the sixth side 116F extend substantially perpendicularly between the first side 116A and the second side 116B. Likewise, each of the third side 116C and the fourth side 116D extend substantially perpendicularly between the fifth side 116E and the sixth side 116F. In other embodiments, a housing can be shaped differently, including being shaped as different regular or irregular polyhedrons (e.g., platonic solids, pyramids, and prisms, etc.), or as non-polyhedrons, for example, cylinders, hemispheres, toruses, etc.

[0055] The lens 128 is configured as an annulus, which may be a square annulus, or form a ring-like lens. More specifically, the lens 128 is configured as a rectangular annulus having a rectangular outer profile comprised of four sidewalls, which together, define an opening (e.g., a central opening). The lens 128 can be coupled between a top cover 120 and a bottom cover 160 of the housing 104. In this way, the shape of the lens 128 can provide the safety light 100 with an optically transparent perimeter that allows light from the lighting assembly 108 to be observed from up to three hundred sixty degrees around the safety light 100. That is, the shape of the lens 128 can allow light to be emitted around an entire perimeter of the safety light 100. Accordingly, the lens can be made of a transparent or translucent material, for example, a polymer (e.g., polycarbonate, PMMA, acrylic, transparent ABS (MABS), and urethanes (Trivex®)) or a non-polymeric material (e.g., glass, such as borosilicate glasses, and optical silicones). In some embodiments, a lens as described herein can be a single or monolithic lens;however, multiple lenses arranged to provide similar lighting characteristics are also contemplated and are within the scope of the present disclosure. In some examples, a second lens 196 can be provide in the top cover 120 to allow light to be emitted therethrough.

[0056] A lighting device can generally include a user interface (i.e., a control interface) configured to allow a user to control a one of more functions of the lighting device. In particular a user can control the emission of light from the lighting device. That is, the control interface can allow a user to control the emission of light from a lighting assembly of the lighting device. Such control interface can be configured as physical control interfaces (e.g., buttons, switches, toggles) that are physically manipulated by a user, or as a virtual interface (e.g., buttons or other types of icons on a screen, such as a touchscreen or similar interfaces implemented via an augmented reality device). Relatedly, a user interface can be provided both on a lighting device and as a remote interface. For example, with continued reference to FIG. 2, the housing 104 includes a set of buttons 208 that are configured to control one or more functions of the safety light 100. For example, the buttons 208 can operate to turn the safety light 100 on or off, to cycle through schemas in a memory of the lighting device 100, to implement different lighting operations within a given schema, to indicate a battery level, etc.

[0057] In some examples, a user interface of a remote imitate some or all of a user interface on a lighting device. For example, as shown in FIG. 3, an example remote 200 (e.g., such as remotes 16A, 16B, 18) includes a first user interface 204 having a first set of inputs 206 (e.g., physical or virtual buttons, toggles, switches, dials, etc.). The first set of inputs 206 can correspond with the set of buttons 208 on the safety light 100, or a subset of the set of buttons 208. In this way an input of the first set of inputs 206 causes similar operation as if the corresponding button 208 were activated. In the illustrated example, the set of inputs 206 are organized similar to the set of buttons 208. However, this may not always be the case and the set of inputs 208 may be arranged differently. For example, where the user interface 204 is a virtual interface, a user may be able to rearrange a layout of the set of inputs 206 into a desired arrangement, which can include removing or adding inputs to the layout. In some cases, a user can program the first set of inputs 206 to control different schema or other functions of the safety light 100, as compared with the set of buttons 208. In some cases, the remote can communicate the programming of the first set of inputs 206 to the safety light 100 to modify operation of the buttons 208 to match that of the first set of inputs 206. In other cases, the remote 200 can communicate the programming of the buttons 208 separate from programming of the set of inputs 206.

[0058] In some examples, a user interface of a remote may allow unique operations or other functionality of a lighting device that can only be activated with the remote. Still referring to FIG. 3, the remote 200 includes a second set of inputs 210 that can control operation of schema or other light functions that cannot be activated directly through the first set of buttons 208, or that can only be activated by the first set of buttons 208 while the safety light 100 is connected with the remote 200, as discussed in greater detail below. In this way, certain functions can be “locked” to the remote 200 so that they can only be activated by using the first user interface 204 of the remote 200 or when the remote 200 is connected to the safety light 100.

[0059] FIG. 4 is an example of hardware that can be used to implement a system 300 for providing customizable lighting schemas. The system can include a lighting device 302 (e.g., the lighting device 100 shown in FIG. 2 and lighting device 12 shown in FIG. 1), and one or more remotes 304, 306 (e.g., any of remotes 16a, 16b, 18 shown in FIG. 1).

[0060] As further shown in FIG. 4, the lighting device 302 can include a processor 308, memory 310, a communications interface 312, inputs 334, and lighting elements 316. In some embodiments, processor 308 can be any suitable hardware processor or combination of processors, such as a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), an application specific integrated circuit (ASIC), a field- programmable gate array (FPGA), a combination thereof, etc. A processor for a lighting device can be any known processing component configured to receive and implement instructions for operating lights of the lighting device according to particular patterns or schemas.

[0061] In some examples, memory 310 can include any suitable storage device or devices that can be used to store instructions, values, configurations, etc., that can be used, for example, by processor 308 to implement one or more lighting schemas. For example, memory 310 can include a set of data structures (e.g., tables, objects, j son objects, SQL and / or no SQL databases, files, etc.) which can at least partially store instructions for implementing one or more lighting schemas (e.g., a set of lighting schemas). The memory 310 can further include instructions usable by the processor 308 to operate the lighting device in accordance with data stored in the data structure, as further illustrated in FIG. 5. Memory 310 can include any suitable volatile memory, non-volatile memory, a non-transitory computer readable medium, storage, or any suitable combination thereof. For example, memory 310 can include random access memory (RAM), read-only memory (ROM), electronically-erasable programmable read-only memory (EEPROM), one or more flash drives, one or more hard disks, one or more solid state drives, one or more optical drives, or some combination thereof, etc. In some examples, memory 310can have encoded thereon a computer program for controlling operation of the lighting device 302. In an example, the memory 310 can include a volatile memory component (e.g., RAM, EEPROM, etc.) and a non-volatile memory component (e.g., ROM, EEPROM, etc.). The nonvolatile memory component can have stored thereon a set of one or more schemas (e.g., in tables, objects, files, or other data structures) and when a schema is selected for a current operation of the lighting devices, the schema can be loaded onto the volatile memory component and can be implemented by the processor 308.

[0062] In some examples, communications interface(s) 312 can include any suitable hardware, firmware, and / or software for performing peer-to-peer communication with another device (e.g., either or both of remotes 304, 306) or communicating information over a communication network (e.g., communications network 20 shown in FIG. 1). For example, communications interface(s) 312 can include one or more transceivers, one or more communication chips and / or chip sets, one or more antennas, etc. In a more particular example, communications interfaces 312 can include hardware, firmware and / or software that can be used to establish a Wi-Fi connection, a Bluetooth connection, a near field communication (NFC) connection, a radio frequency identification (RFID) connection, a cellular connection, an Ethernet connection, an ultra-wideband (UWB) connection, etc. In some cases, a lighting device can be configured to receive communication from a wired connection.

[0063] As further shown in FIG. 4, the lighting device 302 can include inputs 314. In some cases, the inputs can include one or more buttons or other controls (e.g., button 208 shown in FIG. 2). In some examples, buttons of inputs 314 can include a power on button, a command button, and a schema rotation button. A power button can be engaged (e.g., pressed) to power the lighting device 302 on and off. A command button can be engaged by a user to change a parameter of a lighting device without changing a schema. For example, a command button can be engaged to adjust an intensity of lighting elements of a lighting device. In some cases, a schema can include multiple lighting operations and a command button can cycle a lighting operation of a lighting schema. As an example, a schema can be a law enforcement schema, and can include a blinking operation for the schema, a roadside warning lighting operation, a reading operation, etc. and engagement of the command button can change an operation of the lighting device to a different operation defined in a schema. A schema rotation button can change a schema used by the lighting device 302 upon each press. For example, as shown in FIG. 1, one or more schemas can be stored on the memory 310, and can include a Default Schema. When the lighting device is powered on, the Default Schema can be loaded, and thelighting device 302 can operate to implement the Default Schema (e.g., can selectively implement a lighting sequence for lighting elements of the lighting device 302 in accordance with instructions included in the Default Schema). When the schema rotation button is pressed, a schema of the lighting device 302 can be changed to the next schema in memory. Subsequent presses of the schema rotation button can iterate through respective schemas stored in the memory. In some cases, one or more schemas can be unavailable for use by engagement of a schema rotation button and can instead require the presence of an associated remote, as detailed below. In some cases, the input 314 can include a number of buttons, and an engagement of one or more of the button can determine an operation implemented by the lighting device (e.g., a press and hold operation, or a double tap operation can power the lighting device 100 on or off, while a single press can iterate a schema of the lighting device 100). In some cases, the inputs 314 can include a “pairing” button. For example, the lighting device 302 can be configured to communicate or receive communication from one or more Bluetooth enabled devices (e.g., one or more of remotes 304, 306), and pressing the “pairing button” can allow the lighting device 302 to receive communication from, and pair with the Bluetooth enabled device. In some cases, a lighting device (e.g., lighting device 302) can include one or more interfaces that can receive input directly from another device (e.g., the lighting device can include a USB port that can receive instructions and data structures from a device connected to the lighting device through the USB port).

[0064] The lighting device 302 can further include lighting elements 316. The lighting elements 316 can include one or more LEDs. For example, the lighting elements 316 can include separately controllable multi- or single-color LEDs at corners of the lighting device 302. In an example, a schema of the lighting device 302 can require alternately flashing LEDs of two opposing corners green, and flashing the LEDs of the other pair of opposing corners red. In another example the lighting elements 316 on a first side or a second side can be illuminated constantly, or the lighting elements 316 can be operated in a sequential pattern. In some cases, all the lighting elements 316 can be operated in unison (e.g., can flash at the same rate) and can display the same color, or they can be operated at different times. In some cases, various sets of lighting elements 316 can be operated individually. Correspondingly, a schema can account for various flashing patterns, sequences, and groupings of individual lighting elements 316 to allow for a desired emission of light from the lighting device 302. In some cases, the lighting elements 316 can be installed around a perimeter of the lighting device 302. Any configuration is possible, and a lighting device can include one lighting output 316 (e.g.,a LED or another type of light emitting element), two lighting outputs, three lighting outputs, four lighting outputs, six lighting outputs, eight lighting outputs, ten lighting outputs, or more than ten lighting outputs. Further, while the lighting elements 316 described above comprise one or more LEDs, a lighting output of a lighting device 302 can include any element known to produce light (e.g., halogen lights, filament-based lights, fluorescent lights, etc.).

[0065] As further shown in FIG. 4, the remote 304 can be a static remote (e.g., remotes 16a, 16b shown in FIG. 1). In the illustrated example, the static remote includes a processor 320, a memory 322, one or more inputs 324, and a communications interface 326. The descriptions of the processor 308, memory 310, and communications interfaces 312 can be applicable to the respective processor 320, memory 322, and inputs 324, respectively. In a particular example, the communications interface 326 can comprise an RFID tag (e.g., a low- frequency (LF), high frequency (HF), or ultra-high frequency (UHF) tag) configured to emit a radio signal to the communications interface 312. In some examples, a static remote does not comprise a processor (e.g., processor 320) and inputs (324), but includes a communications interface which can communicate one or more values (e.g., one or more values stored in the memory 322) to the lighting device 302. In some cases, as described further below, a communication between the communications interface 326 and the communications interface 312 can be initiated when the static remote 304 is within a threshold distance (e.g., in range) of the lighting device 302. In some cases, communication between the static remote 304 and the lighting device 302 can require engagement of one or more inputs 324 of the static remote 304 (e.g., the static remote 304 can pair with the lighting device 302 when a user presses a button of the input(s) 124). In some cases, the static remote 304 can be a hardware component. In other cases, the static remote 304 can be software-defined, and can be installed onto a computing device (e.g., a phone, a tablet, a smart watch, an intemet-of-things (IOT) device, etc.).

[0066] Still referring to FIG. 4, the programming remote 306 can include a processor 330 (e.g., similar or identical to processor 308), a memory 332 (e.g., similar or identical to memory 310), and a communications interface 336 (e.g., similar or identical to communications interfaces 312). In some examples, as shown the programming remote 306 can further include a display 338. In some embodiments, the display 338 can include any suitable display device, such as a touch screen of a smart phone device or a tablet, computer monitor, a television, a projector, a smart phone, a virtual reality headset, augmented reality goggles, etc. In some examples, the programming remote 306 further includes inputs 334 can include any suitableinput, such as a keyboard, a mouse, a touchscreen, a microphone, a camera, etc. As described further below, a user of the programming remote 306 can input parameters (e.g., light color, flashing frequencies, lighting sequences, etc.) via the inputs(s) 334 to the programming remote 306 to define a desired lighting schema, and the lighting schema can be stored in the memory 332. When the programming remote 306 pairs with the lighting device 302, the lighting schema can be communicated to the lighting device (e.g., via communications interface 336 and communications interface 312), and can be stored in memory 310. That is, the programming remote 306 can send a signal to the lighting device 302 that contains data indicative of the desired schema. Upon receiving the signal via the communications interface 312, the processor 308 can initiate a new schema in the memory 332, or can rewrite a currently stored schema (e.g., Schema 1, Schema 2, Schema 3, or another dedicated, re-writable schema) to include information indicative of the desired schema. The processor 308 can then reference the schema received from the programming remote 306 and operate the lighting elements 316 to implement the schema (e.g., the user-defined schema) when the programming remote is paired to the lighting device (e.g., when the programming remote 304 is within a threshold distance of the lighting device 302). In some cases, a programming remote (e.g., programming remote 306) can be fully or partially software-defined. For example, the programming remote 306 can be implemented within an application hosted on a user’ s smartphone, and can utilize the processor, memory, communications interfaces, inputs, and display of the user’s smartphone.

[0067] FIG. 5 illustrates an example system 400 for changing a lighting schema of a lighting device 402 (e.g., similar or identical to lighting devices 12, 100, and 302 shown in FIGS. 1, 2, and 4). As illustrated, the system 400 can include a static remote 404, having stored thereon a lighting schema ID. For the purposes of illustration, the lighting schema ID shown is “3,” however, a lighting schema ID can be any value, including numbers, integers, text strings, binary values, etc. The lighting schema ID can correspond to a desired flash pattern for a lighting device (e.g., lighting device 402). In some examples, a lighting schema ID can correspond to a law enforcement lighting schema (e.g., flashing blue and red lighting elements, flashing blue and red lighting elements in a back of the lighting device with a white light in the front, etc.), a roadside assistance lighting schema, a running lighting schema, a lighting schema adhering to U.S. Coast Guard lighting requirements for vessels, a biking lighting schema, a running lighting schema, or a lighting schemas associated with any other activity. The static remote 404 can be configured to communicate with the lighting device 402 when the static remote 404 comes within a distance threshold of the lighting device 402. In some examples, astatic remote can communicate with a lighting device when the remote device is within about 100 meters of the lighting device. In some cases, a static remote can communicate with a lighting device when the static remote is within 20 meters, or within 10 meters, or within 1 meter, or within 20 centimeters of the lighting device. The static remote 404 can include any communications interface configured to allow a communication between the static remote 404 and the lighting device 402 (e.g., communications interface 326 shown and described in FIG. 4). In some cases, a static remote can be continuously broadcasting, and can automatically pair with the lighting device 402 when in range of the lighting device 402. In some cases, an action is taken to initiate a communication, which can include engaging a button or control on either the static remote 404 or the lighting device 402.

[0068] As shown, the lighting device includes a communications interface 412 (e.g., similar or identical to communications interface 312) a memory 414 (e.g., similar or identical to memory 310), a processor 420 (e.g., similar or identical to processor 308) and lighting elements 422 (e.g., similar or identical to lighting elements 316). The memory 414 includes a persistent memory 418 and a volatile memory 418. The persistent memory 416 can store data that can persist through schema changes and power on / power off events for the device. The volatile memory 418 can be used by the processor 420 and data in the volatile memory can be used by the processor 420 to operate the lighting elements 422. In some cases, data can be copied from the persistent memory 416 to the volatile memory 418 upon a powering on of the lighting device 402, or upon a change in a lighting schema. As further illustrated, the persistent memory 416 can include a plurality of tables, each being associated with an ID (e.g., IDs 1, 2, and 3, s shown). While the illustrated example shows a persistent memory 416 including three tables, a persistent memory for a lighting device can include any number of tables according to this disclosure. In some cases, the ID can be a value stored in an entry or attribute of the table. In some cases, the tables can be included in a database, and the IDs can be stored in a separate table to map the tables to the IDs. In some cases, a memory of a lighting device includes data structures other than tables. In an example, a memory can include a plurality of objects (e.g., j son objects), each having a plurality of attributes interpretable by a processor to operate lights according to a given lighting schema.

[0069] Tables or data structures defining lighting schema can specify lighting operations to be performed in implementation of a lighting schema. For example, in some cases, a table can include entries (e.g., rows) corresponding to individual lighting elements or groups of lighting elements to be operated in together (e.g., in unison or in a sequential pattern). Theentries can define attribute including a color of the lighting elements, a flash rate, a brightness, a sequence (e.g., an order in which to activate lighting elements), etc. In a particular example, a table defining a lighting schema for kayaking can include an entry specifying that all lighting elements on a first side of the lighting device operate continuously (e.g., without flashing) with a white color at maximum brightness. Another entry can require a group of lighting elements at a front right of the lighting device operate continuously at a green color at maximum intensity, and another entry can require lighting elements at a front right of the lighting device operate continuously at a red color at maximum intensity. Further, the table can include information defining behavior of the lighting elements upon engagement of one or more controls. For example, the table can include one or more entries defining an operation of the lighting elements in response to an engagement of a command button. With reference to the previous example, the entry can specify that upon a button press, the lighting elements on the front side of the lighting device can flash (e.g., at a constant rate, or according to a pattern to communicate a message, etc.) at a white color at maximum intensity. Other configurations are possible, and tables or combinations of tables can define any number of intensities, flashing patterns, lighting element sets, colors, etc. at which to operate lighting elements (e.g., or other lights) of a lighting device. Correspondingly the table can map buttons or other control elements to specific functions of the lighting device. For example, a first table can map a first button to perform a first set of functions depending on input received at the first button (e.g., long press, short press, sequential press, etc.), while a second table can map the first button to perform a second set of functions depending on input received at the first button.

[0070] Continuing to refer to FIG. 5, the communications interface 412 can receive a communication from the static remote 404 (e.g., via RFID, Wi-Fi, Bluetooth, wired connection, or any known connection method, as described in FIG. 4). The communication can include the ID of the static remote 404, which, as described above, can be an ID associated with a particular activity or lighting schema. The ID can be used to perform a lookup and selection of a table (e.g., or other data structure) within the memory 414. For example, as shown, The ID “3” which can be received via the communications interface 412 can be used to lookup a table having a corresponding ID 3. If a table with a matching ID is identified in the memory 414 (e.g., the persistent memory 416), the corresponding table can be loaded for use as the table referenced by the processor 420 to operate the lighting elements 422. In the illustrated example, the table with the ID of “3” is selected based on the communication of the ID “3” from the static remote 404, and the table with the ID “3” is copied from the persistent memory 416 to the volatile- 1 -memory 418. The copied table can thus comprise the authoritative lighting schema for the lighting device 402, and the lighting elements 422 can be operated according to instructions included in the table copied to the volatile memory 418. In some cases, a memory does not include a persistent and volatile memory component, and a processor can reference a table directly, based on a selection of the table (e.g., without an additional copying operation.

[0071] FIG. 6 illustrates an example process for operating a lighting device 504 with a static remote 502. The lighting device 504 can be similar or identical to the lighting devices 12, 100, 302, and 402 shown in FIGS. 1, 2, 4, and 5, respectively. The static remote 502 can be similar or identical to the static remotes 16a, 16b shown in FIG. 1, or the static remotes 304, 404 shown in FIGS. 4 and 5, respectively.

[0072] As shown in FIG. 6, the process 500 can begin with a powering on of the lighting device 504 at block 506. In some cases, powering on a lighting device 504 can include pressing a button of the lighting device (e.g., button 208 shown in FIG. 2). In some cases, a lighting device 504 can be powered on by a motion, by a signal received from another device (e.g., a phone, a tablet, remote 502, etc.).

[0073] At block 508, when the lighting device 504 has been powered on at block 506, the lighting device 504 can load and implement a default schema (e.g., the Default Schema shown in FIG. 1). In some cases, a default schema can be stored in a memory of the lighting device 504 (e.g., as shown in FIGS. 1 and 6). A default schema can be defined in a table, as illustrated and described with respect to FIG. 5. In some cases, loading a default schema at block 508 can include copying a table defining the default schema to a portion of a memory accessed by a processor to operate lighting elements (e.g., lighting elements 316, 422) of the lighting device 504 (e.g., copying a table or other data structure to the volatile memory 418 shown in FIG. 5). In some cases, loading the default schema does not include copying a table or other data structure defining the default schema and the processor may read the default schema directly. The default schema can be implemented by the lighting device 504 to operate lighting elements of the lighting device in accordance with the default schema (e.g., to flash lighting elements of the lighting device 504 at a default rate, at a default color, and a default intensity defined in a default schema table).

[0074] At block 510, the lighting device 504 (e.g., a communications interface of the lighting device 504) can determine if a remote is detected. Detecting a remote can include evaluating if a signal has been received from a remote in proximity to the lighting device 504. In some cases, the lighting device 504 can be passive, and can detect a remote only when asignal is received from the remote. In some cases, the lighting device 504 can perform a scanning operation to detect nearby remotes. In some examples, the lighting device 504 can “poll” or send out periodic signals to actively assess whether a remote is in proximity to the lighting device 504. In some cases, a detection is performed in response to a user input. For example, a user can initiate a scan or detection process through pressing a button of the lighting device 504 (e.g., a pairing button). If a remote is not detected at block 510, the process 500 can continue to block 508, and either load the default schema, or continue operating according to the default schema.

[0075] At block 512, the static remote 502 can determine if the remote 502 is within range of a lighting device (e.g., lighting device 504). Block 512 can be performed independently of operations performed at the lighting device 504 (e.g., blocks 506, 508, 510 as described above). Further, the remote can continuously perform block 512, or can evaluate whether a lighting device is within range of the remote 502 in response to a condition. For example, a user can press a button of the static remote 502, and in response to the button engagement, the remote 502 can determine at block 512 if a lighting device is within range. In some cases, block 512 can be reevaluated at regular intervals (e.g., every second, every 10 seconds, every minute, every five minutes, etc.). In some cases, a static remote 502 does not include block 512, and determination of whether a lighting device is within range can be automatically performed when a communication is established between the remote 502 and a lighting device.

[0076] At block 514, the static remote 502 can determine if a pairing condition is met. For example, a pairing condition can require that one or both of the remote 502 and the lighting device 504 is in “pairing mode”, and if either or both of the remote 502 and the lighting device 504 is not in pairing mode, the process can either end, or return to block 512. In some cases, block 514 can be continuously evaluated. In other examples, block 514 can be initiated by a user, through an input (e.g., a button press) on the device. In some cases, a pairing condition can require that a lighting device be compatible with the remote 502. For example, a lighting device may be of a professional class and include lighting schemas for professional use (e.g., in construction, law enforcement, firefighters, EMTs, etc.), while the remote is usable only with recreational devices. As another example, a pairing condition may require that a lighting device have a particular configuration of lighting outputs (LED) arranged to provide a specific type of output. For example, a remote used for boating or kayaking may require a lighting device configured to provide an all-around white light (e.g., a three hundred sixty degree emission of white light) or a bi-colored and bi-directional light configured to provide a firstemission of a first color (e.g., red) along a first one hundred eighty degrees and a second emission of a second color (e.g., green) along the remaining one hundred eighty degrees. In this case, at block 514, the process 500 can determine that a pairing condition is not met, and the remote 502 and the lighting device 504 are not paired.

[0077] At block 516, the remote 502 can send (e.g., can broadcast) an ID of the remote 502 to the lighting device 504. In some cases, a remote can be configured to continuously broadcast an ID (e.g., via passive RFID technology) without a determination of a pairing condition at block 516.

[0078] At block 518, the lighting device can receive the remote ID (e.g., the remote ID broadcast from the remote 502 at block 516). The remote ID can be stored in a memory of the device and can be used to select a corresponding lighting schema stored in a table or other data structure in a memory of the lighting device 504 (e.g., memory 414 illustrated in FIG. 5).

[0079] At block 520, a lighting schema can be selected based on the remote ID received at block 518. For example, the remote ID of the remote 502 can correspond to an ID of a table or data structure in a memory of the lighting device 504, and the corresponding table can be selected as the table usable by a processor of the lighting device 504 to implement a desired lighting schema. In some case, the lighting device 504 can have a lookup table stored in a memory that includes known remote IDs and a mapping of the known remote IDs to corresponding lighting schema tables in the memory. Selecting a table can include performing a lookup using the remote ID and the lookup table.

[0080] At block 522, the lighting device 504 can load and implement the lighting schema corresponding to the remote ID received at block 518 (e.g., the lighting schema selected at block 520). As described above, the lighting schema can be defined in a table (e.g., the table selected at block 520). In some cases, loading the lighting schema at block 522 can include copying the selected table defining the lighting schema to a portion of the memory accessed by a processor to operate lighting elements of the lighting device 504 (e.g., copying a table or other data structure to the volatile memory 418 shown in FIG. 5). In some cases, loading the lighting schema does not include copying a table or other data structure defining the lighting schema. The lighting schema can be implemented by the lighting device 504 to operate lighting elements of the lighting device 504 in accordance with the lighting schema (e.g., to flash lighting elements of the lighting device 504 at a rate, color, intensity, and pattern defined in the table selected at block 520). In some cases, the lighting device 504 can implement the lighting schema (e.g., the lighting schema selected at block 520, and corresponding to the remote IDreceived at block 518) as long as the remote 502 is within range of the lighting device 504. For example, the lighting device 504 can continuously evaluate block 510 to determine if a remote is detected. If a remote is no longer detected at block 510, the process 500 can revert to block 508, and return to a default schema. In some cases, the lighting device 504 can continue to implement the lighting schema corresponding to the remote ID until a user input is received (e.g., at button 208 shown in FIG. 2), or until the device is powered off. In some cases, a pairing operation can reset the lighting schema of the lighting device 504.

[0081] FIG. 7 illustrates another example system 600 for changing a lighting schema of a lighting device 402 (e.g., similar or identical to lighting devices 12, 100, and 302 shown in FIGS. 1, 2, and 4). As shown, the lighting device 402 is identical to lighting device 402 shown and described with respect to FIG. 5. For example, the lighting device 402 includes communications interface 412, memory 414, processor 420 and lighting elements 422. The memory includes a persistent memory 416 including tables having table IDs “1”, “2”, and “3”. A memory of a lighting device, according to this disclosure, is not limited to three tables, but can include any number of tables defining any number of lighting schemas for the lighting device.

[0082] As shown in FIG. 7, the system 600 includes a programming remote 604 (e.g., similar or identical to programming remote 18 shown in FIG. 1, and programming remote 306 shown in FIG. 4). The programming remote 604 can be a software defined remote hosted on a user device (e.g., a phone, a tablet, a head-mounted device, a GPS device, etc.), or can be a remote with dedicated hardware. As shown, the programming remote 604 includes a table 606 (i.e., the table with ID “4”). The table 606 can define a lighting schema interpretable by a lighting device (e.g., lighting device 402) to operate lighting elements of the device in the defined pattern. In the illustrated example, the table 606 is not included in the tables stored in the persistent memory 416 (e.g., the table 606 is not pre-programmed on the lighting device 402).

[0083] As shown, the table 606 can be communicated to the lighting device 402 at the communications interface 412 of the lighting device 402, when the programming remote 604 is paired with the lighting device 402. In some examples, including as shown, the table 606 can be written to the volatile memory 418 directly and can provide instructions to the processor 420 to operate the lighting elements 422 according to the lighting schema defined in the table 606. As shown, the table 606 is not stored in the persistent memory 416. Thus, in some examples, the table 606 does not remain stored in memory 414 of the lighting device 402 whenthe lighting device 402 is powered off, restarted, or when another table is loaded in the volatile memory 418 to operate the lighting elements 422 according to a different lighting schema. Accordingly, the table 606 may not be stored in persistent memory 416 or volatile memory 418 when the lighting device 402 is disconnected from the remote 604. The result is that the table 606 may not be available to a user unless lighting device 402 is paired with the remote 604. This allows certain functionality (e.g., schema) of the lighting device 402 to be automatically enabled and disabled based on the pairing of the remote 604. Enabling and disabling schema in this way allows a user to easily switch between different functionality based on the type of connected remote. As one example, connecting a first remote can allow a lighting device to operate using a schema specifically designed for a first activity or use (e.g., boating), while connecting a second remote can allow the lighting device to operate using a schema specifically designed for a second activity (e.g., roadside emergency).

[0084] In other examples, a user-defined table (e.g., the table 606 communicated to the lighting device 402 from the programming remote 604) can be persistently stored in the memory 416, and can be usable at the lighting device 402 even when the remote 604 is out of range (e.g., a user of the lighting device 402 can cycle the lighting schema to the user-defined table using controls of the lighting device 402). In some cases, when a user defined table is written to persistent memory 416, it can be loaded and implemented upon a subsequent pairing of the remote 604 (e.g., without requiring the remote 604 to recommunicate the table 606). In some cases, the user-defined table can be associated with a table ID (e.g., “4”, as shown), and the lighting device 402 can load and implement the user-defined table upon pairing of any remote providing an ID corresponding to the ID of the user-defined table.

[0085] FIG. 8 illustrates an example process 700 for operating a lighting device 704 with a programming remote 702. The lighting device 704 can be similar or identical to the lighting devices 12, 100, 302, 402, and 504 shown in FIGS. 1, 2, 4, 5, 7, and 6, respectively. The programming remote 702 can be similar to the programming remotes 18, 306, and 604 shown in FIGS. 1, 2, and 7, respectively.

[0086] As shown in FIG. 8, the process 700 can begin with a powering on the lighting device 704 at block 706. In some cases, powering on a lighting device 704 can include pressing a button of the lighting device (e.g., button 208 shown in FIG. 2). In some cases, a lighting device 704 can be powered on by a motion, or by a signal received from another device (e.g., a phone, a tablet, remote 702, etc.).

[0087] At block 708, after the lighting device 704 has been powered on at block 706, the lighting device 704 can load and implement a default schema (e.g., the Default Schema shown in FIG. 1). In some cases, a default schema can be stored in a memory of the lighting device 704 (e.g., as shown in FIGS. 1 and 5). A default schema can be defined in a table, as illustrated and described with respect to FIG. 5. In some cases, loading a default schema at block 708 can include copying a table defining the default schema to a portion of the memory accessed by a processor to operate lighting elements of the lighting device 704 (e.g., copying a table or other data structure to the volatile memory 418 shown in FIGS. 5 and 7). In some cases, the table can be read directly from memory (e.g., persistent memory 416) so that loading the default schema does not include copying a table or other data structure defining the default schema. The default schema can be implemented by the lighting device 704 to operate lighting elements of the lighting device in accordance with the default schema (e.g., to flash lighting elements of the lighting device 704 at a default rate, at a default color, and a default intensity defined in a default schema table).

[0088] At block 710, the lighting device 704 (e.g., a communications interface of the lighting device 704) can determine if a remote is detected. Detecting a remote can include evaluating if a signal has been received from a remote in proximity to the lighting device 704. In some cases, the lighting device 704 can be passive, and can detect a remote only when a signal is received from the remote. In some cases, the lighting device 704 can perform a scanning operation to detect nearby remotes. In some examples, the lighting device 704 can “poll” or send out periodic signals to actively assess whether a remote is in proximity to the lighting device 704. In some cases, a detection is performed in response to a user input. For example, a user can initiate a scan or detection process through pressing a button of the lighting device 704 (e.g., a pairing button). If a remote is not detected at block 710, the process 700 can continue to block 708, and either load the default schema, or continue operating according to the default schema.

[0089] At block 712, a user can define a lighting schema at the programming remote 702. In some cases, defining the lighting schema can include manually entering values into a table. In some cases, the programming remote can provide a simulation of the lighting device 704 to the user and the user can interactively define a lighting schema (e.g., at a user interface provided at a display of the programming remote via an application or web interface). In some cases, a user can define a lighting schema at a first device (e.g., a laptop or personal computer) and defining the lighting schema at block 712 can include loading the schema from the first deviceonto the programming remote (e.g., via a wired or wireless connection). In some cases, some lighting options are not configurable by the user. For example, an interface allowing a user to define a lighting schema may not allow a user to define a behavior or operation of individual lighting elements, but may allow the user to define an operation for predefined grouping of lighting elements (e.g., a group of lighting elements at a front of the lighting device, a group of lighting elements at a back left of the lighting device 704, and a group of lighting elements at a back right of the lighting device, etc.). Further, a programming remote 702 or interface thereof can disallow the definition of a lighting schema that may mimic other lighting schemas that may be limited in use (e.g., lighting schemas adhering to regulations indicating a law enforcement or emergency responder status, etc.).

[0090] At block 714, the programming remote 702 can store a lighting schema table (e.g., table 606 shown in FIG. 7) or other lighting schema structure on a memory of the programming remote 702 (e.g., memory 332 shown in FIG. 4). The lighting schema table can be translated from an input of a user into an interface defining the lighting schema. For example, a user can define a schema by selecting elements on a user interface, or proceeding through a “wizard,” and the user selections can be translated to table entries for a lighting schema table without exposure of the lighting schema table to the user.

[0091] At block 716, the programming remote 702 can determine if the remote 702 is within range of a lighting device (e.g., lighting device 704). Block 716 can be performed independently of operations performed at the lighting device 704. Further, the remote 702 can continuously perform block 716, or can evaluate whether a lighting device is within range of the remote 702 in response to a condition. For example, a user can press a button of the static remote 702, and in response to the button engagement, the remote can determine at block 716 if a lighting device is within range. In some cases, block 716 can be reevaluated at regular intervals (e.g., every second, every 10 seconds, every minute, every five minutes, etc.). In some cases, a process for operating a lighting device does not include determining at a remote whether the remote is within range of a lighting device (e.g., block 716). Determination of whether a lighting device is within range can be automatically performed upon initiation of a communication between the remote 702 and a lighting device (e.g., when the remote 702 pairs with a lighting device).

[0092] At block 718, the static remote 702 can determine if a pairing condition is met. For example, a pairing condition can require that one or both of the remote 702 and the lighting device 704 is in “pairing mode”, and if either or both of the remote 702 and the lighting device704 is not in pairing mode, the process can either end, or return to block 716. In some cases, block 718 can be continuously evaluated. In other examples, block 718 can be initiated by a user, through an input (e.g., a button press) on the remote 702. In some cases, a pairing condition can require that a lighting device be compatible with the remote 702. For example, a lighting device may be of a professional class and include lighting schemas for professional use (e.g., in construction, law enforcement, firefighters, EMTs, etc.), while the remote 702 is usable only with recreational devices. In this case, at block 718, the process 700 can determine that a pairing condition is not met, and the remote 702 and the lighting device 704 are not paired.

[0093] At block 720, the remote 702 can send (e.g., can broadcast) the lighting schema table (e.g., the lighting schema table stored at block 714) to the lighting device 704. In some cases, a programming remote can have store thereon multiple user define lighting schema tables, and a user can select a particular lighting schema table to be communicated to the lighting device 704 at block 720. In some cases, a remote can be configured to continuously broadcast user defined schema table (e.g., via passive RFID technology) without a determination of a pairing condition at block 718.

[0094] At block 722, the lighting device 704 can receive the lighting schema table (e.g., the lighting schema table broadcast from the remote 702 at block 720). The lighting schema table can be stored in a memory of the lighting device 704. In some cases, as shown in FIG. 7, the lighting schema table can be stored in a volatile memory of the lighting device 704. In some cases, the lighting schema table can be stored in a persistent memory and can be available for use at the lighting device 704 even in an absence of the programming remote 702.

[0095] At block 724, the lighting device 704 can load and implement the lighting schema table received at block 722. In some cases, loading the lighting schema at block 724 can include copying the lighting schema to a portion of the memory accessible by a processor to operate lighting elements of the lighting device 704 (e.g., copying a table or other data structure to the volatile memory 418 shown in FIG. 5). In some cases, loading the lighting schema does not include copying a table or other data structure defining the lighting schema (e.g., as when the lighting schema table is written directly to the volatile memory upon being received at the lighting device 704). The lighting schema can be implemented by the lighting device 704 to operate lighting elements of the lighting device in accordance with the lighting schema (e.g., to flash lighting elements of the lighting device 704 at a rate, color, intensity, and pattern defined by the user at block 712). In some cases, the lighting device 704 can implement thelighting schema included in the lighting schema table as long as the remote 702 is within range of the lighting device 704. For example, the lighting device 704 can continuously evaluate block 710 to determine if a remote is detected. If the remote 702 is no longer detected at block 710, the process 700 can revert to block 708, and return to a default schema. In some cases, the lighting device 704 can continue to implement the lighting schema corresponding to the lighting schema table until a user input is received (e.g., at button 208 shown in FIG. 2), or until the device 704 is powered off. In some cases, a pairing operation can reset the lighting schema of the lighting device 704.

[0096] In some cases, the lighting device 704 can continuously evaluate whether the programming remote 702 is paired with the lighting device 704 at block 726. If the remote is unpaired, the process can proceed to delete the lighting schema received at block 728 from the lighting device 704. In some cases, deleting the lighting schema includes overwriting the lighting schema table in a memory of the lighting device 704 with the default schema, or another schema stored in a memory of the lighting device 704. In other configurations, the lighting schema received at block 722 is persistently stored on the lighting device 704.

[0097] As used in the claims, the phrase "at least one of A, B, and C" means at least one of A, at least one of B, and / or at least one of C, or any one of A, B, or C or combination of A, B, or C. A, B, and C are elements of a list, and A, B, and C may be anything contained in the Specification.

[0098] The present devices systems, and method have been described in terms of one or more preferred examples, and it should be appreciated that many equivalents, alternatives, variations, and modifications, aside from those expressly stated, are possible and within the scope of the disclosure.

Claims

CLAIMSWhat is claimed is:

1. A lighting device, comprising: a lighting element; a communications interface; a processor; and a memory including a first data structure defining a first lighting schema and instructions for causing the processor to: receive a first identifier via the communications interface, the first identifier corresponding to the first data structure, select the first data structure based on the first identifier, and operate the lighting element according to a first set of parameters defined in the first data structure.

2. The lighting device of claim 1, wherein the communications interface is configured to pair with a first remote and to receive the first identifier from the first remote.

3. The lighting device of claim 1, wherein the memory includes a default data structure and further includes instructions for causing the processor to: determine if a remote is paired with the communications interface, and responsive to a determination that a remote is not paired with the communications interface, operate the lighting element according to a default set of parameters defined in the default data structure.

4. The lighting device of claim 1, wherein the memory further includes instructions for causing the processor to: receive a second data structure via the communications interface; write the second data structure to the memory; and operate the lighting element according to a second set of parameters defined in the second data structure.

5. The lighting device of claim 4, wherein the set of parameters defined in the second data structure includes at least one of: a color of the lighting element, an intensity of the lighting element, and a flash pattern of the lighting element.

6. The lighting device of claim 4, wherein the lighting element is one of a plurality of lighting elements and the set of parameters includes a button map that maps buttons of a control interface to corresponding sets of the plurality of lighting elements.

7. The lighting device of claim 4, wherein the communications interface is configured to pair with a second remote and to receive the second data structure from the second remote.

8. The lighting device of claim 7, wherein the memory further includes instructions for causing the processor to: determine if the second remote is paired with the communications interface; and responsive to a determination that the second remote is not paired with the communications interface, remove the second data structure from the memory.

9. The lighting device of claim 1 wherein the lighting element is one of a plurality of LEDs.

10. A method of operating a lighting system, the method comprising: receiving a first identifier at a lighting device, selecting one of a first data structure and a second data structure based on the first identifier, the first data structure and the second data structure stored in a memory of the lighting device; and receiving an operating instruction to cause operation of a lighting element of the lighting device according to a set of parameters defined in the selected one of the first data structure and the second data structure.

11. The method of claim 10 further comprising sending the first identifier via a first remote that is in wireless communication with a communications interface of the lighting device, wherein the first identifier is received at the communications interface.

12. The method of claim 11 wherein the first identifier is received at a control interface provided on the lighting device.

13. The method of claim 12, wherein the first remote includes a first set of buttons that represent a corresponding second set of buttons of the control interface.

14. The method of claim 13, wherein the first remote includes a third set of buttons that correspond to a set of operating instructions that is locked to the first remote.

15. The method of claim 11 further comprising: pairing the first remote with the lighting device; determining whether a third data structure corresponding with the first remote is stored in the memory of the lighting device; and upon determining that the third data structure is not stored in the memory, storing the third data structure in the memory of the lighting device.

16. The method of claim 15 further comprising: disconnecting the first remote from the lighting device; and removing the third data structure corresponding with the first remote from memory.

17. The method of claim 15 further comprising: receiving a signal to turn off the lighting device; and upon receiving the signal to turn off the lighting device, removing the third data structure corresponding with the first remote from the memory.

18. The method of claim 10 further comprising: sending a third data structure to the lighting device; andstoring the third data structure in the memory of the lighting device.

19. The method of claim 18, wherein storing the third data structure in the memory of the lighting device include overwriting one of the first data structure and the second data structure.

20. A non-transitory computer-readable medium storing instructions that, when executed by a processor, cause the processor to: determine whether a first schema corresponding with a remote device is in a set of schema; upon determining that the first data structure is not in the set of schema, store the first schema in the set schemas; activate a schema of the set of schema based on an identifier; and operate a lighting element according to a set of parameters defined in the activated schema based on an operating instruction.

Images