The Embedded Beat

Consumerization of healthcare: My personal marathon

admin@community.freescale.com — Thu, 16 May 2013 16:01:01 GMT

Healthcare is not just about getting medical attention when you’re feeling ill or going to the doctor once a year for a physical. To me, healthcare is about a lifestyle of wellbeing. Wellbeing is about physical fitness, mental fitness, illness management, nutrition and more. And, in order to create this lifestyle of wellbeing, we as individuals have to take charge of our own health. Yes, I know, this is easier said than done. So, what will it take or what can be done to make this simple and routine in our lives? The answer? Consumerization of healthcare.

Consumerization is a common buzz word, but how does this term apply to the healthcare industry? In order for us to have more control over the various aspects of our own health, we need technologies to arm us with the right tools and resources.

My personal fitness experience was the road that led me to running my first marathon. I first started running because it was an efficient way for me to get some exercise in after having two kids. I wanted to be healthy and strong for my kids, prevent physical issues as I aged (my mom has dealt with back and foot pain off and on for years), deal with stress (juggling family and working full time is no easy task) and have alone time to force my mind to slow down and think through things.

I started by running two to three miles twice per week and participating in 5K races. Then, my husband gave me a Garmin GPS watch as a birthday present. That’s when my attitude for running totally changed. It was the transition point where I became a runner. As I learned to track my pace and heart rate, I found that I was motivated to do more – run faster, go further, run more difficult terrains (hills), run with other runners and to make better choices regarding my nutrition. This motivation drove me to run a half marathon the year I turned 40. Over the next two years, I completed four half marathons and then decided to take the BIG step and go for a full marathon. Crazy! Trust me, this was not an event I ever thought of doing before.

After months of training, the day finally arrived: May 5, 2013. I was in beautiful Vancouver, Canada (hey, if you’re going to set a high goal for yourself might as well do it somewhere exciting!). I was a bit nervous but reminded myself to trust the training. I used my Garmin watch to monitor my pace and distance throughout the race. There is absolutely no way I could have made it through the entire 26.2 miles AND achieve my goal (finish in 4:30 hours and not walk any of it) without my watch. Running the marathon was definitely one of the hardest things I’ve ever done, but crossing the finish line in 4:29:48 and meeting my goal was an amazing experience and an accomplishment that will always be a part of me. I’m stronger both physically and mentally because of it.

The "enabler" for me was the technology. It turned a dream into a reality. What’s next for me with my fitness goal? I’m not sure about doing another marathon anytime soon, but I’m definitely going to keep running and have now set a goal to finish a half marathon in less than 2 hours. Of course, my Garmin watch will continue to be my companion. It keeps me motivated, provides guidance while I’m running so I can stick to my training plan, gives me the data to constantly challenge myself and improve my running abilities and allows me to share this data with my friends through social media.

This is just one example of how the medical and healthcare industry is going through consumerization. There are so many other devices doing the same thing and even more ideas waiting to become reality. Being a part of a company like Freescale that’s creating the technologies and working with companies who use our technology to turn these ideas into reality is truly exciting! What ideas do you have? We’d love to hear them.

Healthcare in Asia: Technology and market trends

b15116@freescale.com — Wed, 15 May 2013 20:58:09 GMT

Hi friends. I’m back after a taking a little hiatus from blogging. I’ve been busy relocating to Asia. The Asian market and the role it plays in global macroeconomics prompted my move. China is currently the second largest economy in the world, followed by Japan, so we have two mayor players on the same continent. And, global trends show that China will begin to play a major role in medical device manufacturing.

China, with its one child policy, has slowly shaped its population to invert the birth rate. However, this does not come without consequences. Slowly, the aging population will increase and there will be fewer young people to support this inverted pyramid population structure. The concerns that societies like the ones in Europe have for their elderly, will surely be mimicked by China . In terms of healthcare assurance, China is a large country with vast differences in the rural and major metropolitan areas, so bringing health to everyone will be an immense challenge.

Elderly populations often face chronic diseases such as hypertension, diabetes and cancer. And in order to serve and efficiently manage their health services, how will there be enough hospitals and doctors to serve them all? How can a major issue like this be solved by the largest inhabited country in the world?

I saw some indications of this recently at the Electronica China show in Shanghai. The event was huge. It took me three full days to experience the different sections of the event. The large halls that connect to one another with infinite pavilions almost made me feel diluted in such an enormous space. You could find other semiconductor vendors, software companies, manufacturing facilities, service providers, OEMs (smart home, medical and healthcare, connected home, energy efficiency, consumer, networking, etc), and ODMs.

I think the message is clear. Everyone -- from the semiconductor vendor to the OEMs -- need to work together to bring a concept together like the Internet of Things (IoT) for the medical and healthcare market. Envision body medical sensors attached to individuals, that are continuously and efficiently monitored through a network of IT services, internet, cloud services with a management platform of healthcare information on top. The goal of IoT for healthcare is to prevent, solve and control diseases.

It is why we launched the first integrated Healthcare Analog Front End (AFE) reference platform, aimed at monitoring and controlling the most common incidence pathologies like, COPD, cardiovascular diseases, and endocrine diseases like diabetes. This reference platform allows medical device designers to build the body area network with different sensors and wireless and USB communication. The Healthcare AFE reference platform along with our Home Health Hub reference platform, provide our customers with an easy to use, rapid prototyping solution to build innovative IoT solutions for healthcare.

Sensor fusion and the Internet of Things (IoT)

r62516@freescale.com — Tue, 14 May 2013 12:05:14 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.

The Bare Metal Enthusiast: To RTOS, or not to RTOS, that is the question

scn099@freescale.com — Mon, 13 May 2013 13:29:48 GMT

As many of us consider the migration from 8-bit to 32-bit microcontrollers (MCUs), we need to contemplate possibly changing the way that we create our code. That is a conclusion that you will likely reach once you take a hard look at 32-bit MCU architectures. These can be complex platforms. Blindly moving your 8-bit code into a 32-bit machine is rarely an easy transition. It can certainly be an eye-opening experience. According to the UBM 2013 Embedded Market Study (ubdmdesign.com), 68% say that they are using an RTOS, kernel, software executive or scheduler of any kind, while 32% say they do not. Interestingly, about the same number (63%) said that they are using a 32-bit microprocessor. Does this mean that you have to use an RTOS if you are going to use a 32-bit microprocessor?

Let's look at some pros and cons for using an RTOS.

Question #1: Do I need an RTOS?

Some developers might tell you that you absolutely need an RTOS. Well, maybe their projects are pretty big and complicated. Maybe they have a user interface that requires a touch screen QVGA display. Or perhaps they need to handle Ethernet communications. It’s possible that some sort of data file system is required. Their projects could be so big that they require a software team with each individual developing separate parts of the application code. I will agree that these are all good reasons for using an RTOS.

An RTOS provides a software framework that will help provide a good structure for your overall code. It can improve the overall efficiency of a project by compartmentalizing your code into logical modules (known as “tasks”) that can be exercised and tested in isolation. Notice that “efficiency” is measured here in units of hours in front of your keyboard, as opposed to nanoseconds of CPU cycles. An RTOS will typically provide device drivers that can remove some of the complexity involved in using an MCU’s peripherals. A good RTOS should provide communication software stacks for Ethernet and USB (to name a few), thereby simplifying their use. A good example of such an RTOS is Freescale’s MQX software. For an RTOS with minimum features, such as a task scheduler but without the drivers and communication stacks, I suggest considering Freescale’s MQX Lite RTOS. As you might expect, applications that have been written using MQX Lite RTOS are easily upward migratable to MQX RTOS.

Beyond the peripheral drivers and communication stacks, an RTOS provides other services to your application. That's why an RTOS is typically considered to be “middleware.” Similar to communication stacks, it provides services like heap management, synchronization primitives like semaphores and mutexes, queues and events, the apparent running of parallel tasks, and real-time synchronization methods like waiting for a given time or event. Of course, you could implement these features without using an RTOS, but you would be reinventing the wheel. Your version might be more code efficient but you need to consider your time investment for this extra software development and, more importantly, debugging it.

Another benefit of using an RTOS in MCU projects is software portability. A good RTOS will use some sort of common interface layer to communicate with the MCU’s peripherals. This is commonly referred to as an Application Programming Interface, or API. One popular API standard is POSIX (Portable Operating System Interface) which was first introduced in UNIX systems. Using an API means that your application code never directly touches the hardware peripheral’s control registers. The RTOS already has the peripheral driver code to handle this low level interface. Your code simply interfaces with these drivers. When you move your code to a different MCU it doesn’t need to change since it’s contact with the peripherals continues to be through the API. This sort of portability provides you with the opportunity to transition your application software between different platforms with greater ease.

Naturally, those of us that have been around for awhile realize that this sort of flexibility and portability doesn’t come for free. For starters, an RTOS will require its own code space. Today, that means extra flash memory above and beyond what’s required for your application software. If all you want is a simple Task Scheduler, then this might only require an extra 5k bytes. But if you’re using multiple tasks coordinated with software semaphores, an Ethernet communications stack and multiple peripheral drivers, then don’t be surprised if the RTOS grows to beyond 50k bytes. And that’s just the flash memory. All of these drivers and API overhead will need more RAM too. That of course depends on the RTOS and functionality used. For example, a Freescale MQX Lite RTOS application with three tasks (plus one idle task), one semaphare and one event needs less than 8 Kbyte flash and less than 4 KByte of RAM.

Everything comes at a price. We should all be familiar with trade-offs. In general, the more scalability your software project needs, the more it will benefit with the use of an RTOS. The resulting software should be very portable and you will have a better chance of finishing your project on time. But this comes at the cost of needing extra memory.

Question #2: What is compelling you to switch from 8-bits to 32-bits?

I think that this is the better question and one that can be often overlooked. To find the answer we should take a closer look at what we are doing.

Most companies specialize. They create products that relate directly to their core competencies. A company that has become very good at manufacturing conveyor belt motor controllers isn’t really expected to start developing Ethernet routers. They will probably continue to offer a wide variety of conveyor belt motor controllers. Some of these may be simple and some may be more complicated. Let’s suppose that these controllers have traditionally used 8-bit MCUs. What benefits would using a 32-bit MCU bring them?

The answer is simply. 32-bit MCUs give us more.

More computational performance is reasonably obvious. Not only do we get 32-bit data resolution that can speed up our math routines, but 32-bit MCUs typically have faster clocks. Comparing an 8-bit MCU running at 10MHz to a 32-bit MCU clocking at 100MHz is like comparing the family sedan to a race car.

We get more peripherals. 32-bit MCUs are usually available in packages with larger pin counts than 8-bit devices. That means more general purpose I/O. Quite often we’ll have more serial communications peripherals, such as a higher number of individual UARTs, SPI and I2C modules. Add to this Ethernet and USB peripherals and you shouldn’t have any problems connecting your project to the outside world. And if timer channels are what you need then you will likely find more of them on a 32-bit MCU.

We get more memory. 8-bit MCUs excel at code that fits within a 64k byte memory map. But when you go beyond this limit you will ordinarily need to start dealing with bank switching. Yuck. Compare this to the 4G bytes of linear memory space offered by many 32-bit devices. That is simply easier. MCUs are designed to adhere to relatively common Flash-to-RAM ratios. So moving up to 32-bits with more Flash memory also translates to having more RAM than an 8-bit MCU can offer.

32-bit MCUs give us more for less. This is probably the biggest reason for all the fuss surrounding 32-bit MCUs. To make them cost effective, they are manufactured using smaller silicon geometries than their 8-bit cousins. This also explains their faster clock speeds. In some cases, transitioning to a 32-bit MCU may result in costing you less than if you stayed with your existing 8-bit design. This has made the game very interesting.

It seems to me that we sometimes get so wrapped up in the CPU that we forget that we’re actually dealing with an MCU. A microcontroller’s computational capabilities are determined by its CPU while its application capabilities are determined by its peripherals. But a microcontroller’s performance capabilities are determined by its overall architecture – by how the CPU and peripherals are interconnected. If you look closely you will see that the architecture of 32-bit MCUs make them much more than just “big brothers” to 8-bit devices.

Many of Freescale’s 32-bit MCUs employ a crossbar switch architecture. This allows for concurrent accesses from different bus master to different bus slave peripherals. For example, the CPU can access its next opcode instruction from the Flash memory while, during the same clock cycle, the DMA can move an ADC data sample into a buffer located in RAM. By taking advantage of this concurrent operation capability we experience more MCU performance and can reduce a project’s overall power consumption.

Question #3: Does moving to 32-bits really mean that you need to start using an RTOS?

I hope that you know the answer to this question by now. An RTOS can be slick and groovy. But if you’ve never used one, then you’re at the starting end of the learning curve. That may be inevitable but it is rarely a lot of fun. Especially if you’ve been developing code using 8-bit MCUs and you’re really just interested in taking advantage of what 32-bit MCUs have to offer. In other words, you’re real interest is in more. And you especially like more for less.

When it comes to writing code for an 8-bit machine, most of us will default to using either a “super loop” approach or some sort of state machine design. These are simple yet powerful techniques that work well and give you the ability to modularize your software. Modular software is easier to develop and test. And, if done correctly, adding or deleting states and functions is normally pretty easy. This is a proven methodology that has served us well for many years. Why would you think that it wouldn’t work on a 32-bit machine?

As I’ve briefly outlined above, the benefits of using an RTOS include readily available peripheral drivers, software portability and the ability to organize complex project with additional scalability. These can be important advantages that can ultimately help you reduce your project development time, and to avoid to re-implement the wheel.

But if your primary reason for moving up to a 32-bit MCU is to simply take advantage of more for less, than I would suggest that you really don’t have a pressing need to dramatically change your fundamental coding methodology. It probably makes more sense to understand the MCU’s architecture and how you can really take advantage of it. But keep an open mind. Even after taking a closer look, it may still make sense to consider an RTOS to improve overall performance and scalability.

Improved electronic compass software released: Xtrinsic eCompass software

admin@community.freescale.com — Mon, 29 Apr 2013 16:42:45 GMT

A few weeks ago, my coworkers and I had the pleasure of participating in an awards ceremony in which Electronic Products Magazine presented Freescale with a Product of the Year award for our Xtrinsic eCompass software. This software processes the outputs of two sensors (an accelerometer and a magnetometer) to implement a tilt-compensated electronic compass. The software is available in source code format supported by an easy-to-use click through license.

We were at revision 2.0 of that library when Electronic Products announced the award. Since then, revision 3.0 has been uploaded to our web site. To download, click on the ECOMPASS_SW link on the Xtrinsic eCompass software page, read and approve the license agreement that pops up (you can freely use this software in products which include Freescale magnetometers and accelerometers), and save the offered .zip file onto your hard drive.

When you expand the zip file, you will have a folder called "eCompass", with sub-folders: "Documents" and "Software". This is a major new release. I'm going to claim it to be the best-documented e-compass solution anywhere, thanks to the Herculean efforts of my good friend Mark Pedley, who also supplied much of the content for this post. Here's what you're going to find in the "Documents" folder:

Software for Tilt-Compensated eCompass with Magnetic Calibration (v3 Release) User Guide
AN4676 - Euler Angle, Rotation Matrix and Quaternion Representations of Orientation in Aerospace, Android® and Windows 8® Coordinates
AN4684 - Magnetic Calibration of Hard and Soft Iron Interference
AN4685 - Tilt-Compensated eCompass in Aerospace, Android and Windows 8 Coordinate Systems
AN4696 - Accelerometer and Magnetometer Sensor Simulatoin for Tilt-Compensated eCompass
AN4697 - Low Pass Filtering of Orientation Estimates
AN4698 - CPU, Flash and RAM Benchmarks : Xtrinsic eCompass and Magnetic Calibration Algorithms
AN4699 - Data Structures for Matrix and Vector Algebra
AN4700 - Control Loop, Data Structures and Compile Time Constants
AN4706 - Accelerometer and Magnetometer Selection and Configuration

The software itself has been expanded and improved.

The "Software" directory contains half a dozen C source and header files that contain everything you need to implement your own e-compass. It also includes a pre-compiled command line tool that lets you simulate performance of the e-compass. The ANSI C source code is processor agnostic allowing Freescale customers to retain their existing MCU architecture. The software is highly optimized to minimize use of program memory, RAM and floating point calculations. Software features include:

The code compiles into 10KB of ARM Thumb2 object code and uses less than 4KB of RAM.
A dedicated floating point unit (FPU) is not required and the software can run on typical 32 bit integer processors with software floating point emulation.
Orientation is provided in Euler angle (roll, pitch, yaw and compass heading), rotation matrix and quaternion formats.
Supports Aerospace, Android and Windows 8 coordinate systems
Tilt-compensated
Programmable low pass filter
Quality of fit metric indicates expected compass heading error
Resilient to magnetic jamming corrupting calibration
Three levels of hard and soft iron magnetic calibration are provided at increasing levels of performance and computational complexity.
1. The simplest 4 element calibration solver computes the hard iron correction vector and geomagnetic field strength and removes the largest component of the magnetic interference caused by ferromagnetic components on the circuit board. It consumes 3300 floating point operations per call.
2. The seven element calibration solver corrects for differing magnetic permeability along the three Cartesian axes and is suitable for the more complex calibration environments found in the dense circuit board layouts of smartphones and tablets. It consumes 20,000 floating point operations per call.
3. The 10 element calibration solver computes a best-fit solution to the 10 dimensional magnetic optimization problem including off-diagonal elements of the soft iron matrix. It consumes 62,000 floating point operations per call.

The web-release includes source for options 1 and 2 above. Option 3, the highest performing 10 element calibration solver, is not available in source form, but is available under license in object code format for ARM Thumb2 processors.

If you have used previous generations of our e-compass software, you will see major improvements in the feature set above. I like the fact that it now supports any of three different orientation representations right out of the box. The math behind an electronic compass isn't easy, but Mark has done an excellent job of breaking it down into manageable chunks that are easily digested. So please, download the new release, give it a go and let us have your feedback.

References:

Going the RTOS way with MQX

admin@community.freescale.com — Mon, 22 Apr 2013 15:04:19 GMT

RTOS or bare metal? If you’re designing with 8-bit MCUs, moving from bare metal to RTOS can be seem overwhelming and downright challenging. I’ve followed a lot of vibrant debates. What I’ve found is that reluctance to use RTOS over bare metal often comes down to the perceived complexity of RTOS. While there are times when it is more efficient to use a low-level software, there’s a general lack of understanding of the value and benefits of an RTOS over bare metal.

RTOS newbies have the impression is that it’s going to waste a lot of memory – and it does. But as systems get more complex, and memory gets more plentiful, we need start changing our mindset by measuring efficiency in terms of time (i.e., how long will it take for you to finish writing and, perhaps more importantly, debug your code). An RTOS forces you to write your code in a more modular fashion, which should be easier and quicker to test.

In this video, I explain the value of an RTOS – and the availability of the free MQX RTOS for Kinetis ARM Powered® microcontrollers.

The MQX RTOS provides a standard list of device drivers, USB or Ethernet communication stacks and a software framework to help you start your design from the ground up. You’ll receive a full set of off-the-shelf tools and a software framework to get started. Freescale partners, such as Embedded Access, also offer expert paid support for the MQX RTOS implementations. With bare metal implementation, on the other hand, you would start your design from scratch and write everything yourself without the support infrastructure.

The use of RTOS and software for embedded solutions is growing, but there are times when a low-level approach makes more sense. My colleague, Derrick Klotz, will offer his perspective in his post, “To RTOS or Not to RTOS, that is the question.” Watch for this piece next week.

Do you RTOS? Or bare metal it?

Welcome Joe Byrne, new Strategy lead for Freescale's Digital Networking Group

admin@community.freescale.com — Mon, 15 Apr 2013 15:34:40 GMT

Today, I want to officially welcome Joe Byrne to Freescale’s Digital Networking Group as the head of Product Strategy. If that name sounds familiar, you may recognize it from Joe’s previous work with the Linley Group, where he was a senior analyst covering communications ICs. Prior to his tenure at Linley Group, Joe led Gartner’s coverage of wired communications semiconductors.

Joe is a distinguished industry expert who brings keen technology insight and deep industry knowledge to Freescale’s business in networking and communications markets. Joe will focus on refining product strategies designed to take Freescale and the Digital Networking Group’s products to the next level of success.

I asked Joe what he thought about joining Freescale and why he’s decided to make the move from an industry analyst to an active participant. This is what he said:

“The market is changing rapidly and addressing a range of key trends, including software-defined networking, the Internet of Things, cloud computing and heterogeneous networks. It’s exciting to be able to help drive and influence these changes.”

Given his passion and domain knowledge in the area of multicore technology, Joe is uniquely positioned for this crucial role at Freescale. He has a lot of ideas that we’re already beginning to put into motion. Joe’s full bio is at the bottom of this post so you can see the breadth of his knowledge and experience.

Please join me in welcoming Joe to Freescale!

About Joe Byrne:

Most recently, Byrne was a senior analyst at The Linley Group, where he focused on communications and semiconductors, providing strategic guidance on product decisions to senior semiconductor executives. Prior to working at The Linley Group, he was a principal analyst at Gartner, leading the firm’s coverage of wired communications semiconductors. There, he advised semiconductor suppliers on strategy, marketing and investing.

Byrne started his career at SMOS Systems after graduating with a bachelor of science in engineering from Duke University. He spent three years at SMOS as part of the R&D engineering team working on 32-bit RISC microcontrollers. He then returned to school for an MBA, which he received with high distinction from the University of Michigan. He worked with Deloitte & Touche Consulting Group for a year before going on to work at Gartner, where he spent the next nine years until going to work for The Linley Group in 2005.

Free Android app teaches sensor fusion basics

admin@community.freescale.com — Mon, 08 Apr 2013 18:22:18 GMT

Every year or so, Freescale runs "Technical Enrichment Matrix" (aka: TEM) series of local events. It's essentially an adult science fair where the engineering community within our various facilities gets together to share ideas. Participating engineers put together posters and demos designed to teach their colleagues a bit about what they've been working on for the past year. Last week we held our 2013 TEM in Tempe, Arizona - and were lucky to have our CEO Gregg Lowe as well as CTO Ken Hansen on hand. It's a fun event, and I look forward to it every year.

This time around, my team and I got the opportunity to show off some of the sensor fusion work we've been doing. We're using Android phones and tablets to communicate to a development board via Bluetooth link. The fusion is done on the development board. We use Android as a visualization tool. The embedded software and boards are not (yet) available outside Freescale, but you CAN download Version 1.0 of the Android app today.

"Why would I bother?" is an obvious question. If you are a sensor fusion expert, you might just want to see what Freescale is up to. But if you are interested in the topic, and still learning, then this will be (I hope) a good educational resource for you.

We call this application the "Xtrinsic Sensor Fusion Toolbox". It's a free download from Google Play. Just type "sensor fusion" in the search field and it should pop right up. Or if you are viewing this posting from your phone, simply click here. Or if you like QR codes, use this one:

The tool was designed to allow us to benchmark our sensor fusion results versus other solutions already on the market, so it can play with fusion options already present on your Android phone or tablet. The app uses standard Android interfaces to access sensor and orientation data from the Android framework. Although optimized for tablets, it should run fine on any phone running Android 3.0 or above. On smaller screen devices, some GUI components will extend offscreen. Extensive use of Android ScrollViews mean you can just slide the appropriate tool bar or display to one way or the other with your finger to access "offscreen" components.

At this point, I'm going to assume you're intrigued enough to have downloaded the app from Google Play. Open the app and tap on the "Source/Algorithm" button, and you will be presented with a number of options.

Try "Local accel" first. You will immediately notice that the image of the PCB on the phone begins to respond to your movements. But there are limitations. Put your device on a table top and spin it. You will see that the image does not respond with any change. This is because the app is computing orientation with just an accelerometer, which we are using to measure gravity. Spinning the device as described just rotates it about the very vector it is trying to measure, which doesn't change the measured value. So you cannot see changes in "yaw". But pick up your device and tip it right to left (roll) or bottom to top (pitch) and you will see the image of the PCB adjust itself such that it tries to remain stationary in space, regardless of how you hold your device. This inability to measure yaw is not an error in the algorithm, it is a limitation imposed by the use of a single sensor to compute orientation.

Now try the "Local mag/accel" option. With the addition of a magnetometer, you have everything needed to create an electronic compass. Now the app knows which way magnetic north is, and it will attempt to fix the PCB in space. It's tough to describe, but if you download and try the app, you'll see what I mean.

Magnetic sensors tend to be a bit noisy, and you may notice this option has a bit of jitter. If necessary, scroll the Fusion Settings Bar (where you see "Exit" and "Source" buttons to the left, and you'll find a checkbox labeled "LPF Enable". This let's you apply a low pass filter to sensor readings before they are used to compute device orientation. You can change the filter coefficient with the scroll bar that appears when you check the box. Both notice that adding filtering also makes the display respond slower to changes in orientation.

At this point, you should start to see the point of this application. It lets you explore options for sensor fusion. And bear in mind that at this point, you are playing with options already in your Android device. We're using standard Android routines and whatever sensors your device manufacturer decided to include.

Up to now, we've been exploring the "Device View." Other options you should try include the "Panorama View". You get to that using the navigation button (shown below).

The Panorama View (shown below) places you in the center of a virtual room. As you rotate and move your device, your view into that room changes to match your movements. If your device includes a gyroscope, I would set the "Source/Algorithm" control to "Local 9-axis". This will give you smoothest control.

I personally find the "Device View" more useful for visualizing fusion results. We included the "Panorama View" as an example of just how easy it is to use orientation results in a Virtual Reality application (see Orientation Representations: Part 2).

In June 2011, I presented Online data sets for inertial and magnetic sensors (part 1). Regular readers may have noticed there was never a second part. This Android app addresses that deficiency. You can use it to capture your own data sets. Go back to the Navigation control and select "Log Window".

Assuming you've set the "Source/Algorithm" control to one of the three "Local" options, you should see a continuous display of sensor values scrolling down the screen. If you click the "File logging enable" checkbox on the Fusion Settings Bar, these will be captured to an output file that you can then email to yourself using the "SHARE" option on the Android Action Bar (you must have an email client installed on your device for this to work).

There are a lot more options available on the tool. All are documented in the "Documentation" view, again enabled via the NAV button. In addition to tool features, the documentation also goes into some detail explaining the basics of sensor fusion and how some of the results are calculated, incorporating several of our previous blog topics on the topic.

Please send me feedback and suggestions for improvement. Although I can't promise that all suggestions will be incorporated in future versions, they will be considered. I authored this application, and have a vested interest in making it useful.

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

r62516@freescale.com — Sun, 07 Apr 2013 13:59:12 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.

Meet YOUR 2013 Top 5 Smart Device Pundits

b05928@freescale.com — Tue, 26 Mar 2013 09:15:36 GMT

Did you know that the number of connected, smart devices is estimated to surge to 7.4 billion this year, up from 6.8 billion in 2012? To put that in perspective, there are 7.1 billion people in the world, and that figure is growing at a much slower rate.

But if you stop to think about the number of appliances in your home, the traffic lights on your way to work, and the retail displays surrounding you as you shop; it makes sense that more devices are connected to the Internet than there are people on the planet.

The brain making these “things” smarter? Embedded processing. Small chips enable devices to connect, learn, adapt and react to help facilitate our everyday lives. However, as smart as these devices may be, we still depend on bloggers, reporters and analysts to report on the deep impact that connected machines and the Internet of Things phenomenon are having on every aspect of our lives.

When Freescale asked, “Who is putting the SMART in Internet of Things coverage?” readers around the globe responded with their nominations and votes. Join us in congratulating the 2013 Top 5 Smart Device Pundit winners for their outstanding coverage and for serving as a valuable source for consumers, suppliers and manufacturers who seek to learn more about how the Internet of Things and connected machines are driving data-enabled social innovation.

· Ben Bajarin, TIME

· Brad Linder, Liliputing

· Kevin Tofel, GigaOM

· Sascha Pallenberg, Mobile Geeks

· Terrence O’Brien, Engadget

Be sure to spread the world and to stay connected with Freescale and your favorite Smart Device Pundits all year long, via http://freescale.com and our social media communities including Twitter, Facebook, Google+ and LinkedIn where we will continue to celebrate the pundits’ and highlight their best coverage.

Congratulations to all 20 pundits nominated to the 2013 Smart Device Pundit list!

· Ben Bajarin, TIME

· Brad Linder, Liliputing

· Clive Thompson, Wired/NYTimes

· Craig Timberg, Washington Post

· Chris Davies, SlashGear

· Chris Murphy, InformationWeek

· Dean Takahashi, VentureBeat

· Jason Hiner, TechRepublic

· Joshua Topolsky, The Verge

· Harry McCracken, TIME

· Kevin Fitchard, GigaOM

· Kevin Tofel, GigaOM

· Kit Eaton, Fast Company

· Lance Ulanoff, Mashable

· Michael Kozlowski, GoodEreader

· Sarah Rotman Epps, Forrester

· Sascha Pallenberg, Mobile Geeks

· Stephen Shankland, CNET

· Sylvie Barak, Freelancer

· Terrence O’Brien, Engadget

How do you promote innovations to accelerate the rollout of the Internet of Things (IoT)?

r62516@freescale.com — Tue, 19 Mar 2013 17:38:00 GMT

After my last blog post about the need for harmonizing the business models of stakeholder companies, one of our partners from one of these “stakeholder companies” called me and said that I was basically being too harsh on them, and if there is any blame, we are all guilty of it. He specifically mentioned that I am letting semiconductor and software companies "home free" in these discussions, as we, too, are not doing enough as an industry to promote enough innovations to promote the rollout of IoT. And maybe if we had better innovative products that could facilitate the discussions between the end users, the industry would move forward faster. After all, we are the ones who provide the basic building blocks of the end solutions.

I thought about his call for a while. How does one define “innovation,” and what is it that we should be doing to promote IoT to a greater extent? Wikipedia’s definition for the word “Innovation” is “Creation of better and more effective products, processes, services, technologies, or ideas that are readily available to markets, governments, and society.” I don’t usually blog to peddle a product (and forgive me if this sounds self serving), but one thing Freescale knows how to do is to innovate, and we have a strong history and legacy of innovations, with lots of “firsts” along the way. Perhaps nothing captures a sample of the innovations our company has done better than this timeline.

From the 1974 introduction of the MC6800, our first 8-bit microprocessor used in automotive applications, to the 2010 debut of the TFS-90 Flash, industry leading bit-level reliability through revolutionary silicon nanocrystal technology—and lots of others before, in between, and after that—Freescale has set the benchmark for innovations. (Click image at left to enlarge.)

Looking closer at the type of technologies that we have developed, and the ones we are working on now and what is needed to spur the innovations our customers are asking us to enable for the faster role out of the IoT, I realized that something has changed.

Twenty five years ago, innovations were closed loop systems. However, systems have become more complex and the role of software has increased drastically, and now innovation flourishes and accelerates within an open ecosystem. Surely we still have original research on fundamental technologies around process technologies, packaging, sensors, RF, and new system architectures, and we will continue to differentiate against our peers. However, from the perspective of MCU- and MPU-related applications processing, innovations now need open platforms, and a strong leverage of our ecosystem partners.

We intend to deliver solutions, but clearly no one company can do it all, especially when you consider the various flavors of tools, development kits, RTOSes, applications software, middle wares, and reference platforms that our customers would need around the world. This can only happen when an open ecosystem contributes to the overall solution, and creates the opportunity for ecosystem partners to work across common open platforms, indeed facilitates faster innovations for our end customers.

A quick Internet search highlighted the following example use cases/applications under consideration:

• Machine-to-machine communication

• Machine-to-infrastructure communication

• Machine to environment communications

• Telehealth: remote or real-time pervasive monitoring of patients, diagnosis and drug delivery

• Continuous monitoring of, and firmware upgrades for, vehicles

• Asset tracking of goods on the move

• Automatic traffic management

• Remote security and control

• Environmental monitoring and control

• Home and industrial building automation

• “Smart” applications, including cities, water, agriculture, buildings, grid, meters, broadband, cars, appliances, tags, animal farming and the environment, to name a few

• And lots of other innovative services

Yes, IoT is about offering lots and lots of innovative services, and right now many of these services may not sound appealing, or simply come to mind. However, when they are here, humanity becomes addicted to it and expects it everywhere. Many people forget that until 20 years ago, most of us lived without mobile phones and didn’t see a need for them, but now they are the most popular personal gadgets in the Western world. Along those lines, some IoT services will address needs easily identifiable today (e.g. asset tracking, smart energy, etc.), but others are yet to be defined.

So, why does software get such a big headline? Software enables the various services the IoT will provide. Services are the means by which the IoT will address certain needs, and are enabled by the use of various pieces of software code, hence software is the lifeblood of the IoT services.

There will be thousands of applications available that will address certain types of services, and will be used by a new generation of service providers. Last October, the number of Google Android apps matched Apple’s count of 700,000. In a recent TechNet study, the "app economy," which includes Apple, Facebook, Google's Android and other app platforms, was directly and indirectly responsible for 466,000 jobs. There are thousands of man-years worth of software written to provide the cellular infrastructure that iPhone alone uses to provide services. A cellular infrastructure is one of many networks that will be supported by IoT, and a fraction of the types of services that will be offered supporting all of those services listed above. Now you can see how much software needs to be written to support IoT.

How can you accelerate the process of software development and spur innovations? How about making it easy for various ecosystem partners to come to the same table and use the same platform to develop pieces of the solution as easily as possible? How about giving the smaller players a voice and an outlet to be able to sell their software and work with other ecosystem partners and provide as much of the solution to the end product developers, as fast as possible?

How does what’s above help spur the much-needed innovations? Here’s my rationale: If the engineers who are working on the end gadgets tied to end services spend less time on getting the basics of their design working, they can spend more time innovating in differentiating areas. The more they innovate, the more they spur competition, which, in turn, spurs more innovations. It all starts with making life easier for the design engineers, so that they spend minimum time getting pieces of the widgets working together, and more time on higher-value stuff. How does a semiconductor company help with that? By working with ecosystem partners and making sure that not just the silicon, but all supporting "cast members" who contribute to the overall success of a project, is well thought through, debugged, and works as seamlessly as possible.

That is why our team at Freescale spends so much time, effort, and money on developing our ecosystem, and provides tools, reference designs, and development kits. That is also why we chose to partner with ARM, not only to provide that open platform to spur innovations, but also bring an army of ecosystem partners and software developers and providers that make their products and services available to our customers. Here are some of the links that show in earnest, what we and our partner ARM are doing to do our share in spurring innovations: Freescale ARM technology-based solutions http://www.freescale.com/webapp/sps/site/overview.jsp?code=ARM. When I talked to my friend Willard Tu of ARM, he pointed me to the Embedded Software Store, which “is a combination of the ARM Connected Community® partners and a marketplace for embedded developers. The Embedded Software Store allows the developer to find, evaluate, and learn about enablement software. If you find something that meets your needs, you can purchase it right there, all in one place”.

Don’t get me wrong, there is a lot more work to do, but we are past the starting point now, and depending on the types of applications, there are a lot of successes for our customer base to point to.

Lastly, when it comes to services, they need to be customized based on local culture, customs, languages, habits, etc., or we cannot count on rolling out services outside of the western world. We cannot assume that a Chinese grandmother will use the same exact services as my grandmother and her poker buddies in South Florida. This is especially true as we move closer to the edge of the network and the services offered relate to the sensing and edge devices. Hence, customizing IoT services for local consumption is a must-have in order to promote the adoption of IoT services, and it can only happen by collaborating with local ecosystem partners across common open platforms.

Comments? Kaivan Karimi can be reached at kaivan.karimi (@) freescale (dot) com.

Building a virtual gyro

admin@community.freescale.com — Tue, 12 Mar 2013 22:06:02 GMT

In Orientation Representations Part 1 and Part 2, we explore some of the mathematical ways to represent the orientation of an object. Now we’re going to apply that knowledge to build a virtual gyroscope using data from a 3-axis accelerometer and 3-axis magnetometer. Reasons you might want to do this include “cost” and “cost”. Cost #1 is financial. Gyros tend to be more expensive than the other two sensors. Eliminating them from the BOM is attractive for that reason. Cost #2 is power. The power consumed by a typical accel/mag pair is significantly less than that consumed by a MEMS gyro. The downside of a virtual gyro is that it is sensitive to linear acceleration and uncorrected magnetic interference. If either of those is present, you probably still want a physical gyro.

So how do we go from orientation to angular rates? It’s conceptually easy if you step back and consider the problem from a high level. Angular rate can be defined as change in orientation per unit time. We already know lots of ways to model orientation. Figure out how to take the derivative of the orientation and we’re there!

In our prior postings, we’ve discussed a number of ways to represent orientation. For this discussion, we will use the basic rotation matrix. Jack B. Kuipers has a nice derivation of the derivative of direction cosine matrices in his “Quaternions and Rotation Sequences” text - one of my most used textbooks. It makes a good starting point. Paraphrasing his math:

Let:

v_f= some vector v measured in a fixed reference frame
v_b= same vector measured in a moving body frame
RM_t = rotation matrix which takes v_finto v_b
ω = angular rate through the rotation

Then at any time t:

v_b= RM_t v_f

Differentiate both sides (use the chain rule on the RHS):

dv_b/dt = (dRM_t/dt) v_f + RM_t(dv_f /dt)

Our restrictions on no linear acceleration or magnetic interference imply that:

dv_f/dt = 0

Then:

dv_b/dt = (dRM_t/dt) v_f

We know that:

v_f = RM_t^-1 v_b

Plugging this into (8) yields

dv_b/dt = (dRM_t/dt) RM_t^-1 v_b

In a previous posting (Accelerometer placement – where and why) , we learned about the transport theorem, which describes the rate of change of a vector in a moving frame:

dv_f/dt = dv_b/dt - ω X v_b

Those who take the time to check will note that we have inverted the polarity of the ω in Equation 11 from that shown in the prior posting. In that case ω was the angular velocity of the body frame in the fixed reference frame. Here we want it from the opposite perspective (which would match gyro outputs).

And again,

dv_f/dt = 0
so
dv_b/dt = ω X v_b

Equating equations 10 and 13:

ω X v_b = (dRM_t/dt) RM_t^-1v_b
ω X = (dRM_t/dt) RM_t^-1

where:

0 -ω_z ω_y
ω X = ω_z 0 -ω_x
-ω_y ω_x 0

Going back to the fundamentals in our first calculus course and using a one-sided approximation to the derivative:

dRM_t/dt = (1/Δt)(RM_t+1 – RM_t)

where Δt = the time between orientation samples

ω_b X = (1/Δt)(RM_t+1 – RM_t) RM_t^-1

Recall that for rotation matrices, the transpose is the same as the inverse:

RM_t^T = RM_t^-1
ω_b X = (1/Δt)(RM_t+1 - RM_t) RM_t^T

Equation 15 is a truly elegant equation. It shows that you can calculate angular rates based upon knowledge of only the last two orientations. That makes perfect intuitive sense, and I’m ashamed when I think how long it took me to arrive at it the first time.

An alternate form that is even more attractive can be had by carrying out the multiplications on the RHS:

ω_b X = (1/Δt)(RM_t+1 RM_t^T - RM_t RM_t^T)
ω_b X = (1/Δt)(RM_t+1 RM_t^T - I_3x3)

For the sake of being explicit, let’s expand the terms. A rotation matrix has dimensions 3x3. So both left and right hand sides of Eqn. 22 have dimensions 3x3.

(1/Δt)(RM_t+1 RM_t^T – I_3x3) = (1/Δt) W

0 W_1,2 W_1,3
W = RM_t+1 RM_t^T - I_3X3= W_2,1 0 W_2,3
W_3,1 W_3,2 0

The zero value diagonal elements in W result from small angle approximations since the diagonal terms on RM_t+1 RM_t^T will be close to one, which will be canceled by the subtraction of the identity matrix. Then:

0 -ω_z +ω_y 0 W_1,2 W_1,3
ω X = +ω_z 0 -ω_x = (1/Δt) W_2,1 0 W_2,3
-ω_y +ω_x 0 W_3,1 W_3,2 0

and we have:

ω_x= (1/2Δt) (W_3,2 - W_2,3)
ω_y= (1/2Δt) (W_1,3- W_3,1)
ω_z= (1/2Δt) (W_2,1- W_1,2)

Once we have orientations, we’re in a position to compute corresponding angular rates with

One 3x3 matrix multiply operation
3 scalar subtractions
3 scalar multiplications

at time each point. Sweet!

Some time ago, I ran a Matlab simulation to look at outputs of a gyro versus outputs from a "virtual gyro" based upon accelerometer/magnetometer readings. After adjusting for gyro offset and scale factors, I got pretty good correlation, as can be seen in the figure below.

You will notice that we started with an assumption that we already know how to calculate orientation given accelerometer/magnetometer readings. There are many ways to do this. I can think of three off the top of my head:

Compute roll, pitch and yaw as described in Freescale AN4248. Use those values to compute rotation matrices as described in Orientation Representations: Part 1. This approach uses Euler angles, which I like to stay away from, but you could give it a go.
Use the Android getRotationMatrix [4] to compute rotation matrices directly. This method uses a sequence of cross-products to arrive at the current orientation.
Use a solution to Wahba’s problem to compute the optimal rotation for each time point. This is my personal favorite, but I think I’ll save further explanation for a future posting.

Whichever technique you use to compute orientations, you need to pay attention to a few details:

Remember that non-zero linear acceleration and/or uncorrected magnetic interference violate the physical assumptions behind the theory.
The expressions shown generally rely on a small angle assumption. That is, the change in orientation from one time step to the next is relatively small. You can encourage this by using a short sampling interval. You should soon see an app note that my colleague Mark Pedley is working on that discards that assumption and deals with large angles directly. I like the form I’ve shown here because it is more intuitive.
Noise in the accelerometer and magnetometer outputs will result in very visible noise in the virtual gyro output. You will want to low pass filter your outputs prior to using them. Mark will be providing an example implementation in his app note.

This is one of my favorite fusion problems. There’s a certain beauty in the way that nature provides different perspectives of angular motion. I hope you enjoy it also.

References

Freescale Application Note Number AN4248: Implementing a Tilt-Compensated eCompass using Accelerometer and Magnetometer Sensors
Orientation Representations: Part 1 blog posting on the Embedded Beat
Orientation Representations: Part 2 blog posting on the Embedded Beat
getRotationMatrix() function defined at http://developer.android.com/reference/android/hardware/SensorManager.html Wikipedia entry for "Wahba’s problem"
U.S. Patent Application 13/748381, SYSTEMS AND METHOD FOR GYROSCOPE CALIBRATION, Michael Stanley, Freescale Semiconductor

What hinders the mass-scale rollout of IoT services? Technology standards or business models?

r62516@freescale.com — Mon, 11 Mar 2013 15:21:38 GMT

I just read about a group forming that is aiming to establish a standard protocol to connect a huge range of devices and sensors in the Internet of Things (IoT). Reading the news clip was one of those things that make you go “hmmm?” It’s not because I don’t believe the group’s intentions are admirable and it’s not because I don’t believe that standardization is necessary. Instead, my head spins at the task ahead. I believe that the multitude of technical solutions and dispersed standardization activities are slowing the roll out of the global IoT market, but these standardization efforts will take a LONG time.

As mentioned in my original IoT whitepaper, What the Internet of Things (IoT) Needs to Become a Reality, there are as many edge/sensing node types as there are applications. A lot of these applications already have associated standards, and consequently there are already a ton of different machine-to-machine interface standards in use. Each one addresses a different part of the use cases on a number of different media and operates at many protocol layering schemes. Some were created before IoT and M2M became hot topics, and some do not even refer to the concept of M2M. As a result, existing M2M solutions are highly fragmented and typically dedicated to a single application (e.g. smart healthcare, smart grid, etc.), and even with that single application, there are multiple hands at the table as we will see later in this blog.

I have no doubt that some of these non-uniform standards will get harmonized and there will be some sort of pruning done in the process. Going from tens of different standards and business models to just one or two is like one global cuisine made using a single unified international food cooking standard! IoT is about global communication of machine-to-machine, machine-to-infrastructure, and machine-to-environment, with lots and lots of services that one can imagine today, and new ideas created over time. The IoT value chain is perhaps the most diverse and complicated value chain of any industry or consortium that exists in the world. In fact, the gold rush to IoT is so pervasive that if you combine much of the value chain of most industry trade associations, standards bodies, the ecosystem partners of trade associations and standards bodies, and then add in the different technology providers feeding those industries, you get close to understanding the scope of the task. First, all of these groups must not only talk, but they must come to an agreement on a uniform standard. One may say this is a pretty ambitious task. Not that it isn’t doable, but it will take a LONG time. And how much standardization is good? Do we really want to come up with a uniform way of cooking international cuisine? And if you do that, would your French batard baguette and Indian naan be created the same way using the same bread-making standards? Would they taste the way you want them to taste?

First, back to the technology building blocks of the IoT:

The standards in question are related to the communications nodes and the interactions of these nodes at each segment of this system, from the edge nodes, all the way to the cloud. It also would then include service and business models associated with services created. It’s a given that ubiquitous access to the cloud, IP and the web paradigm will help hide some of the complexities of the systems for the users, and would allow simpler lower cost solutions down the road.

The challenges that inhibit the IoT-related standards and hence a robust rollout of IoT services are:

Security and privacy issues (Note that security and privacy measure are a lot of times at odds with each other)
Endless IoT applications
Endless potential types of edge node technologies, and the interface to the communication nodes (e.g. Sensors and use cases integration into Telco services)
High fragmentation of today’s IoT connectivity solutions
Lots of legacy systems that will now be a part of IPv6 network, with no (or minimal) existing “co-existence” and interoperability plans
Partnerships, between heterogeneous and diverse industries, and defining the associated business models involving multiple stakeholders and service providers of some of those legacy systems in number 5
Management and provisioning of the various networked devices, applications, and services, and the network capacity planning that comes with it
Regulatory issues that will hinder deployments on a worldwide basis
Special needs of “industrial grade” product rollouts, with long lasting requirements in the field, that require future proofing of any standard recommended
Slow development of the IoT services market, partially due to lack of future proof standards
etc.

One look at the list, and it’s easy to realize that while the technical items are hard to implement, they are not necessarily going to be the bottleneck here. Consider items 5 and 6 in a scenario as simple as smart home automation. There was a time that a home owner had a landline telephone service provider, a cellular phone service provider, and a television service provider (cable, fiber, or satellite base). Thanks to the concept of triple/quadruple play, a lot of homes in the U.S. have only one company to deal with, or at least purchase one bundle from two companies. However, some still have a separate security company, a separate gas provider (public or private propane), a separate water provider, and a separate electricity provider.

Now imagine a time when smart home services are rolled out, which comprehensively include electricity and utility management, remote command and control of all of your appliances, security of all of your points of entry, with auxiliary services related to remote health and elderly care added to the mix. Additionally, all of your relevant “things” have a unique ID, and can be controlled locally through a home gateway and remotely through cloud server(s). How many companies of diverse backgrounds along with the new IoT service providers, would have to come to agreements and standardize on business models, services, choice of technologies and communication standards? How many people are betting right now that they can easily get their telco and utility companies for their neighborhood come to an agreement on the types of communication technologies they need to have for PAN/LAN/NAN/WAN coverage? Yes, the camps that promote BTLE/Wifi/LTE versus 802.15.4/some flavor of PLC (Prime, G3, 1902.1, etc.)? Now, let’s assume they agree on a set of communication standards. How about business models that can work for them and all of their ecosystem partners?

This already assumes that there is only one home gateway inside of the house, although we all know that there are multiple competing camps that want to have their own gateway a part of many gateways inside of the house. For example, utility companies want to bring a utility home hub inside of your home that communicates with your meter outside of the house. That, in turn, communicates with a curbside/neighborhood aggregator box, which then communicates to the utility company. At the same time, your triple-play provider (telco of choice) wants your home gateway to become the center of command and control for all things in your house. Lastly, there are new kids on the block with alternative business models (think Google TV) who have their own ideas about who should control that “box” inside your home. But seriously, if everything is supposed to become IPv6 compliant and get accessed via the cloud, does it make sense to have so many boxes in your house? Or, is only one all you need?

Now you can see why companies like Cisco are so interested in all smart energy related discussions.

While standardization of technical solutions will promote and accelerate the roll out of the global IoT market, harmonizing the business models of the stakeholder companies that have diverse backgrounds, as well as their ecosystem partners, will be the bigger factor to help the rollout of IoT services.

Scream it out, Say it out loud: Vote for the Pundit that makes you proud!

b05928@freescale.com — Wed, 06 Mar 2013 12:01:49 GMT

The Internet of Things rises! It's in our cars, appliances, devices, homes - making us more connected and our world smarter. But who's putting the SMART in Internet of Things coverage?

On February 18th, we began our annual search for the top 2013 Smart Device Pundits – a collection of the very best and brightest advisors who keep us up to date on the biggest news and trends for the Internet of Things and the vast array of connected devices that make our world smarter. We asked you to nominate your favorite Pundit and tell us why they deserve to be recognized – and nominate you did!

The results for this year's 20 Pundits are in, but now we need your help to take it one step further and whittle down the top 20 to only 5 superstar geeks. Who will make your ultimate list of the Top 5 Smart Device Pundits for 2013? It’s your vote, your voice! You can vote once per day, so make it count.

Here is the 2013 lineup. Voting closes at midnight on March 15!

Material handling robotics

admin@community.freescale.com — Tue, 05 Mar 2013 10:43:43 GMT

Do you know the difference between mechanization, automation and robotics? Mechanization acts. Automation senses and acts. Robotics senses, thinks and acts. Electra Studios' President Dan Kara shared this and other interesting facts about robotics during the “Robotics Solutions for Materials Handling Application” webinar, which was sponsored by Freescale. (You can access it until May 16.)

The similarity between Dan’s robotics definition and Freescale’s own charter and product focus—sensors (senses), embedded processing and software (thinks) and connect and control (acts)—explains why there is such a nice fit between robotics companies and Freescale technology.

Material handling robots are used to package or palletize goods, pick and place production items, transfer pieces of equipment, load and unload boxes and even move goods throughout warehouses. According to the International Federation of Robotics, 68,500 handing robots shipped in 2011. With the 42 percent growth in 2011, material handling robotics had the highest year-on-year growth within industrial robotics. Mobile robots and “co-worker” robots, which can operate safely and easily next to a human worker, are the growing trends within this market segment. The challenges are to make them cheaper, safer, easier to program and flexible to use, which precisely where Freescale industrial robotic technology can help.

	0	-ω_z	+ω_y		0	W_1,2	W_1,3
ω X =	+ω_z	0	-ω_x	= (1/Δt)	W_2,1	0	W_2,3
	-ω_y	+ω_x	0		W_3,1	W_3,2	0

	0	-ω_z	ω_y
ω X =	ω_z	0	-ω_x
	-ω_y	ω_x	0