- Product Description
BHI160
The BHI160 is a small, low-power smart-hub with an integrated three axis gyroscope plus an integrated three axis accelerometer plus a programmable microcontroller. Containing pre-installed software and specific algorithms for activity recognition it is specifically designed to enable always-on motion sensing. It perfectly matches the requirements of smartphones, wearables or any other application which demands highly accurate, real-time motion data at very low power consumption. The device integrates our best-in-class 6-axis IMU (BMI160) with an MCU – the new Bosch Sensortec Fuser core. It is bringing you the full Android sensor stack inside your devices – even without having an Android OS or an Android environment. Combining this with the built in computing power and the highly configurable on-board memory the BHI160 offers you a low power solution for motion sensing and data processing. Software included! Programmable! Extendable!
Applications
- Activity recognition of standing, walking, running, biking or in vehicle
- Step-counting, Indoor navigation and PDR
- HMI interfaces incl. gesture detection of motion, tilt, pickup, wake up, glance or other gestures for wearables
- Augmented reality, immersive gaming and tilt-compensated eCcompass
- Full 9DoF data fusion for highly accurate 3D orientation, quaternions, Euler angles, etc.
Virtual reality to touch
Manus Virtual reality gloves utilize BHI160 to integrate your hands with the virtual world
More information about Manus VR
Watch the video about the Manus VR application for astronauts
Mobile Applications
Would you like to check an altitude on a map and plan the the best route or check the local weather forecast for your next hike? Are you monitoring your daily sports acitivities with your smartphone? These and many more outdoor applications are enabled by MEMS sensors. These new and advanced devices will even help you to find your car in a public parking garage.
Other sensors in the same category
BHA250
The BHA250 is a small, low-power smart-hub with an integrated three axis accelerometer plus a programmable microcontroller. Containing pre-installed software and algorithms for activity recognition it is specifically designed to enable always-on motion sensing. It perfectly matches smartphones, wearables or any other application which requires highly accurate, real-time motion data at very low power consumption.
- Technical details
Technical data BHI160 Package dimension 3.0 × 3.0 × 0.95 mm³ Temperature ranges -40 °C ...+85 °C Supply voltage (VDDI0)
Supply voltage (VDD)1.2 V … 3.6 V
1.71 V ... 3.6 VMicrocontroller
Bosch Sensortec "Fuser Core"32-bit floating-point ARC EM4 MCU running at 10 MHz
1.6 DMIPS/MHz performance, 3.41 CoreMarks/MHz
96 kByte ROM, 48 kByte shared RAM for FIFO, features & extension
optimized for ultra-low power sensor data fusionTyp. current consumption
- Full 9DoF Fusion @100 Hz ODR1
- Hub+IMU @100 Hz ODR
- Hub+Gyro @100 Hz ODR
- Hub+Acc @100 Hz ODR
- Activity recognition
- Significant motion
- Step detector
- Suspend mode
1,6 mA
1,2 mA
1 mA
310 μA
150 μA
128 μA
131 μA
11 μASensor Fusion Performance
- Static accuracy
- Dynamic accuracy
- Calibration time1
- Orientation stabilization time
- Step counting error
- Activity recognition accuracy
[Head., Pitch, Roll] = 2, 2, 2, degrees
[Head., Pitch, Roll] = 7, 2, 2, degrees
<1 second
0.2 seconds
<5%3
Precision: 85...97%4 Recall: 83...95%4Implemented Sensor Types2
with integrated IMU onlyAccelerometer, Gravity, Linear acceleration,
Gyroscope, Gyroscope uncalibrated, Game rotation vector, Step counter,
Step detector, Significant motion, Tilt detector, Pickup gesture, Wake up gesture,
Glance gesture, Activity recognition of standing, running, biking, in vehicleImplemented Sensor Types2 with attached
magnetometerGeomagnetic field, Magnetic field uncalibrated, Orientation vector, Rotation vector, Geomagnetic
rotation vector
- Downloads
Type of document Download Flyer BST-BHI160-FL000-01 Datasheet BST-BHI160-DS000-01 Handling, Soldering & Mounting Instructions BST-BHy-HS000-00 Shuttle board flyer BST-BHI160-FL023-01 Shipment Packaging Details BST-BHI160-SP000-00 Driver, MCU solution & Code examples
MCU Driver Porting Guide
Interfacing Reference Code from Generic DriverDownload Link
BST-BHy1-SD001-00
BST-BHy1-SD002-00Firmware
Quickstart GuideDownload Link
BST-BHI160-AN002-00Reference Boards & Reference Designs Microchip ULPDC; Ultra Low Power Connected Demonstrator
Highlights: BTLC1000 MR110CA module,
SAML21G18B, BHI160 & BME280 on board,
ARM Cortex M0+ MCU, BLE, ULP in sensor
fusion processing from BHI160 fuser core
Target Markets: IoT, Wearables, Smart Home,
Motion and Fitness tracking, Other low power
motion based applicationslink
Press releaseADVANTECH M2.COM IoT Platform
Highlights: Open standard sensor platform,
BHI160 & BNO055 on board, ARM based embedded processing,
Embracing MBED OS and open source SW platform for fast TTM,
Driving for defining relevant standardized interfaces
for ease of connectivity and interoperability
Target Markets: IoT, Smart Citylink - Product FAQ
This is a product specific FAQ for Sensor Hubs, the general Bosch Sensortec FAQ can be found here
Hardware
Questions Answers Q1: When the BHy is in suspend mode, are its GPIOx pins powered? If a GPIO pin is programed to output high, will the pin output be high even when BHI160 is in suspend mode (with all sensors are disabled)? Yes. As tested, when GPIO1, 2, 3 were set to output high, the GPIOs output kept high during all sensors were both enabled and disabled. So the GPIO pins can hold high when all sensors are disabled. Q2: Why does the current consumption of BHy samples seem higher than normal? For example, when GPIO1, 2, 3 are set to high output, ~280uA current is consumed even when no sensor is enabled. This leakage current is probably induced by the PD resistors when the GPIO pins are set to output high. Actually, there are two places that users can configure the PUPD states of a GPIO: one is in the ‘.cfg’ file code, and another is in the RAM patch code. So please check both and make sure the PD/PU (or both) resistors are disabled when you want to set the GPIO output high, low or toggling. Q3: Could you explain how to configure the GPIO in the cfg file? Below example shows a configure section of a .cfg file. The line with blue color is the place for GPIO configuration.
#Global Configuration
irq,6
pull,down,down,down,down,down,down,down,none
noexec,0
upload-speed,400
fifo,50.00
For example, if you want to enable GPIO1 PD and GPIO2 PU with all others disabled, you can modify that line to below:
modified line(enable GPIO PD, GPIO2 PU, all other GPIOS’ disabled, ‘pull’ is the keyword)
pull,none,down,up,none none,none,none,noneQ4: Is the physical sensor status of ACC is power down when HW step counter is enabled? Why? Yes. Some physical sensors can be powered separately from ACC sensor in driver, such as HW step counter. So when such sensor is enabled, the physical ACC sensor remains power down. This function is used for debugging purpose. Q5: What is the speed range of I2C the BHy sensors can support? 100KHz, 400KHz, 1MHz I2C speed are supported and were tested on U7183-sensor I2C bus. Q6: I got a waveform form customer HW team about BHA250. There was a drop pulse on SDA after powering up, which was coming from other device on the I2C bus. Does this drop pulse on SDA influence the normal operation of BHy? No, because the pulse width is ~2us, which is large enough for the BHy I2C controller to detect a START condition and then a STOP condition. So after the detection of STOP condition, the BHy considers the I2C bus is released and return back to IDLE and normal status.
Q7: When testing the current of a BHy mounted on shuttle board connecting to APP2.0 board platform, why is the current figure is higher than expected data released by V&V team & PM? This is because the BHy was running under different conditions.
First, In V&V tests, the test setup was based on CLCC phones, in which the BHy (MCU + BMI / BMA) is working at 1.8V and the AP acts as a host of BHy. Moreover, V&V team normally tests the current of U7183 (MCU) and sensor(s) (BMI or BMA or Mag sensor) separately.
Below table is an example of the current test results released by V&V team. Please note that the current is similar when tests with BHy sample (compared to U7183 + BMI / BMA):
Note1: Use FASTEST ODR = 200Hz when applicable; for some virtual sensors Output Date Rate(ODR) is not applicable, i.e. step counter, significant motion sensor, AR, Tilt, etc.
Second, there are some differences between CLCC phone tests and APP2.0 board + BHY shuttle:
1. The APP board by default enables the internal pull-down resistors (~100Kohms) on all MultIO pins. This draws some leakage current from INT pin of BHy when INT is output High. The leakage current is around 33uA (3.3V / 100Kohm). Therefore, the idle current (after powering up) of BHy shuttle is around 42uA, including 8uA from BHy sample itself.
2. The APP2.0 board has fixed 3.3V power supply, while it is 1.8V in CLCC phone. The higher voltage level causes higher current consumption.
3. Please switch off all other Mag sensors on shuttle board and reserve the only one you want, or switch off all Mag sensors to avoid unexpected current leakage during tests.
Current consumption test on BHI160 sample
Test setup:
APP2.0 board + BHI160 shuttle board + DD2.0(UI) or
APP1.0 board + BHI160 shuttle board + Python scripts
Current consumption over different voltage of BHI160
Test setup: APP1.0 board + BHI160 shuttle board + Python scripts
Software
Questions Answers Q1: BHA250 has 3 GPIO pins. All of these GPIOs can be detected interrupt from secondary interfaced sensor, is this correct? For BHA250, there are GPIOs below:
RSV1(GPIO0) dedicated for INT1_bma2x2
GPIO1 shared with INT2_bma2x2, output LOW during powering up until downloading patch. Be careful to connect external sensor
GPIO2 can be freely used, can be configure as input/output/interrupt
GPIO6(INT) dedicated for INT to host, not recommend for other usage
SA_GPIO7 share with SA0(I2C address selection), better short to GND
From the list above, only 2 GPIOs(GPIO1, GPIO2) can be used as external interrupt;
And for GPIO1, we should check further the default status of the INT pin of connected external sensor.Q2: How do you configure BHA250 interrupt setting? Is there a document for this?
For example, how to set which GPIO pin, how to set detect method (edge or level), how to set default level (active high or low).We can specify GPIO pin in board configuration file.
#Physical Drivers
#DriverID,Addr,GPIO,Cal0,Cal1,Cal2,Cal3,Cal4,Cal5,Cal6,Cal7,Cal8,Off0,Off1,Off2,Range
m11,16,-, 0,-1, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0
a48,105,0, 1, 0, 0, 0,-1, 0, 0, 0,-1, 0, 0, 0, 0
g49,105,-, 1, 0, 0, 0,-1, 0, 0, 0,-1, 0, 0, 0, 0
Please find the GPIO configuration in red. One special case is “-“. We specify “-“ when no interrupt is needed by this physical driver.
Currently the only supported interrupt mode is rising edge (Active high) for secondary sensors.Q3: What are the possible side effects if watermark if NON-WAKEUP FIFO is set to very high level, say >90%? Fuser core transfers the wakeup FIFO before the non-wakeup FIFO. When the watermark is very large, the non-wakeup FIFO can overflow even if the wakeup FIFO did not (since data is still accumulating in both FIFOs during the transfer).
If the non-wakeup FIFO overflow meta event is enabled, fuser core clears the count of discarded bytes as soon as it places the overflow meta event in the FIFO. In this case, everything works as expected.
But, if the non-wakeup FIFO overflow meta event is disabled, Fuser core does not clear the count of discarded bytes until host transfer ends. Fuser core clears it later, after checking to see if watermarks is passed again.
Here is a limitation in current design: if the discarded bytes count is non-zero, even if the watermark is not exceeded, fuser core assumes (incorrectly) that overflow must have happened. Because of this, we may be able to see following FIFO data output example, which is accepted for GEN1.
The solution is to simply enable non-wakeup FIFO overflow meta event.
<6>[ 6282.760293] [D]<7>BHI<631>irq_work_func entry, timestamp: 1421139992586049
<6>[ 6282.761138] [D]<7>BHI<540>Fifo length: 21908
<6>[ 6283.297812] [D]<7>BHI<631>irq_work_func entry, timestamp: 1421139993112048
<6>[ 6283.298304] [D]<7>BHI<540>Fifo length: 2727
<6>[ 6287.220066] [D]<7>BHI<631>irq_work_func entry, timestamp: 1421139997045774
<6>[ 6287.221365] [D]<7>BHI<540>Fifo length: 21908
<6>[ 6287.758927] [D]<7>BHI<631>irq_work_func entry, timestamp: 1421139997570398
<6>[ 6287.759426] [D]<7>BHI<540>Fifo length: 2727
Q4: How to swab the FW content during FW download
Q5: How Axis remapping is done for BHy? There are several ways to adjust axis mapping:
Change setting in board config file and then re-compile;
Reconfigure ELF file;
Modify axis mapping at run-time.
Axis remapping data is called as “Orientation Matrix” inside of fuser core, and is stored as part of “Physical Sensor Information”.
The calibration matrix is output in the same order as the elements are listed in the board .cfg file used to generate a firmware image, described in the U7183 Application Note 007 Programming Guide section 6.4, where each matrix element is stored in successive nibbles.
For example, if the board .cfg file contains:
#DriverID,Addr,GPIO,C0,C1,C2,C3,C4,C5,C6,C7,C8,Off0,Off1,Off2,Range
a9, 24, 3, 1, 0, 0, 0, -1, 0, 0, 0, -1, 0, 0, 0, 0
Or, if the stuffelf utility were used to generate the .fw file using the command line:
stuffelf outerloop.elf –a -d24 -p3 -c1,0,0,0,-1,0,0,0,-1
Then bytes 11-15 of the Physical Sensor Information structure would be:
Byte 11: 01 (hexadecimal)
Byte 12: 00
Byte 13: 0F
Byte 14: 00
Byte 15:0F
The matrix is used to correct the orientation of physical sensor axes to match the required ENU (east north up) orientation required by Android. The calculation is performed as:
Reference code is uploaded https://inside-ilm.bosch.com/irj/go/nui/sid/20055aba-64bf-3310-c480-9ee589d6e59bQ6: How to interpret BHy FIFO? Is there an example? Here is a sample FIFO data:
FC C1 40 01 51 01 CC 0C F3 1C 00 0B 69 09 A6 F7 77 DB 04 33 22 02 14 60 14 38 F7 BC DF 9E 32 88 08 03 52 19 FA F7 D2 00 03
We can devide the FIFO data into the following frames:
Q7: What is the recommended I2C bandwidth between BHy and AP? The recommended I2C bandwidth is 800K.
In case I2C bandwidth is lower (say, 400K), I2C may be the blocker in data transfer between BHy and AP, in case some 200hz virtual sensors are running and BSX_A/B/C raw data are enabled in the background as well.
The phenomenon could be unsmooth virtual sensor outputs in SensorList or 3DCompass or PhotoSafari, etc.Q8: Why is the Accel virtual sensor enabled by default in some cases Most probably the virtual sensor is enabled by Android Location service. The setting must be modified to disable it. Q9: Compilation is broken after make clean, how can this be fixed? Full SDK supports make clean, but the Customer SDK does not. Make clean will delete object that are necessary for the linking process. Please start from a new fresh SDK and copy over your changes. Q10: “ERROR: no driver in firmware” after changing the driver ID, what to do? There may still be a compiled version with the old driver ID. Delete the /sym and /obj folders when changing the driver ID in the driver.config file. Q11: What is the size limit for a sensor event data in the FIFO? In host interface the maximum size is 17 for BSX_A/B/C virtual sensors. The maximum size is 17 bytes, and it is a hard limit. Q12: How to move global variables from data RAM(16KBytes) to code RAM(32KBytes)? Unsigned char __attribute__ ((section (".rodata"))) test[3*1024]; - Order
