K is for Kit Kat

You may recall that PNI Sensors has a sensor hub called SENtral. It represents a unique partitioning between hardware and software intended to lower its power and size. Its focus was primarily motion-oriented sensors, which, at the time, were the bulk of what system designers were paying attention to.

Since then, Google has issued their sensor requirements for Android 4.4 (Kit Kat). It requires very specific sensors, some of which are actual physical sensors, and others of which are “virtual” sensors – fused out of data from the real sensors. A step counter is an example of a virtual sensor: There is no hard step counter in any device, but the information from the inertial sensors can be combined to create the step counter.

So PNI Sensor has updated their SENtral hub to meet the Kit Kat requirements; they call it SENtral-K. It supports more sensors than their original version did, meeting the list that Google has sent down. Some of what the –K version does could have been done in the older one by adding new functions in the RAM space; this new version implements the functions in the ROM space.

One of their focuses is on what they call “simultaneity.” The idea is that it takes time to do the calculations required for the virtual sensors, and yet Android doesn’t accept excuses for virtual sensors. Heck, it thinks it knows which sensors are real and virtual, but in fact it doesn’t. (For example, the gyroscope could be a “soft gyro”).

What that means is, if you’re sampling your real sensors at 100 Hz, then Kit Kat expects all sensors – real or virtual – to be available at 100 Hz. Which means the calculations better be fast enough to keep up with that. Yeah, they’re not rocket science, but we’re talking tiny platforms drawing as little power as possible, making the burden non-trivial.

That power is lowered by implementing many of the fusion algorithms in hardware. They claim to be the lowest power, at least against microcontroller-based sensor hubs, with under 200 µA at 1.8 V, which is 360 µW. That would appear to be higher than QuickLogic’s claimed 250 µW (yes, that’s for their wearable version, but it’s the same hardware as the Kit Kat version – just different libraries), but it’s an order of magnitude less than what they show for Cortex-based hubs.

The other Kit Kat requirement they meet is that of “batching.” In and of itself, that term isn’t particularly helpful, since I can imagine a number of ways of batching sensor data. A conversation with PNI’s George Hsu clarified Google’s intent, and it wasn’t one of the scenario’s I had envisioned.

The idea is that the real sensors, from which all the virtual sensors are determined, should be buffered for some amount of time – like 10 s or so (there’s no hard spec on the time; it’s left to designers to do the right thing for their systems). If something goes wonky with the calculation and the application processor (AP) sees a sensor value that it finds suspect, it can actually go back to the original sensors, grab the historical raw data, and redo the calculations itself to confirm or correct the suspect values.

SENtral buffers five sensors: the accelerometer, the gyroscope (with and without bias correction) and the magnetometer (with and without offset correction). The buffer size is flexible; it uses RAM, and so the available RAM must be allocated between buffers and any other functions using the RAM.

Oh, and they go to pains to point out that this thing is small. (I’ve seen it; it’s small.)