WO2024033775A1 - Systèmes et procédés de gestion d'état de faible puissance - Google Patents

Systèmes et procédés de gestion d'état de faible puissance Download PDF

Info

Publication number
WO2024033775A1
WO2024033775A1 PCT/IB2023/057944 IB2023057944W WO2024033775A1 WO 2024033775 A1 WO2024033775 A1 WO 2024033775A1 IB 2023057944 W IB2023057944 W IB 2023057944W WO 2024033775 A1 WO2024033775 A1 WO 2024033775A1
Authority
WO
WIPO (PCT)
Prior art keywords
modular
message
wake
devices
controller
Prior art date
Application number
PCT/IB2023/057944
Other languages
English (en)
Inventor
Aliakbar Juzer ESKI
Godwin GUO
Tomas Rodinger
Nathan Dyck
Original Assignee
Nanogrid Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nanogrid Limited filed Critical Nanogrid Limited
Publication of WO2024033775A1 publication Critical patent/WO2024033775A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0225—Power saving arrangements in terminal devices using monitoring of external events, e.g. the presence of a signal
    • H04W52/0235—Power saving arrangements in terminal devices using monitoring of external events, e.g. the presence of a signal where the received signal is a power saving command
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/04—Generating or distributing clock signals or signals derived directly therefrom
    • G06F1/12—Synchronisation of different clock signals provided by a plurality of clock generators
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3206—Monitoring of events, devices or parameters that trigger a change in power modality
    • G06F1/3209—Monitoring remote activity, e.g. over telephone lines or network connections
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3234—Power saving characterised by the action undertaken
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/12—Arrangements for remote connection or disconnection of substations or of equipment thereof
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0261—Power saving arrangements in terminal devices managing power supply demand, e.g. depending on battery level
    • H04W52/0274—Power saving arrangements in terminal devices managing power supply demand, e.g. depending on battery level by switching on or off the equipment or parts thereof
    • H04W52/028—Power saving arrangements in terminal devices managing power supply demand, e.g. depending on battery level by switching on or off the equipment or parts thereof switching on or off only a part of the equipment circuit blocks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks

Definitions

  • Embodiments of the present disclosure relate to the field of power management, and more specifically, embodiments relate to systems and methods for low power state management for interconnected modular circuitry.
  • Smart devices can be provided to control or provide various functionality, and can include modular circuit components which interoperate together to provide functionality such as temperature monitoring, home alarms, sensors, lighting, etc.
  • a challenge with smart devices is that the operating modes can consume significant amounts of electricity and power, and electricity and power are limited resources. It is desirable to provide an approach to reduce the amount of electrical resource consumption in respect of overall operation of electronic devices.
  • low power management approaches can include provisioning state changes including wake and sleep states for the electronic devices.
  • Low power management approaches need to be balanced against a need for responsive functionality from the electronic devices.
  • Low power management is important to aid in improving overall operating efficiency and contributes to an overall reduced environmental footprint by aiding in conserving energy resources.
  • Systems, methods, and computer readable media directed to managing low power mode on modular devices that are managed via a centralized controller are described herein.
  • the controller controls the modular devices to enter low power modes and synchronizes the wake up when requested (e.g., by the user or other device through a computer controlled request data message or object).
  • the modular devices and controller devices in some embodiments, can be different physical devices (e.g., different hardware), while in other embodiments, can be similar devices having been assigned different roles (e.g., same hardware, interchangeable based on software configuration).
  • Low power modes are useful and power savings are also useful in promoting energy efficiency electronic devices that are coupled together, such as light panels, cameras, home temperature control, etc. Controlling any of these types of devices are contemplated in this application. While an objective is to achieve power savings, there are several technical challenges as described herein relating to wake up latency and managing data communications between modular devices due to low power mode clock errors that can have significant errors (e.g., +/- 40%). Power management is an important and practical application of the proposed approaches and provides a useful practical implementation in an attempt to achieve a technical objective having regard to practical trade-offs between competing technical priorities.
  • the approach implements a number of control steps that are utilized to control operation of the modular electronic devices in respect of low-power state “sleep” states and wake states, the control steps adapted to minimize latency associated with waking the modular electronic devices to reduce a perceived latency that may impede a user experience associated with the modular electronic devices.
  • a number of variant approaches are described herein, including (1) an approach for a system wake by a controller device, (2) an approach for a system wake by module device, and (3) an approach for a path wake by module device.
  • the approaches can include recursive steps where the system or parts of the system progressively wake in each scenario.
  • the modules module or modular electronic devices, e.g., lighting panels
  • communicate with one another for example, through connections that are designated as “root” I “parent”, and “child”, and the communications propagate accordingly.
  • Recursive steps are useful in situations where the arrangement, number of modules, or the geospatial relationship is not known or subject to change.
  • the modular electronic devices can be coupled to one another through the usage of linking elements, which may be physical or virtual for the sharing of power and/or data (e.g., signals transmission) capability.
  • the sharing of power and data can be conducted across the same (e.g., an AC signal coupled over a DC power transmission) or on separate circuitry (e.g., separate power and data lines).
  • Each of the modular electronic devices can include one or more (or a plurality of) linking sections where a modular electronic device can be linked with another modular electronic device.
  • a modular electronic device can be linked with another modular electronic device.
  • the controller device could be the first point in which there is a coupling to a power source, such as a wall outlet.
  • the specific physical or geometric arrangement I layout of the modular electronic devices may be periodically modifiable or “hot swappable” by a user such that the specific physical or geometric arrangement I layout is modifiable and thus not known a priori by the system.
  • a layout detection approach may be utilized to traverse the physical or geometric arrangement I layout to, store in a data structure, a representation of the linkage connections as between modular electronic devices (e.g., Device1 Edge1 is coupled to Device2Edge1), and so forth.
  • a flow of a normal sleep mechanism is both initiated and interrupted by the controller device, whereby the controller device “wakes” children modular electronic devices coupled to it, and then the modular electronic devices progressively awaken their children.
  • the controller can then initiate various functioning of the system, such as communicating a modular electronic device assembly-wide effect to be generated, etc.
  • the module with data communicates to wake all of its neighboring modular electronic devices, and then a progressive waking approach can be utilized.
  • a path to the controller device is established, data relating to the modular electronic device that initiated the wake protocol can be obtained by the controller, and modular electronic devices can continue to be woken through various neighboring connections.
  • the controller can then initiate various functioning of the system, such as communicating a modular electronic device assembly-wide effect to be generated, etc.
  • the modular electronic device may be interacted with, and then begin waking neighboring modular electronic devices until a path to the controller device is established.
  • a signal to stop waking neighbors can be optionally propagated to avoid unnecessarily awakening modular electronic devices, and the controller can conduct various functions associated with the specific initiating modular electronic device (e.g., clearing an error condition, updating firmware), etc.
  • the controller device can also return various woken modules to sleep by propagating a sleep signal when the function is completed.
  • the electronic devices can include interconnected lighting panels having edges that can be coupled together to provide a lighting assembly where individual lighting modules that are luminaires constituting the modular electronic devices can be re-arranged and reconnected, for example, to create flexible and modular lighting structures.
  • each of the lighting modules may have various sensors on-board that allow them to be interacted with at various times, for example, having motion sensors to identify proximate movement, light sensors to calibrate for a time of day, touch sensors to detect touch inputs, or on-board buttons or switches.
  • Power management states can be utilized so that the even while the lighting assembly is in various sleeping modes to save energy, the lighting assembly can be awoken in a reasonable amount of time when one of the lighting panels is interacted with by a user.
  • the electronic devices can include temperature sensors that are coupled together across a set of rooms in a home or an office.
  • the temperature sensors can be placed in each room or a portion of each room, and can have a plurality of edge interconnections for coupling to other temperature sensors.
  • Power management states can be utilized so that the even while the temperature sensor assembly is in various sleeping modes to save energy, the temperature sensor assembly can be awoken in a reasonable amount of time when one of the temperature sensors detects a change in temperature beyond a triggering threshold, for example.
  • the devices are utilized to establish power conservation states of the modular system to control the modular devices that are coupled either with one another, or with a central controller device. Because the system of some embodiments can be hot-swappable or modified, a challenge is that the controller and/or devices cannot pre-determine the number of modular elements that form the whole of the system, nor how they are connected - they are only able to observe their neighbors through their corresponding edge communication interfaces.
  • timing circuitry is not synchronized and/or not sufficiently accurate (e.g., to keep manufacturing costs reasonable for consumer electronics, or to use lower latency I lower power consumption chipsets).
  • each of the modular devices and/or the controller may have onboard timing functionality on the circuitry, but these might have experienced drift relative to one another since manufacturing and/or were never initially synchronized.
  • the modular devices when the modular devices enter into the power conservation states, they wake periodically in an asynchronous manner and “check” whether their edge communication devices and/or coupled message or data buffers include an unprocessed wake message, which they can then process to transition into a fully woken state and/or discard if already awake.
  • each of the modular devices is able to poll and/or otherwise interrogate their coupled edge communication devices and coupled ports or buffers, this can be used to respond to various poll messages from a controller such that a modular device that is awake can respond with whether all of the outstanding wake messages to its neighbors have been processed or not.
  • the controller can periodically propagate a poll message that radiates outwards requesting communication responses from awakened modular devices.
  • the awakened modular devices can respond with message fields indicating the status of each of their edge communication device ports and/or a message field indicating that they themselves are on, along with any other information (e.g., operational state information, such as the specific brightness I color output, a temperature reading, whether there has been a touch input to be processed), among others.
  • operational state information such as the specific brightness I color output, a temperature reading, whether there has been a touch input to be processed
  • the other information provided can then be utilized for other functionality, such as initiating a visual effect to be propagated across lighting panels by controlling their lighting output, etc. , or for a home thermometer system, a desired change in humidity or temperature settings.
  • the system can save, cache or identify the existing spatial relationship (e.g., edge hops based on pre-identified edges) based on the poll response messages, which can then be useful for more targeted communications to a specific modular device if the spatial orientation has not been changed. Even if the spatial orientation has been changed, the saved existing spatial relationship can still be useful as a first approximation for a path for attempting point to point messaging (e.g. , attempt across this path first, and then variations based on branches I tree nodes, and failing that, broadcasting a new poll to obtain responses to rebuild the spatial relationship).
  • the existing spatial relationship e.g., edge hops based on pre-identified edges
  • the controller can propagate the poll to check if a device flagged as the path wake initiator is awake, and if it receives that indication (potentially along with other initiator characteristics), it can establish a communication path directly with that device and stop the propagation of wake messages and/or stop polling messages.
  • the path wake mechanism can be used for localized effects or functionality, or for maintenance activities, such as pushing out firmware updates or requesting debugging information for a faulting modular device.
  • a spatial orientation can similarly be established as a potential path to the initiating modular device. While the path may not always be the shortest or most efficient, it nonetheless represents a path that has worked previously.
  • the path wake mechanism may be used in cases where a module wants to send information to the controller by disturbing or waking the least number of other modules.
  • An example use case, as mentioned, may be a firmware upgrade or update, where data flow might be from the controller to the individual module.
  • Variant embodiments are also contemplated with accurate (but unsynchronized) clocks, and the approaches described herein can be utilized to instead include as part of the data fields, synchronization information to re- synchronize clocks during wake periods (or set of wake periods), in order to minimize latency and improve power savings.
  • This can be used, for example to address clock drift and other challenges relating to practical limitations of clock mechanisms, as even subtle variations in manufacturing, gravity, or relativistic effects cause clocks to eventually be unsynchronized with respect to one another.
  • Clock synchronization is particularly important when the modular devices are being used for time sensitive functionality, such as home I premises recording devices (e.g., time stamps).
  • Coupling as described in this application between ports is not necessarily a physical electrical connection. While physical electrical connection devices are contemplated, such as a luminaire that is a system of modular devices that are interconnected together using interconnection linkers, etc., it is not the only implementation that is possible.
  • coupling could occur in the context of a mesh-based network, where devices have medium or low-range communications capability and can “see” various neighbors, and the modular devices include wireless communications transceivers.
  • the devices could be coupled as communications enabled lighting, communications enabled cameras, thermostats, alarms, that cover a larger area, such as across an office, an apartment building complex, among others.
  • Mesh networking can be electromagnetic coupling, and coupling could also occur in the context of communication from a vertex or otherwise arbitrary location along a surface of a module.
  • FIG. 1 is a schematic diagram showing an example modular lighting system, according to some embodiments.
  • FIG. 2 is a block diagram showing a workflow for waking a system by its controller, according to some embodiments.
  • FIG. 3 is a flowchart of a process for waking a system by its controller, according to some embodiments.
  • FIG. 4 is a block diagram showing a workflow for waking a system by a module, according to some embodiments.
  • FIG. 5 is a flowchart of a process for waking a system by a module, according to some embodiments.
  • FIG. 6 is a block diagram showing a workflow for waking a module path, according to some embodiments.
  • FIG. 7 is a flowchart of a process for waking a module path, according to some embodiments.
  • FIG. 8 is a schematic diagram showing an example lighting module, according to some embodiments.
  • FIG. 9 is a flowchart of a process for waking a module by controller using low energy (LE) sleep timer, according to some embodiments.
  • FIG. 10 is a flowchart of a process for waking a module by controller using interrupt, according to some embodiments.
  • LE low energy
  • FIG. 11 is a flowchart of a process illustrating low power mode control, according to some embodiments.
  • Systems, methods, and computer readable media directed to managing low power mode on modular devices that are managed via a centralized controller are described herein.
  • the controller controls the modular devices to enter low power modes and synchronizes the wake up when requested (e.g., by the user or other device through a computer controlled request data message or object).
  • a modular electronic system can include various variations of different electronic modular devices (e.g., modules, lighting panels) adapted for different functionality.
  • a lighting system with a controller unit and various lighting modules is used as an example, but other variations are possible and contemplated.
  • Other different types of modular devices that are contemplated for use include coordinated cameras, sensors, light switches, thermostats, among others, where the different devices interoperate together through data communications.
  • the examples relating to lighting system apply mutadis mutanis to the other variations.
  • module in this application refers to physical electronic devices that are designed for modular interconnection I coupling (not necessarily directly connected).
  • the modules can be connected using local or wide area network protocols, such as modular devices that are connected over TCP/IP connections, UDP connections, datagrams, etc.
  • a near distance communications protocol such as ZigbeeTM , BluetoothTM.
  • the modules can be connected using local or wide area network protocols, such as modular devices that are connected over TCP/IP connections, UDP connections, datagrams, etc.
  • a controller unit is used to coordinate operation (e.g., the lighting state) of the various modules (e.g., lighting modules) which may constitute a modular system I arrangement (e.g., lighting system).
  • the modular system I arrangement may have a specific geometric arrangement that is established through the positioning and/or orientation of the different modules in Cartesian I Euclidean space.
  • the respective lighting modules may, in some embodiments, be able to go into a low power state such that they can conserve the energy.
  • the approaches proposed herein are adapted to provide practical solutions to control state management of different devices using different approaches to handle wake I sleep commands.
  • commands can be provided in combination with the wake I sleep commands, and the commands can be provided in the form of machine instruction sets, such as commands sent in the form of analog device signals (e.g., voltage up I voltage down relative to neutral), or digital signals (e.g., sending data packets having specific fields and payloads, such as those encapsulated in XML or JSON messaging formats).
  • analog device signals e.g., voltage up I voltage down relative to neutral
  • digital signals e.g., sending data packets having specific fields and payloads, such as those encapsulated in XML or JSON messaging formats.
  • a technical challenge, to which the described embodiments present a solution, is while in such a low power state, the modules may need to be woken with minimal latency perceived by the user and they should be able to continue time- critical communication functions with minimal impact to communication latency. There is a trade-off between latency and energy savings (e.g., time panels need to be awake to make sure they catch a wake message before going back to sleep).
  • latency and energy savings e.g., time panels need to be awake to make sure they catch a wake message before going back to sleep.
  • Clock drift occurs as each of the clocks start to “drift” apart from one another and become desynchronized over time. This is a practical problem as processor clocks start to drift and thus not run at the same rate as a reference clock (until resynchronized). Accordingly, until a re-synchronization, the desynchronization may cause the time difference to diverge over time.
  • a problem with consumer electronics is that it is not always possible to enforce a re-synchronization or expect individual users to have the technical skills to successfully conduct a re-synchronization. This is further compounded with lower cost electronic devices, which are even more susceptible to clock drift.
  • An example maximum latency of 0.5 s is derived from energy standards minimums (e.g., turn on time for lightbulbs), and in certain cases, an 100 ms maximum overall system response could be even more preferred, and as described in various embodiments herein, the controller device can be configured to controlled to periodically poll the assembly (e.g., roughly every 25 ms or 50 ms).
  • the approach described herein can include adapting modules to be awake for at least 2 periods to ensure that the model is able to receive and process the wake signal from a neighbor.
  • the approach could include a different process to re-synchronize clocks every wake period (or set of wake periods), in order to minimize latency and power savings.
  • a first iterative approach utilized panel low energy timer (LE timer) to place the processor into a timed low power mode.
  • the controller would broadcast a message to the panels to sleep for a specified amount of time and then once the panels woke up it would check for user interaction and put them back to sleep if no user interaction is detected.
  • This method had reasonable performance, however, due to the inaccuracies in the clock, the wake up period was large, and required the controller to wait until panels were awake before being able to react to user interaction. This resulted in a high latency before the panels could react to the user’s interaction. If we attempted to reduce the latency the panels wouldn't be in low power mode for a very small amount of time in the sleep-wake period.
  • the second issue was the inaccuracy of the LE timer which resulted in a max low power mode time of no more than 70%, leading to theoretical savings of no more than 30%.
  • Applicants changes the configuration of the approach and removed the dependency of the panels on the LE timer and modified the panel wake mechanism to be based on GPIO interrupts from serial messages received on the root edge.
  • the root edge is the receiving edge of the panel which the panel is listening on for a message from the parent.
  • the controller now would put the panel to sleep, and wait for a wake up message from the panels based on user interaction or send a wake up message to the panel when the user requested the panels to display colour.
  • the controller still needed to a refresh every few seconds, to ensure that no layout changes had occurred.
  • FIG. 1 is a schematic diagram showing an example modular lighting system, according to some embodiments.
  • FIG. 1 Shown in FIG. 1, is a power source 100 providing input power which feeds into a controller, through to eight lighting modules, 102, 104, 106, 108, 110, 112, 114, and 116.
  • lighting modules 102 - 116 may draw 0.18 W of power from power source 100 in a standby mode, and may draw 0.0165 W in a low power state. Lighting modules 102 - 116 may provide minimal latency, which may, in some embodiments, provide response times of 500 ms or less.
  • the clocks on a system on a chip (SoC) of a lighting module may have a documented margin of error of 40%.
  • Embodiments and approaches described may be clock time agnostic, since the controller awaits for all modules, such as lighting modules 102 - 116, to wake up and has methods to verify if all modules have woken up or not.
  • wake intervals were precisely scheduled, then modules could be put to sleep, and there could be high confidence in when the modules will wake up to interrupt the sleep when, for example, a user interaction wakes the layout.
  • the described GPIO interrupt method embodiments for example, do not require this precise scheduling to function appropriately.
  • a leak condition e.g., water sensor
  • a camera detections motion e.g., a camera detections motion
  • an error condition e.g., over-voltage, over-temperature detected
  • Touch inputs from a user are one example of time-critical communication functions which may require low latency.
  • Other examples of time-critical communications may include module touch data, motion sensor data, button presses, and/or other sensor data, among others.
  • the layout of the individual lighting modules 102 - 116 may have an impact on communication time. For example, if lighting modules 102 - 116 were arranged in a long 1-D line, the communication time would be the time of propagation multiplied by the number of lighting modules in the chain. For instance, with lighting modules 102 - 116, if they were re-arranged into a long 1-D chain with eight modules, then the communication time from one end to the controller at the other end may be Tprop*8.
  • the lighting modules 102 - 116 and controller may have a certain layout, and this layout may be mapped according to the connections between the each of the individual modules. For example, the controller connected to module 102, which is connected to both modules 104 and 106, and these two way connections continue and propagate through to the others creating a loop connecting all modules back to the controller. In some embodiments, there may be various different paths from each module to and from the controller.
  • FIG. 2 is a block diagram showing a workflow 200 for waking a system by its controller, according to some embodiments. In workflow 200, the flow of the normal sleep mechanism that is both initiated and interrupted by the controller is described, according to some embodiments, below. The process described below should be understood as exemplary only.
  • the controller sends out a message using a layout detection protocol to instruct all the lighting modules to go to sleep for a defined period of time.
  • a sleep instruction message can include a coded data message that is sent from the controller communication interface and transmitted to each of the modules.
  • the modules transmission can be propagated through each through device to device interconnections.
  • the controller can identify a path to each module and send individualized messages.
  • the controller can simply broadcast a sleep message that is broadcast across all modules to instruct them all to enter the sleep state.
  • the sleep state can be handled through a finite state machine residing on state registers or state memory residing on each module.
  • the sleep state can be set for a defined period of time.
  • the layout detection protocol may be transport methods for hierarchical data networks. Such a protocol may provide methods to transport data providing “address-less data transport” using various approaches to implementation using hardware, software, embedded firmware, circuitry, and/or combinations thereof.
  • An order may be introduced or associated with the nodes to establish relationships, and the order may be stored in the form of a tree topology in a data structure, for example.
  • the order of nodes is thus known, and logic and/or other data sets, data payloads, etc., may be transmitted across the nodes.
  • the transmitting of the content provides for an improved data transport across a topology, for example, such as traversal across a tree topology of address-less nodes.
  • the layout detection protocol may provide a method for transporting data arrays in a data network with multiple nodes, and with connections between nodes.
  • Each node may include multiple network interfaces through which data arrays can be sent and received, and the connections between nodes of the plurality of nodes may be formed through pairwise joining of a plurality of network interfaces of the nodes, such that the network topology of the connections is a tree topology, for example.
  • the method for transporting data may, in some embodiments, include: assigning a first order (e.g. a first ordinal relation) to the network interfaces for all the nodes; determining a second order (e.g. a second ordinal relation) for the nodes as a function of a network topology and the first order, for the network interfaces; and generating a first composite data array by a concatenation of a multiple data arrays, such that a first and a second data array in the first composite data array are in an equivalent order to each other as a corresponding pair of nodes in the second order.
  • a first order e.g. a first ordinal relation
  • a second order e.g. a second ordinal relation
  • the orders may be in relation to the network interfaces of any given node are in. That means, the first order makes statements such as: “select the first network interface” or “select the next network interface” unambiguous and for any specific data network installation persistent. This may be an important consideration for connecting address-less nodes, especially for modular electronics having multiple connectable interfaces where it is not known ahead of time which connections will connect with which, and in what order (e.g. a user is assembling a geometric shape using modular LED panels and would like to be able to conveniently connect them without regard to matching specific panel interfaces or establishing and communicating the shape to a central controller).
  • the second order is similarly an order of the nodes of any given data network. One important consideration is to derive or determine the second order.
  • the content of a first composite data array may be transmitted throughout the data network, such that each node can receive from at least one other node connected through a first network interface, a first contiguous sequence of the first composite data array, and such that each node may send to other nodes connected to it through a second network interface, a second contiguous sequence of the first composite data array, wherein the second contiguous sequence may be constructed from the first contiguous sequence as a function of the first and second order.
  • a first contiguous sequence of the composite data array may be created.
  • the significance of the word “contiguous” is that (1) the sequence is ordered and (2) that it overlaps with one stretch of the content of the first composite data array.
  • the first contiguous sequence can therefore be obtained by simply defining one lower bound and one upper bound to be applied to the content of the first composite data array.
  • a second contiguous sequence may, in some embodiments, be constructed from the first contiguous sequence by applying the same type of minimal set operations, which will, in effect, decompose the first composite data array (or the ordered content comprising the first composite data array, if that is a preferable way to formulate it), into contiguous sequences.
  • these contiguous sequences may be for one given node, overlapping or non-overlapping.
  • any single unit of content of the first composite data array that has been received through a first network interface of a given node, defined as a unit of content Q will only be sent through at most one other network interface of the same given node, in some embodiments. It is possible it is sent through no network interface, since this unit of content can be intended to be consumed by the one given node.
  • the modules proceed to sleep for the period of time defined at 202.
  • the modules may have networking interfaces residing, for example, on different edges of each module for interconnection. These receive the sleep message payload, and process it to enter into a state transition for a sleep, for the defined period of time, either a default amount of time pre-defined on the system, or a specific sleep duration field from the sleep message payload.
  • the modules individually wake for a second period of time, waiting to receive a message on their root side from their parent I root module. Should the modules not receive the message within the second period of time, they may resume sleep.
  • a plurality of available connections e.g., on each edge
  • either all of the connections can be used to await a message, or in a more specific embodiment, only the connections on a “root side” designated as the connection which the path to the controller is designated is woken.
  • the approach to check only the root side can yield more cost I power savings, but has less redundancy in the event of a failure of the root side interface.
  • the controller wakes its children (e.g., modules that are proximate from a connection perspective). In some embodiments, this may be done using a serialized message (e.g., root detect). In other embodiments, this may be done using a general purpose input I output (GPIO) interrupt.
  • the modules may progressively wake their children moving out the tree. Children may be woken by the controller at 208 during the second period of time at 206.
  • the controller may periodically check the lighting module system to see if all modules are awake, as expected, using a layout detection protocol approach. This can be done by propagating various detection messages to effectively poll each module to see if it has woken up yet (e.g., identifying their specific states). The responses from each poll as returned to the controller can be compared, for example, to an expected desired response to check to see if all modules have been woken. For example, this can be compared against a full list of available modules. [0087] The controller may then resume normal functions of the system. These functions can include, for example, the rendering of geometric lighting effects on each or some of the modules, running smart thermostat functions (e.g., maintaining a desired temperature or humidity), turning on cameras, etc.
  • the workflow 200 for waking a system initiated by its controller may follow such a process outlined above, but may in other embodiments include more or less steps, and may be performed in various orders.
  • Workflow 200 may be initiated, for example, when the modules are turned off by a user and the modules are not required to supply any output.
  • the time period defined at 202 may be the period of time for the modules to sleep, and be completely unresponsive.
  • the system requires the modules to wake up after a defined time which may be 500 ms or less, and check for messages from the controller, other modules on their side and/or using a GPIO interrupt.
  • the modules individually wake for a second period of time, waiting to receive a message on their root side from their parent I root module using a very low energy clock available on the hardware to track time for how to sleep.
  • the modules may be woken up by a low energy (LE) timer, and the modules may be configured to check for interruptions to the sleep.
  • LLE low energy
  • These messages can be stored on buffers on the root side. Detection can include interrogation of the buffer memory registers.
  • the messages can only be processed when the module is awakened (e.g., there can be variations without buffers for messaging).
  • the modules may return to sleep for the period of time defined in 202. Due to the low accuracy of a LE timer, for example, the modules may wake up in a staggered manner.
  • a staggered wake can include the controller initiating the wake by sending out the wake message, and individual modules waking up and then waking its children gradually as they wake periodically. Because the timing may not be particularly synchronized as between the individual modules, they may be waking up in waves.
  • the individual waking of the modules at 206 may be adapted to check for messages from other modules or the controller. Since messages cannot be received in the sleep state, modules may need to periodically wake up to check. If interrupted via GPIO, for example, this checking may not needed.
  • FIG. 3 is a flowchart 300 of a process for waking a system by its controller, according to some embodiments. In some embodiments, the process shown in flowchart 300 may follow similar steps to those described in workflow 200.
  • modules 102 - 116 are turned off by a user and the modules are not required to supply any output. Since messages cannot be received in the sleep state, modules 102 - 116 need to periodically wake up to check.
  • the controller may interrupt and initiate a system wide wake up.
  • the controller may be sending out a message using a layout detection protocol instructing modules 102 - 116 to sleep for a defined period of time.
  • the system may require modules 102 - 116 to wake up after a defined time which may be 500 ms or less, and check for messages from the controller, other modules on their side and/or using a GPIO interrupt.
  • Modules 102 - 116 may wake individually for a second period of time to check if they have received a message on their root side from their parent I root module. If the individual module of modules 102 - 116 does not receive a message during this second period of time, the individual module will resume sleeping. In some embodiments, the modules may wake up on expiration of a timer. Differences in the timer’s base frequency may lead to variation in when the modules wake up from sleep mode, for example. [0097] Once the system of modules needs to be woken, the controller can wake its children by, for example, sending a serialized message or using a GPIO interrupt. Beginning from the controller, the modules 102 - 116 may progressively wake their children as the children modules move out the tree.
  • a user may input a desire for all the module lights to turn on, so the controller may send a serialized message to module 102.
  • Module 102 would wake modules 104 and 106.
  • Module 106 would then wake modules 108 and 110.
  • This message sending would continue to propagate through the tree until all of the modules 102 - 116 were awake, which may be confirmed by the controller periodically checking the system to ensure all modules were awake.
  • FIG. 4 is a block diagram showing a workflow 400 for waking a system by a module, according to some embodiments.
  • modules in the system may periodically have real-time information relevant to the controller that is time sensitive (e.g., module touch data, motion sensor data, button presses, and/or other sensor data, among others). It can be beneficial to wake the entire system when this data needs to be transmitted, as it may have relevance to the entire system.
  • a practical example of a waking the from a module can include a lighting module that is being touched by a user.
  • the lighting module has a touch sensor that when the user touches it, it is designed to wake up either a path to the controller, or the entire lighting system and render a geometric lighting effect, for example, starting from the specific module that was touched and radiating outwards.
  • a challenge with such a system to process this touch input is that when the modules are asleep (e.g., to save power instead of constantly having all of the individual modules awake), the touched module now has to wake the entire system.
  • Another use case for wake from module can include a user desiring to initiate a system update without having to interact with the main controller first.
  • the user can connect to a single module, provide the update instructions (e.g., firmware update, BIOS update), and that single module can then begin the wake process and either transmit the instructions to the controller for the controller to propagate out.
  • the update instructions being propagated by way of the wake messages as a piggy backed payload.
  • the workflow 400 of the normal sleep mechanism that is first initiated by the controller and later interrupted by any module in the system is described, according to some embodiments, below.
  • the process described below should be understood as exemplary only.
  • the interruption is the approach to waken the system as initiated by a module (as opposed to the controller).
  • the controller sends out a message using a layout detection protocol to instruct all the lighting modules to go to sleep for a defined period of time.
  • the modules proceed to sleep for the period of time defined at 402.
  • the modules individually wake for a second period of time, waiting to receive a message on any side. Should the modules not receive the message within the second period of time, they may resume sleep.
  • these can be messages that are stored either in buffers (if buffer memory is available), or received in real-time to be processed. In FIG. 2, in a variation, only the root side needed to wake periodically. Unlike that variation of FIG. 2, these messages can be configured to be received at any of the plurality of interfaces (e.g., each interface corresponding to a side) because there cannot be a presumption of which interface the message is received from.
  • the module with the data to be communicated may wake up all of its neighbors. In some embodiments, this may be done using a serialized message (e.g., root detect). In other embodiments, this may be done using a GPIO interrupt.
  • the modules may progressively wake their neighbors moving out the tree. Neighbors may be woken by the controller at 408 during the second period of time at 406.
  • the controller may periodically check the lighting module system to see if all modules are awake, as expected, using a layout detection protocol approach (the “pixel” approach), as described above, for example.
  • step 412 once the modules at least along the shortest path from the module performing the wake back to the controller are awake, the data may be queried successfully by the controller. In some embodiments, step 412 may be skipped, and the controller may resume functionality once all panels have been woken up.
  • the controller once aware of the fact that the system is in the process of being awoken (e.g., a short path has indicated that a wake command was initiated by a module) can start tracking the progress of the wake through polling the system.
  • the controller may continue to periodically check the system to see if all modules are awake, as expected, using various layout detection protocol methods, such as those described in the related patent application.
  • the controller may then resume normal functions of the system. For example, the system begins asleep.
  • the user touches a non-controller module to initiate a geometric lighting effect.
  • the workflow 400 is initiated and the system eventually wakes up all of the modules. While, from a computational perspective, the system may take a number of cycles to full awaken before the geometric lighting effect can be implemented, from a human perspective, it may be an acceptable or non-noticeable level of delay.
  • the longer the sleep duration is relative to the second period of time for individual module wake the greater the power savings at a tradeoff of system responsiveness. However, even if the second duration is relatively small, depending on the frequency of which it occurs, there may be significant power savings.
  • the periodic check can include periodically polling or sending messages to each module and comparing against a list of all available modules. Once all available modules are awake or a timeout period has elapsed, for example, the controller can designate the entire system as being awake and begin normal functionality, such as the rendering of a geometric lighting effect, temperature control, camera operation, etc.
  • the workflow 400 for waking a system by a module may follow such a process outlined above, but may in other embodiments include more or less steps, and may be performed in various orders.
  • Time sensitive information may be understood to be information within 100s of ms, but under 500 ms, for example.
  • the controller may continue to poll the system, broadcasting messages across all awake modules until it reaches the wake initiator module.
  • the controller may wait until it receives messages from all the modules in the system layout, and the controller keeps track of the modules connected in the system layout.
  • the controller may use a layout detection protocol methods to query the layout and retrieve the interaction information.
  • FIG. 5 is a flowchart 500 of a process for waking a system by a module, according to some embodiments.
  • the process shown in flowchart 500 may follow similar steps to those described in workflow 400.
  • module 116 in the system receives real-time information relevant to the controller that is time sensitive (e.g., button presses). It can be beneficial to wake the entire system when this data needs to be transmitted, as it may have relevance to the entire system.
  • the controller may be sending out a message using a layout detection protocol instructing modules 102 - 116 to sleep for a defined period of time. For the wake up latency to be minimum, the system requires modules 102 - 116 to wake up after a defined time which may be 500 ms or less, and check for messages from the controller, other modules on their side and/or using a GPIO interrupt.
  • Modules 102 - 116 may wake individually for a second period of time to check if they have received a message from any side (e.g., a message being received at a network interface on each side). If the individual module of modules 102 - 116 does not receive a message during this second period of time, the individual module may resume sleeping.
  • module 116 which receives an input during one of the second waiting periods, said module with the data will wake its neighbors by, for example, sending a serialized message or using a GPIO interrupt. Beginning from the module with the data to be communicated, the modules 102 - 116 may progressively wake their neighbors moving out the tree.
  • module 116 would wake modules 108 and 114. This message sending may continue to propagate out through neighbor modules.
  • the controller may periodically be querying the system checking for new data, such as the input received by module 116 which would now propagating through the system. Once at least the modules along the shortest path from module 116 to the controller are awake, the data can be queried by the controller.
  • This message sending would continue to propagate through the tree until all of the modules 102 - 116 were awake, which may be confirmed by the controller periodically checking the system to ensure all modules were awake. See an example embodiment of the wake shown in flowchart 500 following a similar path to that described in workflow 400 in Table 1 below:
  • FIG. 6 is a block diagram showing a workflow 600 for waking a module path, according to some embodiments.
  • modules in the system may periodically have real-time information relevant to the controller that is time sensitive (e.g., firmware update, module touch data, motion sensor data, button presses, and/or other sensor data, among others). It can be beneficial to wake only the path from the module to the controller to allow this data to be transmitted when this data needs to be transmitted, as it may not have relevance to the rest of the system.
  • time sensitive e.g., firmware update, module touch data, motion sensor data, button presses, and/or other sensor data, among others. It can be beneficial to wake only the path from the module to the controller to allow this data to be transmitted when this data needs to be transmitted, as it may not have relevance to the rest of the system.
  • workflow 600 Another variation for workflow 600 is the usage of the system for error condition clearing, and reporting same to the controller so that the controller can update internal records. For example, a camera module may be obstructed or have fallen over due to wind, and a user may take steps to rectify the situation. The user rights the camera, and then presses a button to clear the error. An error condition clearing message triggered by the button press is then desired to be sent from the camera module back to the controller. However, this is compounded because the modules along the path to the controller may be asleep. Workflow 600 can be used for the path routing and message sending back to the controller without unnecessarily waking up too many modules along the way back to the controller. By avoiding unnecessarily waking up certain modules, a technical benefit of this approach is to save power by allowing those modules to remain asleep, while being still able to clear the error condition.
  • a module may have interactive buttons or tactile inputs that cause messages relating to the controller to be initiated. These messages can include different controller operation settings (e.g., changing an overall power level drawn from the power grid), etc.
  • the module attempts to find a fast I fastest path to the controller to transmit a message to the controller instead of waking the entire system.
  • the path to the controller is awakened to send the message to the controller, and once the controller is aware of the instruction, it can also begin waking up modules to resume normal functions.
  • each of the modules may periodically assign a module side as the parent I root side module based on a layout detection approach to determine path communications to a parent node or controller.
  • the controller sends out a message using a layout detection protocol to instruct all the lighting modules to go to sleep for a defined period of time.
  • the layout detection protocol can be, for example, one of the embodiments utilized as described in PCT Application No. PCT/CA2019/050012, filed 04-Jan-2019, entitled “TRANSPORT METHOD IN HIERARCHICAL DATA NETWORK” as the communications protocol.
  • the modules individually wake for a second period of time, waiting to receive a message on any side. Should the modules not receive the message within the second period of time, they may resume sleep.
  • This second period of time could be a short duration designed for significant power savings.
  • the drawback of a short duration can be that it may take a number of cycles as the modules wake up in a staggered manner (due to the clock drifts that arise over time as between modules).
  • the module with the data to be communicated may wake its parent I root side module. In some embodiments, this may be done using a serialized message (e.g., root detect). In other embodiments, this may be done using a GPIO interrupt.
  • the modules may continue to wake moving back to the controller. The modules may be woken by the controller at 608 during the second period of time at 606.
  • the controller may periodically query the lighting module system to check for new data. In some embodiments, step 610 may not be required. In some embodiments, the controller is the root I parent, and is the last module to receive the wake up message for a message moving up the tree towards the root I parent. In such an embodiment, it may be guaranteed that all modules on the path to the root I parent are awake by the time the controller receives a message. In some embodiments, step 612 may be directly after step 608.
  • the data may be queried successfully by the controller. In some embodiments, this is not necessarily the shortest path, but a short path is sufficient due to the potential complexity of the layout.
  • the controller may then resume normal functions of the system. These can include firmware upgrades of the controller, error condition clearing, etc.
  • the workflow 600 for waking a module path may follow such a process outlined above, but may in other embodiments include more or less steps, and may be performed in various orders.
  • a path-only relevant scenario, where a workflow 600 may be a preferred wake method may be, for instance, a sensor input that does not result in all the modules having to wake up.
  • a button input for example, will result in the modules needing to wake up.
  • Another path-only relevant scenario may be a firmware update for a particular module or to clear an error-condition in a module, for example.
  • the modules may only wake up their root I parent modules, while making way to the controller.
  • the controller is the parent I root node of the layout tree, so moving up the parent route (via root modules, for example), is the surest way to reach the controller for any module.
  • different path routing algorithms and/or trajectories may be implemented.
  • the layout tree can be established during a periodic poll session that, for example, can be triggered whenever a device is detected to be removed or added to the topology.
  • the layout tree can also be periodically determined through interrogation of the modules.
  • the layout tree or a portion thereof can also be propagated to each module and stored on on-board memory.
  • an alternative to save memory can include simply a designation of which of the connections if there is a plurality of connection is designated as a root connection.
  • the modules may denote each interconnection as a root I parent or children connection.
  • a module A which is connected to modules B and C.
  • on-board memory of module A could indicate that module B is a root I parent module and module C is a child module, and on-board memory may be used to distinguish between the connections.
  • module A would be parent to both modules B and C.
  • redundant connections if B and C were also connected to each other (i.e., all modules connected to one another), these may be referred to as redundant connections.
  • redundant connections may be used. The usage of redundant connections can be triggered as backup connections when the path does not appear to work and the module cannot confirm that the controller has received the message.
  • redundant connects may be used when coupling occurs in the context of a mesh-based network, where devices have medium or low- range communications capability and can “see” various neighbors, and the modular devices include wireless communications transceivers.
  • the devices could be coupled as communications enabled lighting, communications enabled cameras, thermostats, alarms, that cover a larger area, such as across an office, an apartment building complex, among others.
  • Mesh networking can be electromagnetic coupling, and coupling could also occur in the context of communication from a vertex or otherwise arbitrary location along a surface of a module.
  • FIG. 7 is a flowchart 700 of a process for waking a module path, according to some embodiments. In some embodiments, the process shown in flowchart 700 may follow similar steps to those described in workflow 600.
  • module 116 in the system receives real-time information relevant to the controller that is time sensitive (e.g., firmware update, layout change, module touch data, motion sensor data, and/or other sensor data, among others). It can be beneficial to wake only the path from the module to the controller to allow this data to be transmitted when this data needs to be transmitted, as it may not have relevance to the rest of the system. For example, module 116 may require a module specific firmware update, which is not relevant to the entire system of modules.
  • the controller may be sending out a message using a layout detection protocol instructing modules 102 - 116 to sleep for a defined period of time. For the wake up latency to be minimum, the system may require modules 102 - 116 to wake up after a defined time which may be 500 ms or less, and check for messages from the controller, other modules on their side and/or using a GPIO interrupt.
  • Modules 102 - 116 may wake individually for a second period of time to check if they have received a message from any side. If the individual module of modules 102 - 116 does not receive a message during this second period of time, the individual module may resume sleeping.
  • module 116 which receives an input during one of the second waiting periods
  • said module with the data may wake its parent I root side module, for example, sending a serialized message or using a GPIO interrupt.
  • the modules 102 - 116 may progressively wake their parent I root side modules moving out the tree back to the controller.
  • module 116 may wake modules 108 and 114. This message sending may continue to propagate out through the modules by their parent I root side.
  • the controller may periodically be querying the system checking for new data, such as the input received by module 116 which may now propagating through the system. Once the modules along the shortest path from module 116 to the controller are awake, the data can be queried by the controller.
  • the parent or root side may be the side on which the module receives a message. In some embodiments, even in the case of a looped layout, such as that shown in part of FIG. 7, a message may be received first on one of the two sides, for example, and not on both sides.
  • the first side to receive a message may be called the parent side or the root side, and the other(s) may be called the redundant side(s).
  • FIG. 8 is a schematic diagram showing an example lighting module 800, according to some embodiments.
  • lighting module 800 includes one or more digital signal processor(s) 802, memory 804, one or more light emitter(s) 806, a power input 808, and connectors 810, 812, and 814.
  • Processor(s) 802 may be one or more IntelTM x86, Intel x64, AMDTM x86- 64, PowerPCTM , ARMTM processors or the like.
  • Memory 804 may include random-access memory, read-only memory, or persistent storage such as a hard disk, a solid-state drive or the like. Read-only memory or persistent storage is a computer-readable medium.
  • a computer-readable medium e.g., a non-transitory computer readable medium
  • Light emitter(s) 806 may be one or more of light-emitting diodes, or the like.
  • lighting module 800 can also include different types of interactive I input components, such as touch sensors (capacitive sensors), physical buttons, or environmental sensors (e.g., humidity, water, temperature).
  • the input components can include further components, such as a data receipt port such as a USB port so that firmware or other machine instruction sets can be uploaded into the lighting module 800 for ultimately sending same to either all of the modules, some of the modules, or the controller (e.g., firmware upgrade that can be initiated at any capable module).
  • DSP 802 can automatically track conditions and upon a condition trigger being achieved, may initiate the wake of either all of the modules itself or a wake of a path back to the controller. For example, there could be a over voltage condition, and the lighting module 800 needs to wake a path back to the controller to indicate to the controller that it is entering a danger condition. Similarly, a user, upon validating the issue, may press a reset button to indicate that the lighting module 800 has made a spurious message.
  • the pressing of the reset button may require to wake a path back to the controller to indicate to the controller that error is cleared.
  • the lighting module 800 can detect that the error condition (e.g., currentvoltage ⁇ thresholdvoltage) has cleared and conducts the wake automatically.
  • Connectors 810, 812, and 814 may serve to interconnect the lighting module 800 with other lighting modules.
  • the lighting modules connected to lighting module 800 via connectors 810, 812, and 814 may be substantially similar to lighting module 800.
  • module 110 would have nothing connected to its connector 810, but would be connected at its connector 812 to the connector 812 of module 106, and module 110 would also be connected at its connector 814 to the connector 814 of module 112.
  • Each 810, 812, and 814 can have its own networking interfaces and these may, in some embodiments, be designated as different types of connections for the purposes of the messaging as described in embodiments herein.
  • a layout detection protocol may be used periodically and each of these connections can be designated as root/parent (e.g., the root side), or child side.
  • the root/parent connections can be prioritized for communications depending on the method and the child side can be prioritized for redundant communications, or vice versa.
  • the memory 804 can store layout information, or in some embodiments where memory is very limited, simply a set of data records designating each of the plurality of connections as a root/parent connection or a child connection.
  • the memory 804 can also include a message buffer (e.g., memory registers) that track whether there is a recent sleep I wake message to be processed and, in some embodiments store the sleep I wake message for processing when lighting module 800 is awake.
  • the memory 804, in some embodiments, can also store information to be relayed to a controller, such as firmware update information, error clearing I error condition information, etc.
  • the module lighting system, controller and power source may then, according to various embodiments, pass messages to and from the modules and the controller.
  • the controller may in some embodiments, continue to poll to determine the different layout of the individual lighting modules, as they are modular and can be moved. Should a new path be found when a message is being sent, the controller may update its layout tree so that messages can be sent more efficiently.
  • Software instructions are executed by processor(s) 802 from a computer- readable medium.
  • software may be loaded into random-access memory from persistent storage of memory 804 or from one or more devices via I/O interfaces for execution by one or more processors 802.
  • software may be loaded and executed by one or more processors 802 directly from read-only memory.
  • Example software components and data stored within memory 804 of lighting module 800 may include software to perform the wake methods described within.
  • FIG. 9 is a flowchart of a process 900 for waking a module by controller using low energy (LE) sleep timer, according to some embodiments.
  • LE low energy
  • process 900 may expand on the recursive logic that may sit within steps 204-208, 404-408, and/or 604-608, for example. Steps 902, 904, 906, 908, 910, 912, 914, 916, 918, 920, 922, and 924 are shown.
  • module 800 e.g., modular lighting panel
  • the module may place its processor into a low power mode for a certain amount of time. Should the LE timer expire, and the module wakes, the module may, in some embodiments, iterate through its ports, checking for messages.
  • port 1 may be checked, and the module may continue checking from port 1 through to port 6. If there are no messages received on any port, in some embodiments, the module may once again place the processor into a low power mode for a certain amount of time.
  • the module which has received the message may send a message on its parent I root port to wake up the connected module.
  • the parent I root port may be determined by a previous propagation of a message through to the controller.
  • FIG. 10 is a flowchart of a process 1000 for waking a module by controller using interrupt, according to some embodiments. Steps 1002, 1004, 1006, 1008, 1010, 1012, 1014, 1016, 1018 are shown.
  • Process 1000 shows, according to some embodiments, a simpler GPIO flow, which may be similar and/or equivalent to process 900, for example.
  • a module e.g., modular lighting panel
  • the module may, in some embodiments, place its processor into a low power mode indefinitely at 1006. Should the processor be woken up by an interrupt on one of the module ports at 1008, and the module wakes, the module may, in some embodiments, check if the message is for waking up all panels or only for panels on a path to the controller at 1010.
  • the module may check and read a message to wake up all other modules.
  • the module may iterate through its ports. For example, such a hexagon shaped module may send a message on port 1 to wake up a child module, if present, and then may send a message on port 2 to wake up a child module, if present, and may continue to send messages through to port 6, waking all present child modules. All modules would thus be in active mode, and may in some embodiments, continue within such a process 1000.
  • the interrupted module may send a message on its parent I root port to wake up the connected module.
  • the parent I root port may be determined by a previous propagation of a message through to the controller.
  • process 1000 may illustrate a flow for a single module. If, for example, the module is woken up, irrespective of path wake or system wake, the module may end up in the active mode. However, before the module enters active mode, it may check where it should propagate the wake up message, based on path or system wake. The module may then send the message.
  • FIG. 11 is a flowchart of a process 1100 illustrating low power mode control, according to some embodiments. Steps 1102, 1104, 1106, 1108, 1110, 1112 are shown.
  • FIG. 11 illustrates, according to some embodiments, an example implementation on the controller side, and may show how user interaction (e.g. from a smartphone app or voice assistant) can trigger interrupts.
  • user interaction e.g. from a smartphone app or voice assistant
  • the controller may check if modules may be placed into a low power mode at 1102. In some circumstances, modules may be required to be on, or in an active state, and would not be permitted to be placed into a low power mode.
  • the controller may send an “enter low power” message to the modules. While in low power mode, the modules may listen for a wake up message from other modules, for example at 1106. If no messages are received, in some embodiments the module may then check and listen for user interactions at 1108. If no interaction is received, the module may continue listening for wake up messages from panels, and cycling through as shown in process 1100, for example. In some embodiments, the module may listen for a user interaction before listening for a wake up message from other panels.
  • the module When a user interaction is performed on a module, the module “wakes up” (e.g., becomes active) and sends a message or changes the state of a pin on the edges. Depending on the kind of interaction and whether a system or path wake is required, either all the edges or only the parent edge of the panel is switched. This is a useful approach to help optimize power savings.
  • the message propagates depending on the message type and whether it’s a system or path wake.
  • Message type can be processed based on fields in the message payload, such as header or body message payloads indicating whether the message is a system or a path wake.
  • modules propagate the message, they exit low power mode, and remain in active mode until instructed by the system controller to enter low power mode again.
  • Instruction by the system controller can include messages being propagated by the controller.
  • the total latency of the message propagation to the system controller would be the time for a module to exit low power mode multiplied with the number of modules in the path to the system controller.
  • some embodiments may use signal on edge pins as an interrupt to exit low power mode. Some embodiments may also sample the edge pins and/or communication pins for a message. This can lead to a higher latency but may be a simpler option for the processor architecture.
  • An example of a pure path wake would be a sensory module that needs to report the observation from its sensor to the system controller. In such a case, the module does not know if the observation will result in the system exiting low power mode, and hence only the path to the system controller needs to exit low power mode. Similar methods as mentioned above for system wake can be used for path wake as well.
  • the system may check if the modules have exited low power mode. In some embodiments, this check may be done using a layout detection protocol as described in detail above, for example. If a user interaction is detected, a wake up message may be sent to the modules, and the system may check if the modules have exited lower power mode at 1112. In some embodiments, this check may be done using a layout detection protocol, for example. In both cases, as shown in example process 1100, this check may reiterate until all panels have exited low power mode.
  • the controller may continue to check if the modules may be placed into lower power mode, and wait if the modules are still required to be on, until they may return to be placed into low power mode again.
  • edge communications may refer to communications on an edge of the system, such as the edge of a module.
  • communication interfaces may not be restricted to physical edges, but rather may occur at different locations along a surface, interior, or exterior of a modular device, for example.
  • a controller device for controlling power conservation states of a modular system including one or more modular devices electromagnetically coupled to one another or the controller device across one or more communication interfaces of each modular device.
  • the controller device comprising: at least a processor, computer readable memory, and the one or more controller communication interfaces.
  • the processor configured to: communicate a wake message to children modular devices of the one or more modular devices that are coupled directly to the controller device, each of the children modular devices configured to wake periodically during a sleep state period of a corresponding power management protocol and to process the wake message to transition to a woken state.
  • Each of the children modular devices after transitioning to the woken state, proceed to propagate the wake message to its corresponding children modular devices that are coupled across the corresponding one or more communication interfaces such that successive children modular devices are transitioned to the woken state.
  • the processor also configured to periodically communicate a poll message to be propagated across all of the children modular devices to receive a poll response from each of the children modular devices that are in the woken state; and upon determining that all of the children modular devices are in the woken state, initiate a desired system functionality across the entire modular system.
  • a modular device for controlling power conservation states of a modular system including one or more modular devices electromagnetically coupled to one another or the controller device across one or more edge communication interfaces of each modular device.
  • the modular device comprising: a processor, computer readable memory, and the one or more edge communication interfaces.
  • the processor configured to: in response to a triggering event, transition the modular device into a woken state; communicate a wake message to children and parent modular devices that are coupled directly to the modular device, each of the children and parent modular devices configured to wake periodically during a sleep state period of a corresponding power management protocol and to process the wake message to transition to a woken state.
  • Each of the children and parent modular devices after transitioning to the woken state, proceed to propagate the wake message to its corresponding children and parent modular devices that are coupled across the corresponding one or more communication interfaces such that successive children and parent modular devices are transitioned to the woken state.
  • the controller device periodically communicates a poll message to be propagated across all of the children modular devices to receive a poll response from each of the children modular devices that are in the woken state. Upon determining that all of the children modular devices are in the woken state, the controller device initiate a desired system functionality across the entire modular system.
  • a modular device for controlling power conservation states of a modular system including one or more modular devices electromagnetically coupled to one another or the controller device across one or more communication interfaces of each modular device.
  • the modular device comprising: a processor, computer readable memory, and the one or more communication interfaces.
  • the processor configured to: in response to a triggering event, transition the modular device into a woken state; communicate a wake message to parent modular devices that are coupled directly to the modular device, each of the parent modular devices configured to wake periodically during a sleep state period of a corresponding power management protocol and to process the wake message to transition to a woken state.
  • Each of the parent modular devices after transitioning to the woken state, proceed to propagate the wake message to its corresponding parent modular devices that are coupled across the corresponding one or more communication interfaces such that successive parent modular devices are transitioned to the woken state.
  • the controller device periodically communicates a poll message to be propagated across all of the children modular devices to receive a poll response from each of the children modular devices that are in the woken state. Upon determining that the child modular device that initiated the wake is in the woken state, the controller device initiate a desired system functionality relating to the child modular device that initiated the wake.
  • propagating the wake message to the corresponding children modular devices by the modular device includes maintaining the propagated message on a message buffer at the corresponding one or more communication interface until the wake message is processed.
  • propagating the wake message to the corresponding children and parent modular devices by the modular device includes maintaining the propagated message on a message buffer at the corresponding one or more communication interface until the wake message is processed.
  • propagating the wake message to the corresponding parent modular devices by the modular device includes maintaining the propagated message on a message buffer at the corresponding one or more communication interface until the wake message is processed.
  • the message buffer is stored in a memory buffer of the modular device propagating the wake message.
  • the message buffer is stored in a memory buffer of the modular device receiving the wake message.
  • each of the modular devices are configured to wake asynchronously free of a precise schedule for waking during the sleep state period to identify whether the wake message is present on the message buffer and to process the wake message if it is present on the message buffer.
  • each of the modular devices if already in a woken state, processes any wake message present on the message buffer by discarding it.
  • the poll response from each of the modular devices includes at least one data field indicating that there are no wake messages present on any message buffer associated with the corresponding modular device, and the at least one data field of the poll responses from each of the one or more modular devices is utilized in determining that all of the children modular devices are in the woken state.
  • the poll response from each of the modular devices includes at least one data field indicating that there are no wake messages present on any message buffer associated with the corresponding modular device, and the at least one data field of the poll responses from each of the one or more modular devices is utilized in determining that all of the children modular devices are in the woken state.
  • the wake message is communicated through a serialized message or a general purpose input I output interrupt message.
  • the modular devices are modular lighting devices.
  • a periodic wake during the sleep state period is controlled by a low accuracy or unsynchronized low energy clock of each of the modular devices.
  • a non-transitory computer readable medium storing machine interpretable instruction sets representing a software program product, which when executed by a processor, cause the processor to perform the method for controlling power conservation states of the modular system including the devices according to any one of the described embodiments.
  • the power saving is calculated to be 96%. It is important to note that these experimental results are not necessarily the same all the time as it depends on the percentage of sleep time and duration and the intensity of wake commands and how quickly the system returns to sleep.

Abstract

Une approche pour gérer des états de faible puissance de dispositifs électroniques modulaires qui sont interconnectés les uns aux autres est décrite. En particulier, l'approche met en œuvre un certain nombre d'étapes de commande qui sont utilisées pour commander le fonctionnement des dispositifs électroniques modulaires par rapport à des états de faible puissance "veille" et des états d'éveil, les étapes de commande étant conçues pour réduire au minimum la latence associée au réveil des dispositifs électroniques modulaires pour réduire une latence perçue qui peut empêcher une expérience d'utilisateur associée aux dispositifs électroniques modulaires.
PCT/IB2023/057944 2022-08-06 2023-08-06 Systèmes et procédés de gestion d'état de faible puissance WO2024033775A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202263395796P 2022-08-06 2022-08-06
US63/395,796 2022-08-06

Publications (1)

Publication Number Publication Date
WO2024033775A1 true WO2024033775A1 (fr) 2024-02-15

Family

ID=89851097

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2023/057944 WO2024033775A1 (fr) 2022-08-06 2023-08-06 Systèmes et procédés de gestion d'état de faible puissance

Country Status (1)

Country Link
WO (1) WO2024033775A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120159221A1 (en) * 2010-12-21 2012-06-21 Jayakrishna Guddeti Apparatus, method, and system for early deep sleep state exit of a processing element
CN110209428A (zh) * 2018-12-28 2019-09-06 深圳市泰衡诺科技有限公司 一种终端屏幕唤醒方法、装置、终端及存储介质
US20190369709A1 (en) * 2017-01-31 2019-12-05 Hewlett-Packard Development Company, L.P. Parallel/serial operational sequencing
CN112208470A (zh) * 2020-12-11 2021-01-12 智道网联科技(北京)有限公司 一种实现设备低功耗的方法及车载终端

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120159221A1 (en) * 2010-12-21 2012-06-21 Jayakrishna Guddeti Apparatus, method, and system for early deep sleep state exit of a processing element
US20190369709A1 (en) * 2017-01-31 2019-12-05 Hewlett-Packard Development Company, L.P. Parallel/serial operational sequencing
CN110209428A (zh) * 2018-12-28 2019-09-06 深圳市泰衡诺科技有限公司 一种终端屏幕唤醒方法、装置、终端及存储介质
CN112208470A (zh) * 2020-12-11 2021-01-12 智道网联科技(北京)有限公司 一种实现设备低功耗的方法及车载终端

Similar Documents

Publication Publication Date Title
Hill et al. Mica: A wireless platform for deeply embedded networks
Ye et al. A self-adaptive sleep/wake-up scheduling approach for wireless sensor networks
Buonadonna et al. TASK: Sensor network in a box
Vujović et al. Raspberry Pi as a Wireless Sensor node: Performances and constraints
TWI383301B (zh) 網路同步方法與系統
Wang et al. An IoT-based appliance control system for smart homes
TWI453580B (zh) 用於一異質性電腦系統之橋接邏輯裝置
CN104135408A (zh) 一种用于智能家居无线控制的系统及利用该系统的方法
US9477293B2 (en) Embedded controller for power-saving and method thereof
US9671849B2 (en) Controlling power supply unit selection based on calculated total on duration
CN103827773A (zh) 建立低功耗计算机系统的方法和系统
TWI417731B (zh) 匯流排處理裝置及方法
CN105511387A (zh) 一种plc io扩展模块及其扩展方法
TWI511494B (zh) 一種低耗電之無線感測網路系統與運作方法
US20150346789A1 (en) Power supply system for an information handling system and power supply method thereof
CN110554943A (zh) 一种基于i3c的多节点服务器cmc管理系统及方法
US10849084B1 (en) Asynchronous realizations based on accurate, energy-efficient, decentralized, single-hop time synchronization protocol for WSNs
Gao et al. A wireless sensor network environment monitoring system based on TinyOS
TW201325287A (zh) 低功率無線感測系統
JP2022501690A (ja) 電力管理装置及び動作方法
WO2024033775A1 (fr) Systèmes et procédés de gestion d'état de faible puissance
CN103188736B (zh) 基于流量控制的ant节点电源节能方法
Wang et al. Energy-optimal batching periods for asynchronous multistage data processing on sensor nodes: foundations and an mplatform case study
JP2019106660A (ja) 電池駆動型無線通信システムおよび同期補正方式
CN204832835U (zh) 大型办公楼宇智能用电电器控制系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23852086

Country of ref document: EP

Kind code of ref document: A1