Showing posts with label accelerometer. Show all posts
Showing posts with label accelerometer. Show all posts

November 18, 2014

Sensor Hub, Motion Coprocessor or DSP?

In my last blog I referred to the return of digital signal processing in the form of a discrete, low-power chip that acts as co-processor to the main applications processor of a smartphone or mobile device. Taking this one step further raises some fundamental questions. How complex are these helping hands in terms of their signal processing capabilities?

Determining motion


Let’s take the iPhone as an example. The latest iPhone 6 uses the newer M8 motion coprocessor (an NXP Semiconductor LPC18B1 chip) in combination with Apple’s very own A8 / APL1011 applications processor as outlined in a recent teardown by TechInsights. The word motion provides the first clue regarding the primary purpose of the chip: monitoring movement to determine if the user is sitting, running, walking, cycling or driving. In fact iPhone apps interrogate this user activity status from the CMMotionActivity class offered by the iOS operating system. To determine user activity, the motion co-processor will most likely take acceleration readings in three axes (x, y and z) from the accelerometer sensor. Repetitively calculating the max and min values will enable distinction between sitting and running/cycling and driving, regardless if the user is holding the phone, has it stashed in a trouser pocket or nestled in a car’s device cradle.

Motion coprocessor calculates acceleration to determine user activity

However it’s far more difficult to distinguish between running or cycling as the acceleration in all three axes is quite similar for both activities. This is where measuring yaw (rotation) using the gyroscope sensor comes into play. Cycling has a smoother repetitive motion than jogging. By calculating the spectrum of the yaw rate using an FFT (Fast Fourier Transform), cycling will show a single dominant frequency as determined by the cadence of the cyclist. Of course calculations can be further relaxed if likelihoods are taken into consideration. For example, a measurement showing an impromptu change of states from cycling to driving is somewhat implausible. Statistical models as offered by Bayesian probability inference or Markov chains come to the rescue here. And if all goes wrong and a confident activity guess is out of question, iOS luckily provides the state unknown.

The M8 LPC18B1UK chip is based on ARM’s Cortex M3 core. In contrast to the follow-up Cortex M4 core, the M3 does not include a DSP instruction set. So, it ’s plausible that activity tracking calculations are performed at a low frequency. In fact the chip is clocked at only 0.15 GHz. That in turn makes it battery efficient so it can run constantly without ever taking a break. Even in the iPhone’s standby mode it collects, calculates and caches sensor data. The iPhone stores results for a maximum period of seven days in the LPC18B1UK’s on-chip flash of 1 MByte. Sampling rates of 14-bit accelerometer data are thus probably in the 1 to 2 Hz range. In other words, really slow.

From lightweight processing to heavy lifting


As the iPhone 6 example above underlines, motion detection is all about lightweight processing. Similarly Atmel’s sensor hub solution as found in several smartphones from Samsung (see Wikipedia) use Atmel’s SAM D20 which features an ARM Cortex M0+ core on-chip and no DSP functionality. However Atmel’s sensor hub roadmap points to the follow-up SAM G51/53 which is based on the DSP-rich ARM Cortex 4 core. Sensor hubs are evidently transitioning from lightweight DSP processing to heavy DSP lifting. Recent smartphones from HTC, Nokia, Samsung and Sony confirm this trend: they use Qualcomm’s Snapdragon 800 SoC (system-on-chip) family with an on-chip sensor engine based on their powerful 32-bit Hexagon DSP core that also offers floating-point support. Next-generation smartphones, wearables and other mobile electronics will thus not only capture both user and environmental sensor data but also combine these streams in an eclectic signal processing mix to provide never-seen-before smarts for the user.


November 12, 2014

Sensors and the Rebirth of the DSP

Back in the nineties the digital signal processor (DSP) had its heyday. It was a completely different beast compared with CISCs (complex instruction set computers) like Intel’s Pentium or RISCs (reduced instruction set computer) like ARM’s IP cores. DSPs allowed complex mathematical algorithms to be processed in real-time based on the fundamental mutliplier-accumulator structure of their internal architecture. Mostly these signal processors had a 16-bit fixed-point word length with a very basic feature set. Their distinctive clout was speed combined with low power - a boon for all types of embedded applications requiring real-time response. Yet their restricted word length made programming them an art, something for maths whizz kids who could work with integers just as well as with floating point numbers. And then at some point, stand-alone DSPs simply disappeared off the processor map. What happened?

Layed off by semiconductor advances


With each reduction in size of semiconductor processing nodes, clock speeds moved into the gigahertz range whilst supply voltages and power consumption dropped dramatically. Lower power levels and longer word lengths enabled newer processor types and categories to extend their reach into the domain of rigorous real-time requirements, formerly a unique terrain for digital signal processors. Multiple cores on the same dice were suddenly feasible and the stand-alone DSP simply got gobbled up in the process. What was once a stand-alone math starlet enjoying the limelight became reduced to a common (and essential) block on a larger system-on-chip (SoC).

Smartphones and their sensors


Recently I’ve noticed the term “DSP” appearing more frequently again in the semiconductor world. The trail leads back to sensors; in particular, sensors as they are used in smartphones. First -generation devices featured three or four sensors to ensure fluid interaction with their touch screens: a proximity sensor to turn off the display during a call for saving power and preventing contact with the ear or face; an ambient light sensor for the best reading experience under all types of lighting conditions; an accelerometer to sense the orientation of the phone and switch between portrait and landscape modes accordingly. With each new device generation, further sensors joined the fold. Recent smartphones are often blessed with over ten such environment watchdogs.

Smartphones and their sensors require DSP processing

Each new smartphone generation features more sensors



Sensors provide information on what the user is currently doing. Combined with location intelligence, smartphones can react intelligently to the user’s activity and current surroundings. Continuous sampling, storage and processing of sensor data is necessary in order to keep track of what is happening to the device, its user and whereabouts. Keeping the phone’s main processor- one of the battery hogs - on all the time, makes no sense. Enter the power efficient coprocessor, often termed sensor hub, or motion processor and sometimes even DSP.

Fusing sensor data to predict location


By adding an additional processor with scanty energy demands operating separately from the main, power-hungry applications processor, the continuous flow of sensor data can be analyzed all the time, even when the phone itself is asleep. Sharp readers will contest why use a processor geared towards blistering speed (read DSP) if sensor data, like readings of the temperature or magnetic field, arrive at a snail’s pace? Yet most calculations are all about sensor fusion, or using multiple sensors inputs to determine something really useful. Take indoor navigation as an example. The usual satellite GPS signal may not be available yet seamless navigation might still be required. Using combined data from the accelerometer, gyroscope, magnetometer and pressure sensor, the DSP implements a mathematically complex Kalman filter to accurately estimate the user’s position from previous bearings (dead reckoning algorithm) and simultaneously compensates for a number of tricky sensor anomalies such as offset, gain, non-linearity and noise. Such an intelligent sensor hub provides rich soil for further smartphone differentiation to take root as algorithms and smartphone apps combine motion, physiological (e.g. heart rate, voice analysis, …) and environmental data in completely new ways. This new trend brings the digital signal processor (DSP) back into the spotlight, reestablishing it prowess from its former glory days as a highly power-efficient mathematical engine.