Questions
Type
Answers
What is BME680
DS
BME680 is a metal-oxide based chemical sensor. The sensor output is created by interaction of volatile organic compounds (VOCs) with the sensitive layer of BME680. As a raw signal, BME680 will output resistance values and its changes due to varying VOC concentrations (the higher the concentration of reducing VOCs, the lower the resistance and vice versa).metal oxide-based sensors such as BME680 can distinguish between reducing (decreasing sensor resistance) and oxidizing (increasing sensor resistance) environments. If strongly oxidizing conditions are present (e.g. chlorine cleaner, nitrous oxides from exhaust gas, higher concentrations of ozone), this may lead to wrong readout of BME since it may output “clean” air in terms of the algorithm where there is none.
What is BME688
DS
BME688 is the first gas sensor with Artificial Intelligence (AI) and integrated high-linearity and high- accuracy pressure, humidity and temperature sensors. It is housed in a robust yet compact 3.0 x 3.0 x 0.9 mm^3 package and especially developed for mobile & connected applications where size and low power consumption are critical requirements. The gas sensor can detect Volatile Organic Compounds, volatile sulfur compounds and other gases such as carbon monoxide and hydrogen in the part per billion range.
What is BME690
DS
The BME690 is the gas sensor with Artificial Intelligence (AI) and integrated high-linearity and high-accuracy pressure, humidity and temperature sensors. It is housed in a robust yet compact 3.0 x 3.0 x 0.9 mm³ package and especially developed for mobile & connected applications where size and low power consumption are critical requirements. The BME690 is more robust to previous products and can be used in high condensation applications. The gas sensor can detect Volatile Organic Compounds (VOCs), volatile sulfur compounds (VSCs) and other gases such as carbon monoxide and hydrogen.
What’s the difference between BME680 and BME688
DS
Additionally to all features of BME680, the BME688 has a gas scanner function. In standard configuration, the presence of VSCs is being detected as indicator for e.g. bacteria growth. And the gas scanner can be customized with respect to sensitivity, selectivity, data rate and power consumption as well, The BME AI-Studio tool enables customers to train the BME688 gas scanner on their specific application, like in home applications, IoT products or Smart Home.
What’s the difference between BME688 and BME690
DS
Same as BME688, the BME690 has a gas scanner function. In standard configuration, the presence of VSCs is being detected as indicator for e.g. bacteria growth. And the gas scanner can be customized with respect to sensitivity, selectivity, data rate and power consumption as well. The BME AI-Studio tool enables customers to train the BME690 gas scanner on their specific application, like in home appliances, IoT products or Smart Home.
BME680, BME688 and BME690 have different impedances
DS
Low sensor (BME680) resistance value - selectable range: 178 ~ 12800000 Ohms
Low sensor (BME680) resistance value - operating range: 2000 ~ 2000000 Ohms
High sensor (BME688, BME690) resistance value - selectable range: 5865 ~ 102400000 Ohms
High sensor (BME688, BME690) resistance value - operating range: 100000 ~ 64000000 Ohms
Operating temperature for full performance for BME sensors
DS
0 ~ 65 ℃
Operating temperature ( data read-out possible) for BME sensors
DS
-40 ~ 85 ℃
What's the difference between selectable range and operating range for BME sensors
DS
Selectable range represents all possible values, while operating range represents the values for actual work.
Which gases were tested in HQ for BME sensors
DS
Here I listed some gases which were measured by HQ, includes min-max concentration.
The measured range of raw features about BME sensors
DS
For BME680:
Temperature: -40 ~ 85 deg C
Pressure: 30000 ~ 110000 Pa
Humidity: 0 ~ 100 %
Gas resistance: 170 ~ 13000000 Ohm (hardware: 178 ~ 12.8e6 Ohm)
For BME688/BME690:
The T/P/H are the same as BME680
Gas resistance: 5600 ~ 103000000 Ohm (hardware: 5865 ~ 102.4e6 Ohm)
Others Features are same:
IAQ: 0 ~ 500
Static IAQ: 0 ~ Max
CO2: 400 ~ Max ppm
bVOC: 0 ~ 1000 ppm (will be removed from BSEC 3.x)
How to evaluate bVoc/CO2 with IAQ?
DS
It’s recommended to buy some professional devices as references which can measure bVOC and CO2.
For CO2: Sometimes you will find there is a little difference between the reference device and BME output, as BME gives an equivalent CO2 output which is calculated based on the S-IAQ, which is not very accurate as the professional devices, but do not say it to the customer directly, we can change some words.
For bVoc: We can evaluate IAQ by bVOC, here I listed the two charts:
The first screenshot is for BSEC version 1480 and before versions, which regard IAQ-25 as ‘clean air’. (bVOC = 0.5ppm when the S-IAQ=25, bVOC = 15ppm when the S-IAQ=250)
The second screenshot is for after BSEC 1480 versions, which regards IAQ-50 as ‘clean air’. (bVOC = 0.5ppm when the S-IAQ=50, bVOC = 15ppm when the S-IAQ=250)
Usually bVoc can not indicate the real voc concentration in the environment, what showed it's just a reference to the customer, they can also adjust the relationship between bVoc and IAQ according to their environment.
In BSEC 3.x version, TVOC equivalent feature will instead of bVoc for BME690.
What’s the means by ‘burn-in’ and ‘run-in’? and How long time they will take?
DS
‘burn-in’ status means when you get a new sensor, which is a status in the first power-on status, so a sensor only has one ‘burn-in’ status in its life. And in software, we set 0, but it’s recommended to run the sensor for 24h on hardware. Make sure to give the sensor enough time to stabilize.
‘run-in’ status means a status in each power-on status. In software, we set many time about this status which depends on the power mode, here I listed the relation.
Power Mode
Run-in time
LP
5min
ULP
20min
CONT
5min
SCAN
1min
And you can observe the output ‘IAQ-accuracy’, it also shows finishing ‘burn-in’status if ‘iaq-accuracy’ changing from 0 to 1.
The fixed 'run-in' time only existed before BSEC 2.5.0.2 version, after that we have run in profiles to speed up the period for BME688 and BME690, why we do that is fixed time will cause some risks about s-t-s deviation.
However, 'run-in' time is still influenced by the last power-off time, here I list an example of 30mins power-off time for BME690 based on BSEC 3.2.1.0:
LP: ~2mins ULP: ~10mins
How can I distinguish between Operated Mode and Power Mode?
DS
Operated Mode only includes Forced Mode and Parallel Mode, heating is always on in Parallel Mode.
Power Mode includes LP, ULP, CONT, SCAN(HIGH PERFORMANCE), which determines the frequency at which the sensor outputs the data, so it will also influence the power consumption.
What’s more, the sensor works in Forced Mode when you set the Power Mode LP, ULP, CONT, and works in Parallel Mode when you set the Power Mode SCAN.
Why does my sensor continue to show saturation values during operation?
SW
Check which step the sensor at, and check if the temperature and duration of this step are enough or not, it’s recommended to change another Heater Profile to test it again.
Some old sensors will show the saturation value when the heating temperature is below 150℃.
Some customer are using the platforms which aren’t be involved in our generic released package, how can we support them.
SW
Contact with AE, and provide the compiler and compilation options.
IAQ is abnormal when the customer uses DD2.0 with BME688. (Delete)
SW
09/07/2023: Currently DD2.0 can only support BME680 to measure IAQ, which is not suitable for BME688, that means he needs to use EKB to measure IAQ when he wants to use BME688.
Temperature and Humidity are incorrect in BSEC mode in DD 2.0
SW
The DD tool has a compensation factor hardcoded, this was done as it is persisting since many years ago.
This is resulting in the BSEC performing a subtraction from the raw temperature/humidity value and providing a compensated temperature/humidity in BSEC mode.
Can I set the target temperature and duration? What’re the maximum values
SW
Yes, the customer can try their own better heating profiles.
Maximum value of the target temperature is 400 ℃, and maximum value of the duration is 4032ms.
Can I get IAQ without BSEC library?
SW
No, you can only get raw data of T/P/H/G without BSEC library, you need to use BSEC library if you want to output IAQ, some compensated values and gas estimation feature.
What’s the default temperature for ULP/LP/CONT in the library?
SW
No setting config file:
BME68X/ULP- Temperature: 400℃, Duration-heater-on: 1943 ms; BME690/ULP- Temperature: 400℃, Duration-heater-on: 1000 ms;
BME68X/LP- Temperature: 320℃, Duration-heater-on: 197 ms; BME690/LP- Temperature: 320℃, Duration-heater-on: 100 ms;
BME68X/CONT- Temperature: 320℃, Duration-heater-on: 900 ms; BME690/CONT- Temperature: 320℃, Duration-heater-on: 900 ms;
Setting default config file:
BME68X/ULP- Temperature: 400℃, Duration-heater-on: 1943 ms; BME690/ULP- Temperature: 400℃, Duration-heater-on: 1000 ms;
BME68X/LP- Temperature: 320℃, Duration-heater-on: 197 ms; BME690/LP- Temperature: 320℃, Duration-heater-on: 100 ms;
BME68X/CONT- Temperature: 320℃, Duration-heater-on: 900 ms; BME690/CONT- Temperature: 320℃, Duration-heater-on: 900 ms;
Does BSEC2 support BME680?
SW
Yes, you can change the subscriptions according to the datasheet.
Does BSEC3 support BME680, BME688 and BME690?
SW
BSEC 3.x only support both BME688 and BME690, but tvoc equivalent feature only be supported by BME690 in LP Mode, BSEC 3.x can not support BME680.
The sensor will show bad performance in low oxygen environment.
HW
BME series MOX sensors exhibit abnormal behavior in low-oxygen environments because their operation relies on oxygen molecules in the air forming adsorbed oxygen ions on the sensor surface, which react with target gases in redox reactions to produce changes in resistance. In low-oxygen conditions, the surface oxygen ions are insufficient, limiting the reaction and resulting in reduced sensitivity, delayed response, and even baseline drift.
What's the means by .bmeconfig, .config and .aiconfig files in AI_Studio, and how can I use it.
SW
The. bmeconfig file is a file that users need to copy to the SD card when collecting data (the board configuration used by EKB), which is the file exported after configuring the BME board using AI_Studio
The specific content is as follows: (Configure the HP and DC of each sensor on the board)
The. config and. aiconfig files are automatically generated after collecting data
. aiconfig means that when users need to connect an EKB board to Mobile AI_Studio, they need to copy it into the SD card
The things saved in the. config file are similar to the generated. c file array, which can be copied to the SD card along with. aiconfig when using Mobile AI_Studio
New Run-in conditioning for LP & ULP mode.
DS
BME690 in BSEC 3.2.1.0
BME688 in BSEC 2.6.1.0 and BSEC 3.2.1.0
We have handling instructions for BME690.
Are the handling and contamination‑control instructions for BME688 the same or different? Please highlight differences.
HS
With respect to contamination susceptibility and handling risks, BME690 and BME688 are equivalent.
What are the potential effects if a BME-series MOX sensor is touched by a human hand during assembly, and are they reversible?
HW
Finger Touch & Contamination
Two effects:
Short‑term, reversible: abnormal readings, response‑time/ noise changes due to residue from fingerprints. These typically recover with time or mild, proper handling.
Long‑term, irreversible: chemical poisoning or irreversible adsorption on the sensing layer, causing permanent performance drift.
Rule of thumb: prevention over cleaning. Avoid direct touch and keep solvents away from the gas inlet and sensing area whenever possible.
Is post-assembly cleaning allowed?
Which solvents and methods are approved?
How should minor fingerprints be handled?
Any drying or outgassing guidance?
HW
Post-assembly cleaning is allowed only if unavoidable.
Use ≥90% isopropyl alcohol (IPA) applied lightly with a lint-free wipe or swab. Wipe only the metal cap and its perimeter. Never soak or spray the device, and avoid any liquid entering the gas port.
For minor fingerprints, prefer passive recovery or clean, dry compressed air instead of using any liquid.
Ensure the device is completely dry before use to prevent solvent residue.
If cleaned with alcohol, does outgassing affect readings for 24–48 h?
What quarantining time do you recommend before end‑user use?
Our lead time is 5–7 days post‑assembly; is this sufficient?
HW
In low‑VOC conditions, BME688 response time can improve from ~30 s to ~15 s; however, heavy alcohol vapors can prolong recovery and destabilize readings.
Considering the sensor's ~30 min warm‑up and typical solvent off‑gassing behavior, isolate the device for 8–24 hours in well‑ventilated air after cleaning.
A 5–7‑day buffer between assembly and shipment normally satisfies this requirement if ventilation is ensured.
Which assembly materials are compatible (flux, adhesives, conformal coating)?
Are there any “do‑not‑use” chemistries?
Any additional precautions for MOX sensors?
HW
Use neutral or mildly alkaline fluxes, non-acidic adhesives, and VOC‑low conformal coatings that do not release corrosive byproducts. Avoid materials that can outgas acids, amines, or strong solvents near the sensor.
Avoid acetic-acid–releasing materials (e.g., acetoxy-cure silicones), strong amines, and other corrosive or reactive compounds. Acetic acid and similar chemicals can corrode or contaminate MOX sensors, leading to degraded performance or permanent damage.
Always apply adhesives, fluxes, or coatings away from the sensor’s gas port. Ensure proper curing and outgassing before operation. Avoid direct contact or overspray on sensitive surfaces.
What is the ESD handling class for BME688?
HW
BME688 has an ESD robustness of ±2 kV HBM. Proper ESD precautions should be followed when handling the sensor.
What is the Moisture Sensitivity Level (MSL) of BME688?
HW
BME688 is MSL 1, meaning it is not moisture-sensitive under standard storage conditions.
How should BME688 be stored?
HW
Long-term storage is acceptable at ≤30 °C / 85% RH. Prefer a dry, clean, non-corrosive atmosphere. Avoid direct sunlight, high temperature, and high humidity.
Is baking required before use?
HW
MSL1 parts generally do not require baking. If exposed to high humidity or improper storage, a 125 °C × 24 h bake is a common practice. Always align final bake conditions with the manufacturer’s guidance.
Is there a preferred sensor orientation on the PCB?
HW
Orient the sensor pins toward the PCB edge or an accessible area for routing and soldering. Ensure the top surface is exposed to ambient air and not shadowed by other components or traces.
Are there keep-out areas around the sensor?
HW
Keep the sensor away from strong heat sources (power resistors, high-power ICs) and EMI sources (inductors, transformers).
How should vent holes be designed?
HW
Provide vent holes beneath or around the sensor with a diameter ≥0.5 mm to allow free air exchange.
Are there guidelines for airflow channels?
HW
Keep ducts as straight as possible. If bends are required, use a radius ≥2× duct height. Add flow guides if needed to distribute airflow uniformly across the sensing area.
What is the purpose of burn-in for BME688?
HW
The primary purpose of burn-in is to stabilize sensor performance and improve consistency between sensors.
What is the semiconductor/chemistry rationale behind burn-in?
HW
The MOX element is exposed to high temperature during burn-in to:
Stabilize the microstructure of the metal oxide layer.
Stabilize surface states, ensuring consistent adsorption/desorption behavior.
Remove impurities and residues from fabrication or handling.
These steps reduce sensor drift, improve reproducibility, and ensure predictable response characteristics.
Can burn-in be performed at the factory or at the customer site?
HW
Burn-in can be performed in either location.
Factory burn-in: Controlled environment allows consistent temperature, clean air, and absence of interfering gases, ensuring uniform sensor stabilization. Risk is minimal if proper procedures are followed.
Customer-site burn-in: Environment may contain interfering gases (VOC, smoke, chemicals) that can alter sensor surface chemistry, cause drift, or reduce reproducibility. Maintaining consistent temperature and airflow is also more challenging.
What precautions are required during burn-in?
HW
Ensure the sensor is exposed to clean, interference-free air. Avoid gases or vapors that can adsorb on the MOX surface. Maintain proper temperature and airflow control throughout the burn-in period.
How “clean” must the environment be during burn-in?
HW
“Clean” means the air should not contain reactive or interfering gases, including tVOCs, silicides, alcohols, carbon monoxide, or other substances that may adsorb on or react with the sensor surface (even unusual compounds such as durian VOCs). Maintain normal indoor temperature and humidity with stable, moderate airflow. The sensor should not be sealed in a small box, as this would prevent proper heat dissipation.
How can cleanliness be quantified or monitored?
HW
While no absolute threshold exists, common practices include:
Measuring TVOC levels with a calibrated sensor; keep as low as practical.
Monitoring temperature and relative humidity for stability.
Ensuring consistent airflow without stagnant zones.
These measures help prevent adsorption of interfering gases and maintain reliable burn-in results.
What heater temperature/time profiles minimize burn‑in time while ensuring stability?
SW
It is necessary to operate the sensor in the same mode.
LP mode(IAQ ±15%±15): up to 7 days; qualitative 8 hours;
ULP mode(IAQ ±15%±15) up to 15 days; qualitative less than 1day;
Is burn‑in required only once for the product life, or after long storage/shock events?
HW
Burn‑in/Re‑conditioning
On first use, perform ≥8 hours of burn‑in.
After prolonged storage or mechanical shock, perform re‑conditioning.
Before routine operation, a ~10 min pre‑burn can help stabilize readings.
How do we know burn‑in is complete (e.g., ΔR/R stabilization, BSEC state convergence)?
HW
It is not always easy to determine when the stabilization is finished from field data, since usually no reproducible pulses occur in real-world condations; thus, aged BME690 sensors were used as reference and completion of stabilization considered to be the time when new and aged sensors behave similar(e.g. ±15% range of IAQ)
What unit‑to‑unit resistance variation (pre/post burn‑in) is normal?
HW
Resistance Distribution (Indicative)
Resistance depends on temperature, humidity, and gas composition. After burn‑in, values stabilize typically in the mega‑ohm to tens‑of‑mega‑ohm range.
Under stable lab conditions, a narrower spread such as 20–40 MΩ may be observed. Treat these as guidelines, not hard limits.
Recommended humidity/temperature and exposure controls during burn‑in to avoid biasing the baseline.
HW
Recommended Environment for Burn‑in
Humidity: while the measurable range is 0–100% RH, maintain 20–80% RH during burn‑in for stability.
Temperature: operating range is −40 to 85 °C; for burn‑in, target ~25 °C to avoid irreversible shifts.
Should we use BSEC “gas‑scanner/AI” vs custom heater control? Which BSEC version/configs fit H₂S/NH₃?
HW
There is no internal recommended gas configuration. Based on internal experience, HP-354 is more suitable for detecting H2S. AI_Studio supports 16 HP configuration files by default. Customers can select specific profiles based on actual performance or customize their own configuration files.
What are the achievable detection limits (LOD), linear/usable ranges for H₂S/NH₃ under the recommended profiles?
HW
0.1 ppm ~ 50 ppm NH3
100 ppb ~ 500 ppb H2S
What we measured in the lab, but it's not the limitation
How do typical home interferents affect H₂S/NH₃ readings?
Is there guidance for compensating for these interferents?
HW
Pet excreta, cleaning agents, and food residues may emit sulfur‑ or ammonia‑bearing compounds or VOCs, which can directly skew H₂S/NH₃ and total‑VOC readings.
Be aware that readings may be biased in the presence of the above interferents. Possible strategies include:
Sensor placement: locate sensors away from direct sources (litter boxes, cleaning areas, kitchens).
Data filtering: implement software routines to detect transient spikes associated with known interferents.
Calibration updates: periodic recalibration may help reduce long-term drift caused by persistent interfering gases.
What is the recommended compensation scheme for stable gas readings?
HW
A three-layer approach is recommended:
Environmental isolation
Physically shield the sensor from rapid changes in airflow, temperature, or humidity.
Real-time temperature/humidity correction
Apply real-time compensation using sensor readings of temperature and humidity to correct gas measurement output.
Dynamic baseline calibration
Combine hardware pre-conditioning and algorithmic optimization to adapt the baseline over time, compensating for drift or environmental effects.
This layered approach helps stabilize MOX sensor readings under varying temperature and humidity conditions.
How can we diagnose a clogged pinhole in dusty environments?
HW
Key telemetry indicators include:
Response time
Slower than a healthy reference by >30% under the same environmental conditions.
Noise level
Increased to ≥2× normal.
Baseline drift
Short-term drift exceeding 15% of the post-calibration baseline, with irregular fluctuations.
How should thresholds be used for maintenance decisions?
HW
Evaluate response time, noise, baseline drift, and sensitivity decay collectively. When one or more metrics exceed thresholds, maintenance is required. After cleaning or replacement, re-measure these metrics to confirm that performance has returned to acceptable levels.
How do different membranes (PTFE/ePTFE, pore size, thickness, oleophobic) affect sensitivity and response time for H₂S/NH₃?
HW
Protective membranes generally have a relatively low impact on MOX sensor performance, including response time and recovery time. Minor differences may exist due to thickness or pore structure, but typical PTFE/ePTFE membranes allow gas diffusion sufficient for accurate readings.
Are there recommended parts or vendors?
HW
Membranes should be chemically inert, mechanically stable, and compatible with H₂S/NH₃ gases. While no specific vendors are required, commercially available PTFE/ePTFE membranes from reputable suppliers are commonly used. Selection should prioritize thickness, pore size, and oleophobic treatment based on application constraints.
What behaviors should be expected immediately after minor finger contact?
HW
Short-term contact basically does not affect baseline drift, and may only temporarily influence the current reading.
How should the sensor be restored or cleaned safely?
HW
Passive recovery: Power off and place in clean air at 30–50% RH for approximately 2 hours.
Dry compressed air: Use ≤0.1 MPa, stand 15–20 cm from the gas port at an angle, 3-second blast ×2 with 5-second interval (total ≤6 s).
Do NOT use liquids on the gas port. Do not touch the port with swabs or tissue, to avoid fiber shedding.
Which heat profile is better?
SW
Currently, there is no gas-specific heat profile. AI Studio provides 16 preset heat profiles (HPs). Each data collection and training session supports up to 4 HPs. After training, users can check the prediction accuracy for each HP, and the one with the highest accuracy is considered the best-performing heat profile.
What is the expected lifetime of BME688 ?
How do accelerated stress tests relate to field lifetime?
HW
Lifetime is estimated based on accelerated storage and stress tests following JEDEC standards.
Accelerated stress tests such as High-Temperature Operating Life (HTOL) and Temperature Humidity Bias (THB) simulate long-term aging. If BME688 withstands >1,000 hours under these conditions, it is considered equivalent to ~10 years of normal field operation.
Is there any way to determine the degree of deterioration of the gas sensor?
How to track deterioration over time?
HW
Signs of sensor deterioration include:
Decrease in GasRaw value
The baseline GasRaw reading gradually decreases compared to a healthy sensor.
Slower or reduced IAQ response
IAQ and other derived gas indices rise more slowly and less sharply in response to the same gas concentration.
Longer recovery time
The time between the rise and fall of IAQ becomes longer, indicating slower sensor kinetics.
Maintain time-stamped records of GasRaw, IAQ, and other key sensor outputs under controlled conditions. Analyze trends in baseline, response amplitude, and recovery time to quantify degradation.
How can AI Studio differentiate between different gases and their concentrations?
What machine learning principle is applied?
SW
The differentiation relies on unique patterns in the sensor’s gas resistance:
Gas-induced resistance changes
Each gas or concentration produces distinct changes in BME688’s gas resistance, which may not be visible to the naked eye.
Supervised learning with ground truth
Users provide reference labels (ground truth) corresponding to the gas type and concentration.
Model training and inference
The AI model maps resistance patterns to the reference labels during training.
During testing, if a similar pattern occurs, the model outputs the predicted gas type and/or concentration.
This is a supervised machine learning approach, where the model learns to associate sensor signal patterns with labeled gas types/concentrations.
For a heat profile with 10 steps per cycle, does AI Studio check the resistance difference between gases (e.g., FA and Ethanol) at each step separately?
How does this relate to neural network operation?
SW
Not directly. AI Studio uses preprocessing followed by a neural network to analyze the data. The neural network can extract any relevant information from the 10 heater steps, including:
Differences between gases
Mean, variance, or other statistical features
Any patterns that map gas resistance to the reference label
It does not require step-by-step manual comparison; the network automatically learns the features needed for classification or regression.
Neural networks can learn complex mappings between input signals (heater step resistance) and outputs (gas type/concentration) from labeled data. You can refer to standard resources on how neural networks process multivariate time-series inputs for further understanding.
How does AI Studio use variance in each heat profile step to differentiate gases and concentrations?
How should rapid transitions between gases be handled?
Can slow transitions be used for training?
SW
The term “variance per step” usually refers to the signal fluctuations during a heat step. To distinguish different gases or ppm levels, there must be a measurable change in gas resistance.
If the gas changes quickly (fast transition in resistance), it is recommended not to use this period for training. The sensor may not detect the new gas immediately, but the model will detect it after the sensor stabilizes. This approach improves overall model performance.
Yes, if the resistance change from one gas to another occurs slowly, this period can be included for training. The model may detect gas changes more quickly, but it may also produce occasional false outputs after stabilization. This trades overall stability for faster response.
What is the minimal quantity of sensors recommended for gas training?
Any additional recommendations for sensor usage?
SW
Ideally, use as many sensors as possible within budget. With Bosch development kit boards, 2 boards provide 16 sensors, which is the minimum recommended number. If performance is insufficient, increase the number of sensors.
Use brand-new sensors that have completed burn-in.
Enable data augmentation in BME AI Studio to improve model robustness.
Can burn-in time be decreased by higher temperature or shorter duration?
SW
his is an open topic that has not yet been explored or verified for BME688. In general, higher temperature and longer heater-on time are conventionally used to reduce burn-in for MOX sensors, but no validated data exists for BME688 yet.
ISO16000-29 'Test methods for VOC detectors' document link
DS
EN_ISO_16000-29_2014-06.pdf.
What is manual calibration for TVOC equivalent in BSEC 3.2.1.0?
SW
In BSEC 3.2.1.0, the TVOC equivalent is by default calibrated to lab data without considering interfering gases. In real-world environments, other gases may affect readings, so the manual calibration API was provided. Users could:
Enable the API.
Calibrate TVOC to a reference concentration (e.g., 250 ppb) in the expected environment.
Disable the API to prevent deviation from the calibrated value.
Since TVOC (manual calibration) and IAQ (automatic calibration) are calibrated separately, differences between reported values could occur.
In BSEC 3.3.0, TVOC calibration was changed to automatic calibration, removing the need for a separate manual calibration step. This aligns TVOC calibration more closely with IAQ and reduces discrepancies between the two outputs.
Do we have any docs for quick calibration and slow calibration in TVOC feature in this release, and how long it will take to get the reliable output and the lowest s-t-s deviation output.
SW
The recommendation to customer is 22 days in field. By this time, TVOC would be calibrated and S2S would be least. We are not giving specific instructions for quick calibration as it is for development purpose.
Conditions that trigger a BSEC -2 error in the BSEC built-in algorithm
SW
The BSEC -2 error is triggered when one or more BME sensor input parameters exceed the allowable input limits specified by the BSEC algorithm.
(gas): High: 170.0 ~ 1.03E+8 Low: 170.0 ~ 1.32E+7
(temperature): -65.0 ~ 125.0
(humidity): 0.0 ~ 100.0
(pressure): 0.0 ~ 2.0E+6
Can we use the current PCB designed for the BME680/BME688 and upgrade it with the BME690 without any hardware changes?
HW
Yes, the BME690 is designed to be backward compatible with existing PCB layouts developed for the BME680 and BME688. In most cases, the BME690 can be mounted directly onto the existing hardware without requiring PCB modifications.
However, it is recommended to update to the latest software API version to ensure full support of the BME690 features and optimized signal processing. The updated API automatically detects the connected sensor variant and applies the appropriate configuration and compensation algorithms.
Is it necessary to actively force air into the BME sensors when taking measurements?
DS
No, active airflow is generally not required. Gas exchange occurs naturally through diffusion. Whenever the gas composition around the BME sensor changes, a concentration gradient is created, causing gases to diffuse into and out of the sensor package.
Due to the compact sensor design and the very short distance between the package opening and the gas sensing element, the sensor responds to environmental gas changes within a few seconds under typical operating conditions.
How many measurements can be stored on the BME sensors?
DS
The BME sensor stores configuration information such as scan profiles, along with a limited amount of temporary measurement data in its internal buffer. In normal operation, the measurement data is continuously read out by the host microcontroller (MCU) connected to the sensor.
As a result, the practical storage capacity mainly depends on the available memory of the host system rather than the sensor itself. When using the Bosch sensor software library on the MCU, sensor data can be processed directly on the device, reducing the need to store large amounts of raw measurement data. In many applications, storing only the relevant processed output values is sufficient.
How much computing power is required to run the AI software? Can you provide examples of compatible MCUs?
SW
Training and optimizing AI models using Bosch AI-Studio requires a desktop or laptop computer with sufficient processing resources for data analysis and algorithm generation.
However, executing a trained algorithm on an embedded device requires only modest computing resources. Many commonly used microcontrollers are capable of running the sensor processing and AI inference in real time. Examples include the ESP8266, ESP32, and a wide range of ARM Cortex-M based MCUs.
The exact hardware requirements depend on the complexity of the application, sampling configuration, and system-level software architecture.
Can you please explain how the gas scanning functionality works?
SW
The BME gas sensor performs measurements under multiple operating conditions during a gas scan sequence. This is achieved by dynamically controlling internal sensor parameters, such as the heater temperature profile, which changes the sensor sensitivity to different gases and volatile compounds over time.
By combining the measurement responses from these different operating points, the sensor can generate characteristic signal patterns — often referred to as “fingerprints” — for specific gas mixtures or environmental conditions.
Using Bosch AI-Studio, developers can configure, optimize, and train custom scan profiles for their specific application requirements. This allows the system to improve selectivity and adapt the sensing behavior for use cases such as air quality monitoring, odor classification, or gas detection.
Does the BME sensor include integrated Flash or EEPROM memory?
SW
No. The BME sensor does not contain integrated Flash or EEPROM memory for long-term user data storage. Configuration data and measurement results are typically managed by the external host microcontroller (MCU) connected to the sensor.
After training an algorithm using data collected from multiple sensors, can the resulting model be deployed on a device using only a single BME sensor?
SW
Yes. Bosch AI-Studio can export the trained algorithm as a configuration file or configuration string that can be integrated into the Bosch sensor software running on a target device with a single BME690 sensor.
Once deployed, the device can locally execute the trained model and directly evaluate the gas scan data generated by the BME690 in real time. This enables compact and cost-efficient implementations without requiring multiple sensors during normal operation.
However, the achievable performance and robustness of the trained model may depend on factors such as sensor variation, environmental conditions, and the quality and diversity of the training data.
Which AI or neural network topology is used? Is the system based on neural networks or statistical pattern recognition?
SW
The current version of Bosch AI-Studio uses a neural network–based approach for gas pattern recognition. The software utilizes a predefined neural network architecture together with configurable training parameters and optimization methods, including the ADAM optimizer, for model training.
The generated models are designed to operate efficiently on embedded systems with limited computational resources while still enabling reliable classification of gas patterns and environmental conditions.
In addition, we explicitly encourages customers to develop and implement their own algorithms based on their specific application requirements. AI-Studio is designed as a flexible development tool that supports customization of models and workflows to enable application-specific optimization.
Is it possible to detect gases produced by burning network cables or electronic components?
DS
Yes, this can be a relevant application for the BME690. In scenarios where abnormal conditions occur in electrical systems or cabinets, gas emissions can often be an early indicator of faults or overheating.
Typically, two main situations can be distinguished:
Overheating or material degradation
When insulation materials or other components are exposed to excessive heat or short circuits, they may begin to decompose or melt. This process leads to increased outgassing, often containing a mixture of volatile organic compounds (VOCs), including unburned hydrocarbons. These gas signatures can be detected by the BME sensor in a manner similar to how humans perceive odor.
Electrical arcing or flashovers
In cases of high voltage events, short circuits, or arcing, ozone (O₃) and other reactive gases can be generated. These have a distinct gas signature compared to thermal decomposition products and can also be detected by the BME sensor.
By analyzing these different gas patterns using appropriate algorithms, the sensor can potentially contribute to early detection of electrical faults and abnormal operating conditions.
Does the BME sensor detect combustible gases such as methane (CH₄) and propane (C₃H₈), as well as toxic gases like carbon monoxide (CO)?
DS
The BME sensor is sensitive to a broad range of gases, including many volatile organic compounds (VOCs) and various combustible and reducing gases. This includes many hydrocarbons (CₓHᵧ) and gases such as carbon monoxide (CO), which can be reflected in the overall gas pattern measured by the sensor.
Combustible gases are often categorized into methane (CH₄) and non-methane organic gases (NMOG). Methane is a special case, as it is chemically less reactive and typically requires specific sensing materials or catalysts for strong direct response. As a result, the BME sensor is not optimized for strong direct sensitivity to methane, and detection performance for methane alone may be limited, especially at lower concentrations.
However, in many real-world applications, methane is not present in isolation but occurs alongside other gases such as VOCs or sulfur-containing compounds, which the BME sensor can detect effectively. In such scenarios, gas mixture patterns can still provide useful information for classification and anomaly detection when combined with appropriate algorithms.
For application-specific evaluation, testing the sensor under real operating conditions is recommended to determine suitability and achievable performance.
Is the BME sensor certified as a medical sensor?
DS
No. The BME sensor is not certified as a medical sensor at the component level. Sensor components are typically qualified according to standards applicable to consumer electronics, such as JEDEC requirements, rather than medical device regulations.
Medical certification, where required, is carried out at the device or system level by the manufacturer of the final product, as certification depends on the complete system design, intended use, and regulatory classification.
In general, customers are responsible for evaluating and ensuring compliance of their end products within the relevant application domain and regulatory framework. From a system perspective, the benefit of pre-certified individual sensor components is therefore limited in most cases.
Is it possible to detect drugs or explosive materials using the BME sensor?
DS
Bosch Sensortec does not provide validated use cases or application experience for the detection of drugs or explosive materials with the BME sensor. The sensor is designed for general gas sensing applications and the detection of volatile gas patterns in air quality and environmental monitoring contexts.
In principle, the BME sensor can measure changes in gas composition, and its response to different volatile compounds can be evaluated in customer-specific development and testing environments. However, Bosch does not provide performance specifications, calibration data, or application guidance for drug or explosive detection use cases.
Customers may conduct their own evaluation using development hardware to determine suitability for their specific application, subject to applicable laws and regulations.
How can I determine whether the gases in my application can be measured with the BME sensor?
DS
A key purpose of Bosch AI-Studio is to enable exactly this type of evaluation in real-world conditions. Instead of requiring detailed prior knowledge about individual target gases or their concentrations, developers can directly test the sensor in their actual application environment.
Traditionally, gas sensing development required extensive laboratory testing with individual gases in controlled environments, such as synthetic air. While such tests can provide useful baseline information, they often do not fully represent real-world conditions, where multiple gases and environmental influences are present simultaneously.
With the BME sensors and Bosch AI-Studio, developers can collect data directly in the target application, build and evaluate models under real operating conditions, and iteratively optimize performance based on real-world gas mixtures and dynamics. This approach helps bridge the gap between laboratory characterization and practical field performance.
Are over-the-air (OTA) updates possible to enable detection of additional gases or substances in the future?
SW
Yes. The system supports updating sensor behavior through software-based configuration. The sensor’s measurement behavior is defined by software parameters rather than being permanently fixed in hardware.
When using Bosch AI-Studio, a trained application results in a configuration package (including model parameters and scan profile settings). This package can be deployed to field devices via over-the-air update mechanisms, as it is typically small in size and designed for efficient transfer.
Once the updated configuration is loaded into the Bosch sensor software on the device, the BME sensor operates according to the new scan profile and model behavior, enabling adaptation to new application requirements without requiring hardware changes.
Why does the evaluation board use eight sensors?
HW
The development kit is designed to support flexible evaluation and optimization using Bosch AI-Studio. It allows developers to fine-tune key parameters such as performance, output data rate (ODR), and power consumption according to application-specific requirements.
By integrating eight BME sensors on a single evaluation board, the system enables parallel testing of multiple configurations under identical environmental conditions. This allows developers to compare different settings simultaneously, improving data quality and statistical reliability while significantly reducing overall development time.
Product Overview
The main characteristics of the BME680 are described below:
Key features
3.0 mm x 3.0 mm x 0.93 mm, metal lid LGA package
Digital interface I²C (up to 3.4 MHz) and SPI (3 and 4-wire, up to 10 MHz)
Supply voltage
VDD main supply voltage range: 1.71 V - 3.6 V
VDDIO interface voltage range: 1.2 V - 3.6 V
Current consumption
2.1 μA at 1 Hz humidity and temperature
3.1 μA at 1 Hz pressure and temperature
3.7 μA at 1 Hz humidity, pressure and temperature
0.09‒12 mA for p/h/T/gas depending on operation mode
0,15 μA in sleep mode
Operating range: -40 to +85 °C, 0 - 100% r.H., 300 - 1100 hPa
Individual humidity, pressure and gas sensors can be operated independently
RoHS compliant, halogen-free, MSL1
Furthermore here some performance parameters:
Key parameters for gas sensor
Response time (𝜏33−63%)
< 1 s (for new sensors)
Power consumption
< 0.1 mA in ultra-low power mode
Output data processing
direct indoor air quality (IAQ) index output
Key parameters for humidity sensor
Response time (𝜏0−63%)
~8 s
Accuracy tolerance
±3% r.H.
Hysteresis
±1.5% r.H.
Key parameters for temperature sensor
RMS Noise
0.12 Pa, equiv. to 1.7 cm
Offset temperature coefficient
±1.3 Pa/K, equiv. to ±10.9 cm at 1 °C temperature change
Available evaluation tools and software
To best evaluate the product from the BME68x faminly
COINES Desktop software
Bosch Sensortec Environmental Cluster (BSEC) Software
Application board 3.0
Sensor shuttle board
BME680 shuttle board.
Reference design
Figure 1 shows the complete schematic for a typical use case.
Figure 1: Mockup reference design
Bill of materials
Table 2 lists the bill of necessary materials.
Value
Part number
Qty
RefDes
Name
0.1uF
C0402
2
C1, C2
Capacitor
4.7 kΩ
R0402
2
R1, R2
Resistor
Table 2: Bill of materials
Layout recommendations
Landing Pattern
For the design of the landing pattern, the dimensions shown in Figure 2 are recommended. It is important to note that areas marked in red are exposed PCB metal pads.
In case of a solder mask defined (SMD) PCB process, the land dimensions should be defined by solder mask openings. The underlying metal pads are larger than these openings.
In case of a non-solder mask defined (NSMD) PCB process, the land dimensions should be defined in the metal layer. The mask openings are larger than these metal pads.
Figure 2: Recommended landing pattern (top view, in mm)
Typical Layout
Figure 3 shows the typical layout.
Figure 3: Typical layout
Manufacturing notes
Table 3 lists some recommendations for the manufacture.
Parameter
Value
PCB thickness
1.6mm
Solder paste type
3.0Ag/0.5Cu/Remain Sn
Paste mask stencil thickness
100um
Peak reflow temperature
260°C
Table 3: Manufacture recommendation
First power-on
After powering the sensor for the first time, the initial specs would be to test for communication with the device. This can be done simply by reading the chip identification code in the register 0xD0. See below for the expected values:
Device
Chip ID
BME680
0x61
Table 5: Chip ID of the BME68x product family.
Here is some sample code on how to perform this test, based on BME680, using the COINES software as the host.
/*! * @brief This internal API is used to initializes the bme680 sensor with default * settings like power mode and OSRS settings * * @param[in] void * * @return void * */
static void init_bme680(void)
{ int8_t rslt; rslt = bme680_init(&bme680Dev); if (rslt == BME680_OK) { printf("BME680 Initialization Success!\n"); printf("Chip ID 0x%x\n", bme680Dev.chip_id); fflush(stdout); } else { printf("Chip Initialization failure !\n"); fflush(stdout); exit(COINES_E_FAILURE); }
How to test the sensor’s functionality
The BME680 is a digital 4-in-1 sensor with gas, humidity, pressure and temperature measurement based on proven sensing principles. In order to verify the functionality of new sensors after soldering, an example self test code is available based on BME680 API.
The self-test starts by performing a soft reset of the device. After this, Chip-ID and trimming data are read and verified. Then temperature, pressure and humidity sensor signals are measured and compared against customisable plausibility limits. For Gas sensor the heater and gas sensor resistance are checked. For more information on self test please refer to the BME680 self test application note.
A sample code on how to perform this self-test for BME680 is available on Github.
https://github.com/BoschSensortec/BME680_driver/tree/master/Self test
Usage
The COINES installation provides sample code on how to turn on the sensor, configure it and read out the sensor data. it can be found under the installation directory on examples\c\bme680
Sample code
The COINES installation includes an example code for using BSEC library with BME680.
/*! * @brief Main Function where the execution getting started to test the code. * * @param[in] argc * @param[in] argv * * @return status * */
int main(int argc, char *argv[])
{ return_values_init ret_bsec; int16_t rslt; struct coines_board_info board_info; signal(SIGINT, ctrl_c_sig_handler); init_bme680_sensor_driver_interface(); rslt = coines_open_comm_intf(COINES_COMM_INTF_USB); if (rslt < 0) { printf("\n Unable to connect with Application Board ! \n" " 1. Check if the board is connected and powered on. \n" " 2. Check if Application Board USB driver is installed. \n" " 3. Check if Board is in use by another application. (Insufficient permissions to access USB) \n"); exit(rslt); } rslt = coines_get_board_info(&board_info); if (rslt == COINES_SUCCESS) { if (board_info.shuttle_id != BME680_SHUTTLE_ID) { printf("! Warning invalid sensor shuttle. This application will not support this sensor \r\n" "1.Check the sensor shuttle \r\n" "2.Reset the board \r\n"); exit(COINES_E_FAILURE); } } init_sensor_interface(); /* after sensor init introduce 200 msec sleep */ coines_delay_msec(200); init_bme680(); /* Call to the function which initializes the BSEC library * Switch on low-power mode and provide no temperature offset */ ret_bsec = bsec_iot_init(BSEC_SAMPLE_RATE_LP, 0.0f, bus_write, bus_read, sleep, state_load, config_load); if (ret_bsec.bme680_status) { /* Could not intialize BME680 */ return (int)ret_bsec.bme680_status; } else if (ret_bsec.bsec_status) { /* Could not intialize BSEC library */ return (int)ret_bsec.bsec_status; } /* Call to endless loop function which reads and processes data based on sensor settings */ /* State is saved every 10.000 samples, which means every 10.000 * 3 secs = 500 minutes */ bsec_iot_loop(sleep, get_timestamp_us, output_ready, state_save, 10000); return 0;
}
Further reads
BME680 datasheet
BME680 Self-Test Application Note
BME680 Handling, soldering & mounting instructions
The last few years have seen a remarkable increase in the number of use cases involving barometric pressure sensors in consumer electronics devices such as smartphones, tablets, wearable devices, and various home appliances. Barometric pressure sensors have been used for ambient air pressure measurement for several decades, however, recent developments and improvements in both these sensors and the devices in which they are installed have paved the way to superior performance and lower costs. The barometric pressure sensor has found its place across a wide range of products, no longer limited to traditional "weather stations". Today’s barometric pressure sensors are so incredibly accurate that they can determine altitude to within just a few centimeters. This, coupled with low-cost manufacture, has made these sensors the mainstays for motion tracking, enabling what had previously been solely the realm of science fiction.
This paper will describe the two primary types of technologies used for pressure sensors, capacitive and piezoresistive, and subsequently, focus on several applications and key requirements.
The BME688 is the first gas sensor with Artificial Intelligence (AI) with integrated high-linearity and high-accuracy pressure, humidity and temperature sensors. The BME688 can detect gases by measuring their unique electrical fingerprint and therefore distinguish different gas compositions. However, the sensor has to be teached about these different gases first. That means, we have to train the sensor using Machine Learning. And that’s where the BME AI Studio comes in, it lets the user explore, verify and validate the specific use case based on their application.
In these series of short videos we take you through a step by step approach to realize these use case detection. It showcase all the key steps from how to configure the board, data collection, algorithm training and finally deployment of algorithm. The video series features a “quick start” video in the beginning that gives a quick overview of the all the steps involved and additional videos about each step. The videos have been split in to smaller modular videos that gives an overview of all the key steps, it can be viewed as a playlist (one after the other) or the user can go to a specific video to know more about it. We hope that you will enjoy watching it.
The Arduino Nicla Sense ME board featuring a rich set of Bosch Sensortec sensors is a robust and versatile development board that enables users to develop smart sensing applications.
This series of tutorial videos aim to help users to get started and familiar with the board and quickly explore some of the functionalities and resources around it.
The Self-Learning AI Software can recognize and track more than fifteen pre-learned fitness exercises and has the ability to learn new movements and fitness exercises created by you!
Please find attached the ZIP file with the following contents:
Never Skip Leg Day
This session includes exercises where the sensor is mounted on the ankle and the focus will be on building leg strength.
PDF document with all instructions
Generated patterns
Raw sample data
Outdoor Bodyweight Workout
This session includes exercises where the sensor is mounted on the arm. This workout is great for strengthening your core, arms and legs muscles.
PDF document with all instructions
Generated patterns
Raw sample data
Outdoor Core Workout
This session includes exercises where the sensor is mounted on the ankle. This workout is great for strengthening your core.
PDF document with all instructions
Generated patterns
Raw sample data
Waist Tracking
This session includes exercises where the sensor is mounted on the waist and the arm.
PDF document with all instructions
Generated patterns
Raw sample data
The self-learning AI firmware is available on our Nicla Sense ME board here. For more information about the list of virtual sensors, see the Nicla Sense ME Board examples.
Selecting the right part
BMA456 is 16bit, digital, triaxial acceleration sensor with intelligent on-chip motion triggered interrupt features optimized for wearable and hearable applications. BMA456 support different advanced features via different configure file. Table 1 shows an overview of the features.
Parameter
BMA456
Digital resolution
16bit
Range and sensitivity
+/-2g: 16384LSB/g
+/-4g: 8192LSB/g
+/-8g: 4096LSB/g
+/-4g: 2048LSB/g
Zero-g offset(typ.)
+/-20mg
Noise density(typ.)
120µg/√Hz
Bandwidths
5Hz …684Hz
Interfaces
SPI & I2C, 2 x digital interrupt pins
Supply voltage
VDD: 1.62 to 3.6V
VDDIO: 1.2 to 3.6V
LGA package(mm3)
2.0 x 2.0 x 0.65
Feature/Interrupts
Step Counter/Step detector
(optimized for wearables)
Activity recognition: running, walking, still
Tilt on wrist
Tab/Double Tab
Any-motion/No-motion
High-g/ low-g
Table 1: Overview BMA456 features
Common characteristics
The main characteristics of this product family are:
Key features:
2.0 x 2.0 mm² size
Pin to pin compatibility with all other 2.0 x 2.0 accelerometers from Bosch Sensortec
SPI or I²C interface
Configurable range from ±2G to ±16g
Configurable output data rate up to 1.6kHz
Integrated 1kB FIFO
Auxiliary I²C interface for connecting external magnetometer, including data synchronization
Built-in smart interrupt controller, with features such as step-counter which offers high performance for all wearing positions, including wrist-worn.
BMA456 parameters
BMA456 offers higher performance and stability in a smaller package. See the complete description in Table 2.
Parameter
BMA456
Units
Height
0,65
mm
Digital resolution
16
bits
Zero-g offset (typ.)
±20
mg
Noise density (typ.)
120
µg/√Hz
TCO (X&Y axis)
0.2
mg/K
TCO (Z axis)
0.35
mg/K
TCS
0.005
%/K
Cross Axis Sensitivity
0.5
%
Table 2: BMA456 parameter value
Available evaluation tools and software
To best to evaluate the products from the BMA456 family, we recommend the following combination of evaluation tools:
COINES Desktop software
Application board 3.0
Sensor Shuttle board
BMA456 Shuttle board.
Layout recommendations
Because the BMA4xy sensor family contains tiny mechanical structure inside the package, care must be taken during the layout phase to ensure the best performance. The complete handling and soldering guide can be found on the Bosch Sensortec's website.
First power-on
After powering the sensor for the first time, the initial specs would be to test for communication with the device. This can be done simply by reading the chip identification code in the register 0x00. See below for the expected values:
Device
Chip ID
BMA456
0x16
Table 3: Chip IDs of the BMA4xy product family
Here is some sample code on how to perform this test, based on BMA456, using the COINES software as the host.
/*!
* @brief This internal API is used to initializes the bma456 and verify the
*communication by reading the chip id.
*
* @param[in] void
* @return void
*
*/
static void init_comm_test_bma456(void)
{
int8_t rslt;
struct bma4_dev bma456dev = { 0 };
rslt = bma4_interface_init(&bma456dev, BMA4_I2C_INTF, BMA45X_VARIANT);
rslt = bma456_init(&bma456devbma425dev);
if (rslt == BMA4_OK)
{
printf("BMA456 Initialization Success!\n");
printf("Test #1: Communication. PASSED. Chip ID 0x%x\n", bma456dev.chip_id);
}
else
{
char err_string[255];
printf("BMA456 Initialization Failure!\n");
if (BMA4_E_INVALID_SENSOR == rslt)
{
sprintf(err_string, "Test #1: Communication. FAILED. Expected Chip ID: 0x%x. Received 0x%x\n",\
BMA456_CHIP_ID, bma456dev.chip_id);
}
else
{
sprintf(err_string, "Test #1: Communication. FAILED. No response from the sensor.");
}
coines_exit_error(err_string);
}
coines_delay_msec(100);
}
How to test the sensor's functionality
The BMA4xy series of accelerometers feature a fully integrated and motionless self-test procedure on the ASIC itself. When the self-test is triggered, the accelerometer uses electric fields to physically move the electrodes in all directions, senses the deflection and compares it with the expected output. Therefore, the built-in self-test features is the recommended way to test the sensor's functionality.
Here is some sample code on how to perform this self-test, based on BMA456, using the COINES software as the host.
/*!
* @brief This internal API is used to test if the sensor is working by triggering the self-test.
*
* @param[in] void
* @return void
*
*/
static void function_test_bma456(void)
{
uint16_t rslt;
uint8_t testrslt;
rslt = bma4_perform_accel_selftest(&testrslt, &bma456dev);
if ( 0 != rslt ) coines_exit_error("Test #2: Functionnality. FAILED. Unknown communication error\n");
if ( BMA4_SELFTEST_PASS == testrslt )
{
printf("Test #2: Functionnality. PASSED. Sensor self-test successful\n");
}
else
{
printf("Test #2: Functionnality. FAILED. Sensor self-test failed\n");
}
}
How to test the sensor's performance
There are 2 performance parameters that can easily be tested with the device motionless: offset and noise. See below for the typical values of the sensors.
Note: Typical values are defined as ±1σ, which means that we expect 68.3% of sensors to fall within these values. Min/Max values are defined as ±3σ, which means 99.7% of sensors shall be within these values.
Parameter
BMA456
units
Offset
±20
mg
Noise
120
µg/√Hz
Table 4: Typical performance of BMA456
For the offset, the test procedure is quite simple. With the device in a known position, such as a flat surface, calculate the average value for each axis, and substract the expected output (e.g. 0G, 0G, +1G) from the data. The result is the offset of the sensor.
Here is some sample code on how to perform this test, based on BMA456, using the COINES software as the host.
/*! Average value calculation */
double x_avg_mg=0;
double y_avg_mg=0;
double z_avg_mg=0;
for (int i=0; i<1000; ++i)
{
double xval, yval, zval;
/* ( 'datapoint' * '4G' * '2' * '1000mg') / ('scaling factor for 16 bits') */
xval = (((double)sens_data[i].x) * 4. * 2. * 1000) / pow(2,16);
yval = (((double)sens_data[i].y) * 4. * 2. * 1000) / pow(2,16);
zval = (((double)sens_data[i].z) * 4. * 2. * 1000) / pow(2,16);
x_avg_mg += xval / 1000.;
y_avg_mg += yval / 1000.;
z_avg_mg += zval / 1000.;
}
/*! Offset Calculation */
double x_off_mg=x_avg_mg - X_REST_POSITION_MG;
double y_off_mg=y_avg_mg - Y_REST_POSITION_MG;
double z_off_mg=z_avg_mg - Z_REST_POSITION_MG;
if( OFFSET_THRESHOLD_MG > x_off_mg && OFFSET_THRESHOLD_MG > y_off_mg && \
OFFSET_THRESHOLD_MG > z_off_mg )
{
printf("Test #3: Performance. Offset. PASSED: X=%4.1lfmg Y=%4.1lfmg Z=%4.1lfmg Threshold <\ %4.1lf\n", x_off_mg, y_off_mg, z_off_mg, OFFSET_THRESHOLD_MG);
}
else
{
printf("Test #3: Performance. Offset. FAILED: X=%4.1lfmg Y=%4.1lfmg Z=%4.1lfmg Threshold <\ %4.1lf\n", x_off_mg, y_off_mg, z_off_mg, OFFSET_THRESHOLD_MG);
}
The noise calculation is a bit more complicated. First, subtract the offset from each datapoint. The RMS value can be calculated as the square root of the arithmetic mean of the squares of the noise values.
x_rms = sqrt[1/n( x_1^2 + x_2^2 + .... + x_n^2)]
Since the noise value is affected by the bandwidth of the digital filter, we need to convert it back to noise density with the following formula. Note: this applied only to a second order filter
noise_density = noise_RMS/[sqrt(1.22 x bandwidth)]
Here is some sample code on how to perform this test, based on BMA456, using the COINES software as the host.
/*! RMS Noise Calculation */
double x_rms_noise_mg=0;
double y_rms_noise_mg=0;
double z_rms_noise_mg=0;
for (int i=0; i<1000; ++i)
{
double xval, yval, zval;
/* ( 'datapoint' * '4G' * '2' * '1000mg') / ('scaling factor for 12 bits') */
xval = (((double)sens_data[i].x) * 4. * 2. * 1000.) / pow(2,16);
yval = (((double)sens_data[i].y) * 4. * 2. * 1000.) / pow(2,16);
zval = (((double)sens_data[i].z) * 4. * 2. * 1000.) / pow(2,16);
x_rms_noise_mg += pow(xval - x_avg_mg,2) / 1000.;
y_rms_noise_mg += pow(yval - y_avg_mg,2) / 1000.;
z_rms_noise_mg += pow(zval - z_avg_mg,2) / 1000.;
}
/* rms noise is the square root of the arithmetic mean of the squares of the noise values */
x_rms_noise_mg = sqrt(x_rms_noise_mg);
y_rms_noise_mg = sqrt(y_rms_noise_mg);
z_rms_noise_mg = sqrt(z_rms_noise_mg);
/*! RMS Noise to RMS noise density convertion */
/* noise density = RMS noise / sqrt ( 1.22 * bandwidth) */
/* BMA456 has 40.5Hz bandwidth at 100Hz normal mode */
double x_noise_dens_ug = 1000 * x_rms_noise_mg / sqrt(1.22 * 40.5);
double y_noise_dens_ug = 1000 * y_rms_noise_mg / sqrt(1.22 * 40.5);
double z_noise_dens_ug = 1000 * z_rms_noise_mg / sqrt(1.22 * 40.5);
if( NOISE_THRESHOLD_MG > x_noise_dens_ug &&
NOISE_THRESHOLD_MG > y_noise_dens_ug &&
NOISE_THRESHOLD_MG > z_noise_dens_ug )
{
printf("Test #3: Performance. Noise. PASSED: X=%4.1lfug/sqrt(Hz) Y=%4.1lfug/sqrt(Hz) \ Z=%4.1lfug/sqrt(Hz) Threshold < %4.1lf\n", x_noise_dens_ug, y_noise_dens_ug, z_noise_dens_ug,\ NOISE_THRESHOLD_MG);
}
else
{
printf("Test #3: Performance. Noise. FAILED: X=%4.1lfug/sqrt(Hz) Y=%4.1lfug/sqrt(Hz) \ Z=%4.1lfug/sqrt(Hz) Threshold < %4.1lf\n", x_noise_dens_ug, y_noise_dens_ug,\ z_noise_dens_ug,NOISE_THRESHOLD_MG);
}
Calibrating the sensor
The first question to ask concerning calibration is whether it is required for the intended application. Accelerometer calibration mainly consists of calibrating the accelerometer's offset. The main impact for this is in tilt-sensing application, where the offset will induce an error in the measurement of the horizon.
The accelerometer comes from the factory pre-trimmed, but the soldering process and PCB bending due to assembly can vary the offset, therefore it is preferable to calibrate the accelerometer after assembling the device into the device housing.
Pre- and post-calibration accuracy
Sample code
The calibration procedure is outlined in the inline calibration application note. Here is some sample code on how to perform this calibration, based on BMA456, using the COINES software as the host.
Note : Although the concept is the same, the BMA4xy family of accelerometers does not include a built-in offset calculation on the ASIC. Since the offset are calculated inside of the Sensor API itself, it allows for a much more flexible target position.
rslt = bma456_init(&bma456dev);
if (rslt == BMA4_OK)
{
printf("BMA456 Initialization Success!\n");
}
else
{
coines_exit_error("BMA456 Initialization Failure!\n");
}
coines_delay_msec(100);
rslt = bma456_write_config_file(&bma456dev);
/* Enable the accelerometer */
rslt = bma4_set_accel_enable(BMA4_ENABLE, &bma456dev);
/* Set the accel configurations */
struct bma4_accel_config accel_conf = { 0 };
accel_conf.odr = BMA4_OUTPUT_DATA_RATE_50HZ;
accel_conf.bandwidth = BMA4_ACCEL_NORMAL_AVG4;
accel_conf.perf_mode = BMA4_CIC_AVG_MODE;
accel_conf.range = BMA4_ACCEL_RANGE_8G;
rslt = bma4_set_accel_config(&accel_conf, &bma456dev);
dev.delay_us(20000, dev.intf_ptr);
if (rslt == BMA4_OK)
{
/* Set accel foc axis and it's sign (x, y, z, sign)*/
struct bma4_accel_foc_g_value g_value_foc = { 0, 0, 0, 0 };
rslt = bma4_perform_accel_foc( &g_value_foc, &bma456dev);
if (rslt == BMA4_OK)
{
printf("BMA456 perform FOC successful!\n");
/* Delay after performing Accel FOC */
dev->delay_us(30000, bma456dev ->intf_ptr);
/*! calculates the offset after compensation */
rslt = bma4_read_regs(BMA4_OFFSET_0_ADDR, data_array, 3, & bma456dev);
printf("Post-calibration offset : X=%4.1lfmg Y=%4.1lfmg Z=%4.1lfmg", data_array[0],\
data_array[1], data_array[3]);
}
else
{
coines_exit_error("Unknown communication error. Exiting...\n");
}
}
Once the offsets are determined, they can be written into the NVM so that the sensor automatically compensates for the soldering offset even after physically removing the power. Here is some sample code on how to save calibration data to NVM, based on BMA456, using the COINES software as the host.
/*!
* @brief This internal API is used to update the nvm content
*
* @param[in] void
* @return void
*
*/
static void bma456_update_nvm(void)
{
uint16_t rslt;
uint8_t data;
/* unlocks the NVM for writing */
data = 0x02;
bma4_write_regs(0x6A, &data, 1, &bma456dev);
/* makes sure the BMA456 is not executing another command */
do
{
rslt = bma4_read_regs(BMA4_STATUS_ADDR, &data, 1, &bma456dev);
if ( 0 != rslt ) coines_exit_error("Unknown communication error. Exiting...\n");
} while ( 0 == (data&0x10) );
/* performs the writing of the NVM */
rslt = bma4_set_command_register( 0xA0, &bma456dev);
if ( 0 != rslt ) coines_exit_error("Unknown communication error. Exiting...\n");
/* wait for the command to be completed */
do
{
rslt = bma4_read_regs(BMA4_STATUS_ADDR, &data, 1, &bma456dev);
if ( 0 != rslt ) coines_exit_error("Unknown communication error. Exiting...\n");
} while ( 0 == (data&0x10) );
/* locks the NVM writing */
data = 0x00;
bma4_write_regs(0x6A, &data, 1, &bma456dev);
}
Further reads
Datasheets:
BMA456 Datasheet
Application notes:
Inline calibration of accelerometers
Handling, soldering and mounting instructions, Accelerometers HSMI
1 Characteristics of BMP384
What is the max. overpressure and damage range of the BMP384?
The piezo resistive membrane withstands an overpressure of up to several bar (burst pressure). This value is for the single membrane inside the package only, so a theoretical value, because this maximum value until the sensor will be damaged is much higher than the water pressure you will use e.g. 5 bar.
What is the waterproof level, which you can achieve with the BMP384?
The possible waterproof level depends on the final 2nd integration concept, but IP67, IP68 or 5 bar is realistic if the applicable concept is used.
Could you elaborate on the mechanical integration concept for a watertight solution?
There is no generic integration concept. It depends on the customer experience and requirements. However, the customer has to take care that only the gel area gets in contact with the water. This is possible with an O-ring sealing, under fill or adhesive gel.
How much difference in response time of the BMP384 could be expected compared to the non-gel version?
There is no difference in response time due to the gel.
What influence does the gel have on the performance of the sensor?
There is almost no performance influence due to the gel-filled package.
What is the difference in sensor handling compared to the non-waterproof BMP388?
BMP384 is packed according to MSL3 level.
2 Technical specifications
What is the typical current consumption of the BMP384?
BMP384 has a typical current consumption of 3.4 µA @ 1 Hz for pressure and temperature.
What is the maximum pressure the BMP384 can withstand?
If we are talking about maximum air pressure, maximum pressure the BMP384 can withstand is 10 bar.
What is the absolute accuracy of the BMP384?
The absolute accuracy is ± 0.5 hPa between 900…1100 hPa from 25…40 °C.
3 Applications and use cases of the BMP384
Is there any application note showing how to place/use the BMP384 in a final application?
We are working on an application, which will be released on our website soon.
4 Tools for BMP384
Do you have an evaluation board to test the BMP384?
Yes, an evaluation board is available via our distribution partners.
5 Availability of BMP384
Where can I actually buy the BMP384?
BMP384 is available at all our distribution partners. You can find a list on our website at www.bosch-sensortec.de.
1 Characteristics of BME688
Can we use the current PCB using the BME680 print and upgrade it with BME688 without any changes?
Yes, the BME688 is fully backward compatible and can be placed on every PCB, which has been designed for the BME680. You just have to update the API to the new version, which automatically detects the BME688 and does the right value calculation (necessary due to the extended ASIC range of the BME688).
Do you need to force air into the BME688 when taking samples?
No, this just happens “by itself” due to the laws of nature, in particular due to diffusion. As soon as the gas composition around the BME688 changes, there is a concentration gradient, which leads to diffusion of gases into and out of the BME housing. In addition, thanks to the tiny dimensions (the lid hole is less than 1 mm away from the gas sensor chip inside) this happens within few seconds.
As the data is stored on the sensor, how many measurements are possible?
The BME688 stores the scan profile as well a few data points in its buffer. The measured data has to be continuously read by the microcontroller (MCU) of the device to which the BME688 is connected anyway. In that configuration, the only limit for measurement data is the device storage. By running the BME688 library (called “BSEC”) on the MCU, the sensor data can directly be evaluated. Therefore, you do not have to store raw data but only the required output values.
How much computing power is required to run the AI software? Can you give examples for compatible MCUs?
BME AI-Studio requires a desktop PC to analyze the data and derive the best algorithm. However, running a defined algorithm is not demanding at all anymore. For instance an ESP8266 or ESP32 can do everything in real-time.
Can you please explain how the gas scanner works?
The gas sensor is measuring with different sensitivities during one gas scan. By doing so, it can generate a specific fingerprint for different gas mixtures. In addition, you can modify and optimize the scan profile with BME AI-Studio on your application.
Does the BME688 have Flash or EEPROM?
No.
2 AI firmware and algorithm of the BME688
As soon as the algorithm is trained with data from several sensors in order to recognize one component, can we export the parameters and use only one sensor to detect it?
Yes, the BME AI-Studio software tool can export the trained algorithm as a configuration string, which can be loaded into the BSEC 2.0 software on any device having one BME688. This allows the device to directly output the trained scan results of the BME688.
Do you use the sensor to train its AI model?
Yes, the sensor data is being used for the AI model. The standard gas scan mode for VSC detection is being developed based on sensor data from a huge number of sensors and lab tests with different gases. And for other applications, BME AI-Studio software tool enables everyone to develop own use-cases based on BME688 sensor data, for instance by using the dev-kit with eight BME688 sensors.
One of the major benefits of the BME688 is that you can directly use sensor data measured in real-life applications. So far, the typical procedure for enabling new gas sensor-based applications is the following:
Identify single lead gases as well as potential interfering gases with sophisticated gas analyzers.
Find or develop suitable gas sensors for these gases.
Do lab tests with lead gases against interference gases (usually in synthetic air, which cannot represent real life conditions).
Test reproducibility and performance in the real-life application.
This procedure still makes sense in case of known target gases like for e.g. sulfur compounds as a marker for bad breath. However, it comes to its limits for other smells or more complex gas mixtures.
With BME688 and the BME AI-Studio software tool you can directly develop, test and optimize in your application. For sure, this can still be accompanied by lab tests and might be even mandatory in some applications. However, using real-life data for gas sensing algorithms can significantly improve the performance and even enable new use-cases.
Which neural network topology is used in AI? Or is it just statistical analysis for pattern recognition?
The current version of the BME AI-Studio software tool uses a pre-defined Neural Net Architecture combined with one configurable optimizer for training (ADAM optimizer). Depending on market requirements, we plan to have the possibility of choosing other architectures in a future release.
3 Applications and use cases of the BME688
Is it possible to detect the gases produced by burning of network cables and electronics?
We expect that this can be an interesting application for using the BME688.
Let’s give some background: If there are unusual states in electric circuits or cabinets, there are typically two reasons:
Materials (e.g. isolator) get hot due to high currents / shorts,
High voltages or shorts lead to flashovers / sparks.
In case 1, hot or even melting materials produce increased outgassing, typically many unburned hydrocarbons, which can be well detected by the BME688 (just as humans smell it). In case 2, flashovers generate ozone, which is well detected by a BME688 and has a completely different signature than other gases.
Does BME688 detect combustible gases like CH4 & C3H8 and poisonous gases like CO?
Yes, nearly all hydrocarbons (CxHy) are being detected by the BME688 gas sensor as well as many other gases like for example CO. Combustible gases are typically classified into NMOG (“Non-Methane Organic Gases”) and methane. Methane (CH4) is an exception, since its decomposition requires special catalysts, so we do not expect high signals even for high concentrations of methane. However, in many applications, methane does not appear as a single gas but together with other gases (e.g. sulfur compounds), which are well detected by BME688. Therefore, it makes sense to test with the BME688 in your application.
Next to gasses, what else can be measured with the sensor?
The BME688 has temperature, barometric pressure, air humidity and gas sensor elements inside. All sensor information can be used either as single values or combined in the AI software to recognize certain conditions or states. In the BME AI-Studio software tool, you can decide whether you just want to use the gas sensor data for your application or take as well pressure, temperature and humidity sensor data into account.
Are profiles of pre-trained models of some gases available for implementation?
The standard profile is developed to detect VSCs. There are several other gas scan profiles available in the BME AI-Studio software tool and you can even configure your own profile. For sure, they have to be trained on an application.
Are you planning to offer more pre-trained models than currently available?
Bosch Sensortec, as well as first customers are already developing models for other applications.
Is the BME688 certified as a medical sensor?
No, usually this is done on device level, not on sensor component level. Bosch Sensortec qualifies products according to the standard requirements for consumer electronics (e.g. JEDEC). Generally, our customers are the experts for their specific application field and mission profile in which they use our sensor components. End devices anyway have to be certified, the advantage of certified components is usually low.
Is it possible to detect drugs and explosions with your BME688?
We do not have experience in this field. However, you can test it with the BME688 development kit.
How can I find out if the gases in my application can be measured with the BME688?
This is exactly one reason why we have developed the BME AI-Studio software tool. You can test directly in your application in real life conditions. There is no need to know which gases in which concentrations might be target gases or which other gases might be present as well. Just get started.
So far, one typically had to start lab tests with single gases in synthetic air for every single application. However, even if this works in the lab, it does not mean that it works as well in the field, because in real life many other gases are present as well.
With the BME AI-Studio, you can develop, test and optimize in your real application.
4 Tools for BME688
4.1 Software tools
Do you have a code and examples showing the integration and use with your BSEC library?
Both is becoming available on our website https://www.bosch-sensortec.com/software-tools/software/BME688-software/ for download until end of March.
Are over-the-air updates possible to detect more gasses and substances in future?
You can do that even today: The configuration of the BME688 is completely defined by software, not hard-coded in the ASIC. For instance, if you have developed a new application with BME AI-Studio, the result is a new configuration string in combination with a scan profile. Both can be easily transferred to each of your devices in the field over the air, since it is just a few kb of size. As soon as the BSEC software on your device is loaded with the new configuration, the sensor works with the new characteristic.
Does the AI software only use the gas sensor or could I use the humidity sensor data as well for detecting events?
Of course, the AI software can use all sensor data from the 4-in-1 sensor BME688: gas, humidity, temperature and pressure signals. You can choose which one is reasonable for your application.
4.2 Hardware tools
Why do we need 8 sensors on the evaluation board?
The BME688 development kit can be configured with the BME AI-Studio software tool. This allows to optimize performance, ODR and power consumption on specific application needs. By featuring eight BME688 sensors, the board allows you to test and gather data with more than one configuration at the same time. This significantly increases statistics and reduces development time as well.
Where is the BME development kit X8 (BME688) available?
Both BME688 and the development kit with eight BME688 sensors will be available at all our distribution partners as of April 2021. We are going to link to all suppliers on our BME688 product website.
1 Characteristics and compatibility of BHI260AP
1.1 General information
What is the overall size of the package?
The size of the system-in-package with an accelerometer, gyroscope and a programmable 32bit microcontroller is 3.6 mm * 4.1 mm.
Where are you in the commercialization phase - i.e. Prototype? Sampling? Beta customers?
The mass production launch is in preparation.
1.2 MCU
Is there a MCU inside the BHI260AP?
Yes, there is a MCU inside.
Can the raw data from the BHI260AP be accessed in real-time and does the sensor include a multi-axis accelerometer?
Yes, the raw sensor data can be accessed in real-time. The sensor includes a 3-Axis accelerometer and a 3-Axis Gyroscope.
Is the BHI260AP compatible with other MCUs?
Yes, the BHI260AP can be used together with other MCUs
1.3 IMU
Is there any downside or potential tradeoff to having a 6-axis versus a 9-axis IMU, or is drift not an issue in this application?
The recommendation of 6-axis or 9-axis is dependent on the typical usage environment, whether it is subject to magnetic distortion in indoor and/or outdoor environments. While the current magnetometers suffer from hard-iron and soft-iron effects, the sensor is equipped with a state-of-the-art sensor data fusion that includes a fast magnetometer calibrator to help reduce or control drift in direction after magnetic distortions are detected. Here, an absolute generic recommendation is not possible due to the nature of sensors, but guidance can be provided specific to the application and expected use. Insights on this topic are available in our publication (EDN whitepaper)
1.4 Power management
What is the typical mean power consumption when the sensor is steadily in use (e.g. when someone is doing a workout)?
It depends on the number of sensors activated inside the sensor (accelerometer or gyroscope) and the variety of activities simultaneously being tracked. For an exact number, please get in touch with Bosch Sensortec.
What is a possible strategy to manage power efficiently, and is ultimate power consumption determined by the customer developing the wearable?
Typically, for saving system power, the developers look for power-expensive components such as the GPS, display, connectivity and the running time of application processors, etc.
1.5 Sensor fusion and ML:
How are you using sensor fusion to develop information from the raw sensor output? Please provide an example.
Sensor data are fused together for multiple purposes. One of them is the generation of relative and absolute orientation. This orientation information is quite useful for tracking the angle (heading, pitch and roll) at which the device moves in relation to the user's body movements.
Individual sensors, i.e. an accelerometer, gyroscope, magnetometer and pressure sensor suffer from problems such as distortion and sensitivity caused by different environmental and operating conditions, such as temperature. Sensor data fusion helps to leverage the strengths of one sensor to correct the output of the other sensors, and vice-versa.
With a reliable estimate of heading over longer periods of time, the position tracking and navigation becomes reliable even when GPS is running in duty cycle mode to save system power.
Similarly, sensor data is fused together to classify and count user functions such as swimming and fitness tracking, as individual sensors (accelerometer or gyroscope) do not generate unique enough information to identify the type of movement.
Can you explain the different ways that sensor fusion, ML, and a powerful software framework are being used in this sensor and the difference between them?
This smart sensor system offers many state-of-the-art features that are very useful for devices worn on the wrist or head. These include dedicated solutions for pedestrian dead reckoning, swimming analytics and fitness tracking, as well as generic software platforms with self-learning AI software and orientation estimation.
The sensor also comes with a software development kit that allows you to program and add your own code to these platforms and dedicated solutions. This makes creating solutions with the sensor easier.
The orientation estimation platform can be used to develop applications such as position tracking, while the self-learning AI platform can be used to develop applications that involve tracking repetitive patterns during use for a simplified human-machine interface or to enable a personalized recommendation system.
The software framework makes it possible to offer all functions as virtual sensors and thus activate/deactivate them depending on the context of the end user.
2 AI firmware and algorithm of the BHI260AP
Is the AI firmware updateable?
Yes, the AI firmware is updatable.
What is the prediction accuracy rate for the trained algorithms?
The typical prediction accuracy is >90% for personalized pre-trained activities.
Which neural network topology is used in AI? Or is it just a statistical analysis for pattern recognition?
It is a proprietary patented Bosch technology designed especially for learning on the edge (which enables personalization) and still keeps computational and power requirements low.
What is the classification based on, is there a NN used?
Classification (learning and recognition) is based on time-series accel and gyro data using a proprietary patented Bosch technology designed especially for learning on the edge (which enables personalization) and still keeps computational and power requirements low.
What types of software algorithms have you developed and what are their functionalities?
Self-learning AI software for fitness tracking
This software enables on-device learning and automatic tracking of a wide variety of fitness movements, including options for on-device individual-specific personalization of movements and support for increasing numbers of activities without the need to modify the original software.
Swim analytics
This software dedicated for wrist wearables generates useful information of users’ swimming activities, such as length count, style of swimming and stroke counts.
Pedestrian dead reckoning
This software helps to reduce the power consumption of a wearable device by enabling the duty cycling of power-consuming GNSS components, as well as improving the accuracy of outdoor positioning with pedestrian dead reckoning.
Relative and absolute orientation
This software estimates relative and absolute orientation of the device, including outputs such as rotation vector, game rotation vector, linear acceleration and gravity.
3 Applications and use cases of the BHI260AP
Some of the heavy compound exercises might be dangerous if they are not done correctly. Is there a measure to prevent incorrect training due to the incompetence of the users?
For providing guidance to the user for appropriate training, you can make use of a combination of the recognition and orientation tracking included inside BHI260AP.
Is the sensor able to indicate that the workout is done correctly?
To provide guidance to the user for appropriate training, you can use a combination of recognition and orientation tracking included in the BHI260AP.
The ability to indicate if a workout is done correctly would open up the field to physiotherapy applications, right?
Yes, correct.
How is the software reacting to highly variating movements like “burpees directly followed by heavy deadlifts” etc.? Is it picking up those constantly changing movements properly performed in a row when learned individually?
Yes, the sensor is picking up the changing movements automatically, without any explicit information from user.
How configurable is the BHI260AP for different activities? For example, a swimming expert with biomechanics background may have some different focus than the built in swimming analysis. Will developers be able to configure that?
Yes, developers would be able to create and load custom patterns for the activities of their interest. Please contact us via the Bosch Sensortec Community if you need further support on this topic.
Can the self-learning AI Software be used for other activities than fitness, like for e.g. fishing?
Yes, please get in touch with us via the Bosch Sensortec Community for further discussions on how to achieve this.
This product has a lot of functionalities - what is the most innovative aspect/feature/function?
The most innovative aspect is the self-learning function designed inside the sensor itself, which enables a seamless personalization of activity tracking for a wide variety of activities and end-users.
4 Tools for BHI260AP
Do you have development boards, like for e.g. a pulse band?
Yes, we have application and shuttle boards. Shuttle boards for BHI260AP are not yet available from our distributors. We plan to make them available in Q2 2021.
Do you provide a design kit and a free graphical user interface (GUI) with real-time raw data display at Windows OS?
Yes, we provide software development kit for programming the BHI260AP and the PC based development desktop tool for visualization of real-time data.
Does the BHI260AP need any real-time cloud AI support or is it an edge AI sensor?
BHI260AP is a complete edge sensor. Cloud support is not needed.
Is there an IDE available to use the API and customize it?
Yes, we provide a software development kit for programming the BHI260AP and a sensor API for customizing the sensor.
Is it going to be a black box for the devs or will it be an open software development kit?
We will provide a software development kit for programming the BHI260AP and make it as open as possible for developers.
Is there any data analytics previewed in real time (smart data profiling) or that are used for diagnostic predictions for instance?
Yes, data analytics can be previewed in real time with the development desktop.
Please find attached the two white papers for our BHI260AP self-learning AI sensor:
White paper: Me, myself and AI
How the new self-learning AI sensor pesonalizes your home workout
Fitness tracking is presently experiencing a huge upswing in popularity. The market for fitness trackers and step counters has surged by 65% year-on-year [1], with just the Fitbit platform alone claiming nearly 30 million active users [2]. Current activity tracking devices have demonstrated the huge market potential of this segment and have laid the groundwork for next-generation AI-enabled devices to take centre stage as individual fitness tracking goes mainstream.
White paper: Swim like a fish with Artificial Intelligence
Combining AI and sensors to create a new generation of intelligent wearables
Artificial intelligence (AI) is rapidly becoming a natural and integral part of our everyday lives – working silently and unnoticed in the background. AI makes sense of the multitude of data streaming in from various sensors to deliver detailed and precise insights, which have the potential to increase the utility of virtually all electronic devices on the market today. This defining technology can accurately determine whether the user of a device is walking, running, sitting, sleeping – or even swimming in real-time. This article explores how sensors synergize with AI in wearables to deliver valuable information to users – even in demanding environments like swimming pools.
Purpose
This document describes the steps that need to be undertaken to setup a running python environment (at the moment limited to Windows systems), with which sensors from Bosch Sensortec can be read out using the Application Board APP2.0 and the shuttle boards.
Overview
The Application Board APP2.0 runs a firmware that allows connecting to it via USB and interface to a host PC. APP2.0 mainly serves as a protocol translator (like usb to i2c/spi) and has a dedicated streaming functionality for accurate sensor readout using the real-time capabilities of the MCU on the APP2.0.
On PC side, Bosch Sensortec provides a library for convenient access of the board using C# or python.
Requirements and material
PC or Laptop
Tested hardware / software: Windows 7 (64bit)
Software
Development Desktop 2.0 software from Bosch Sensortec web page:
https://www.bosch-sensortec.com/bst/support_tools/downloads/overview_downloads
python environment (python 3 is recommended, but should also work with python 2), e.g. https://www.anaconda.com/download/#windows
python module: pythonnet (see details in instructions section)
Installation
Windows Platform
Assumption: the computer has a recent firefox web browser installed and has direct access to the internet. Furthermore, admin rights are required.
Upgrade pip
Install pip:
conda install pip
After installing the environment, it needs to be activated:
activate my35env
Create virtual environment (this is to prevent any issues with anaconda python and non-conda installed packages. For example name your virtual environment "my35env" with the command:
conda create -n my35env anaconda python=3.5
Note: the script should also work with other 3.x versions of python. However, using version 3.5 enables to add guiqwt to a later moment, which may be a required module for displaying sensor data in a GUI format.
Run cmd.exe as admin
Install the Anaconda python environment
Install the Development Desktop 2.0 on the PC.
The library UserApplicationBoard.dll that is required to access the APP2.0 can be found in this folder:
C:\Program Files\Bosch Sensortec\Development Desktop 2.0\UserpApplicationBoard
direct internet access: pip install --upgrade pip
direct internet access: pip --proxy https://proxy.xyz.com:8080 install --upgrade pip
Note: use the proxy settings for the rest of the commands as well if required
Note: in some cases the proxy needs authentication, e.g. https://username:[email protected]:8080. In such a case, if the user uses special characters in his password, these characters must be written in html format, e.g. "%23" corresponds to the ASCII escape character of "#", details: https://www.ascii.cl/htmlcodes.htm
Install pythonnet:
pip install --pre pythonnet
Copy the python script (see below) so some place
Linux
The board can also be interfaced using libusb, the required software is currently under development.
Operation
Based on the instructions and if the anaconda package is used, the following steps should be taken to run the script:
Connect the APP2.0 to the PC, mount the shuttle board, switch the board on
open cmd.exe
Activate the environment, e.g.
activate my35env
Open the IDE spyder:
spyder
Open the script using the IDE
Press the green triangle button (i.e. run the file)
Code example
# -*- coding: utf-8 -*-
"""
****************************************************************************
* Copyright (C) 2018 Bosch Sensortec GmbH
*
* Created 15.12.2017
* * This script is intended to be used to check BMI085 using GenericAPI and
* shuttle board on APP2.0.
* * Version changelog
* =================
* 0.9 (15.12.2017) * - Initial version based on previous sample scripts
* 1.0 (18.12.2017) * - Released after testing, small code modifications
* - Test signal function does not work, reason unknown
* ****************************************************************************
* BSD-3-Clause
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
*
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* 3. Neither the name of the copyright holder nor the names of its
* contributors may be used to endorse or promote products derived from
* this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
* FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
* COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
* (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
* SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
* STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
* IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.**************************************************************************/ """ import sys
import clr
from time import sleep sys.path.append(r"C:\Program Files\Bosch Sensortec\Development Desktop 2.0\UserpApplicationBoard") # path of dll
clr.AddReference("UserApplicationBoard") from System import Byte
from System import UInt16
clr.AddReference('System.Collections') import numpy as np
import BST # Pin descriptions and other constants
PS_Gyro = 9
SCX = 6
SDX = 5
SDO = 4
BMI085_ShuttleID = 70
ACCEL_RANGE = 2 # BMI085: smallest Accel range is 2G (for BMI088 here would be 3G)
GYRO_RANGE = 2000 # BMI08x: "standard" gyro range board = '' # This class contains the relevant information about the sensor. # In case of BMI08x, there are 2 class initializations neeeded, one
# for accelerometer, the other one for the gyroscope.
class Sensor: def __init__(self, sensor_ID, i2c_addr, interface, CSB, asic): self.sensor_ID = sensor_ID self.i2c_addr = i2c_addr self.interface = interface self.CSB = CSB self.asic = asic self.firstdatareg = 0 self.rangereg = 0 self.fullrange = 0 if asic == 'baa450': self.firstdatareg = 0x12 self.rangereg = 0x41 self.fullrange = ACCEL_RANGE if asic == 'bag160': self.firstdatareg = 0x02 self.rangereg = 0x0F self.fullrange = GYRO_RANGE def get_if_detail(self): if self.interface == 'spi': return self.CSB elif self.interface == 'i2c': return self.i2c_addr else: return -1 def set_if(self, interface): self.interface = interface # create single board instance over USB connection
def bst_init_brd_app20(): global board board = BST.UserApplicationBoard() board.PCInterfaceConfig( BST.PCINTERFACE.USB ) # print board info bi = board.GetBoardInfo() print('BoardInfo: HW/SW ID: ' + str(bi.HardwareId) + '/' + \ str(bi.SoftwareId) + ', ShuttleID: ' + str(bi.ShuttleID)) if bi.HardwareId == 0: print('Seems like there is no board commincation. Stop') board.ClosePCInterface() sys.exit()
# if bi.ShuttleID != BMI085_ShuttleID:
# print('Seems like you are not using BMI085 shuttle board. Stop')
# board.ClosePCInterface()
# sys.exit() # Set SPI bus
def brd_set_spi_if(sensor): board.PinConfig(SCX, BST.EONOFF.ON, BST.PINMODE.OUTPUT, BST.PINLEVEL.HIGH) board.PinConfig(SDX, BST.EONOFF.ON, BST.PINMODE.OUTPUT, BST.PINLEVEL.HIGH) board.PinConfig(SDO, BST.EONOFF.ON, BST.PINMODE.INPUT, BST.PINLEVEL.HIGH) board.SensorSPIConfig( Byte(sensor.sensor_ID), sensor.CSB, \ BST.SPISPEED.SPI1000KBIT, BST.SPIMODE.MODE0 ) board.PinConfig(sensor.CSB, BST.EONOFF.ON, BST.PINMODE.OUTPUT, \ BST.PINLEVEL.HIGH) if sensor.asic == 'bag160': board.PinConfig(PS_Gyro, BST.EONOFF.ON, BST.PINMODE.OUTPUT, \ BST.PINLEVEL.LOW) # ic2 select # Set I2C bus
def brd_set_i2c_if(sensor): # selecz ic2 addr board.PinConfig(SDO, BST.EONOFF.ON, BST.PINMODE.OUTPUT, BST.PINLEVEL.LOW) board.PinConfig(sensor.CSB, BST.EONOFF.OFF, BST.PINMODE.INPUT, \ BST.PINLEVEL.LOW) if sensor.asic == 'bag160': # selecz ic2 mode board.PinConfig(PS_Gyro, BST.EONOFF.ON, BST.PINMODE.OUTPUT, \ BST.PINLEVEL.HIGH) board.SensorI2CConfig( Byte(sensor.sensor_ID), UInt16(sensor.i2c_addr), \ BST.I2CSPEED.STANDARDMODE) # Power up sequence fo the sensors
def power_up(sensor): if sensor.asic == 'baa450': # Wait times according to datasheet sleep(.001) board.Write(0x7D, 4, sensor.get_if_detail()) # write 4 to ACC_PWR_CTRL board.Write(0x7C, 0, sensor.get_if_detail()) # Clear ACC_PWR_CONF sleep(.05) if sensor.asic == 'bag160': brd_write(sensor, 0x11, [0]) pwr = brd_read(sensor, 0x11, 1) print(pwr) # Function to read from the previous selected bus def brd_read(sensor, reg, range): # Consider the dummy byte if (sensor.asic == 'baa450') and (sensor.get_if_detail() == sensor.CSB): range += 1 data = board.Read(reg & 0x7F, UInt16(range), sensor.get_if_detail()) data = [int(i) for i in data] # data is in Int32[] format if (sensor.asic == 'baa450') and (sensor.get_if_detail() == sensor.CSB): data.pop(0) return data # Function to write on the previous selected bus
def brd_write(sensor, reg, data): return board.Write(reg & 0x7F, data, sensor.get_if_detail()) # Calculate 2's complement out of given uint value
def twos_comp(val, bits): """compute the 2's complement of int value val""" if (val & (1 << (bits - 1))) != 0: # if sign bit is set e.g., 8bit: 128-255 val = val - (1 << bits) # compute negative value return val # return positive value as is # This function reads a number of samples, calculates the average and the
# standard deviation and outputs the result to the user
def read_sensor_values_3D(sensor, num_of_samples = 25, delay_in_ms = 0): x = [] y = [] z = [] # Read in number of samples while(num_of_samples > 0): data = brd_read(sensor, sensor.firstdatareg, 6) x.append(twos_comp(data[1] * 256 + data[0], 16)) y.append(twos_comp(data[3] * 256 + data[2], 16)) z.append(twos_comp(data[5] * 256 + data[4], 16)) sleep(delay_in_ms) num_of_samples -= 1 return ([np.mean(x), np.mean(y), np.mean(z), np.std(x), np.std(y), np.std(z)]) # This function converts LSB to pyhsical measure (e.g G for accel or
# dps for gyro)
def convert_lsb_2_phys(sensor, data): sensrange = brd_read(sensor, sensor.rangereg, 1) print('Range is set to : ' + str(sensrange[0])) result = [] for d in data: result.append(d/32768. * sensor.fullrange * 2 ** (sensrange[0])) return result def read_temp_sensor_baa450(sensor): if sensor.asic == 'baa450': data = brd_read(sensor, 0x22, 2) return(twos_comp(data[0] * 8 + (data[1] >> 5), 11) * 0.125 + 23) # This function is not yet working reliably at the moment! (refers to V1.0)
def trigger_selftest(sensor): if sensor.asic == 'baa450': # Set 16G measurement range brd_write(sensor, 0x41, 3) # Set ODR 1.6kHz, normal mode: brd_write(sensor, 0x40, 0xA7) # Wait 2ms (see datasheet) sleep(.003) print('-> Enabling positive selftest signal') brd_write(sensor, 0x6D, 0x0D) # Wait >50ms (see datasheet) sleep(0.051) data = read_sensor_values_3D(bmi08x_accel) data = convert_lsb_2_phys(bmi08x_accel, data) print(data) print('-> Enabling negative selftest signal') brd_write(sensor, 0x6D, 0x09) sleep(.1) data = read_sensor_values_3D(bmi08x_accel) data = convert_lsb_2_phys(bmi08x_accel, data) print(data) brd_write(sensor, 0x6D, 0x00) sleep(.1) # ############################################################################ # Main routine.
if __name__ == "__main__": bst_init_brd_app20() try:
# ##### SPI section ##### myif = 'spi' print('\n +++ Interface: ' + myif + ' +++') bmi08x_accel = Sensor(0x1F, 0x18, myif, 8, 'baa450') bmi08x_gyro = Sensor(0x0F, 0x68, myif, 14, 'bag160') board.SetVDD(0) board.SetVDDIO(0) brd_set_spi_if(bmi08x_gyro) brd_set_spi_if(bmi08x_accel) board.SetVDD(3.3) board.SetVDDIO(3.3) # Read chip-ID 2x for accelerometer to switch to spi mode chipid = brd_read(bmi08x_accel, 0, 1) # Read chip id chipid = brd_read(bmi08x_accel, 0, 1) print ('Chip ID accel: ' + str(chipid[0])) chipid = brd_read(bmi08x_gyro, 0, 1) print ('Chip ID gyro: ' + str(chipid[0])) board.SetVDD(0) board.SetVDDIO(0) # ##### I2C section ##### myif = 'i2c' print('\n +++ Interface: ' + myif + ' +++') bmi08x_accel = Sensor(0x1F, 0x18, myif, 8, 'baa450') bmi08x_gyro = Sensor(0x0F, 0x68, myif, 14, 'bag160') brd_set_i2c_if(bmi08x_accel) brd_set_i2c_if(bmi08x_gyro) board.SetVDD(3.3) board.SetVDDIO(3.3) # Read chip id chipid = brd_read(bmi08x_accel, 0, 1) print ('Chip ID accel: ' + str(chipid[0])) chipid = brd_read(bmi08x_gyro, 0, 1) print ('Chip ID gyro: ' + str(chipid[0])) # Read accel data power_up(bmi08x_accel) data = read_sensor_values_3D(bmi08x_accel) data = convert_lsb_2_phys(bmi08x_accel, data) print ('Accel x [mg]: %.2f\t(Noise RMS: %.2f)' % \ (data[0] * 1000, data[3] * 1000)) print ('Accel y [mg]: %.2f\t(Noise RMS: %.2f)' % \ (data[1] * 1000, data[4] * 1000)) print ('Accel z [mg]: %.2f\t(Noise RMS: %.2f)' % \ (data[2] * 1000, data[5] * 1000)) # Read gyro data data = read_sensor_values_3D(bmi08x_gyro) data = convert_lsb_2_phys(bmi08x_gyro, data) print ('Gyro x [mg]: %.2f\t(Noise RMS: %.2f)' % \ (data[0], data[3])) print ('Gyro y [mg]: %.2f\t(Noise RMS: %.2f)' % \ (data[1], data[4])) print ('Gyro z [mg]: %.2f\t(Noise RMS: %.2f)' % \ (data[2], data[5])) # Read temperature data data = read_temp_sensor_baa450(bmi08x_accel) print ('Temperature [degC]: %.2f' % data) # Trigger selftest not yet working for unknown reason, not a sensor, # but obvious a python/toolchain issue #trigger_selftest(bmi08x_accel) except Exception as e: print('Fehler: ' + str(e)) board.SetVDD(0) board.SetVDDIO(0) board.ClosePCInterface(
For customer usage, you need to download the sensor driver package from the website to communicate with sensor after connecting the BMP388 chip to your developing board. You can find the information from the following link https://github.com/BoschSensortec/BMP3-Sensor-API.
The procedure of using BMP388 sensor API is presented in the following flow chart:
The detailed example code for integration of API could be found in:
https://github.com/BoschSensortec/BMP3-Sensor-API/blob/master/README.md
Following steps need to be considered to ensure the API/sensor configured correctly.
For reading the data information from API, the following example can follow
1.The following static function should be added into your own project
static int64_t compensate_temperature
static uint64_t compensate_pressure
static double bmp3_pow
static void parse_calib_data
static double compensate_temperature_d
static double compensate_pressure_d
2.Define the main function to print the data, the structure for BMP3 and put the trimming data into the correct position as follow. One example shown below
calib_data->reg_calib_data.par_t1 = (int16_t)27402;
calib_data->reg_calib_data.par_t2 = (int16_t)18868;
calib_data->reg_calib_data.par_t3 = (int8_t)-10;
calib_data->reg_calib_data.par_p1 = (int16_t)-244; calib_data->reg_calib_data.par_p2 = (int16_t)-3254;
calib_data->reg_calib_data.par_p3 = (int8_t)35;
calib_data->reg_calib_data.par_p4 = (int8_t)0; calib_data->reg_calib_data.par_p5 = (int16_t)25879;
calib_data->reg_calib_data.par_p6 = (int16_t)31477; calib_data->reg_calib_data.par_p7 = (int8_t)-13; calib_data->reg_calib_data.par_p8 = (int8_t)-10; calib_data->reg_calib_data.par_p9 = (int16_t)16342;
calib_data->reg_calib_data.par_p10 = (int8_t)29;
calib_data->reg_calib_data.par_p11 = (int8_t)-60;
3.Give the correct default value to the uncompensated temperature and pressure, define the version to temperature and pressure.
uncomp_data->pressure = 8241776;
uncomp_data->temperature = 8329880;
double temp = compensate_temperature_d(uncomp_data, calib_data);
double press = compensate_pressure_d(uncomp_data, calib_data);
double tempurature = temp;
double pressure = press;
4.Print out the final value
printf("Temperature\t Pressure\t\n");
printf("%0.2f\t\t %0.2f\t\t\n", tempurature, pressure);
system("pause");
General Description
The BME280 is a combined digital humidity, pressure and temperature sensor based on proven sensing principles.
The API can be downloaded from Github. The BSEC can be downloaded from the Bosch Sensortec website.
Sensor Data
The humidity sensor data is expressed as a percentage (10% - 90% at 0°C-65°C).
The pressure sensor data is in hPa (300hPa - 1100hPa at 0°C-65°C).
The temperature sensor data is in °C (-40°C - 85°C).
The function bme280_get_sensor_data in the API is used to get the sensor data.
Accuracy
The accuracy represents how accurate the sensor can be under certain condition.
Table 1 lists the accuracy of humidity sensor, pressure sensor, and temperature sensor.
Pressure Sensor Drift
The pressure sensor drift represents the error in the measured value. Basically, there are two drifts on the pressure part in the BME280, i.e. solder drift and long-term drift.
Pressure Sensor TCO
The TCO (offset temperature coefficient) is the change in the pressure signal caused by a change in the temperature.
For the pressure sensor, the TCO is ±1.5 Pa/K, equivalent to ±12.6 cm at 1 °C temperature change, which means the pressure sensor data changes within ±1.5 Pa, with 1 °C temperature change at constant pressure.
Working Mode
The BME280 can be operated in three working modes: sleep mode, normal mode, and force mode, which can be selected using the mode [1:0] setting (in register 0xF4 [1:0], sleep mode -> b11, force mode -> b10 and b01, normal mode -> b11). The function bme280_set_sensor_mode in the API can also used to set power mode.
During the measurement cycle, the BME280 measures temperature, pressure and humidity, with optional oversampling.
After the measurement cycle, the pressure and temperature data can be passed through an optional IIR filter, which removes short-term fluctuations in pressure (e.g. caused by slamming a door). For humidity, such a filter is not needed and has not been implemented.
Humidity/Pressure/Temperature OSR
Oversampling can be enabled during the measurement, which can reduce noise but also consumes more power. Different sensors have different OSRs (oversampling rate).
The osrs_h<2:0> settings are explained as follows:
b000-> skip humidity data/no humidity
b001-> oversamplingx1
b010-> oversamplingx2
b011-> oversamplingx4
b100-> oversamplingx8
b101, and other settings -> oversamplingx16
The osrs_p<4:2> settings are explained as follows:
b000-> skip humidity data/no humidity
b001-> oversamplingx1
b010-> oversamplingx2
b011-> oversamplingx4
b100-> oversamplingx8
b101, and other settings-> oversamplingx16
The osrs_t<7:5> settings are explained as follows:
b000-> skip humidity data/no humidity
b001-> oversamplingx1
b010-> oversamplingx2
b011-> oversamplingx4
b100-> oversamplingx8
b101, and other settings-> oversamplingx16
The function bme280_set_sensor_settings in the API can also be used to set the OSR for any sensor. See below for the example.
...
int8_t rslt;
uint8_t settings_sel; dev->settings.osr_h = BME280_OVERSAMPLING_1X;
dev->settings.osr_p = BME280_OVERSAMPLING_16X;
dev->settings.osr_t = BME280_OVERSAMPLING_2X;
... settings_sel = BME280_OSR_PRESS_SEL | BME280_OSR_TEMP_SEL | BME280_OSR_HUM_SEL | BME280_FILTER_SEL; rslt = bme280_set_sensor_settings(settings_sel, dev);
....
return rslt;
...
Signal Filter
The environmental pressure is subject to many short-term changes caused by, for example, door or window slamming, wind blowing into the sensor, etc. The BME280 features an internal IIR filter which can suppress these disturbances in the output data without causing additional interface traffic and processor workload. By setting the filter coefficient (c), the bandwidth of the temperature and pressure output signals can be effectively reduced and the resolution of the pressure and temperature output data can be increased to 20 bits. The output of the next measurement step is filtered using the following formula:
Where, data_filter_old is the data coming from the current filter memory. data_ADC is the data coming from current ADC acquisition. data_filtered is the new value of filter memory and the value that will be sent to the output registers.
The filter<4:2> settings are explained as follows:
b000-> Filter off
b001-> filter coefficient 2
b010-> filter coefficient 4
b011-> filter coefficient 8
b100, and other settings-> filter coefficient 16
The function bme280_set_sensor_settings in the API can also be used to set filter. See below for the example.
...
int8_t rslt;
uint8_t settings_sel; ...
dev->settings.filter = BME280_FILTER_COEFF_16;
... settings_sel = BME280_OSR_PRESS_SEL | BME280_OSR_TEMP_SEL | BME280_OSR_HUM_SEL | BME280_FILTER_SEL;
... rslt = bme280_set_sensor_settings(settings_sel, dev);
...
return rslt;
Introduction
This document is meant as a reference guide on how to design using Bosch Sensortec’s BHy1. BHy1 family includes two parts, one is BHA250 series, the other is BHI160 series.
Selecting the right part
The BHA250 contains part number: BHA250 and BHA250B. The BHA250/BHA250B is sensor hub which integrated Accelerometer. Figure1 shows the BHA250 laser marking.
Fig1
The BHI160 contains part number: BHI160and BHI160B. The BHI160/ BHI160B is smart sensor which integrated IMU(ACC+Gyro). Figure2 shows the laser marking.
Fig2
Common Characteristics
Key features
1xI2C(3.4MHz) Host Interface; 1xI2C(1MHz) Aux Interface; up to 3 GPIOs
32-bit Floating-point; 96 KB ROM; 48 KB RAM
Max ODR is 200Hz
Difference between products
Table 1: Difference on BHA250 and BHI160
Table 2: Accelerometer Parameter on BHA250 and BHI160
Table 3: BHI160 Gyroscope Parameter
Available evaluation tools and software
To best to evaluate the products from the BHy1 family is the following combination of evaluation tools:
COINES Desktop software
Application board 2.0
Sensor Shuttle board
BHI160/BHI160B Shuttle board
BHI250/BHA250B Shuttle board
Reference design
See Figure 3 for BHA250 schematic of a typical use-case.
Figure3 BHA250/BHA250B typical schematic
Bill of materials:
Note: R3 and R4 are mandatory, even if no external sensor is attached.
Layout recommendations
Landing Pattern
Figure5: BHA250/BHA250B Landing Pattern
Figure6: BHI160/BHI160B Landing Pattern
Typical Layout
Figure7: BHA250/BHA250B Layout
Figure8: BHI160/BHI160B Layout
Manufacturing notes
BHy1 on COINES
COINES setup
Platform: Windows
gcc: "C:\DiaSemi\SmartSnippetsStudio\Tools\mingw64_targeting32\bin\gcc.exe C:\TDM-GCC-64\bin\gcc.exe".
[ MKDIR ] build
[ CC ] bhy_activity_recognition.c
[ CC ] ../../../../sensorAPI/bhy/src/BHy_support.c
[ CC ] ../../../../sensorAPI/bhy/src/bhy_uc_driver.c
[ CC ] ../../../../sensorAPI/bhy/src/bhy.c
[ CC ] ../../../../sensorAPI/bhy/AppBoard_usb_driver/AppBoard_usb_driver.c
[ MAKE ] coinesAPI
[ MKDIR ] build
[ CC ] coines.c
[ CC ] comm_intf/comm_intf.c
[ CC ] comm_intf/comm_ringbuffer.c
[ CC ] comm_driver/usb.c
[ CC ] comm_driver/legacy_usb/legacy_usb_support.c
[ AR ] libcoines
[ LD ] bhy_activity_recognition.exe
Operation finished successfully
Running on BHy1 shuttle board
Connect with APP2.0 board (BHy1 Shuttle board) and compile the sample code (..\..\examples\c\bhy\rotation_vector),
Click to run and get the output on the console.
Running example 'bhy_rotation_vector.exe' ... uploading RAM patch... W: 1.000 X: 0.000 Y: 0.000 Z: 0.000 W: 1.000 X:-0.000 Y: 0.000 Z: 0.000 W: 1.000 X:-0.000 Y: 0.000 Z: 0.000 W: 0.999 X: 0.005 Y: 0.018 Z: 0.000 W: 0.999 X: 0.005 Y: 0.018 Z: 0.000 W: 0.999 X: 0.005 Y: 0.018 Z: 0.000 W: 0.999 X: 0.005 Y: 0.018 Z: 0.000
BHy1 example code on COINES
Activity recognition example
Data parsing for activity recognition is available in COINES. The user can open the “bhy_activity_recognition.c” in COINES, compile and run. The output will be shown in the COINES console.
The code is shown as below.
/* @brief This API is used for parsing the activity recognition data from BHY
*
* @param[in] sensor_data: bhy data
* @param[in] sensor_id: bhy id
*
* @return void
*
*/
void sensors_callback(bhy_data_generic_t * sensor_data, bhy_virtual_sensor_t sensor_id)
{
float temp;
u8 index;
/* Since a timestamp is always sent before every new data, and that the callbacks */
/* are called while the parsing is done, then the system timestamp is always equal */
/* to the sample timestamp. (in callback mode only) */
temp = g_system_timestamp / 3200000.; for (index = 6; index <= 8; index++)
{
outBuffer[index] = floorf(temp) + '0';
temp = (temp - floorf(temp)) * 10;
} for (index = 10; index <= 12; index++)
{
outBuffer[index] = floorf(temp) + '0';
temp = (temp - floorf(temp)) * 10;
}
/* if there are no changes then it will read X */
outBuffer[22] = 'X';
outBuffer[35] = 'X';
outBuffer[48] = 'X';
outBuffer[61] = 'X';
outBuffer[74] = 'X';
outBuffer[87] = 'X'; /* '0' means "end of activity and '1' means start of activity */
if (sensor_data->data_scalar_u16.data & 0b0000000000000001)
outBuffer[22] = '0';
if (sensor_data->data_scalar_u16.data & 0b0000000000000010)
outBuffer[35] = '0';
if (sensor_data->data_scalar_u16.data & 0b0000000000000100)
outBuffer[48] = '0';
if (sensor_data->data_scalar_u16.data & 0b0000000000001000)
outBuffer[61] = '0';
if (sensor_data->data_scalar_u16.data & 0b0000000000010000)
outBuffer[74] = '0';
if (sensor_data->data_scalar_u16.data & 0b0000000000100000)
outBuffer[87] = '0';
if (sensor_data->data_scalar_u16.data & 0b0000000100000000)
outBuffer[22] = '1';
if (sensor_data->data_scalar_u16.data & 0b0000001000000000)
outBuffer[35] = '1';
if (sensor_data->data_scalar_u16.data & 0b0000010000000000)
outBuffer[48] = '1';
if (sensor_data->data_scalar_u16.data & 0b0000100000000000)
outBuffer[61] = '1';
if (sensor_data->data_scalar_u16.data & 0b0001000000000000)
outBuffer[74] = '1';
if (sensor_data->data_scalar_u16.data & 0b0010000000000000)
outBuffer[87] = '1'; fprintf(stderr, "%s", outBuffer);
/* activity recognition is not time critical, so let's wait a little bit */
mdelay(200);
}
Gesture recognition example
Data parsing for gesture recognition is available in COINES. The user can open the “bhy_gesture_recognition.c” in COINES, compile and run. The output will be shown in COINES console.
In the example code, three gestures are enabled, which are “Glance, Pickup and Significant Motion”. The code is shown as below.
/* @brief This API is used for parsing the activity recognition data from BHY
*
* @param[in] sensor_data: bhy data
* @param[in] sensor_id: bhy id
*
* @return void
*
*/
void sensors_callback(bhy_data_generic_t * sensor_data, bhy_virtual_sensor_t sensor_id)
{
float temp;
u8 index;
/* Since a timestamp is always sent before every new data, and that the callbacks */
/* are called while the parsing is done, then the system timestamp is always equal */
/* to the sample timestamp. (in callback mode only) */
temp = g_system_timestamp / 3200000.; for (index = 6; index <= 8; index++)
{
outBuffer[index] = floorf(temp) + '0';
temp = (temp - floorf(temp)) * 10;
} for (index = 10; index <= 12; index++)
{
outBuffer[index] = floorf(temp) + '0';
temp = (temp - floorf(temp)) * 10;
} sensor_id &= 0x1F;
/* gesture recognition sensors are always one-shot, so you need to */
/* re-enable them every time if you want to catch every event */
bhy_enable_virtual_sensor(sensor_id, VS_WAKEUP, 1, 0, VS_FLUSH_NONE, 0, 0); switch (sensor_id)
{
case VS_TYPE_GLANCE:
strcpy(&outBuffer[24], "Glance \r\n");
break;
case VS_TYPE_PICKUP:
strcpy(&outBuffer[24], "Pickup \r\n");
break;
case VS_TYPE_SIGNIFICANT_MOTION:
strcpy(&outBuffer[24], "Sig motion\r\n");
break;
default:
strcpy(&outBuffer[24], "Unknown \r\n");
break;
} fprintf(stderr, "%s", outBuffer);
fflush(stderr);
}
Gravity vector example
Data parsing for gravity vector is available in COINES. The user can open the “bhy_gravity_vector.c” in COINES, compile and run. The output will be shown in COINES console.
The code is shown as below.
/* @brief This API is used for parsing the activity recognition data from BHY
*
* @param[in] sensor_data: bhy data
* @param[in] sensor_id: bhy id
*
* @return void
*
*/
void sensors_callback(bhy_data_generic_t * sensor_data, bhy_virtual_sensor_t sensor_id)
{
float temp;
u8 index; temp = sensor_data->data_vector.x / 8192.;
outBuffer[3] = temp < 0 ? '-' : ' ';
temp = temp < 0 ? -temp : temp;
outBuffer[4] = floorf(temp) + '0'; for (index = 6; index <= 8; index++)
{
temp = (temp - floorf(temp)) * 10;
outBuffer[index] = floorf(temp) + '0';
} temp = sensor_data->data_vector.y / 8192.;
outBuffer[13] = temp < 0 ? '-' : ' ';
temp = temp < 0 ? -temp : temp;
outBuffer[14] = floorf(temp) + '0'; for (index = 16; index <= 18; index++)
{
temp = (temp - floorf(temp)) * 10;
outBuffer[index] = floorf(temp) + '0';
} temp = sensor_data->data_vector.z / 8192.;
outBuffer[23] = temp < 0 ? '-' : ' ';
temp = temp < 0 ? -temp : temp;
outBuffer[24] = floorf(temp) + '0'; for (index = 26; index <= 28; index++)
{
temp = (temp - floorf(temp)) * 10;
outBuffer[index] = floorf(temp) + '0';
} fprintf(stderr, "%s", outBuffer);
fflush(stderr);
}
Rotation vector example
Data parsing for Rotation Vector is available in COINES. The user can open the “bhy_rotation_vector.c” in COINES, compile and run. The output will be shown in COINES console.
The code is shown as below.
/* @brief This API is used for parsing the activity recognition data from BHY
*
* @param[in] sensor_data: bhy data
* @param[in] sensor_id: bhy id
*
* @return void
*
*/
void sensors_callback(bhy_data_generic_t * sensor_data, bhy_virtual_sensor_t sensor_id)
{
float temp;
u8 index; temp = sensor_data->data_quaternion.w / 16384.;
outBuffer[3] = temp < 0 ? '-' : ' ';
temp = temp < 0 ? -temp : temp;
outBuffer[4] = floorf(temp) + '0'; for (index = 6; index <= 8; index++)
{
temp = (temp - floorf(temp)) * 10;
outBuffer[index] = floorf(temp) + '0';
} temp = sensor_data->data_quaternion.x / 16384.;
outBuffer[13] = temp < 0 ? '-' : ' ';
temp = temp < 0 ? -temp : temp;
outBuffer[14] = floorf(temp) + '0'; for (index = 16; index <= 18; index++)
{
temp = (temp - floorf(temp)) * 10;
outBuffer[index] = floorf(temp) + '0';
} temp = sensor_data->data_quaternion.y / 16384.;
outBuffer[23] = temp < 0 ? '-' : ' ';
temp = temp < 0 ? -temp : temp;
outBuffer[24] = floorf(temp) + '0'; for (index = 26; index <= 28; index++)
{
temp = (temp - floorf(temp)) * 10;
outBuffer[index] = floorf(temp) + '0';
} temp = sensor_data->data_quaternion.z / 16384.;
outBuffer[33] = temp < 0 ? '-' : ' ';
temp = temp < 0 ? -temp : temp;
outBuffer[34] = floorf(temp) + '0'; for (index = 36; index <= 38; index++)
{
temp = (temp - floorf(temp)) * 10;
outBuffer[index] = floorf(temp) + '0';
} fprintf(stderr, "%s", outBuffer);
fflush(stderr); }
Create customer example
Customer can create their own case based on the sensor they used in the folder “examples”, for example, BHI160 Shuttle board, we can create a new folder “acc_gyro data output”
Create the file and copy “Makefile” from other bhy example(like gravity_vector)
Modify the Makefile
#CCE_Board_Definitions:BHI160;BHI160B;BHA250;BHA250B COINES_INSTALL_PATH ?= ../../../.. EXAMPLE_FILE ?= acc_gyro data output.c SHUTTLE_BOARD ?= BHI160 CFLAGS += -DBST_APPBOARD_VIA_USB -D$(SHUTTLE_BOARD) include $(COINES_INSTALL_PATH)/examples/c/examples.mk
Now, you can make, compile and run your own code via COINES.
Further reads
BHA250/BHA250B Datasheet
BHI160/BHI160B Datasheet
BHy1 Handling, Soldering & Mounting Instructions
BHy1 MCU Driver Porting Guide
BHy1 Interfacing reference code from generic driver
BME680 is as combined digital gas, humidity, pressure and temperature sensor based on proven sensing principles.
API Link: https://github.com/BoschSensortec/BME680_driver
BSEC Link: https://www.bosch-sensortec.com/bst/products/all_products/bme680
Sensor data type
Gas sensor data is gas sensor resistance.
Humidity sensor data is in type of percentage (10%-90%, in 0°C-65°C).
Pressure sensor data is in type of hPa (300hPa-1100hPa, in 0°C-65°C).
Temperature sensor data is in type of °C (-40°C-85°C).
Use function bme680_get_sensor_data in API to get sensor data.
Use BSEC software Library, put gas/humidity/pressure/temperature sensor data as inputs into BSEC, you can also get IAQ(Indoor Air Quality) from outputs.
Measurement preiod
The BME680 measurement period consists of a temperature, pressure and humidity measurement with selectable oversampling. Moreover, it contains a heating phase for the gas sensor hot plate as well as a measurement of the gas sensor resistance.
After the measurement period, the pressure and temperature data can be passed through an optional IIR filter, which removes short-term fluctuations in pressure (e.g. caused by slamming a door). For humidity and gas, such a filter is not needed and has not been implemented
Gas resistance sensitivity
The sensitivity of BME680 to certain target gas is gas_resistance/gas_resistance_base. The sensitivity equaling to 1 means BME680 is not sensitivity in this concentration of the target gas, while the less value in sensitivity, the more sensitive BME680 to the target gas.
Data Interrupt
There is new data interrupt in BME680, below table shows how to enable this feature.
Pressure sensor drift
Used to represent errors in measured values. Basically, two drifts will appear on the pressure part in BME680: one is solder drifts and the other is long term drift.
Pressure sensor offset temperature coefficient (TCO)
TCO is the change in the pressure signal introduced by a change of the temperature.
For pressure sensor, TCO is ±1.5 Pa/K, equiv. to ±12.6 cm at 1 °C temperature change, which means pressure sensor data will change within ±1.5 Pa with 1 °C temperature change at constant pressure.
Accuracy of temperature/pressure/humidity
This feature is used to represent how much accuracy can be achieved on certain condition.
Humidity sensor:
±3 % relative humidity, on condition: 20-80 %r.H., 25°C, including hysteresis
Pressure sensor:
0.12 hPa, on condition: 25°C-40°C, 700-1100hPa, at constat humidity
Temperature Sensor:
±1°C, on condition: 25°C
±0.5°C, on condition: 0…65°C
OSR / Oversampling of humidity/pressure/temperature
There are several oversampling options for different sensors. It is possible to reduce noise, but the power consumption will be higher.
Humidity sensor OSR
As for how to set osrs_h<2:0>, b000->skip humidity data/no humidity, b001->oversamplingx1, b010->oversamplingx2, b011->oversamplingx4, b100->oversamplingx8, b101/Others->oversamplingx16.
Pressure sensor OSR
As for how to set osrs_p<4:2>, b000->skip humidity data/no humidity, b001->oversamplingx1, b010->oversamplingx2, b011->oversamplingx4, b100->oversamplingx8, b101/Others->oversamplingx16.
Temperature sensor OSR
As for how to set osrs_t<7:5>, b000->skip humidity data/no humidity, b001->oversamplingx1, b010->oversamplingx2, b011->oversamplingx4, b100->oversamplingx8, b101/Others->oversamplingx16.
You can use function bme680_set_sensor_settings in API to set OSR of any sensor.
Signal filter
The environmental pressure is subject to many short-term changes, caused e.g. by slamming of a door or window, or wind blowing into the sensor. To suppress these disturbances in the output data without causing additional interface traffic and processor work load, the BME680 features an internal IIR filter. Via setting filter coefficient(c), it effectively reduces the bandwidth of the temperature and pressure output signals and increases the resolution of the pressure and temperature output data to 20 bit(Pressure and Temperature OSR must be non-zero). When c is bigger, response time will be longer.
As for how to set filter<4:2>, b000->filter coefficient 0, b001-> filter coefficient 1, b010-> filter coefficient 3, b011-> filter coefficient 7, b100-> filter coefficient 15, b101-> filter coefficient 31, b110-> filter coefficient 63, b111-> filter coefficient 127.
You can use function bme680_set_sensor_settings in API to set filter.
Introduction
This document is intended as a reference guide on how to design using Bosch Sensortec’s BMI08x series IMU.
It describes the main features of the BMI08x family, available evaluation tools and software, reference design, layout recommendations, and gives instructions on how to test the BMI08x family’s functionality using sample codes, and how to demonstrate and evaluate it with COINES.
Selecting the right part
The BMI08x family has two products: BMI085 and BMI088, which are ideally suited for high-performance consumer applications.
The BMI085 is designed for virtual augmented and mixed reality applications, high-end gaming, platform stabilization applications such as image stabilization, as well as indoor navigation and dead reckoning, such as robotics applications.
The BMI088 is designed for applications in harsh vibration environments such as drones and robotics. The IMU is designed to effectively suppress vibration above several hundred Hz, which may occasionally occur due to resonance on the PCB or the structure of the total system.
Table 1 shows an overview of the features.
Table 1: Overview of the features
Key features
This section describes the key features of the BMI08x family.
Good stability of TCO, TCS, bias and stress
Low latency
BMI088 has vibration robustness and suppression
BMI085 has integrated accelerometer and gyroscope data synchronization function
Differences between products
The main differences between the BMI08x family products are the accelerometer part and the overall performance of the MEMS element.
Table 2: Main differences
Available evaluation tools and software
To best evaluate the BMI08x family, the following combination of evaluation tools is recommended:
COINES Desktop software (Windows version &Linux version & MacOS)
Development Desktop Software
Application board 2.0
Sensor shuttle board
BMI085 shuttle board
BMI088 shuttle board
Hardware reference design
Figure 1 and Figure 2 show the I2C and SPI reference designs for BMI085 and BMI088
Figure 1: I2C connection
Figure 2: SPI connection
Bill of materials
Table 3 lists the bill of necessary materials.
Table 3: Bill of materials
Layout recommendations
Because the BMI08x sensor family contains tiny mechanical structures inside the package, care must be taken during the layout phase to ensure optimum performance. The complete handing and soldering guide can be found on the Bosch Sensortec’s website.
The typical manufacturing procedures for the BMI08x IMU are described in the following sections.
Recommended layout rules
The recommended layout rules are as follows:
PCB land width = LGA solder pin width
PCB land length = LGA solder pin length + 0.1mm on each side
Solder mask opening width = PCB land width + 0.05mm on each side
Solder mask opening length = PCB land
Landing Pattern
The BMI08x family has the same landing pattern. The following dimensioning is recommended.
Figure 3: Recommended landing pattern (top view, in mm)
Typical Layout
Figure 4 shows the typical layout.
Figure 4: Typical layout
Manufacturing notes
Table 4 lists the recommendations for the manufacture.
Table 4: Manufacture recommendations
First power-on
This chapter describes how to test the BMI08x family’s functionality and performance after powering it on for the first time.
To properly initialize the device, the user must decide which interface to use (I2C or SPI) during hardware design. With the PS pin, the user can determine which interface the sensor should listen to. The gyroscope part of the BMI08x initializes its I/O pins according to the selection given by the PS pin. The accelerometer part starts and remains in I2C mode. When a rising edge is detected on the CSB1 pin (chip select of the accelerometer), the accelerometer part switches to SPI mode and remains until the next power-up reset. To switch the accelerometer to SPI mode, the user can perform a dummy SPI read operation during the initialization phase.
After the power-on reset, the gyroscope enters normal mode, while the accelerometer enters suspend mode. To switch the accelerometer to normal mode, do the following:
Power up the sensor.
Wait for 1ms
Enter normal mode by writing ‘4’ to ACC_PWR_CTRL.
Wait for 50ms. The accelerometer enters normal mode.
Below are some example codes for performing tests based on BMI08x shuttle board and API, using the COINES software as the host. To test the BMI08x family’s functionality, do the following:
1) Initialize the sensor driver API interface (based on GenAPI and COINES as example)
/*! * @brief this internal API is used to set the sensor driver interface to * read/write the data. * * @param[in] void * * @return void * */
static void init_bmi08x_sensor_driver_interface(void)
{
#if BMI08x_INTERFACE_I2C==1 /* I2C setup */ /* link read/write/delay function of host system to appropriate * bmi08x function call prototypes */ bmi08xdev.write = coines_write_i2c; bmi08xdev.read = coines_read_i2c; bmi08xdev.delay_ms = coines_delay_msec; /* set correct i2c address */ bmi08xdev.accel_id = (unsigned char) BMI08x_ACCEL_DEV_ADDR; bmi08xdev.gyro_id = (unsigned char) BMI08x_GYRO_DEV_ADDR; bmi08xdev.intf = BMI08X_I2C_INTF;
#endif
#if BMI08x_INTERFACE_SPI==1 /* SPI setup */ /* link read/write/delay function of host system to appropriate * bmi08x function call prototypes */ bmi08xdev.write = coines_write_spi; bmi08xdev.read = coines_read_spi; bmi08xdev.delay_ms = coines_delay_msec; bmi08xdev.intf = BMI08X_SPI_INTF; bmi08xdev.accel_id = COINES_SHUTTLE_PIN_8; bmi08xdev.gyro_id = COINES_SHUTTLE_PIN_14;
#endif
}
2) Set up the communication between Bosch Sensortec application board 2.0 and PC, and get the board hardware and software information.
struct coines_board_info board_info; int16_t rslt; rslt = coines_open_comm_intf(COINES_COMM_INTF_USB); if (rslt < 0) { printf("\n Unable to connect with Application Board ! \n" " 1. Check if the board is connected and powered on. \n" " 2. Check if Application Board USB driver is installed. \n" " 3. Check if board is in use by another application. (Insufficient permissions to access USB) \n"); exit(rslt); } rslt = coines_get_board_info(&board_info); if (rslt == COINES_SUCCESS) { if ((board_info.shuttle_id != BMI085_SHUTTLE_ID) && (board_info.shuttle_id != BMI088_SHUTTLE_ID)) { printf("! Warning invalid sensor shuttle \n ," "This application will not support this sensor \n"); exit(COINES_E_FAILURE); } }
3)Initialize the sensor interface, protocol, and power on VDD and VDDIO.
/*********************************************************************/
/* functions */
/*! * @brief This internal API is used to initialize the sensor interface depending * on selection either SPI or I2C. * * @param[in] void * * @return void * */
static void init_sensor_interface(void)
{ /* Switch VDD for sensor off */ coines_set_shuttleboard_vdd_vddio_config(0, 0); coines_delay_msec(10);
#if BMI08x_INTERFACE_I2C==1 /* set the sensor interface as I2C with 400kHz speed*/ coines_config_i2c_bus(COINES_I2C_BUS_0, COINES_I2C_FAST_MODE); coines_delay_msec(10); /* PS pin is made high for selecting I2C protocol*/ coines_set_pin_config(COINES_SHUTTLE_PIN_9, COINES_PIN_DIRECTION_OUT, COINES_PIN_VALUE_HIGH);
#endif
#if BMI08x_INTERFACE_SPI==1 /* CS pin is made high for selecting SPI protocol*/ coines_set_pin_config(COINES_SHUTTLE_PIN_8, COINES_PIN_DIRECTION_OUT, COINES_PIN_VALUE_HIGH); /* CS pin is made high for selecting SPI protocol*/ coines_set_pin_config(COINES_SHUTTLE_PIN_14, COINES_PIN_DIRECTION_OUT, COINES_PIN_VALUE_HIGH); /* PS pin is made low for selecting SPI protocol*/ coines_set_pin_config(COINES_SHUTTLE_PIN_9, COINES_PIN_DIRECTION_OUT, COINES_PIN_VALUE_LOW); coines_delay_msec(10); coines_config_spi_bus(COINES_SPI_BUS_0, COINES_SPI_SPEED_5_MHZ, COINES_SPI_MODE3);
#endif coines_delay_msec(10); /* Switch VDD for sensor on */ coines_set_shuttleboard_vdd_vddio_config(3300, 3300);
}
4) After a delay of approximately 200ms, call the BMI08x API to initialize the BMI08x, including its power mode, ODR, bandwidth, range.
/*! * @brief This internal API is used to initialize the bmi08x sensor * settings like power mode and OSRS settings. * * @param[in] void * * @return void * */
static void init_bmi08x(void)
{ if (bmi08a_init(&bmi08xdev) == BMI08X_OK && bmi08g_init(&bmi08xdev) == BMI08X_OK) { printf("BMI08x initialization success !\n"); printf("Accel chip ID - 0x%x\n", bmi08xdev.accel_chip_id); printf("Gyro chip ID - 0x%x\n", bmi08xdev.gyro_chip_id); } else { printf("BMI08x initialization failure !\n"); exit(COINES_E_FAILURE); } bmi08xdev.accel_cfg.odr = BMI08X_ACCEL_ODR_1600_HZ;
#if BMI08X_FEATURE_BMI085 == 1 bmi08xdev.accel_cfg.range = BMI085_ACCEL_RANGE_16G;
#elif BMI08X_FEATURE_BMI088 == 1 bmi08xdev.accel_cfg.range = BMI088_ACCEL_RANGE_24G;
#endif bmi08xdev.accel_cfg.power = BMI08X_ACCEL_PM_ACTIVE; //user_accel_power_modes[user_bmi088_accel_low_power]; bmi08xdev.accel_cfg.bw = BMI08X_ACCEL_BW_NORMAL; /* Bandwidth and OSR are same */ bmi08a_set_power_mode(&bmi08xdev); coines_delay_msec(10); bmi08a_set_meas_conf(&bmi08xdev); coines_delay_msec(10); bmi08xdev.gyro_cfg.odr = BMI08X_GYRO_BW_230_ODR_2000_HZ; bmi08xdev.gyro_cfg.range = BMI08X_GYRO_RANGE_250_DPS; bmi08xdev.gyro_cfg.bw = BMI08X_GYRO_BW_230_ODR_2000_HZ; bmi08xdev.gyro_cfg.power = BMI08X_GYRO_PM_NORMAL; bmi08g_set_power_mode(&bmi08xdev); coines_delay_msec(10); bmi08g_set_meas_conf(&bmi08xdev); coines_delay_msec(10); }
5. Call the BMI08x API to read Acc and Gyro data in a while loop.
int times_to_read = 0; while (times_to_read < 10) { bmi08a_get_data(&bmi08x_accel, &bmi08xdev); printf("ax:%d ay:%d az:%d\n", bmi08x_accel.x, bmi08x_accel.y, bmi08x_accel.z); bmi08g_get_data(&bmi08x_gyro, &bmi08xdev); printf("gx:%d gy:%d gz:%d\n", bmi08x_gyro.x, bmi08x_gyro.y, bmi08x_gyro.z); fflush(stdout); coines_delay_msec(10); times_to_read = times_to_read + 1; } coines_close_comm_intf(COINES_COMM_INTF_USB);
Calibration
Both accelerometer part and gyroscope part of the BMI08x are pre-trimmed at the factory. However, the soldering process and PCB bending due to assembly can result in offset changing; therefore, it is recommended to calibrate the sensor after assembling the device into the device housing.
The acceleration sensor offset consists of two parts: the static “unwanted” offset mainly due to soldering drift, and the offset generated when an acceleration is applied to the sensor. The latter depends on the applied acceleration and its magnitude if defined by the sensor’s sensitivity. However, the sensitivity has a certain tolerance (typ. <1%). This means that in order to compensate for the static offset, the sensor must be oriented in such a way that no external acceleration is applied to the sensing axis. As gravity also causes a sensor signal, the sensing axis must be oriented perpendicular to the gravity field.
The compensation process described below focuses on the x/y-axis. The z-axis can also be compensated in the same way, but the user has to consider the applied gravity. Alternatively, the process can be repeated after turning the device, with the z-axis perpendicular to the gravity vector.
Place your sensor (the system with the sensor inside) on a well-defined surface, for example, a horizontal table. The expected sensor output for the x/y-axis should be 0 mg.
Set the sensor to the lowest g-range (BMI085 to 2G, BMI088 to 3G)
Measure the sensor output to ensure the sensor is fully at rest, without vibrations, inclinations, big temperature changes or strong VDD fluctuations. It is advisable to take several values and generate the average over the values (e.g. 1000 values).
Consider the resolution of BMI085 and BMI088, and save the offset in LSB or mg.
Subtract the offset from the future accelerometer sensor data.
The gyroscope part of the BMI08x has outstanding offset performance and very high offset stability. However, small offsets may still occur and change over the operation time (mainly due to changes in the operation temperature).
As the needs vary from application to application, the application should take care of the offset compensation. To do this, the application has to ensure that the gyroscope is fully at rest when compensating for the offset. Only at rest the static offset can be separated from any motion-based offset. This can be achieved for example by monitoring the accelerometer signals of all axes and checking the noise of each axis. If the noise is below certain threshold (application specific), the application can assume that the sensor is at rest.
While monitoring, the device remains at rest and the host can read sensor values, for example, for ten seconds. The average of the gathered values per axis shows the residual offset and can be subtracted from any future the sensor data.
Example code
The code below shows how to read the BMI08x sensor data via BMI08x API and COINES system.
/*! * @brief This internal API is used to read sensor data * * @param[in] void * * @return void * */
void read_sensor_data(void)
{ int16_t rslt; int counter = 0; uint8_t lsb, msb; int16_t ax, ay, az, gx, gy, gz; uint32_t valid_sample_count = 0; int idx = 0; int buffer_index = 0; while (counter < 1000) { memset(&bmi08x_accel_stream_buffer[0], 0, COINES_STREAM_RSP_BUF_SIZE); rslt = coines_read_stream_sensor_data(1, 1, &bmi08x_accel_stream_buffer[0], &valid_sample_count); if (rslt == COINES_SUCCESS) { buffer_index = 0; for (idx = 0; idx < valid_sample_count; idx++) {
#if BMI08x_INTERFACE_SPI==1 buffer_index++; //dummy byte; ignore for spi
#endif lsb = bmi08x_accel_stream_buffer[buffer_index++]; msb = bmi08x_accel_stream_buffer[buffer_index++]; ax = (msb << 8) | lsb; lsb = bmi08x_accel_stream_buffer[buffer_index++]; msb = bmi08x_accel_stream_buffer[buffer_index++]; ay = (msb << 8) | lsb; lsb = bmi08x_accel_stream_buffer[buffer_index++]; msb = bmi08x_accel_stream_buffer[buffer_index++]; az = (msb << 8) | lsb; printf("ax: %-5d \t ay: %-5d \t az: %-5d\n", ax, ay, az); fflush(stdout); } } memset(&bmi08x_gyro_stream_buffer[0], 0, COINES_STREAM_RSP_BUF_SIZE); rslt = coines_read_stream_sensor_data(2, 1, &bmi08x_gyro_stream_buffer[0], &valid_sample_count); if (rslt == COINES_SUCCESS) { buffer_index = 0; for (idx = 0; idx < valid_sample_count; idx++) { lsb = bmi08x_gyro_stream_buffer[buffer_index++]; msb = bmi08x_gyro_stream_buffer[buffer_index++]; gx = (msb << 8) | lsb; lsb = bmi08x_gyro_stream_buffer[buffer_index++]; msb = bmi08x_gyro_stream_buffer[buffer_index++]; gy = (msb << 8) | lsb; lsb = bmi08x_gyro_stream_buffer[buffer_index++]; msb = bmi08x_gyro_stream_buffer[buffer_index++]; gz = (msb << 8) | lsb; printf("gx: %-5d \t gy: %-5d \t gz: %-5d\n", gx, gy, gz); fflush(stdout); } } coines_delay_msec(1); counter++; }
}
Further reads
Datasheets:
BMI085 Datasheet
BMI088 Datasheet
Application notes:
FIFO usage
Handing soldering and mounting instructions:
Handling, soldering & mounting instruction
Selecting the right part
The BMP series of pressure sensor contains 2 products: BMP280 and BMP388. Table 1 shows an overview of the features.
Table 1: Overview of the products in this family
Key features
LGA with metal lid package
SPI or I2C interface
Built-in IIR filter.
Differences between products
The main differences in the BMP product family are in the thickness of the package, and the overall performance of the MEMS element. BMP388 offers higher performance in a smaller package compared to BMP280. See the complete list of differences in Table 2.
Table 2: Differences between BMP product family members
Available evaluation tools and software
To best to evaluate the products from the BMP family, we recommend the following combination of evaluation tools:
COINES Desktop software (Windows version &Linux version & MacOS)
Development Desktop Software
Application board 2.0
BMP280 shuttle board
BMP388 shuttle board
Reference design
Figure 1 shows a complete schematic of a typical use case.
BMP280
BMP388
Figure 1: Exemplary Reference design
Bill of materials
Table 3: Bill of materials
Layout recommendations
Because the BMP sensor family contains tiny mechanical structure inside the package, care must be taken during the layout phase to ensure the best performance. The complete handling and soldering guide can be found on the Bosch Sensortec’s website.
BMP28x Handling, soldering & mounting instructions
BMP380 Handling,soldering & mounting instructions
In addition to the attached guidelines, see below for the typical manufacturing procedure for the BMP388 pressure sensor.
Landing Pattern
BMP280
BMP388
Figure 2: Recommended landing pattern
Typical Layout
BMP280
BMP388
Figure 3: Typical layout
Manufacturing notes
Table 4: Manufacture recommendation
First power-on
After powering on the sensor for the first time, the initial specs would be tested for communication with the device. This can be done simply by reading the chip identification code in the register 0xD0 (BMP280) 0x00 (BMP388). See below for the expected values:
Table 5: Chip IDs of the BMP product family
Here is some sample code on how to perform this test, based on the BMP388 , using the COINES software as the host.
/*! * @brief This internal API is used to check the bmp388 sensor chip ID * * @param[in] void * * @return void * */
static void init_bmp3(void)
{ int8_t rslt; rslt = bmp3_init(&bmp3Dev); if (rslt == BMP3_OK) { printf("BMP3 Initialization Success!\n"); printf("Chip ID 0x%X\n", bmp3Dev.chip_id); } else { printf("Chip Initialization failure !\n"); exit(COINES_E_FAILURE); }
}
How to read sensor data
Here is some sample code on how to read sensor data, based on the BMP388, using the COINES software as the host
/*! * @brief This internal API is used to read the streaming data in a while loop and * print in console. * * @param[in] void * * @return void */
static void read_sensor_data(void)
{ int times_to_read = 0; while (times_to_read < 200) { bmp3_get_sensor_data(BMP3_ALL, &bmp3_comp_data, &bmp3Dev); printf("T: %.2f, P: %.2f \n", (bmp3_comp_data.temperature / 100.), (bmp3_comp_data.pressure / 100.)); fflush(stdout); coines_delay_msec(10); times_to_read = times_to_read + 1; }
}
Sample code
The complete sample code shown above can be compiled and executed from the COINES installation directory (by default, C:/COINES under Windows), from the following subfolder: \examples\c\bmp3
Usage
The COINES installation provides sample code on how to turn on the sensor, configure it and read out the pressure data. COINES\v1.0\examples\c\bmp3
Sample code
/*! * @brief Main Function where the execution getting started to test the code. * * @param[in] argc * @param[in] argv * * @return status * */
int main(int argc, char *argv[])
{ int16_t rslt; struct coines_board_info board_info; init_bmp3_sensor_driver_interface(); rslt = coines_open_comm_intf(COINES_COMM_INTF_USB); if (rslt < 0) { printf("\n Unable to connect with Application Board ! \n" " 1. Check if the board is connected and powered on. \n" " 2. Check if Application Board USB driver is installed. \n" " 3. Check if board is in use by another application. (Insufficient permissions to access USB) \n"); exit(rslt); } rslt = coines_get_board_info(&board_info); if (rslt == COINES_SUCCESS) { if (board_info.shuttle_id != BMP3_SHUTTLE_ID) { printf("! Warning invalid sensor shuttle. This application will not support this sensor \r\n" "1.Check the sensor shuttle \r\n" "2.Reset the board \r\n"); exit(COINES_E_FAILURE); } } init_sensor_interface(); /* after sensor init introduce 200 msec sleep */ coines_delay_msec(200); init_bmp3(); read_sensor_data(); coines_close_comm_intf(COINES_COMM_INTF_USB); return EXIT_SUCCESS;
Further reads
Datasheets:
BMP280 Datasheet
BMP388 Datasheet
Application notes:
BMP388 self-test
Handling, soldering and mounting instructions
BMP280 HSMI
BMP388 HSMI
Introduction
This document is meant as a reference guide on how to design using Bosch Sensortec’s BMA400 accelerometer.
Selecting the right part
The BMA400 is the first ultra-low power accelerometer with anti-aliasing performance, so strictly speaking, currently there is no compatible sensors in Bosch SensorTec products. However, a comparison between BMA400 & BMA4xy series is helpful for user to understand BMA400’s performance better.
Table 1 shows an overview of the features.
Table 1 sensor main features
Common characteristics
The main characteristics of this product family are:
Key features
LGA package (12 pins), 2mm x 2mm x 0.95mm
Ultra-low power consumption: 3.5uA @800Hz to 14uA@800Hz (configurable in normal mode)
0.8uA @25Hz to 1.2uA @25Hz (configurable in low power mode)
Anti-aliasing: consecutive sampling in normal mode (not duty-cycling)
Configurable Acceleration ranges ±2g/±4g/±8g/±16g
Configurable output data rate: 12.5Hz to 800Hz (normal mode)
1 KB FIFO
Auto-low power/Auto wakeup
Activity/In-activity
Step Counter (overall device current consumption 4µA)
Activity Recognition (Walking, Running, Standing still)
Orientation detection
Tap/double tap
Free-fall detection
Wearables, position
Differences between products
BMA400 is the only one product with ultra-low power feature from Bosch Sensor tech. The key parameters are listed in Table 2.
Table 2 Key parameters of BMA400
Available evaluation tools and software
To best to evaluate the products from the BMA400 family is the following combination of evaluation tools:
COINES Desktop software,
BST_download_page -> ‘Software’ Tap -> ‘Communication with Inertial and Environmental Sensors (COINES)’
Application board 2.0
https://ae-bst.resource.bosch.com/media/_tech/media/shuttleboard_flyer/Applicationboard-2-0_Flyer.pdf
Sensor Shuttle board
BMA400 Shuttle board
Reference design
See Figure 1 for a complete schematic of a typical use-case.
Note:
SPI is highly recommended because of the low current consumption. Since if I2C interface is applied, the pull-up resistors will consume significantly high current comparing to BMA400 ultra-low power consumption.
The VDDIO of MCU and BMA400 should be connected to same power source (level).
GPIO1 & GPIO2 of MCU should be configured as input if connected to INT1/INT2 of BMA400.
In case I2C interface is used (even not recommended), connect CSB to VDDIO to prevent unwanted level jumps on CSB pin, which might bring BMA400 from I2C mode to SPI mode, especially during ESD test.
Table 3 shows the bill of materials.
Table 3 BMA400 relevant Bill of materials
Layout recommendations
Because the BMA400 sensor family contains tiny mechanical structure inside the package, care must be taken during the layout phase to ensure the best performance. The complete handling and soldering guide can be found on the Bosch Sensortec’s website.
BST_BMA400 -> ‘downloads’ -> ‘Handling & Soldering instructions’
In addition to the attached guidelines, see below for the typical integration & manufacturing procedure for the BMA400 accelerometer.
Landing Pattern
Figure 2 Landing pattern
Typical Layout
Figure 3 Typical layout
Note:
No via under sensor.
On top layer, where sensor is mounted, no copper under sensor; while on the 2nd layer (bottom layer of 2-layers PCB), ground copper is welcomed to prevent EMI interference.
Traces should be fanned out to the outside of sensor, not inside.
In the area of sensor, no trace should be on the 2nd layer (bottom layer of 2-layers PCB); When there is ground copper on the 2nd layer, traces can be on 3rd( and 4th/5th …) layers; But keep high frequency or high current signals away from sensor area, from top to bottom.
Manufacturing notes
Table 4 Manufacturing parameters
First power-on
After powering the sensor for the first time, the initial specs would be to test for communication with the device. This can be done simply by reading the chip identification code in the register 0x00. See below for the expected values:
Table 5 Chip ID of the BMA400 product
To properly initialize the device, the user must decide which interface to use (I2C or SPI) during hardware design.
After power up, BMA400 is by default in I2C mode, until detect a rising edge on CSB pin, then BMA400 will switch to SPI mode until next soft rest or power on reset. Therefore, once BMA400 is connected to SPI interface from host, firstly a rising edge on CSB pin should be triggered, which can be implemented, for example, by a read from CHIPID register. For I2C connect, pulling the CSB pin to VDDIO directly or through a resistor will prevent BMA400 switches to SPI mode during running or ESD.
For SPI read, the first byte got from BMA400 is always a dummy byte, which should be skipped. The valuable information start from the second byte.
Here is some sample code on how to perform a CHIPID reading, using the COINES software (check Chapter 2.3 for detailed information) as the host.
* @brief This internal API is used to initializes the bma400 sensor with default * settings like power mode and OSRS settings * * @param[in] void * * @return void * */
static void init_bma400(void)
{ int8_t rslt; rslt = bma400_init(&bma400dev); if (rslt == BMA400_OK) { printf("BMA400 Initialization Success!\n"); printf("Chip ID 0x%x\n", bma400dev.chip_id); } else { print_rslt(rslt); exit(COINES_E_FAILURE); } coines_delay_msec(100); }
/********************** Global function definitions ************************/
/*! * @brief This API is the entry point, Call this API before using other APIs. * This API reads the chip-id of the sensor which is the first step to * verify the sensor and updates the trim parameters of the sensor. */
int8_t bma400_init(struct bma400_dev *dev)
{ int8_t rslt; uint8_t chip_id = 0; /* Check for null pointer in the device structure*/ rslt = null_ptr_check(dev); /* Proceed if null check is fine */ if (rslt == BMA400_OK) { /* Initial power-up time */ dev->delay_ms(5); /* Assigning dummy byte value */ if (dev->intf == BMA400_SPI_INTF) { /* Dummy Byte availability */ dev->dummy_byte = 1; /* Dummy read of Chip-ID in SPI mode */ rslt = bma400_get_regs(BMA400_CHIP_ID_ADDR, &chip_id, 1, dev); } else { dev->dummy_byte = 0; } if (rslt == BMA400_OK) { /* Chip ID of the sensor is read */ rslt = bma400_get_regs(BMA400_CHIP_ID_ADDR, &chip_id, 1, dev); /* Proceed if everything is fine until now */ if (rslt == BMA400_OK) { /* Check for chip id validity */ if (chip_id == BMA400_CHIP_ID) { /* Store the chip ID in dev structure */ dev->chip_id = chip_id; } else { rslt = BMA400_E_DEV_NOT_FOUND; } } } } return rslt;
}
How to test the sensor’s functionality
The BMA400 accelerometer features a fully integrated and motionless self-test procedure on the ASIC itself. When the self-test is triggered, the accelerometer uses electric fields to physically move the electrodes in all directions, senses the deflection and compares it with the expected output.
Therefore, the built-in self-test features is the recommended way to test the sensor’s functionality.
Here are some sample codes on how to perform this self-test, based on BMA400, using the COINES software as the host.
Codes from COINS(caller):
/*! * @brief This internal API is used to perform the self test * * @param[in] bma400dev: device structure * * @return void * */
static void perform_self_test(struct bma400_dev *bma400dev)
{ int8_t rslt; /* Doing soft reset */ rslt = bma400_soft_reset(bma400dev); print_rslt(rslt); printf("Running self test...\r\n"); coines_delay_msec(500); rslt = bma400_perform_self_test(bma400dev); print_rslt(rslt); if (rslt == BMA400_OK) { printf("Self test passed!\r\n"); } fflush(stdout);
}
Codes from BMA400 API:
/*! * @brief This is used to perform self test of accelerometer in BMA400 */
int8_t bma400_perform_self_test(const struct bma400_dev *dev)
{ int8_t rslt; int8_t self_test_rslt = 0; struct bma400_sensor_data accel_pos, accel_neg; /* Check for null pointer in the device structure */ rslt = null_ptr_check(dev); /* Proceed if null check is fine */ if (rslt == BMA400_OK) { /* pre-requisites for self test*/ rslt = enable_self_test(dev); if (rslt == BMA400_OK) { rslt = positive_excited_accel(&accel_pos, dev); if (rslt == BMA400_OK) { rslt = negative_excited_accel(&accel_neg, dev); if (rslt == BMA400_OK) { /* Validate the self test result */ rslt = validate_accel_self_test(&accel_pos, &accel_neg); } } } } /* Check to ensure bus error does not occur */ if (rslt >= BMA400_OK) { /* Store the status of self test result */ self_test_rslt = rslt; /* Perform soft reset */ rslt = bma400_soft_reset(dev); } /* Check to ensure bus operations are success */ if (rslt == BMA400_OK) { /* Restore self_test_rslt as return value */ rslt = self_test_rslt; } return rslt;
}
How to test the sensor’s performance
There are two performance parameters that can easily be tested with the device motionless: offset and noise. See below for the typical values of the sensors.
Note: Typical values are defined as ±1σ, which means that we expect 68.3% of sensors to fall within these values. Min/Max values are defined as ±3σ, which means 99.7% of sensors shall be within these values.
For the offset, the test procedure is quite simple. With the device in a known position, such as a flat surface, calculate the average value for each axis, and subtract the expected output (e.g. 0G, 0G, +1G) from the data. The result is the offset of the sensor. Here is some sample code on how to perform this test, based on BMA400, using the COINES software as the host.
Missed BMA400 offset calculation examples:
/*! * @brief This internal API is used to measure the sensor offset * * @param[out] x_off_mg, y_off_mg, z_off_mg * * @return void * */
static void bma423_get_offset(double *x_off_mg, double *y_off_mg, double *z_off_mg) { uint16_t commrslt; /* Declare an accelerometer configuration structure */ struct bma4_accel_config accel_conf; /* Declare a data buffer for the sensor data structure */ struct bma4_accel sens_data[20]; /* Enable the accelerometer */
The noise calculation is a bit more complicated. First, subtract the offset from each data point. The RMS value can be calculated as the square root of the arithmetic mean of the squares of the noise values.
Since the noise value is affected by the bandwidth of the digital filter, we need to convert it back to noise density with the following formula. Note: this applied only to a second order filter.
Here is some sample code on how to perform this test, based on BMI160, using the COINES software as the host.
Calibrating the sensor
The first question to ask concerning calibration is whether it is required for the intended application. Accelerometer calibration mainly consists of calibrating the accelerometer’s offset. The main impact for this is in tilt-sensing application, where the offset will induce an error in the measurement of the horizon.
The accelerometer comes from the factory pre-trimmed, but the soldering process and PCB bending due to assembly can vary the offset, therefore it is preferable to calibrate the accelerometer after assembling the device into the device housing. Therefore, it is recommended to calibrate the sensor after assembling the device into the device housing.
The acceleration sensor offset consists of two parts: the static “unwanted” offset mainly due to soldering drift, and the offset generated when an acceleration is applied to the sensor. The latter depends on the applied acceleration and its magnitude if defined by the sensor’s sensitivity. However, the sensitivity has a certain tolerance (typ. <1%). This means that in order to compensate for the static offset, the sensor must be oriented in such a way that no external acceleration is applied to the sensing axis. As gravity also causes a sensor signal, the sensing axis must be oriented perpendicular to the gravity field.
The compensation process described below focuses on the x/y-axis. The z-axis can also be compensated in the same way, but the user has to consider the applied gravity. Alternatively, the process can be repeated after turning the device, with the z-axis perpendicular to the gravity vector.
Place your sensor (the system with the sensor inside) on a well-defined surface, for example, a horizontal table. The expected sensor output for the x/y-axis should be 0 mg.
Set the sensor to the lowest g-range (2G)
Measure the sensor output to ensure the sensor is fully at rest, without vibrations, inclinations, big temperature changes or strong VDD fluctuations. It is advisable to take several values and generate the average over the values (e.g. 1000 values).
Consider the resolution of BMA400, and save the offset in LSB or mg.
The offset subtracted from the future accelerometer sensor data.
Usage
The COINES installation provides sample code on how to turn on the sensor, configure it and read out the acceleration data.
Sample code
The main function shows the initialization process of BMA400 based on COINS software & APP2.0 board.
/*! * @brief Main Function where the execution getting started to test the code. * * @param[in] argc * @param[in] argv * * @return status * */
int main(int argc, char const *argv[])
{ struct coines_board_info board_info; struct bma400_sensor_data data; struct bma400_dev bma; int8_t rslt; uint8_t n_samples = 200; float t, x, y, z; init_bma400_sensor_driver_interface(&bma); rslt = coines_open_comm_intf(COINES_COMM_INTF_USB); if (rslt < 0) { printf("\n Unable to connect with Application Board ! \n" " 1. Check if the board is connected and powered on. \n" " 2. Check if Application Board USB driver is installed. \n" " 3. Check if board is in use by another application. (Insufficient permissions to access USB) \n"); exit(rslt); } /* Check if the right board is connected (implicitly check if board was reset) */ rslt = coines_get_board_info(&board_info); if (rslt == COINES_SUCCESS) { if(board_info.shuttle_id != BMA400_SHUTTLE_ID) { printf("Invalid sensor shuttle ID (not a BMA400 shuttle)\n(sometimes board power off-power on helps.)\n"); fflush(stdout); exit(COINES_E_FAILURE); } } init_sensor_interface(); /* after sensor init introduce 200 msec sleep */ coines_delay_msec(200); init_bma400(&bma); rslt = bma400_soft_reset(&bma); print_rslt(rslt); rslt = set_sensor_config(&bma); if(rslt != BMA400_OK) { printf("Error setting bma400 config.\n"); fflush(stdout); exit(rslt); } while (n_samples && (rslt == BMA400_OK)) { bma.delay_ms(10); /* Wait for 10ms as ODR is set to 100Hz */ rslt = bma400_get_accel_data(BMA400_DATA_SENSOR_TIME, &data, &bma); print_rslt(rslt); /* 12-bit accelerometer at range 2G */ x = lsb_to_ms2(data.x, 2, 12); y = lsb_to_ms2(data.y, 2, 12); z = lsb_to_ms2(data.z, 2, 12); t = sensor_ticks_to_s(data.sensortime); printf("t[s]:%.4f\tdata[m/s2]: ax:%.4f\tay:%.4f\taz:%.4f\n", t, x, y, z); fflush(stdout); n_samples--; } return 0;
}
Below function described how to coinfigure the BMA400:
/*! * @brief This internal API is used to configure the sensor * * @param[in] bma400dev: bma400 device structure * * @return Results of API execution status. * @retval 0 -> Success * @retval Any non zero value -> Fail * */
static int8_t set_sensor_config(struct bma400_dev *bma400dev)
{ int8_t rslt; struct bma400_sensor_conf conf; /* Select the type of configuration to be modified */ conf.type = BMA400_ACCEL; /* Get the accelerometer configurations which are set in the sensor */ rslt = bma400_get_sensor_conf(&conf, 1, bma400dev); print_rslt(rslt); /* Modify the desired configurations as per macros * available in bma400_defs.h file */ conf.param.accel.odr = BMA400_ODR_100HZ; conf.param.accel.range = BMA400_2G_RANGE; conf.param.accel.data_src=BMA400_DATA_SRC_ACCEL_FILT_1; /* Set the desired configurations to the sensor */ rslt = bma400_set_sensor_conf(&conf, 1, bma400dev); print_rslt(rslt); rslt = bma400_set_power_mode(BMA400_LOW_POWER_MODE, bma400dev); print_rslt(rslt); return rslt;
}
Below codes come from BMA400 API, which describe how to read and set BMA400 sensor configuration, and how to read sensor data.
/*! * @brief This API is used to get the accel data along with the sensor-time */
int8_t bma400_get_accel_data(uint8_t data_sel, struct bma400_sensor_data *accel, const struct bma400_dev *dev)
{ int8_t rslt; /* Check for null pointer in the device structure*/ rslt = null_ptr_check(dev); /* Proceed if null check is fine */ if ((rslt == BMA400_OK) || (accel != NULL)) { /* Read and store the accel data */ rslt = get_accel_data(data_sel, accel, dev); } else { rslt = BMA400_E_NULL_PTR; } return rslt;
}
/*! * @brief This API is used to set the sensor settings like sensor * configurations and interrupt configurations */
int8_t bma400_set_sensor_conf(const struct bma400_sensor_conf *conf, uint16_t n_sett, const struct bma400_dev *dev)
{ int8_t rslt; uint16_t idx = 0; uint8_t data_array[3] = { 0 }; /* Check for null pointer in the device structure*/ rslt = null_ptr_check(dev); /* Proceed if null check is fine */ if (rslt == BMA400_OK) { /* Read the interrupt pin mapping configurations */ rslt = bma400_get_regs(BMA400_INT_MAP_ADDR, data_array, 3, dev); if (rslt == BMA400_OK) { for (idx = 0; idx < n_sett; idx++) { switch (conf[idx].type) { case BMA400_ACCEL: /* Setting Accel configurations */ rslt = set_accel_conf(&conf[idx].param.accel, dev); if (rslt == BMA400_OK) { /* Int pin mapping settings */ map_int_pin(data_array, BMA400_DATA_READY_INT_MAP, conf[idx].param.accel.int_chan); } break; case BMA400_TAP_INT: /* Setting TAP configurations */ rslt = set_tap_conf(&conf[idx].param.tap, dev); if (rslt == BMA400_OK) { /* Int pin mapping settings */ map_int_pin(data_array, BMA400_TAP_INT_MAP, conf[idx].param.tap.int_chan); } break; case BMA400_ACTIVITY_CHANGE_INT: /* Setting activity change config */ rslt = set_activity_change_conf(&conf[idx].param.act_ch, dev); if (rslt == BMA400_OK) { /* Int pin mapping settings */ map_int_pin(data_array, BMA400_ACT_CH_INT_MAP, conf[idx].param.act_ch.int_chan); } break; case BMA400_GEN1_INT: /* Setting Generic int 1 config */ rslt = set_gen1_int(&conf[idx].param.gen_int, dev); if (rslt == BMA400_OK) { /* Int pin mapping settings */ map_int_pin(data_array, BMA400_GEN1_INT_MAP, conf[idx].param.gen_int.int_chan); } break; case BMA400_GEN2_INT: /* Setting Generic int 2 config */ rslt = set_gen2_int(&conf[idx].param.gen_int, dev); if (rslt == BMA400_OK) { /* Int pin mapping settings */ map_int_pin(data_array, BMA400_GEN2_INT_MAP, conf[idx].param.gen_int.int_chan); } break; case BMA400_ORIENT_CHANGE_INT: /* Setting orient int config */ rslt = set_orient_int(&conf[idx].param.orient, dev); if (rslt == BMA400_OK) { /* Int pin mapping settings */ map_int_pin(data_array, BMA400_ORIENT_CH_INT_MAP, conf[idx].param.orient.int_chan); } break; case BMA400_STEP_COUNTER_INT: /* Int pin mapping settings */ map_int_pin(data_array, BMA400_STEP_INT_MAP, conf[idx].param.step_cnt.int_chan); break; } } if (rslt == BMA400_OK) { /* Set the interrupt pin mapping configurations */ rslt = bma400_set_regs(BMA400_INT_MAP_ADDR, data_array, 3, dev); } } } return rslt;
}
/*! * @brief This API is used to get the sensor settings like sensor * configurations and interrupt configurations and store * them in the corresponding structure instance */
int8_t bma400_get_sensor_conf(struct bma400_sensor_conf *conf, uint16_t n_sett, const struct bma400_dev *dev)
{ int8_t rslt = BMA400_OK; uint16_t idx = 0; uint8_t data_array[3] = { 0 }; if (conf == NULL) { rslt = BMA400_E_NULL_PTR; } if (rslt == BMA400_OK) { /* Read the interrupt pin mapping configurations */ rslt = bma400_get_regs(BMA400_INT_MAP_ADDR, data_array, 3, dev); } for (idx = 0; (idx < n_sett) && (rslt == BMA400_OK); idx++) { switch (conf[idx].type) { case BMA400_ACCEL: /* Accel configuration settings */ rslt = get_accel_conf(&conf[idx].param.accel, dev); if (rslt == BMA400_OK) { /* Get the INT pin mapping */ get_int_pin_map(data_array, BMA400_DATA_READY_INT_MAP, &conf[idx].param.accel.int_chan); } break; case BMA400_TAP_INT: /* TAP configuration settings */ rslt = get_tap_conf(&conf[idx].param.tap, dev); if (rslt == BMA400_OK) { /* Get the INT pin mapping */ get_int_pin_map(data_array, BMA400_TAP_INT_MAP, &conf[idx].param.tap.int_chan); } break; case BMA400_ACTIVITY_CHANGE_INT: /* Activity change configurations */ rslt = get_activity_change_conf(&conf[idx].param.act_ch, dev); if (rslt == BMA400_OK) { /* Get the INT pin mapping */ get_int_pin_map(data_array, BMA400_ACT_CH_INT_MAP, &conf[idx].param.act_ch.int_chan); } break; case BMA400_GEN1_INT: /* Generic int1 configurations */ rslt = get_gen1_int(&conf[idx].param.gen_int, dev); if (rslt == BMA400_OK) { /* Get the INT pin mapping */ get_int_pin_map(data_array, BMA400_GEN1_INT_MAP, &conf[idx].param.gen_int.int_chan); } break; case BMA400_GEN2_INT: /* Generic int2 configurations */ rslt = get_gen2_int(&conf[idx].param.gen_int, dev); if (rslt == BMA400_OK) { /* Get the INT pin mapping */ get_int_pin_map(data_array, BMA400_GEN2_INT_MAP, &conf[idx].param.gen_int.int_chan); } break; case BMA400_ORIENT_CHANGE_INT: /* Orient int configurations */ rslt = get_orient_int(&conf[idx].param.orient, dev); if (rslt == BMA400_OK) { /* Get the INT pin mapping */ get_int_pin_map(data_array, BMA400_ORIENT_CH_INT_MAP, &conf[idx].param.orient.int_chan); } break; case BMA400_STEP_COUNTER_INT: /* Get int pin mapping settings */ get_int_pin_map(data_array, BMA400_STEP_INT_MAP, &conf[idx].param.step_cnt.int_chan); break; default: rslt = BMA400_E_INVALID_CONFIG; } } return rslt;
}
Further reads
Datasheets:
BMA400 datasheet -> ‘Download’ -> ‘BST-BMA400-DSxxx’, like BST-BMA400-DS000
Application notes:
BMA400 Evaluation Guide
Handing soldering and mounting instructions
Handling, soldering & mounting instruction
Introduction
This document is meant as a reference guide on how to design using Bosch Sensortec’s BME280 series of humidity sensor.
Selecting the right part
The BME280 series of humidity sensor contains 1 products: BME280. Table 1 shows an overview of the features.
Table 1: Overview of the products in this family
Common characteristics
The main characteristics of this product family are:
Key features
The BME280 is an integrated environmental sensor developed specifically for mobile applications where size and low power consumption are key design constraints. The unit combines individual high linearity, high accuracy sensors for pressure, humidity and temperature in an 8-pin metal-lid 2.5 x 2.5 x 0.93 mm³ LGA package, designed for low current consumption (3.6 μA @1Hz), long term stability and high EMC robustness.
The humidity sensor features an extremely fast response time which supports performance requirements for emerging applications such as context awareness, and high accuracy over a wide temperature range. The pressure sensor is an absolute barometric pressure sensor with features exceptionally high accuracy and resolution at very low noise. The integrated temperature sensor has been optimized for very low noise and high resolution. It is primarily used for temperature compensation of the pressure and humidity sensors, and can also be used for estimating ambient temperature.
The BME280 supports a full suite of operating modes which provide the flexibility to optimize the device for power consumption, resolution and filter performance.
Available evaluation tools and software
To best to evaluate the products from the BME280 family, we recommend the following combination of evaluation tools:
COINES Desktop software
Installer for Windows based systems:
https://ae-bst.resource.bosch.com/media/_tech/media/coines/COINES_Installers_v1.1_Windows.zip
Installer for Linux based systems:
https://ae-bst.resource.bosch.com/media/_tech/media/coines/COINES_Installers_v1.1_Linux.zip
Application board 2.0
Without bluetooth. Ordering code 0330.AB0.011
With bluetooth. Ordering code 0330.AB0.111
https://www.bosch-sensortec.com/bst/support_tools/application_boards/overview_application_boards
Sensor Shuttle board
BME280 Shuttle board. Ordering code 0330.SB4.185
Reference design
See Figure 1 for a complete schematic of a typical BME280 use-case.
Fig. 1: Mockup Reference design
Bill of materials
Table 3: Bill of materials
Layout recommendations
Because the BME280 sensor family contains tiny mechanical structure inside the package, care must be taken during the layout phase to ensure the best performance. The complete handling and soldering guide can be found on the Bosch Sensortec’s website.
In addition to the attached guidelines, see below for the typical manufacturing procedure for the BME280 humidity sensor.
Landing Pattern
Fig. 2: Recommended landing pattern
Note: red areas demark exposed PCB metal pads.
In case of a solder mask defined (SMD) PCB process, the land dimensions should be defined by solder mask openings. The underlying metal pads are larger than these openings.
In case of a non solder mask defined (NSMD) PCB process, the land dimensions should be defined in the metal layer. The mask openings are larger than these metal pads.
Typical Layout
Figure 3: Typical layout
Manufacturing notes
Table 4: Manufacture recommendation
First power-on
After powering the sensor for the first time, the initial specs would be to test for communication with the device. This can be done simply by reading the chip identification code in the register 0xD0. See below for the expected values
Table 5: Chip IDs of the BME280 product family
Here is some sample code on how to perform this test, using the COINES software as the host.
/*! * @brief This internal API is used to initializes the bme280 sensor with default * settings like power mode and OSRS settings * * @param[in] void * * @return void * */
static void init_bme280(void)
{ int8_t rslt; rslt = bme280_init(&bme280Dev); if (rslt == BME280_OK) { printf("BME280 Initialization Success!\n"); printf("Chip ID 0x%x\n", bme280Dev.chip_id); } else { printf("Chip Initialization failure !\n"); exit(COINES_E_FAILURE); } coines_delay_msec(100); bme280_set_sensor_mode(BME280_NORMAL_MODE, &bme280Dev);
}
How to read sensor data
Here is some sample code on how to read sensor data, using the COINES software as the host.
/*! * @brief This internal API is used to read the streaming data in a while loop and * print in console. * * @param[in] void * * @return void */
static void read_sensor_data(void)
{ int times_to_read = 0; while (times_to_read < 200) { bme280_get_sensor_data(BME280_ALL, &bme280_comp_data, &bme280Dev); printf("T: %.2f, H: %.2f, P: %.2f \n", (bme280_comp_data.temperature / 100.), (bme280_comp_data.humidity / 1000.), (bme280_comp_data.pressure / 100.)); fflush(stdout); coines_delay_msec(10); times_to_read = times_to_read + 1; }
}
Sample code
The complete sample code shown above can be compiled and executed from the COINES installation directory (by default, C:/COINES under Windows), from the following subfolder: \examples\c\bme280
Usage
The COINES installation provides sample code on how to turn on the sensor, configure it and read
out data.
COINES\v1.0\ examples\c\bme280
Sample code
/*! * @brief Main Function where the execution getting started to test the code. * * @param[in] argc * @param[in] argv * * @return status * */
int main(int argc, char *argv[])
{ int16_t rslt; struct coines_board_info board_info; init_bme280_sensor_driver_interface(); rslt = coines_open_comm_intf(COINES_COMM_INTF_USB); if (rslt < 0) { printf("\n Unable to connect with Application Board ! \n" " 1. Check if the board is connected and powered on. \n" " 2. Check if Application Board USB driver is installed. \n" " 3. Check if board is in use by another application. (Insufficient permissions to access USB) \n"); exit(rslt); } rslt = coines_get_board_info(&board_info); if (rslt == COINES_SUCCESS) { if (board_info.shuttle_id != BME280_SHUTTLE_ID) { printf("! Warning invalid sensor shuttle. This application will not support this sensor \r\n" "1.Check the sensor shuttle \r\n" "2.Reset the board \r\n"); exit(COINES_E_FAILURE); } } init_sensor_interface(); /* after sensor init introduce 200 msec sleep */ coines_delay_msec(200); init_bme280(); read_sensor_data(); coines_close_comm_intf(COINES_COMM_INTF_USB); return EXIT_SUCCESS;
}
Further reads
Datasheets:
BME280 Datasheet https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST-BME280-DS002.pdf
Handling, soldering and mounting instructions:
BME280 HSMI https://ae-bst.resource.bosch.com/media/_tech/media/application_notes/BST-BME280-HS006.pdf
