The Embedded Beat: Freescale Blog Community - Everything Wireless

Sensor fusion and the Internet of Things (IoT)

r62516@freescale.com — Sat, 11 May 2013 02:04:13 GMT

Last month I had a paradigm shifting experience in Europe, when I presented a paper about The Role of Sensor Fusion and Remote Emotive Computing (REC) in the Internet of Things (IoT). I had presented this paper in the U.S. multiple times to a few analysts and reporters, as well as at a couple of different forums and shows. The reaction that I got from the European audience was completely different than what I had experienced in the US, and made me realize how different the experience of IoT could be in Europe versus the U.S.

Now about the topic and setting up the context to the reaction I received from that audience. The paper was about the pervasiveness of sensor technology and how the sensors are experiencing a renaissance of sorts as micro-electromechanical systems (MEMS) technology is becoming less expensive and further miniaturized, in turn fueling penetration of sensors into new applications and creating new potential for the sensor market. Sensors are now found in a wide variety of applications, such as smart mobile devices, automotive systems, industrial control, healthcare, oil exploration and climate monitoring. Sensors are used almost everywhere, and now sensor technology is beginning to closely mimic the ultimate sensing machine … the human being. The technology that allows this to happen is sensor fusion, which leverages a microcontroller (a “brain”) to fuse the individual data collected from multiple sensors to get a more accurate and reliable view of the data than one would get by using the data from each discrete sensor on its own. Sensor fusion creates a situation in which the whole is much greater than the sum of its parts.

Sensor fusion enables context-awareness, which has huge potential for the Internet of Things (IoT). Advances in sensor fusion for remote emotive computing (emotion sensing and processing) could also lead to exciting new applications in the future including smart healthcare. However, these capabilities spark significant privacy concerns that IoT governance will need to address. Massive amounts of context-aware data will become available as use of sensor fusion and REC technologies increases. This data, along with the IoT’s access to the “global neural network in the sky” and cloud-based processing resources, will lead to a tremendous expansion in the delivery of context-aware services, customized for any given situation.

When combining all of these technologies, sensor fusion takes the simultaneous input from the multiple sensors, processes the input and creates an output that is greater than the sum of its parts. Sensor fusion provides a whole host of capabilities that can make our lives easier and enables a variety of services that can leverage these capabilities.

Research shows that heart rate increases due to physical activities have a different pattern and slope than increases due to adrenalin from excitation. Hence, one can use algorithms and analyze sensor data to electronically detect the types of emotion a person is displaying.

Here’s an example of a gaming platform that can detect emotions electronically by monitoring and data acquisition from physiological variables and states, such as:

Muscle relaxation (MR) – via a pressure sensor
Heart rate variability (HRV) – via a two-electrode ECG on a chip
Sweat (S) – via a capacitive sensor
Attitude (A) – via an accelerometer monitoring a person’s state of relaxation (jerky movements vs. steady hands)
Muscle contraction (MC) – via a pressure sensor

Using the sensor data collected, an MCU in the game platform could, for example, detect emotions and give the gamer feedback during game situations to make the game more exciting. How about making turns faster and more difficult to maneuver in a driving game until the gamer shows a more relaxed state (a less jerky reading from the accelerometer)? Hence, the calm driver with better command over his/her emotions will have a better score (similar to real life). This would be considered local emotive computing if the local console’s MCU provided the processing function or remote emotive computing if a cloud-based system provided the processing function. In a cloud-based system, sophisticated “big data” algorithms can be leveraged to provide a more elaborate response to the gaming scenario.

In another example, sensors could be used to detect emotion by measuring the way a user holds a cell phone to type or make a call. Furthermore, software algorithms could be used to provide additional context as to the state of mind of the individual by analyzing the way the person texts, how jerky the phone movement is or how many mistakes are made while typing (use of backspace key).

The addition of sensor fusion platforms and remote emotive computing dramatically increases the capability of the sensing nodes in the IoT. In using contextual information to formulate a deterministic action, context interfaces occur within (and in between) first a human being, then the environment and, lastly, machine and infrastructure elements. Nothing detects and provides the readout of human beings’ emotions the way sensors do. Sensors provide access to the human mindset, making an experience more “personal.” Now what’s the most secret and precious thing that a person holds and usually is difficult to obtain, unless the person volunteers it? It is the person’s emotions and their reaction to their various stimuli? What if sensor fusion would allow a service provider know exactly how you feel when you are exposed to a certain product, location, environment, etc? What is the value of that information to the people who are the providers of those goods and services? Do you really want the world to have access to your most inner feelings, and what your wife or significant other may not know, the local service provider to know?

In previous blogs we had already talked about the privacy issues on the existing internet of people, without any notion of sensor fusion. This was the exact concern the Europeans had, the sense of loss of their privacy. During my talk, you could hear a pin drop in the auditorium of close to 500 people, and after the talk there was more time spent by the audience explaining to me the privacy laws in Sweden and Germany, than any of the technical discussions I was used to from my US presentations. The best way of describing the situation was that the audience was completely freaked out of the notion of a big brother reading their emotions … what a difference compared to the US where we the people have clicked away a lot of our privacy rights via “click-through” terms and conditions in an excitement to use the latest apps on our smart phone. In the US, it’s all about the technical discussions and the price points, and somehow we have all accepted the fact that “commerce” is the big brother we have created for ourselves, so cheap access to the latest and greatest apps. I have now come to understand that security and privacy of IoT will follow different paths in the US vs. Europe. Which model do you prefer?

Kaivan can be reached at kaivan.karimi@freescale.com.

Will the Internet of Things (IoT) turn your smart phone into the center of the universe?

r62516@freescale.com — Thu, 04 Apr 2013 18:57:34 GMT

Yesterday I spent a couple of hours trying to explain to a colleague the IoT, covering the building blocks from the edge of the network with sensing nodes, to the core of the network and cloud based processing, and everything in between. I drew a bubble diagram that shows the layers of embedded processing and connectivity and went on to explain the underlying requirements of each node.

However, I seemed to hit a mental block as he repeatedly brought to my attention the role of the smart phone and today’s cellular operators, how the IoT is all about new apps running on your smart phone controlling various “parts of life” around you, and how exciting it would be to bring the world of apps into your home — and that’s what IoT is all about. I have to admit that I certainly am a fan of my Nokia Lumia 920 smartphone, and turning it to the center of certain home services is quite appealing to me. However, how much of this matches the reality of IoT when it gets rolled out?

Telematics services today are packaged by operators as machine to machine (M2M) technology services, which are being offered to businesses for a variety of applications. A lot of focus is given to business insight (code word for "Big Data" analysis), with the hypothesis that connected machines are fast becoming the eyes and ears of the enterprise, and by adding sensors and networking technologies to the products they sell and the equipment they employ, companies can find new ways to gather powerful insights and use new forms of data. For example, the Verizon advertisement for their M2M telematics services states: “With the influx of device-generated data, businesses can improve decision making and respond more quickly to customer demands. And customer-centric innovations enhance customer satisfaction and provide serious differentiation.” In fact, Verizon was named the Best Telematics Service Provider at the 2012 Telematics Detroit conference. Services offered include asset tracking, fleet management and remote monitoring, among others.

I realize that I have seen the advertisements for these kinds of services by operators around the world before. The ads feature a smiling individual using the touch screen of a tablet or cell phone to make things happening remotely. Voila, now I know why my colleague looks at IoT the way he does — he has been watching too much television!

I changed the diagram, and looked at it from a box level point of view. And yes, cell phones and tablets do show up in a couple of places:

As mentioned in my original IoT whitepaper titled, What the Internet of Things (IoT) Needs to Become a Reality, there are as many edge/sensing node types as there are applications, however all could (or would) include:

• An MCU

• Sensors and actuators

• Integrated modem chip (connectivity)

• Energy source

For the initial rollout, these nodes need to be very small, low cost, low power, low complexity, and robust. Here are a couple of examples, with one being an event monitoring module, and the other Medtronics’ glucose monitoring device that uses Bluetooth to communicate with various gateways. The edge node will always be communicating with a gateway/hub, which in turn will communicate with the core network and cloud based processing. Ninety nine plus percent of the time, that gateway is in form of a box, with potentially interactive screen that allows the user or the gateway/hub to communicate with various “things”, collect the data, using embedded processors, decide on either local actions (based on services, user preferences, situations, etc.), or aggregate and pass the information for cloud based processing, then receive the action directives back and send the commands to the edge nodes. With the category of products called life-style devices or wearables (depending on which analysts’ categories you follow), they will directly communicate with your cell phone and tablet, and use it as a gateway/hub. That is why Bluetooth low energy is taking off in such a big way in this segment of the industry, as all smart phones will be Bluetooth 4.0 capable in the near future, and will be able to communicate with those devices (similar to the Medtronics example from the above diagram). As a gateway, the smart phone/tablet, then sends the data to the data center for cloud based processing, and potentially receives it for the application/action part of the system (top right hand corner box). So in these cases the smart phone/tablet plays a dual role.

This, however, is a fraction of the scenarios envisioned for the IoT applications. The majority of the time it will be another gateway that will be used, and the role of a smart phone is potentially limited to the application/action part of it, and this only for services that user is aware of or allowed to intervene (again a fraction of a fraction of the time).

Now let’s consider the role of the cellular infrastructure in the above diagram. It is extremely doubtful that cellular will be used for any Body Area Network (BAN), Personal Area Network (PAN), or Local Area Network (LAN) applications. That leaves a means for supporting the Wide Area Network (WAN) communications. Rolling out the IoT is like rolling out the largest control data network in the world, hence significantly more data will need to get to the cloud than today, and by some estimates, by 2020 that data traffic will increase by 22X.

Wireless WAN solutions aimed at smartphones (ala LTE) cannot scale, as already 80 percent smart phone data today is offloaded to WiFi networks. How would an LTE network, which is ill-suited to support a lot of IoT services that require building penetration of the signals, use its precious spectrum to support IoT WAN services? Note that cellular networks are only one of the many options that will be available to support the WAN services. The cheapest way obviously is the use of a wired access point, such as a T1 line, and if it is over-fiber optics lines, so much better. Other candidates that are heavily pursued by utility providers, include various forms of power line communications. Then there is 802.11ah, which is on the drawing board and aims to operate at sub-gig frequencies which will increase its range and also will have much better in building coverage than LTE does. Last but not least are the new disruptive standards such as Weightless from Neul, which uses TV white space, and aims at supporting a 10km range, with devices able to have 10-year battery life, and terminal cost of around $2, supporting around 20Mbps.

Here’s a pictorial view of some of the communication standards being considered for various parts of this heterogeneous data network, which is expected to become the largest control data network in the world.

If I was a betting man, I would pick technologies such as Weightless and 802.11ah as the wireless WAN technologies of choice, before I assume LTE would have a role in most of IoT WAN related applications.

I will now go back to my brainwashed colleague who watches too much television, and ask again if he believes his smartphone will become the center of IoT universe.

The i.MX 6 series: Getting it done (Part 3 of capabilities convergence, device divergence)

admin@community.freescale.com — Thu, 03 Jan 2013 15:08:48 GMT

The i.MX 6 Series Ecosystem

As part of Freescale’s premiere series of Smart Application Blueprint for Rapid Engineering (SABRE) market-focused development systems, Freescale has deployed three SABRE designs focused on automotive infotainment, smart devices, and the general embedded market, as well an evaluation kit (EVK) based on the i.MX 6SoloLite, which drives current and next-generation electronic paper display (EPD) panels. The SABRE board for smart devices, SABRE platform for smart devices, SABRE for automotive infotainment and the i.MX 6SoloLite EVK provide customers with the board layout, circuit design, software and other documentation necessary to quickly produce their own i.MX 6 series-based platforms.

Freescale has been working with the leading embedded system design companies, OS vendors, tools vendors, and application developers to create one of the broadest ecosystems in the industry supporting the i.MX 6 series. This is a critical aspect to the i.MX 6 series as it enables broad choices and options in designing products for the processor family. And with the recently improved online i.MX Community within the Freescale Community, the ability to find answers to your design and development questions has never been easier.

In Summary

The market for intelligent devices is increasing exponentially. Tomorrow’s smart devices, auto infotainment and in-flight entertainment systems, medical systems, personal and enterprise-class intelligent control and data systems, and new classes of devices never before seen need to present data and user interface choices to the end user primarily through rich sound, video, voice, pictures and touch, rather than keyboards and mice.

The need for manufacturers to quickly provide multiple devices to fit specific market segments or niches and provide their customers with a broader range of choices is increasing just as quickly. The i.MX 6 series was designed specifically to enable this new market by bringing together high-performance scalable multimedia processing, a software-compatible family of five processors and pin*-compatible processor solutions with integrated power management so that a manufacturer can deploy a full portfolio of products with a single hardware design.

The i.MX 6 series: Being the same is different. Part 2 of capabilities convergence, device divergence

admin@community.freescale.com — Wed, 12 Dec 2012 05:45:11 GMT

As I discussed in Part 1, in order to enable Convergence/Divergence, a processor must provide a common set of capabilities that scale so that a full redesign is not required but so much more is needed!

Let’s start with the basics. The i.MX 6 series portfolio consists of five processor families: The i.MX 6Quad, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo and i.MX 6Sololite families.

One of the more important areas is around CPU cores and multimedia. The i.MX 6 series includes single-, dual- and quad-core families based on the ARM® Cortex™-A9 architecture. Don’t have enough processing power with two cores? No problem, upgrade to the i.MX 6Quad processor. HD video playback has become a very common feature among many classes of smart devices and is fully enabled all the way down to the i.MX 6Solo processor. Need to boost your design from 1080p30 playback to 1080p60 playback? No problem, upgrade from the i.MX 6DualLite processor to the i.MX 6Dual processor.

The use of 3D graphics and multiple screens of content has become increasingly important not only for games but for creating beautiful, quickly rendered and intuitive User Interfaces. The i.MX 6 series is one of the first processors of its class with the ability to drive up to 4 independent LCDs with 4 independent streams of content with dual LVDS, Parallel, MIPI DSI, EPD or HDMI 1.4 with integrated PHY interfaces. Want to differentiate your design by including two displays (content + virtual keyboard for example)? How about 4 screens? These types of designs are useful for industrial automation, innovative tablet designs, scalable IPTV boxes, new types of TV displays and help us think about new creative ways to add value to our users. This is "Divergence" in action.

The flagship i.MX 6Quad processor includes Triple Play Graphics which includes three graphics accelerators including a dedicated, quad-core 3D rendering engine. Full screen 1080p gaming with the i.MX 6Quad processor is fun and exciting! Don’t need to drive games on a 1080p LCD screen? No problem, scale down to the i.MX 6DualLite processor and design the right product for your customers. All this multimedia scalability means that we as users have more choices in how we build products and tailor them to the markets we focus on.

The i.MX 6 series has an extensive I/O set and comes integrated with PCI-e 2.0 (with PHY), a SATA II controller*, up to 4 USB ports, up to 4 SD/SD3.0/SDXC/MMC ports, 2 CAAN and MLB150 ports for automotive, I2S, I2C, SPI, UART, a NOR controller and a 40-bit ECC NAND controller. Why is this important? Divergence requires the ability to morph the central capabilities of the device to fit new form factors and use models. That means maximizing the types of I/O ports you can attach to on the processor. For instance, if you have a differentiating companion IC with high bandwidth needs, you can attach it to the i.MX 6 series via PCI-e. That can make the difference between having a successful, industry leading product vs. a “me too” design. Again, this is Divergence in action

All of what I've discussed relates to the functionality of the i.MX 6 series. The next piece of the Convergence/Divergence puzzle is market segment qualification. By this I mean Freescale designed the i.MX 6 series from the ground up to be fully qualified for the Consumer, Industrial and Automotive market segments with up to 15 year availability^** .

These segments differ greatly in their requirements of duty cycles, temperature ranges, and longevity:

Automotive qualification: This requires the processor to integrate key automotive interfaces such as CAAN and MLB150. In addition, the processor must work within the extreme temperature ranges (-40 to 125 Deg Celsius Tjunction ) required by the automotive market. Finally, the processor must be available for up to 15 years due to the long production and support cycles required by the automotive market

Industrial qualification: The industrial market segment requires the processor to be able to run 100% of the time at 100% duty cycles, every day, 24/7. In addition, the processor must support a working temperature range of -40 to 105Deg Celsius Tjunction with many years MTBF. Industrial is by far one of the more difficult qualifications to achieve

Consumer qualification: This requires the processor to be able to run at its highest frequency to enable the best scalability for the ever changing consumer market requirements. In addition, it must work within the extended consumer temperature range of up to -40 to 105Deg C Tjunction.

Want to investigate extending your business into an entirely new market segment like Industrial? Maybe look into more consumer-centric applications? By qualifying to these market segments, the i.MX 6 series provides a key building block to do this.

The key to it all: Software, pin and power compatibility

All of this scalability does not do us much good if we have to redesign the PCB to use a different member of the i.MX 6 series every time we want to “Diverge” our product design. One of the most important aspects of the i.MX 6 series, and one of the hardest to achieve, is that Freescale designed the family to be software, pin and power compatible. You can have a processor family that is software compatible, or pin compatible or power compatible; but only when you combine all three can you achieve real scalability for an OEM designer. Simply put, Freescale designed the series so that an OEM can create a single PCB design that will enable them to deploy an i.MX 6Quad, i.MX 6Dual, i.MX 6DualLite or i.MX 6Solo processor without changing the PCB.

This is achieved by the following:

Integrated Power Management: Each processor incorporates the power distribution system necessary to enable the processors to operate with a minimal number of power rails (can be as few as 3 rails).
Pin compatibility: the i.MX 6Quad, i.MX 6Dual, i.MX 6DualLite and i.MX 6Solo processors all come in a 21x21 BGA package that is 100% pin compatible. They are literally drop in replacements.
Software compatible: Each processor utilizes IP from the others. For example, the VPU accelerator is exactly the same in all the processors where it is used. This ‘identical-IP’ approach to processor design helps software designers to write code that runs on the entire family with little or no changes.

Pin and power compatibility, common IP design, scalable processing and multimedia performance, extensive I/O and multiple market segment qualification.

These are the components that enable Convergence/Divergence and why I say "Being the Same is Different" when discussing the i.MX 6 series.

For the third and final part of this blog series, I will take a look at the ecosystem available to help you design in the i.MX 6 series.

Let's make it real - Internet of Things

admin@community.freescale.com — Tue, 13 Nov 2012 18:36:09 GMT

People have been talking about the “Internet of Things” for years with the promise of creating a connected world. I was fascinated by “The Jetsons” as a kid and I realize now that it was an early look at the “IoT” world. Ok, yes, “The Jetsons” is a bit of a stretch of the imagination, even today. But, in reality the transition to “IoT” is happening and is being accelerated by technologies that transform devices from being information gatherers, to being part of a smart system where the data collected provides consumers with real improvements to their lives.

What I've found from my experience at Freescale is that creating and implementing these smart systems takes an ecosystem – no one company can cover the gamut of needs. Not only are ecosystems valued now, they are important and necessary to provide complete solutions. More importantly, it’s not about how many partners are in your specific ecosystem – it’s about having the RIGHT partners.

As I stated, the “IoT” is everywhere, some people even use the term “Internet of everything.” At ARM TechCon which was held in Santa Clara a couple of weeks ago with >90 exhibitors and 5,000 attendees, the “IoT” as a reality was certainly obvious as I walked through the show floor. The picture below highlights an example of a RIGHT ecosystem with Freescale and Oracle. Our company booths were back-to-back and Oracle showcased demos based on i.MX processors running Java SE Embedded.

The shot shown above uses Freescale and Oracle technologies. The SABRE Lite board, based on the i.MX 6Quad processor, is used as the aggregator for the smart grid – it receives data from a power meter and then sends it to the utility company for analysis and action. The i.MX 6Quad processor that’s acting as the aggregator is part of Freescale’s newest ARM applications processor family, the i.MX 6 series, which was launched this week. This platform addresses the needs of the “IoT” – scalability, flexibility, performance and low power. The aggregator also communicates to an i.MX based tablet with a user interface (built using Java FX) to view the data. As the saying goes, with knowledge comes power. Consumers can manage their own energy usage to improve their lives if they have the right data and tools to do so.

A partnership between Freescale (makers of applications processors based on ARM technology) and Oracle (makers of Enterprise software) may not seem like a customer-centric partnership at first. However for the “IoT” to become a reality all devices from the enterprise to the edge must be connected and secure. Oracle’s vision is that Java is not only the platform running in the enterprise but also on edge embedded devices based on ARM processors such as Freescale’s i.MX processors. Couple the power and performance of the i.MX portfolio on the embedded side, with the dynamic and growing Java developer community – and the devices that we can see in the future are limited only by the imagination. Heck, who would have thought about a ‘connected’ thermostat five years ago?

The wireless industrial revolution in medical: Hackers, wireless connectivity and standardization

admin@community.freescale.com — Tue, 25 Oct 2011 06:16:45 GMT

By Jon Adams – The first industrial revolution, initiated in England in the mid-1700s, and the concept of standardized, interchangeable parts, developed millenia before but made broadly practical in the 19th century, were the foundation blocks of today’s industrialized world. Standardization is vital to growth. The wireless revolution has already begun, standing on the backs of strong standards that promise broad interoperability and solid security.

I’ve said before that security through obscurity is no security at all, and that wireless adds a whole new level of “excitement” in terms of protecting data and services. And for health care and medical devices, there’s a lot to protect, from patient information and identity, to preventing tampering with or snooping of values read by sensors or the dosages delivered by actuators – for health care and medical, it can literally be a matter of life and death.

Standardization is vital to connected health care, and there are many forces that are acting on driving that standardization. Cost is always an issue, as is complexity. Security adds to that load. But security is perhaps the most important part of developing a connected care device. But, there’s not a lot of attention being paid right now to these issues, especially in the consumer care space. It may not be a big issue that the bored teenager next door can sniff your weight scale or medication monitor, but then again, maybe it is to you.

For consumer-grade care devices or wellness data products, secure platforms and secure wireless are important to making sure that your data remains yours. For portable, wearable or implantable medical devices, or for the clinical environment, whether patient room or operating room, secure platforms and wireless may be a matter of life, death or injury. And this is not even considering the liability exposures that could be created by using inadequately vetted or tested hardware, software and security suites. Standardization and choice of appropriate standards is the best way to manage all these threats and exposures.

On 26 October, I’m fortunate enough to be presenting a couple of webinars on wireless for medical and health care applications. The first, sponsored by EETimes, is directed toward engineers that are developing medical and health care products who might want to take advantage of ZigBee connectivity. You’ll also get a good look, led by Mark Diperri, our Field Applications Engineer based in Boston, on how to design the growing richness of smart sensors into your next medical device. (Register here.)

The second, sponsored by Electronic Design Magazine, is a webinar entitled “Hackers, Connectivity and Your Next Medical Device.” Steven Dean, our Global Healthcare Market Lead, will open this event and then I’ll dig into the security mechanisms common in other industries, like cellular and automotive, but rare or unheard of in the medical and health care spaces. From simple things like monitoring for device tampering, to protecting your algorithms and codebase, to keeping patient/consumer data private, to providing inherently secure yet flexible and standards-based wireless connectivity, and many other incredibly valuable features, this webinar will dig into the details of the available mechanisms and how they work. The amazing thing is that all these mechanisms are widely used and very cost-effective – over a billion cellphones sold a year use many of these methods to protect from hacking the cellular network. (Register here.)

Both webinars will have a Q&A session immediately afterward, so you’ll be able to get your questions addressed there and then. And if there’s not enough Q&A time, we’ll make sure to follow up with you shortly thereafter to better understand your needs and explain the technologies available.

I hope you will take advantage of both of these terrific informational events – If you are involved in developing devices or systems for medical, healthcare and wellness, it will be a very effective expenditure of your time. You’ll see that standardization, the mainstay of the Industrial Revolution that started so long ago, is more alive and valuable than ever today.

Designing medical for a wireless world

admin@community.freescale.com — Tue, 13 Sep 2011 05:53:10 GMT

By Jon Adams -- Medical devices are cutting cords to improve care – it’s a brave new world with great opportunity and unseen risks!

Whether in the home or at the hospital, wireless is improving the ability to deliver care. Devices are smaller, more portable, and capable of delivering better and more complete data which helps the care provider to assess better the patient’s condition. Wireless means that an instrument can get to the patient more easily – it also means that there’s less risk of damage to cabling, loose or unseated connectors, contamination issues from through-wall cable conduits acting as conduits for biohazards.

Wireless communications also brings with it a whole new level of responsibility that the days of unconnected devices didn’t have to consider. An unconnected device means that physical proximity is needed to gain access to the device. With wireless, the attacker doesn’t need to be in physical proximity – data may be sniffed, command and control observed, all from a distance. Security is a fundamental aspect of wirelessly connected care devices.

While the designer of a care device is an expert in the therapeutic use, the algorithms that take the raw sensor information and reduce that to diagnostic utility, even the necessary requirements for regulatory approval of a care device, selecting the appropriate wireless connectivity and applying the necessary security methods is often far outside of that designer’s expertise. With connectivity comes exposure to a much larger audience of observers, some passive, others active. And with wireless, that exposure is greater still. Well vetted, standards-based wireless technologies are the best way to know that an approach has withstood the inspection of experts in many domains.

Security through obscurity is no security at all. Wrong choices or belief that obscurity is “good enough” may be dangerous. Consider that more and more care devices are basically purpose-built embedded computing devices, using a basic hardware platform, and functionality and flexibility enabled through firmware, software, command and control mechanisms. If firmware or software may be upgraded or modified remotely, if commands or modifications may be sent from a distance, then it is vital that solid, well-understood and robust security mechanisms are a native part of the device platform.

On Wednesday, 14 September, I will be participating in a webinar, presented by Medical Design Technology (MDT), entitled “Designing Medical for a Wireless World”, where I’ll dive into the plethora of choices the device designer has when it comes to wireless, and outline some of the pitfalls that can add unnecessary risk and liability. I’ll outline the standards-based approaches that have been developed and why choice of broadly accepted methods allow the care device developer to devote more focus on the therapeutic value of the care device, and reduce the unseen risks.

I hope that you’ll take the opportunity to join me for this live event at 11am US Pacific / 2pm Eastern. Chuck Parker, the executive director of the Continua Health Alliance, and Steven Dean, Freescale’s Global Healthcare Market Segment lead, will also participate. Free registration is available online.

ZigBee powers 2016 smart meter revenue to US$12B

admin@community.freescale.com — Thu, 18 Aug 2011 00:52:36 GMT

By Jon Adams and Matt Maupin -- ZigBee wireless networking technology is powering the smart grid revolution, and there are a couple of recent press mentions that cement this point. One is the recent announcement of the new Consortium for SEP2 Interoperability, the other is a prediction from InStat, a major market analysis firm, that the smart meter space will take off with ZigBee connectivity leading the way.

According to InStat’s Allen Nogee, “ZigBee will maintain its dominance” in the connected home environment. He points out, while there are a number of other technologies all interested in the space, ZigBee has led the way in developing the Smart Energy 2.0 profile, and has embedded that in future versions of ZigBee specifications. The creation of the new consortium, while obviously not having consulted media experts before coming up with a street name, means that the ZigBee Smart Energy profile will now become the application profile standard for connectivities, wired and wireless, that will participate in the customer’s side of the utility meter.

Most know that ZigBee networking is based upon IEEE 802.15.4 wireless technology, and that Freescale has been a market leader in 15.4 platforms and solutions since 2006. According to regular reports from ABI, InStat and OnWorld, the total volume of 15.4 chips out there is rapidly growing and is nearing or has surpassed the 100 million unit mark, proving its value in smart grid, machine to machine (M2M), health care, and the Internet of Things. ZigBee brings powerful mesh networking, strong security, and a broad range of features and application profiles that allow the developer to quickly create cost-effective wirelessly networked products and systems.

The meter is only the first step though, the next phase will be the connected appliances, thermostats, load controls, and consumer electronics widgets that ride on that network, and bring not only the visibility into energy consumption we need given skyrocketing energy costs, but the flexibility and convenience that we need to help bring those costs under control. This ancillary market is a tremendous opportunity for the developer, and will lead to new ways of managing use of energy and water.

There’s plenty of press about how ZigBee technology is driving what is becoming an extremely lucrative smart meter market. Developers, large and small, everywhere in the world, are seeing the potential for new products and services. Freescale’s leadership in the embedded sensor, wireless and processor space, with its constant attention to security and reliability, makes it easy for you to take your products to the next level. How can Freescale help you get a piece of that $12B?

Are you hacked off yet about connected medical device insecurity?

admin@community.freescale.com — Sat, 13 Aug 2011 22:22:00 GMT

By Jon Adams -- Security through obscurity is not security at all. And developing and deploying care devices without adequate and well-vetted, standards-based security measures, is a recipe for disaster. While what this “researcher” performed was a limited attack, the news demonstrates that inappropriate security measures for connected health care devices can injure or potentially kill the patient. Standards-based wireless and standards-based security are the only way forward.

Health care devices are moving steadily toward connectivity, and most of that will be wireless. There’s still a lot of cowboys and cowgirls out there that think they know best, or they know “enough”, when designing their health care device. They’re experts on the medical technology itself, the sensors, the algorithms that calculate what to do based upon the sensor information, and often on the design and packaging of the care device for the environment. But most are more than a little naïve when it comes to understanding the wireless environment, and the necessary security measures that need to be taken to ensure against the plethora of attacks that can be mustered, from script kiddies to hardcore black hats. Time to come back from riding alone and join the rest of us working together to solve these challenges.

Here at Freescale, I was deeply involved a few years back in cellular platform security, and came to appreciate the threats, the actors and their intentions, and the mechanisms that were available to mitigate those threats. Maybe I’m paranoid, but most of the threats seemed very doable, and I could even think of others that, with enough motivation and resources, could be applied to the cell phone platform to either steal identities and make money for the bad guy, to hold customers or the network hostage, or just to allow a script kiddie to demonstrate to his or her buddies how to “pwn” someone’s phone. In dozens of meetings of a room full of security professionals, representing carriers, handset OEMs, and silicon manufacturers, we graded threats in terms of impact (minor to mission-critical), actors (from amateur to hard-core), cost to defend, and investment required by the actor (was it 10 minutes of script writing or was it US$1M of equipment?). One thing that became obvious to me is that security begins at the silicon, but can be subverted anywhere along the line by inattention or a poor choice of technology.

I’m leading technical guidelines development and global standards selection for the Continua Health Alliance. One of the task forces under my watch is focused on end-to-end security for care devices. This group is intimately involved with the complexity of adequate security while also capturing the needs of the end user for a simple and straightforward experience. What we’ve continued to realize is that there’s always opportunity to improve security, and that comes from making informed and careful decisions on technology. Continua has made sure to choose only well-vetted, globally standardized wireless protocols, like ZigBee Health Care, that have very strong and flexible, native, security measures. And Freescale, which has pioneered or driven many silicon-based high security mechanisms for automotive, cellular, industrial, medical and networking, continues to be a strong and passionate voice and instrument for better, more secure, standards-based platforms that allow the device OEM to concentrate on the quality of the medical device and its efficacy in diagnosis, which is what really matters to their customers.

While we should all be hacked off about connected medical device insecurity, there are well vetted, standards-based approaches in place to address many of these concerns. Relying on security through obscurity is no way to engender market or care provider confidence in connected health care, and it’s a lousy business model. If you’re not a part of Continua, get involved and help lead the way. If you’re developing connected health care products and want secure, flexible, cost-effective platforms and wireless connectivity, talk to Freescale.

Smart Energy Profile 2.0 (SEP 2.0) – One profile to rule them all

admin@community.freescale.com — Thu, 11 Aug 2011 07:56:10 GMT

By Mike Dow -- Smart Energy 2.0 Profile, which will be certified by a new open consortium with initial membership of the HomePlug Alliance, ZigBee Alliance, WiFi Alliance, and HomeGrid Forum, is really big news.

This announcement marks the beginning of a growing trend of “uber” profiles – “a profile to rule them all” – at least in a particular vertical market. I’ve dubbed it the uber profile, because it has the potential to dominate a particular vertical market not just in one geographic area, but around the world as well. Why worldwide? HomeGrid Forum promotes the ITU-T G.hn PLC standard, and ITU-T is a major standards setting body for the European Union. This is huge step towards global acceptance of SEP 2.0.

If the OSI seven layer communication stack model is foreign to you, see figure 1 below, which shows the Multi-PHY/MAC IPv6 communication strategy that I have been working on for more than a year for Freescale. Notice its hourglass shape? I’ll explain this below.

Figure 1. OSI seven layer communication stack model

So how is the SEP 2.0 uber profile being born, you ask? Let’s step through the history.

I’ve followed many wireless communication standards battles with much interest over the years. I watched as ZigBee emerged to fulfill the promise of mesh networks for all sorts of applications. While ZigBee has proven itself in the home, ISA100 and WirelessHART now rule industrial process control. When the needs of large networks for building automation, ZigBee Pro emerged. ZigBee RF4CE came about to tackle simple consumer remote controls and other consumer devices. Bluetooth has gone through similar splintering. At first Bluetooth was deemed to be the only point-to-point wireless link required for all sorts of applications. But it has proven too power hungry: Enter Bluetooth Low Energy.

When it comes to interoperability, WiFi has historically been held up as the poster child as the most successful standard in the world. I would have to agree. However, I think there is rational explanation why ZigBee and Bluetooth splintered and WiFi did not. WiFi didn’t splinter because of its “single” use case: an access point talking to many single point high powered, high bandwidth devices such as computers. Only lately has that filtered to a lower powered cell phone (where ZigBee standards still serve high powered devices). The changes in WiFi over the last 10 years have mainly revolved around adding more and more bandwidth. Only in the last couple of years has the notion of “low-power WiFi” entered our vocabulary.

ZigBee and Bluetooth protocols have fractured because they tried to solve too many use cases with the same network and PHY/MAC combination. The original thought of various profiles for various use cases was, and still is, a great idea to tackle specific market requirements. So the idea of a profile targeted at a particular vertical market is here to stay. However, settling on a particular PHY, MAC, network, and transport layer as well as routing protocol, has proven unsuitable for wide swaths of different applications. And, in fact, has lead to ZigBee and Bluetooth protocols to settle into certain niches where the stacks have proven themselves robust.

It stands to reason from the examples above that use cases, and to a lesser extent the vertical market, must dictate all the components of the stack, not just the profile. A one-size-fits-all, top-to-bottom vertically integrated stack is great for interoperability. However, it will always be limited by the use cases that are well served by the selected technology.

My point here is that of all the layers of a communications stack, the profile is probably the most stable layer for any particular vertical market. And, if you make that PHY/MAC agnostic, like the Smart Energy 2.0 profile has done, you have the start of an uber profile. In figure 1 above, I show the uber profiles across the top of the hour glass. There will be many, as many as there are vertical markets, but they will be very stable once established.

The profile is just the tip of the iceberg, or stack, in this case. Other parts of the stack need to come into play to make an uber profile ultimately successful. I have also been watching closely the trend towards IP connected stacks. The “internet of things” is a very compelling concept. This can be summed up in the commonly pitched vision of your toaster having an IP address and you being able to turn it off from anywhere in the world via the internet. The basic concept is that IP is so ubiquitous, and in the last 15 years of internet evolution it’s now “THE” standard for the Network/Transport layers of the stack.

As soon as ZigBee moved to IETF standards as the building block for ZigBee IP (the middle layers of the ZigBee SE 2.0 stack), I started to believe the trend towards IP in the middle was real and would continue to grow over the years.

There are several other things contributing to that trend. For instance, the advent of the IETF standard 6LoWPAN header compression standard has allowed large IP packets to be compressed and transmitted over low bandwidth networks such as 802.15.4. Also, the IPv6 IETF standard was introduced a few years back which extends the IP addressing from 32 bits for IPv4 (what most of the internet is today) to 128 allowing for 3.4×10³⁸ addresses. That change now guarantees that every widget on the planet for the foreseeable future will be able to have an IP address. Already, many, many, communication PHY/MAC standards around the world have by default adopted IP network/transport layers above the PHY/MAC. Therefore, I think it is safe to say that the communication stacks will continue to converge and coalesce around IETF (IP) in the center of the stack. The reason why I show the slim waste in figure 1 is to depict this convergence and make it a sharp contrast to a typical stack diagram.

Now we get to the nitty gritty where the bits physically hit the highway: the PHY/MAC, or more commonly known as the radio or the modem. It is my belief that there will always be another PHY/MAC, a better mouse trap. There will always be a new radio or power line carrier that will transfer data faster, more securely, in larger quantities, over longer distances, and with less power. These PHY/MACs will be many, and ever expanding, which makes the wide bottom of the hour glass. This is a good thing. We need that constant innovation to make things better, faster, cheaper.

However, for the electronics designer, it is a nightmare. Which PHY/MAC should he pick? With the right software and hardware architecture, he simply picks the best one for his world area and application. He might even pick two, such as 15.4 and WiFi for Smart Energy 2.0 in the Americas, or, Sub-GHz 15.4 and G.hn PLC for Smart Energy 2.0 in Europe.

The way to achieve this flexibility is to architecturally split the communication stack between a scalable microcontroller line such as Freescale’s Kinetis MCUs and less expensive PHY/MAC only modems. This concept allows the design engineer to keep the majority of his communication stack design investment in a controller family that can scale as standards morph and application profiles emerge.

This architecture certainly is flexible, but some would argue not very cost effective. They are right if the following conditions are true; you know the single PHY/MAC you need to use for every use of the product in every world area, you know the network/transport and routing protocols you need, and you know the exact profile you need for the application. And none of that is likely to change during the lifetime of the product.

Wow! That is a lot of certainty, but does that kind of certainty apply to most emerging markets like smart energy and home healthcare? I don’t see that for quite some time. So, for the rest of us … Uber profiles and IP centric network/transport layers allow us to contemplate an architecture and stack construct that offers flexibility and security against the every changing market needs.

And mark my words. SEP 2.0 will not be the last of the uber profiles. There will be others. I predict that home healthcare is next, then home automation, then building automation and on and on and on. Will other umbrella consortiums spring up to bring interoperability to these profiles? I sure hope so!

So much radio spectrum, so little interoperability!

admin@community.freescale.com — Fri, 06 May 2011 03:24:49 GMT

By Jon Adams

Connected medical devices are part of the future of health care. And unless it’s a piece of “big-iron” equipment like a CT scanner or MRI machine, wireless is quickly becoming the preferred method for getting data from the device to the data repository, loved ones or the care provider. But there’s wireless and there’s wireless!

In essentially every part of the globe, wireless transmissions are regulated in some manner. Here in the US, the Federal Communications Commission (FCC) manages public spectrum with licensed bands and license-exempt bands. The rules are generally straightforward on maximum transmitted power levels, antenna gain, duty cycle, power per unit of spectrum, and out-of-band and spurious emissions. For the most part, things like communications protocols, networking methods are outside the scope of the regulation, thus the user has a lot of latitude on exactly how to get the data from the device to the other side of the connection. And that latitude can breed a lack of interoperability.

A long time ago, the FCC recognized the growing need for wireless in medical applications, and developed a set of rules for license-exempt operations for medical. Code of Federal Regulations (CFR) 47 Part 18, contains the requirements for devices and systems that use the Industrial, Scientific and Medical (ISM) bands. While the regulations in general include most radio frequencies above 9 kHz, commonly used bands include the 902 - 928 MHz, 2400 – 2450 MHz, and 5725 – 5800 MHz. The ISM rules allow for medical devices with emitted RF power levels of many hundreds of watts – an application that is not that uncommon is the medical diathermy machine, which uses significant RF power levels to warm, but not destroy, tissue. I used to live in the neighborhood of a doctors’ office that used a diathermy machine at 27.120 MHz – it was easy to detect when the machine was running, even when hundreds of meters distant.

Many have found utility for health care and medical applications under the FCC Part 15 Radio Frequency Devices rules. While Part 15, like Part 18, allows license-exempt low-power emission in nearly any piece of spectrum above 9 kHz, the bulk of usage is in the 902 - 928 MHz, 2400 - 2483.5 MHz, and 5725 – 5850 MHz bands. And more and more of that is due to Wi-Fi, Bluetooth, ZigBee and other short-range wireless technologies. Drive by a major hospital with your Wi-Fi sniffer running, you’ll see what I mean!

There are some specific restricted band segments that have been carved out just for medical applications. The Wireless Medical Telemetry Service (WMTS, Part 95, Subpart H), and the Medical Device Radiocommunication Service (MedRadio) (Part 95, Subpart I) are, as their names imply, specifically for medical devices. These bands include 401 – 405 MHz, 608 – 614 MHz, 1395 – 1400 MHz, and 1427 – 1429.5 MHz. The rules are fairly explicit on how these frequencies may be used in a medical device, and sometimes on where these devices may be used. Power levels and usage modes are closely controlled. Examples of devices that might use these bands could be an implanted medical device (like a pacemaker), which would likely use the 401-405 MHz band. Bedside wireless monitoring of a patient might be found in one of the other three bands. Interestingly, the Part 95 rules are probably most known for the Citizens Band, made famous back in the 1970’s with the CB craze (one of my personal lowbrow favorites, the movie “Smokey and the Bandit”). Wow, a time when cell phones didn’t exist!

The cellular telephony bands are another place where health care devices are appearing. In the US, those bands are from 825 – 849 MHz / 869 - 896 MHz (generalized as 850 MHz), and 1850 – 1910 MHz / 1930 – 1990 MHz (generalized as 1900 MHz). There, access to the spectrum is managed completely by the carriers, so all a developer needs to do is to design in the cellular transceiver. But using the spectrum means paying a monthly subscription fee, and possibly data charges on top of that.

The battle to establish spectrum for health care / medical hasn't ended - there is an effort right now before the FCC to create a new band between 2360 and 2400 MHz for medical body area network devices. This chunk of spectrum was the domain for aeronautical mobile communications, among others. In 2009, an Notice of Public Rulemaking (NPRM) was issued to explore this, and final rules are expected later this year. The IEEE 802.15.4j task group was formed to explore how to use this spectrum, and it appears that the base protocol will be the same as used by IEEE 802.15.4 in the 2400 - 2483.5 MHz band.

Building a wirelessly connected health care, wellness, fitness or medical device isn’t just about frequency selection. It’s more about what the product needs to do, requirements on reliability and robustness, whether it needs to be interoperable with other devices, where the device will be marketed, and where the user might take the device. While the FCC regulates spectrum usage, it’s the US Food and Drug Administration (FDA) that regulates the functionality of medical devices. The designer should carefully consider how much FDA regulatory oversight they want to endure when scoping their product. In many spaces, it’s hard to avoid, but there’s loads of stuff for the health and wellness, sports and fitness space that is low on the FDA radar.

Interoperability is important especially when a product from one manufacturer needs to communicate with a product from another manufacturer. But it’s also valuable within a single company – choosing a communications standard, in a standard frequency band, using standard wireless transceivers can mean far fewer regulatory hassles in developing, testing and getting certification on product. Standardized protocols rather than a homebrew protocol means that others have already vetted out the protocol and that there’s likely a plurality of vendors for the silicon, and a bunch of third-party consultants and contract houses that know how to use the technology and solve communications issues, something for which the health care device manufacturer may not be adequately equipped.

Most of the major short-range wireless technologies, like Bluetooth, Wi-Fi and ZigBee, have developed approaches for using their technology in health care devices. Some, like the Bluetooth SIG or the ZigBee Alliance, have gone so far as to establish specific use profiles for their wireless protocol stack for health care devices. The Bluetooth Health Device Profile (HDP) and ZigBee Health Care (ZHC) are both designed to provide a straightforward communications toolset for the product developer, freeing the product developer to focus on health care product design issues rather than on communications problems. Certification from these groups for products using these use profiles encourages broad interoperability, which can help the developer to reduce design issues and to increase data utility. The Continua Health Alliance, for which I chair the Technical Working Group, has adopted both Bluetooth and ZigBee wireless technologies as part of its guidelines to establish broadly the interoperability of connected wireless health care devices.

The future of connected medical devices is in interoperability. It’s fundamental. I'll be talking more about wireless for medical devices at the upcoming Freescale Technology Forum in San Antonio 20-23 June. How are you planning to use wireless in your next product? If I can help, let me know.

Interoperability key to success of connected health care devices

admin@community.freescale.com — Thu, 28 Apr 2011 03:26:06 GMT

Over two-thirds of Americans are overweight or obese and nearly 1 out of every 2 people are living with at least one chronic disease. The average age of the population is creeping upwards, partly from lower birth rates but also because people are living longer. The cost to the nation of health care continues to skyrocket with no end in sight (reference).

The average person knows more about the health of their automobile than they know about their own health. For most, blood pressure, weight, and calories consumed versus burned are unknown. Some of the problem is lack of quality metrics, and that data, to be actionable, needs to be set in context, trended over time, related to behavior and attitudes so that the person can see paths to improvement. So it’s encouraging to see the results from a recent survey conducted by IDC Health Insights on the consumer use of personal health and monitor devices. Maybe, just maybe, the average person is beginning to want to know more about their own health and how to manage it better.

MobihealthNews exposed a little more detail of the survey discussing the willingness of the consumer to pay out-of-pocket for devices. Since the US medical system is event-oriented vs prevention-oriented, it’s traditionally been difficult to find insurers and care providers willing to reimburse for these kinds of devices. To that point, the survey noted that 60% of the participants paid 100% out of pocket for their devices, with a maximum device price of US$97 and a maximum monthly subscription cost of US$28.

While prices points are always debatable, the concept of a subscription model is interesting. More and more devices available in the market are connected, whether by a cable like USB, or by wireless, whether that’s Bluetooth, Wi-Fi, ZigBee, cellular or something proprietary. I said earlier that the data needs to be in context, trended over time, etc. With connectivity, there’s a chance to aggregate the individual measurements to derive a trend over time. For something like calorie intake as compared to weight, one can generally see a causal relationship: “I eat more, I don't change my activity level, I weigh more.” For weight versus blood glucose versus diabetes medication levels, the data is vital for the clinician to understand better how the patient responds to therapy. In either case, the data needs to be aggregated and analyzed. For unconnected devices, this would generally mean the individual attempting to remember the last measurements, or writing down each measurement. This is doable, but it doesn’t drive compliance or adherence to an exercise program or a treatment regimen nearly as well as third party involvement. Connected devices are vital to success. And connected devices mean expectations of interoperability.

The Continua Health Alliance, for which I drive technical guidelines development and standards selection, has worked hard to develop a set of rules for connected personal health care devices. Its first set of guidelines, released back in 2008, was a shining light of interoperability in a proprietary universe. Its latest guidelines release, announced last year, moves the expectations for interoperability firmly forward. Devices that meet Continua’s guidelines are beginning to appear in the marketplace.

Freescale builds silicon for customers large and small, from sports and fitness to medical implantables to big-iron NMI/CAT scanners. We see the tide turning as well – more customers are becoming aware of Continua, more medical/health care customers are considering some form of connectivity as important (or vital) for their product. While wired connectivity was enough in the past, to resonate with the modern mobile consumer, wireless connectivity is where it’s at. More of these devices are using a couple of AAA cells or a coin cell – so power consumption and battery life are huge design challenges. The microcontrollers that Freescale builds for these spaces, like the Kinetis family, have to do a lot while sipping battery current. For sensors, our multi-axis accelerometers and magnetometers mean high orientational awareness with extremely low power consumption.

I’m right now drafting an hour-long class on connectivity for health care applications, which I’ll be teaching at the upcoming Freescale Technology Forum in San Antonio, TX, the week of 20-23 June. If you’re headed there, be prepared for some great barbecue, and let me know about your application, and how connectivity and interoperability makes a difference for you and your customer!

Trick your aorta with RFID

admin@community.freescale.com — Sat, 05 Mar 2011 01:05:16 GMT

By Jon Adams

Years ago, when I was just a young sprout at NASA/JPL in Southern California, I was fortunate enough to be a small part of an R&D team working with UCLA to develop a wirelessly telemetered artificial hip joint. Hip joint replacement was starting to become routine, but there was little information on how the replacement ball and socket mechanism reacted in the long term to the strain and stress in a real, ambulatory human. The telemetry system we had helped to develop included strain gauge sensors embedded in the ball, stem and head inserted into the femur. These sensors needed power to work, so our contribution was development of an externally worn AC magnetic field generator/reader which slipped over the thigh and induced current into a smaller coil embedded in the ball. That current was rectified to supply power to the sensors and transmitter circuit, which then amplitude-modulated the induced field as changes in the perceived load. The reader extracted the information and sent it via a cable to the display device. It was likely one of the early applications of passive RFID for a device in the human body.

I’d forgotten completely about that project until I was alerted to a recent USA Today article describing an implanted, wireless pressure sensor for patients who have chronic heart failure or have suffered an aortic aneurysm. While the application is significantly different, the CardioMEMS system uses an implanted wireless pressure transducer powered by an externally applied field (could be RF or high-frequency magnetic, from the looks of the paddle/antenna). The sensor in turn makes its measurement, and relays that information back to the paddle/antenna, and then via cable to the display on the main unit. Inserted during the endoscopic stent graft procedure, the sensor and antenna structure is claimed to be about the size of a “small” paper clip and remains permanently in the patient. And on some regular basis, the patient and/or caregiver places the paddle against the chest, energizing the sensor, and collecting live readings of fluid pressure. This helps to judge the ongoing performance of the stent by looking for unreasonable leakage. Pretty cool!

Because of this device, it would seem that the patient can be monitored more effectively than ever before, and the stent performance measured very accurately. The monitoring system is small enough and simple enough that it’s something that could potentially travel with the patient, providing the physician and patient far better visibility than using angiography alone, and generating greater peace of mind for all.

This device and application could be modified for many other monitoring purposes in the body. Even the paddle/antenna could be replaced with a piece of clothing that would allow regular or even continuous monitoring of sensors in different parts of the body. Because of the wireless connection, there’s no fear of infection that can come from systems that need to penetrate the skin with signal and power wires. The induced power delivery means that there’s no battery that will ultimately run down and need another surgical procedure to replace.

As a colleague of mine recently said, “people know more about the health of their car than they do about their own health”. Certainly back when I was working on the hip joint project, the average person had little ability to measure even simple things like blood pressure and pulse oxygen. At least a little of that might be because of how hard it’s been to measure, consistently and relatively non-invasively, vital metrics that before required a visit, at a minimum, to the doctor’s office. Technology in general and wireless technology in particular have begun to unlock a great potential to improve measurably the ability for the average person to acquire, aggregate, store and analyze their own health data in concert with their health care provider.

I'm now involved in the Continua Health Alliance leading the technical guidelines development and standards selection process. We're doing exciting stuff there that is helping to allow the end user/consumer to be far more knowledgeable about their own health, with devices that are connected via Bluetooth and ZigBee wireless technologies. It’s a great time to be a wireless engineer! How are you going to take advantage of wireless communications in your next project?

DECT – Senseless for sensor webs

admin@community.freescale.com — Wed, 12 Jan 2011 08:08:25 GMT

By Jon Adams

Seems like everyone wants to get into enabling the wireless part of the world of wireless sensors. Now there are the DECT (Digital Enhanced Cordless Telecommunications) fans!

What’s DECT? It’s a wireless communications technology that’s been around for over 20 years, and today is pretty much used exclusively for cordless home telephones. But the recent stretch isn’t anything new for the DECT adherents. Over 10 years ago, it was promoted as the way to wirelessly network computers, but that was ill-fated with the advent of IEEE802.11 and Wi-Fi. As well, the DECT aficionados tried a long time ago to position it as a technology for wide-area public access wireless voice networks, but cellular carriers won out easily with their more scalable and cost-effective systems. And at least in a few places in the world, DECT was promoted as the “last-mile” link for internet communications. Oversell isn’t new to them.

DECT has some nice features – if you have a DECT cordless phone system in your home, you’ll find the range performance to be far better than your typical cordless phone, whether 2.4 or 5.8GHz. Regulatory bodies throughout the world have created bands where DECT can be used, in some cases, exclusively. In Europe, it’s the 1880-1900MHz band; in China, 1900-1920 MHz; In South America it’s 1910-1930MHz. DECT (at least in the US) operates on 5 channels in the 1920 – 1930 MHz Unlicensed Personal Communications Service band, and while it must share that band with other legal uses, it’s mostly a pretty quiet band except for DECT phones. DECT devices generate around 250mW output transmit power, and the over-the-air data rate is 552kbps. The DECT specification employs Time-Domain Duplex (TDD) time slots managed by the master, so each client device gets one of 12 slots where it can transmit or receive exclusively. What this means is that the effective data rate for any one pair of devices using a single slot is about 32kbps, which is plenty for a decent audio codec. DECT does what it was designed for, cordless telephony, well: cordless phones have good audio characteristics and generally sound as good as a traditional POTS phone, and far better than a typical cellular device. And just as importantly, cordless phones have cradles where the phone’s battery can recharge at the end of a long phone call.

But this announcement that DECT should be considered for the world of battery-constrained sensor devices was a little surprising – since DECT uses time slots between stations, the devices in a network need to keep their internal clocks synchronized, and that means they need to wake up regularly and “handshake.” This clock sync is the same problem from which Bluetooth and Bluetooth low energy (aka BTLE or BLE) suffer and the number one reason why none of these technologies are compatible with long-battery-lived or energy-harvested sensor networks.

When one is really concerned about running on small batteries, it’s a good idea to work in units of battery capacity. A battery can only give so much before it’s exhausted. The typical capacity unit for small batteries is milliampere-hours (mAh). A CR2032 coin cell is advertised as having about 200mAh of capacity. As a comparison, an alkaline AAA battery has about 1200mAh of capacity. The CR2032 cell in theory can, as an example, power a 1mA load at 3V for 200 hours, or a 0.1mA load for 2000 hours. In practice, it’s always going to be less, and the voltage droops over time as the cell’s internal impedance increases. (Wow – I just discovered that there’s a whole website devoted to CR2032 cells!) In case you were wondering, capacity is not total energy, but it’s directly related via the battery cell’s voltage. So a CR2032 coin cell with a nominal 3 volt output has a theoretical 600mWh (milliwatt-hours) of energy.

To put this power consumption in perspective, take the example of a simple sensor for home security – a door open/close sensor. That kind of device using a magnetic reed switch and a simple microcontroller can sleep most of the time and on long-term average pull only a few microamps at 3v (let’s assume 3µA). That means that for that app a CR2032 cell theoretically lasts 200mAh divided by 3µA or 6.6E4 hours – that’s over 7 years! According to the article, the current draw for a DECT device in standby is “only” 20-40µA (let’s assume 30µA). So adding DECT connectivity to that very simple sensor reduces the battery life from 7 years way down to only 7 MONTHS! And all those years of lost performance are just to keep the keep the DECT transceiver synchronized, not even to transfer data.

Imagine that you have a security sensor web in your home: glass break sensors on each external window, door open/close sensors on each external door, and some motion sensors throughout the house - perhaps 20 sensors total. If those sensors are DECT radio-connected, on average you could be changing the battery on at least one of those sensors every 12 days. That’s completely unacceptable both from a maintenance point of view and from a think-green philosophy.

IEEE 802.15.4, on the other hand, was designed from the beginning for extremely low average power consumption and long battery life. There’s no need to burn most of the battery’s energy just to keep transceivers synchronized to one another, not even exchanging data. 15.4 has been adopted by many different industries, from Smart Grid to Consumer Electronics to Health Care to industrial control and monitoring, that demand excellent low-power performance and efficient wireless communications. And Freescale continues to be the market leader for IEEE 802.15.4 platforms.

Some people like to think things always happen in threes

admin@community.freescale.com — Tue, 14 Dec 2010 07:38:17 GMT

By Jon Adams

Over a year ago, the US NIST (National Institute of Standards and Technology) added ZigBee wireless technology to its Framework and Roadmap for Smart Grid Interoperability Standards, which defines systems and technologies that are approved for use in the rapidly growing smart grid. Then two months ago, in October, the Association of Home Appliance Manufacturers published their missive “Assessment of Communication Standards for Smart Appliances” where the ZigBee protocol was one of the top three, along with Wi-Fi and HomePlug Green PHY, compared to all the usual suspects, both standards-based and proprietary. All good stuff, especially since Freescale is the largest manufacturer by far of IEEE802.15.4 silicon, the basis of ZigBee wireless technology.

Just a few days ago, though, the ZigBee standard got that third feather in its cap when GE Appliances and Lighting published their white paper, “Energy Efficiency Comparisons of Wireless Communication Technology Options for Smart Grid Enabled Devices” (can’t wait for the movie!). In this paper, General Electric’s experts compared ZigBee, low-power Wi-Fi, and even Bluetooth wireless technologies. After ending Bluetooth technology’s fantasy with a single paragraph, the authors conclude that ZigBee technology fits the appliance space best, stressing some very important technical factors.

15.4 technology is now the third largest (in volume) standards-based short-range wireless technology. Bluetooth wireless technology is shipping inside nearly a billion cellphones every year. IEEE802.11 (the basis of Wi-Fi) chip sales have reached a half-billion devices a year and growing steadily. Upwards of a hundred million IEEE 802.15.4 devices have been sold to date, with that number ramping fast due to adoption of ZigBee technology in smart grid, health care, consumer electronics, and other major industries.

The report digs into the technical and business differentiators between Wi-Fi (and the not-yet-standardized low-power Wi-Fi) and ZigBee technologies, comparing cost of radio silicon, cost of associated microcontrollers, supported network topologies, the fit of each technology to the market needs, power consumption and other important factors that design engineers and product line managers need to consider. The paper points out that in the real world, both Wi-Fi and ZigBee wireless protocols have their very distinct values in the home, but that in terms of power consumption and cost containment, the ZigBee protocol is clearly the right choice for smart grid control and monitoring communications.

A note on vampire power, and I’m not talking “Twilight Saga:” the authors estimate that use of ZigBee technology instead of Wi-Fi could save energy annually on the order of the equivalent to Arizona’s allocation of the power output of the Hoover Dam. And that’s just the power savings due to the lower power consumption of a ZigBee transceiver over a Wi-Fi transceiver.

Maybe there’s something to things happening in threes. Probably not. But there’s certainly a growing recognition of the value of ZigBee technology for the smart grid and many other markets. How are you going to use ZigBee wireless technology in your next application?