Logiblock specializes in low energy design at the schematic and firmware levels. Our libLogiC rapid-development framework implements a deadline-scheduling RTOS (realtime operating system) which means that a microcontroller runs only exactly the code necessary to make your product run most efficiently.
The most energy-efficient chip
is a chip that's powered off.
To conserve energy, Logiblock designs embedded systems that are only powered-on and running software when they need to be. Supporting this design in firmware while multitasking and remaining responsive is tricky, but Logiblock's deadline-scheduling RTOS is up to the task.
A cooperative multitasking design also makes software development efficient, predictable and low-risk. At run-time, the scheduler will go so far as to cluster events with nearby deadlines to minimize wakeups and maximize overall efficiency.
There's inevitable latency in remote actuation, not in sensing, but it can be hidden with good design.
When designing wireless features for a low-energy device, there is a near-universal compromise between energy consumption and latency. As a device is required to use less energy, typically the period between data transmission/reception events becomes longer and its responsiveness decreases.
Remote actuation of a product is best when it's truly remote.
Take, for example, a device that can remotely open and close a window to let fresh air into a home. This device runs on batteries and uses Wi-Fi to report the current open or closed state and to receive actuation commands. Because it runs on batteries, the device can't be connected to Wi-Fi very often or for very long. When the window is manually opened or closed, the device can immediately wake up and update the web tier. Receiving commands to remotely open or close the window, however, cannot happen instantaneously.
The latency associated with remote control is completely acceptable in this case if the product is designed such that the window is primarily operated manually, with automatic operation reserved for when nobody is home. With that expectation, the device could check in via Wi-Fi every 30 minutes to learn if there is a state change requested.
The actuation latency in this case is hidden behind the fact that nobody is home to observe it, and that neither weather nor indoor air quality usually change dramatically enough in thirty minutes to be a problem (though a rain sensor may make for an appealing defense against that condition.)
Protocol bridges can be a handy solution, but are best avoided unless absolutely required.
Selecting the right wireless protocol, parameters and expectations are crucial to building a usable low-energy product. Sometimes it's not possible to find an acceptable compromise between all three, and in those cases the best solution may be a wireless bridge device.
Wireless (and wired) bridges are devices which adapt one kind of network to another, like a Wi-Fi access point/router. The bridge for the Philips Hue system is an example which bridges Wi-Fi and Ethernet to Hue's closed 802.15.4 mesh network. The August Connect is an equivalent that bridges Wi-Fi to the Bluetooth Low Energy protocol.
Bridges usually incur a cost in building, certifying, selling and supporting an additional device, plus they burden customers with additional setup and run the risk of being unplugged by users who, over time, forget what it's needed for. If the benefits of the bridge outweigh these factors then they can be a sensible design investment.
Copyright © 2015 Logiblock / Outbreak, Inc.
Logiblock