Hacker News new | past | comments | ask | show | jobs | submit login
iPhone 6: Comparing InvenSense and Bosch Accelerometers (eetimes.com)
68 points by vishalchandra on Sept 26, 2014 | hide | past | favorite | 12 comments



INVN was my former employer (~2013), so I'm quite familiar with the details of both of these chips. I'm not sure just how much I am allowed to talk about these parts, but imo the general consensus regarding power consumption being the killer feature that got Bosch the secondary accelerometer socket win seems correct to me. The likely accel only features are screen orientation, pedometer, and activity recognition, as the articles suggest. (I personally don't think that the 1ms vs 20ms start-up time matters much though)

Also, (a) ST microelectronics parts always had quality issues so I'm not surprised that they lost the socket to Bosch, and (b) I expect Bosch to be selling the BMA280 at cost or even at a loss. Bosch was a late entrant to the consumer electronics accel/gyro world, and has always been keen on price dumping to win sockets and market share.

edit: the more I think about this, the more I think that this is a situation where ST was the only loser. They had both the accel and gyro sockets before, but essentially lost the gyro socket to INVN and accel socket to Bosch. The integrated accel in the MPU-6700 is more of an add-on feature for low power on-chip sensor fusion that was not capable with the ST solution that was previously used (the DMP in the 6700 pre-dates the Apple M7 chip that was touted for low power activity tracking usage, but given that Apple has the M7, I'm not sure how much of its capabilities are being used. My guess would be that it is only the on-chip 6-axis SF that they are using). The ST socket was simply taken by Bosch.


http://www.chipworks.com/en/technical-competitive-analysis/r... is the source URL, the EETimes article is a repost


Civil engineering grad student here, BMA280 are much more stable and low noise than other sensor out there it features noise density of 120 μg/√Hz. Not sure about MPU-6700 but MPU-6500 is 250µg/√Hz. In my research on using consumer MEMS sensor to measure inclination, 16-bit resolution on MPU-6500 does not help a lot if the noise is much higher.


The Invensense has an autonomous mode (on Android devices it can count steps without bothering the host CPU) -- does the Bosch do this too?

Apple have a separate Cortex-M3 which is branded as the "M7" or "M8" motion processor. Is this what they use for step counting when the A8 is suspended? Why not use the Invensense for that? Is the M8 + Bosch less power?


>The Invensense has an autonomous mode (on Android devices it can count steps without bothering the host CPU) -- does the Bosch do this too?

IIRC there are accels that have a built in step counter (via hardware circuitry). I do not recall if Bosch has this, but the problem is that because it is a hardcoded hardware feature of the chip, it cannot be altered for customers. Apple NEVER accepts software/algoriths from its vendors. Bosch may be willing to redesign the chip with a step counter algorithm that Apple uses, but Apple would not share this with Bosch. Thus it is likely that the step counter is run on the M8 + BMA280.

They are unlikely to use the INVN autonomous step counter algorithm either. Whether the M8 + BMA280 is lower power than the MPU-6700 is something that is (a) unknowable, because we don't know the M8 specs, and (b) moot, because Apple would never use a 3rd party activity detection algorithm.


Interesting -- I thought someone with deep enough pockets could write their own DMP code for the IMVN part.

I'm sure the Android Wear devices (which mostly use the MPU-6500) must use the DMP to detect when to power on (they can't keep a Cortex-A7 juiced up just to look at gyro/accelerometer numbers), and IMVN didn't have anything like that publicly advertised a few months ago (I haven't looked more recently, and haven't inspected the Android Wear ROMs yet).


A pipe dream here would be to use both accelerometers at the same time and filter out much of the random noise resulting in much smoother accelerometer readings that could be used to calculate displacement.

(goes off and downloads Apple CoreMotion samples to see if they do this already)


If you mix a good quality accelerometer with a low quality one you get worse quality than the high quality alone.

The main problem that accelerometer have is that they are lineal sensors while human beings or animals use logarithmic ones.

What this means in practice is that it is very easy to saturate a sensor. You have sensors of 1, 2 or 3 maximun gs(gravity vectors of acceleration) while sudden movements could be bigger than that creating "out of range" samples.

What they probably do is use different scales for both accelerometers, giving them "HDR acceleration". E.g the low quality one at 10gs and the high quality at 2-3.


So that 1Hz is causing rotation lag.


I highly doubt that the INVN accelerometer is being used for screen rotation. It is most likely the Bosch accel.

Furthermore, otation lag is typically intentionally added by the OEM as a usability feature is order to avoid flipping the screen orientation overly rapidly. Different OEMs will have different lag and sensitivity (ie angle detection thresholds) because their respective thoughts on ideal usability can differ dramatically.


No, the lag is waiting for the rotation to stop before starting the animation.

If the screen is on then the power drain from the accelerometer running as fast as it can is tiny anyway.


[deleted]


1 Hz is one update per second, not one update per millisecond.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: