editor's blog
Subscribe Now

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.)

SENtral-K_PNI_Sensor_red.jpg

Image courtesy PNI Sensor

 

You can find more in their announcement.

Leave a Reply

featured blogs
Jan 17, 2020
I once met Steve Wozniak, or he once met me (it's hard to remember the nitty-gritty details)....
Jan 17, 2020
[From the last episode: We saw how virtual memory helps resolve the differences between where a compiler thinks things will go in memory and the real memories in a real system.] We'€™ve talked a lot about memory '€“ different kinds of memory, cache memory, heap memory, vi...
Jan 16, 2020
While Samtec started as a connector company with a focus on two-piece, pin-and-socket board stacking systems, High-Speed Board Stacking connectors and High-Speed Cable Assemblies now make up a significant portion of our sales. To support development in this area, in December ...
Jan 16, 2020
Betting on Hydrogen-Powered Cars On-demand DRC within P&R cuts closure time in half for MaxLinear Functional Safety Verification For AV SoC Designs Accelerated With Advanced Tools Automating the pain out of clock domain crossing verification Mentor unpacks LVS and LVL iss...

Featured Video

RedFit IDC SKEDD Connector

Sponsored by Wurth Electronics and Mouser Electronics

Why attach a header connector to your PCB when you really don’t need one? If you’re plugging a ribbon cable into your board, particularly for a limited-use function such as provisioning, diagnostics, or testing, it can be costly and clunky to add a header connector to your BOM, and introduce yet another component to pick and place. Wouldn’t it be great if you could plug directly into your board with no connector required on the PCB side? In this episode of Chalk Talk, Amelia Dalton chats with Ben Arden from Wurth Electronics about Redfit, a slick new connector solution that plugs directly into standard via holes on your PCB.

Click here for more information about Wurth Electronics REDFIT IDC SKEDD Connector