Advancing Advances in Technology
Sometimes taking a fresh look at “conventional wisdom,” no matter how advanced it is, can open even newer and more exciting possibilities.
TOM WILLIAMS, EDITOR-IN-CHIEF
Page 1 of 1
Two innovative companies have different takes on what could be called “conventional advanced technologies”—graphics and wireless networks. Both highlight ways these slightly different approaches can potentially drive embedded technologies forward. They are Fluffy Spider technologies, with a unique approach to graphical user interfaces, and EnOcean, with a focused view on how to use wireless and wired networking in building management.
Decoupling UI and Application
The concept of an “autonomous” user interface is the brainchild of developers at the whimsically named company, Fluffy Spider Technologies. The idea behind an autonomous UI is to decouple the actual implementation and behavior of the screen presentation from the application code. Doing this has a number of implications for how a user interface can be designed, modified—even programmed—and expanded to suit the needs of users and new device capabilities without having to touch the underlying application code.
For companies that are looking to offer a line or family of products, the ability to change and customize the graphic look and feel and even the behavior of the user experience can have a number of advantages—especially if it does not require modifying the actual application. Fluffy Spider’s latest effort is called FancyPants 3.0, which is a user interface that incorporates graphics and multimedia in such a way that it interacts with the application via an engine that lets the application developer specify the generic and abstract presentation of controls and widgets, the presentation of data and even content, but then lets the OEM or other downstream channel partners customize and brand the device for their own segments.
This has a particular appeal because once the application code that has been exhaustively developed and tested has gone through the QA cycle, it can be left alone and need not be subjected to another run of QA simply because the user interface has been changed, because these changes do not affect the application code.
FancyPants has at its heart an engine written in C that interacts with the application’s API and with the elements of the UI as well as with the Lua scripting language, which is used to specify the UI as well as to program its behavior at a high level. Lua is extensively used in the gaming world. Thus the programming of the presentation, the look and feel and the behavior of the UI can take place independent of the application, which simply outputs and inputs to the UI engine.
This decoupling not only allows customization, it also makes it possible for different applications running on different processors, different cores or in a virtualized environment on a single CPU to share the same physical display and to interact with each other. Not surprisingly, FancyPants has been found attractive by the cell phone and mobile device sector because these devices often use quite different processors, where one, for example, handles the most important tasks, which involve the actual communication connection. Another CPU would be running other applications on a smart mobile device. The different applications may need to interact, but there must be no compromise of the underlying communication.
Using an autonomous user interface, such applications can share the same screen, but the data sent to the UI can also be used by the ability to program that UI to do interesting things. In Figure 1, there are two displays with a vastly different look and feel, but they are sitting on top of the exact same application. Also, the display on the right is showing additional information in the form of signal strength and battery life that might not be considered of interest to a user of the display on the left.
Two FancyPants displays running on exactly the same underlying application with completely different look and feel with one displaying information not shown on the other—tailored to the perceived needs of the user.
Autonomy also opens the ability for the user experience to be enhanced with additional device capabilities, if they are added to an existing device, by way of operating system events. For example, if some mobile device comes out with additional hardware capabilities such as GPS, a compass or a thermometer, it is not necessary to modify the application to present that information to the user. The OS can present the data and the UI can be modified to present it. Naturally, if that data is to be used by the application in some new way, it will be necessary to go into the application code and modify it to do so.
Nonetheless, different applications can achieve limited interaction via the UI. For example, the UI could be programmed to look for a given value from one application and if it meets a condition, alert the user and present data from a different application that the user needs to know about. Alternatively, there can be different UI configurations to match the roles of individuals in operations that are based on devices that are actually running the same underlying application code. It would even be possible to bring up a detailed diagnostic or troubleshooting UI on a device that would only be meaningful to a technician but would be instantly available. The possibilities are vast.
The freedom granted by decoupling the UI will also make it easier for third-party developers to create applications that can run on a device and share the same display, for different sales channels to customize and brand devices for their target customers. And eventually it could find use in all kinds of control and automation systems.
In this incarnation, the Fluffy Spider FancyPants solution is unique and consists of the elements depicted in Figure 2. However, the idea of decoupling the UI from the application in such a way could easily catch on in other incarnations. The concept has definite potential in areas like SCADA systems where there are many devices and applications that need to present data and interact with the supervisor and are added and reconfigured constantly. Look for this idea to catch on.
The FancyPants high-level architecture.
Sensor Networks—Wireless and Wired
There is a great deal of activity these days in the area of wireless sensor networks. The Zigbee protocol is being widely adopted and some other proprietary mesh network protocols are cropping up in low-power sensors that are deployed in a vast number of applications such as agricultural and environmental monitoring, security, building management and more. Such wireless mesh networks eventually connect to larger nets based on TCP/IP and often on up to the Internet.
At the level where sensor and actuator nodes are located in difficult and often remote places, the issue of power is paramount. No matter how long a battery may last, it eventually needs to be replaced. This can often involve expensive labor and unacceptable down times. One solution finding its way into the world of wireless sensor networks is energy harvesting—taking and storing small amounts of energy from the surroundings and using it to power the sensor nodes.
The reason energy harvesting is practical at all lies in the commonly used duty cycles of the devices. Mostly, they are in sleep mode, waking only briefly to check for input and/or to transmit a very small packet of data. This allows small amounts of energy to trickle in over time and be used for the very short interval needed.
In the arena of building and facility management, there are unique conditions for which a German-based company, EnOcean—now expanding in the U.S.—is seeking to offer optimized solutions. In buildings, of course, there are tight and out-of-the way places where sensors, actuators and switches are needed. There are also convenient places where both line power and wired networking are available. The trick is to find the optimal mix to solve the facility management problem.
EnOcean has its third generation of Dolphin wireless modules that either integrate with line power or can take advantage of energy harvesting and fit into a larger network to control a building. This requires not only sensors and switches to sense and decide and then to turn things on and off, it also requires line power to do things like open and close valves and control HVAC equipment. Finding the right mix is important.
On the low-power wireless end, the Dolphin devices can make use of a variety of energy harvesting techniques to stay alive without battery power and to send the radio transmissions as needed. For example, the ECT 300 Perpetuum (Figure 3) is an energy harvester that uses a Peltier element that operates off of temperature differentials as small as a few degrees Kelvin. Depending on the actual differential, it can output about a milliwatt. A booster ups the voltage to about 3.5V, but at very low current.
The EnOcean ECT 300 thermal energy harvesting device draws energy from temperature differentials.
The output energy is stored on the device being powered in a capacitor to be available for use when the node wakes up and needs to transmit data. The data packets are very small, only 110 bytes and can be sent in under a millisecond. The user can adjust the duty cycle to determine how often to wake the device to either check for incoming messages or to transmit. A development kit is available to help analyze the power needs and set up the modules accordingly.
Other types of energy harvesting devices are available including a motion converter with an induction coil that can convert energy from things like a button being pushed, a door being opened or vibration, depending on where it is installed. There are also solar cells available for places where they would be more appropriate.
In order to help optimize the wake time (e.g., a device wakes up, finds no message, goes to sleep and ten milliseconds later there is a message sent) so data is not missed, EnOcean offers a line-powered Postmaster device that has mailboxes assigned to each module so that messages can be optimally received. This demonstrates EnOcean’s view that mesh networks are not mature enough for reliable operation and that there should be optimal connection between the wireless, low-power devices and the larger broadband network. According to EnOcean’s Eugene Yu, 99 percent of the applications get to the broadband network in one hop or use a repeater.
This is why the Dolphin system does not use a mesh network, but endeavors to make a connection between the wireless device and the broadband network in one hop. This is also the reason that the Dolphin system uses lower frequencies than many other wireless sensor networks including Zigbee. Dolphin uses 868 MHz in Europe and 315 MHz in the U.S. because these lower frequencies are more able to penetrate walls, thus also reducing the need for multiple hops through a mesh.
Fluffy Spider Technologies
Cottonwood Heights, UT.