posted by Dick Selwood
Two e-mails plopped in to the in-tray, both with the same time stamp
The first was headlined
ARM and Cadence Tape Out First 14nm FinFET Test Chip Targeting Samsung Process
Samsung and Synopsys collaborate to achieve first 14 nanometre FinFET tapeout
posted by Bryon Moyer
GPS is notoriously inaccurate when it comes to vertical positioning. And it disappears entirely inside buildings. So pressure sensors are used to help calculate vertical positioning.
The thing is, a pressure sensor decides your altitude based on the pressure of the air, so it must be comparing it to some baseline. The problem with that is that there is no firm baseline pressure: weather, as we all know, affects the air pressure.
That means that pressure is, first of all, a moving target. Secondly, we can never really know our absolute altitude, only relative.
I posed these questions in a conversation with the Bosch Sensortec team at the MEMS Executive Congress where they were discussing the upcoming release of their new pressure sensors. They talk about being able to handle absolute altitude, so the obvious question is, what about the weather?
There are two pieces to the answer. The first deals with the fact that the baseline pressure isn’t constant. However, compared to pressure changes due to typical motion, the weather pressure changes extremely slowly. (If it’s changing so fast that it could be confused with you moving around, then navigation error is the least of your problems.) From a signal standpoint, the pressure changes of interest can be extracted with a high-pass filter, at least conceptually. More simply, you can think of it as a differential-mode measurement, with actual weather pressure being a common-mode error that’s subtracted out.
That allows you to get a reasonably accurate measure of relative altitude, but what about absolute altitude? Now you need to compare yourself to a sea-level baseline, and that baseline does depend on the weather. Well, there’s no magic available on this. The Bosch Sensortec software can get the data necessary to correct for the current sea-level pressure from the internet. Given that external sanity check, a pressure sensor can provide absolute altitude.
There are a couple other “faster-twitch” effects that can confuse pressure interpretation. The first is simply the fact that some buildings or rooms may have higher or lower air pressure based on the air conditioning or intentional implementation of things like positive pressure for a clean room. Even just opening a door can send a pressure surge. These effects won’t be eliminated or “de-convoluted” in the same way that weather impacts can be. Instead, the pressure data must be fused with other data to decide whether the pressure change reflects a change in altitude. Specifically, if an inertial sensor shows no vertical motion, then the pressure change can be “ignored” (although now it becomes the new baseline).
Pressure measurements also depend on temperature: a local temperature change can register as a pressure change when in fact the pressure didn’t change. Good temperature compensation is required (which is essentially data fusion between a thermometer and a pressure sensor); a pressure sensor less affected by temperature (as is claimed by Bosch Sensortec for their new BMP280) can also help.
posted by Bryon Moyer
It’s always struck me that there seem to be two critical elements to sensor fusion. There’s the part that can be resolved with math – for instance, compensating a magnetometer reading to account for the tilt as measured by an accelerometer – and then there’s the heuristic part. The latter deals with, for example, deciding that your gyro reading makes no sense and deferring to the compass instead to give you a heading. And while the math in the first part is more or less universal for all players, the heuristics would provide more of an opportunity for differentiation.
In a conversation at the recent MEMS Executive Congress, Movea’s Bryan Hoadley noted that there’s actually more to it than that. First of all, I should note that they’re touting the phrase “data fusion” rather than just “simple” sensor fusion. That would partly be due to the fact that they’re trying to raise the level of abstraction far above simple low-level fusion (as indicated by their periodic table and the fact that they’re doing analysis on running gaits and tennis serves), but also because, in many cases, data is included that doesn’t come from a sensor.
The classic example of that would be a navigation algorithm that not only uses IMU data, but also GPS or even speedometer data. (OK, I guess a speedometer is a sensor, albeit a pedestrian one… or… wait, no, a pedometer would be pedestrian… GPS? That’s less obvious.) Add map data and now you’re unquestionably fusing more than sensor data. You’re fusing data, some of which comes from sensors.
There’s one other element that comes along with this, according to Mr. Hoadley. It may sound trivial or inconsequential, but it matters, and it’s kind of like taking a look back into the kitchen of your favorite gourmet restaurant: it’s way less glamorous than the dining room. In addition to the math and the heuristics are the logistics of managing all the data and the data formats correctly and efficiently.
(Reminds me of the college programming project where I took the core assignment and simply added some I/O to it that wasn’t required. A couple ill-conceived all-nighters later and my code was 10% algorithmic stuff that mattered and 90% crap for getting data in and out. Which was worth, like, 3% extra in bonus credit. My first lesson in ROI.)
The point being, there’s more to the cooking than creating pretty stacks of elegant food (which will topple when the first fork hits it); there’s lots of boring, mundane food prep.
I’ve actually asked the question before as to whether these data formats could be simplified by any sorts of standards or unification; it’s one area where there doesn’t seem to be enough pain to worry. Either that, or the early movers have already solved the problem themselves and the chaos now acts as an entry barrier to others.