Bosch Sensortec Community

    cancel
    Showing results for 
    Search instead for 
    Did you mean: 
    SOLVED

    BHI260AP Sensor Trigger Chaining

    BHI260AP Sensor Trigger Chaining

    not_karl
    New Poster

    Good evening, I am trying to better understand the use case for sensor trigger chaining. In the programmer's guide I see a high level example where a physical sensor may trigger one or more virtual sensors. I understand the singular relationship between a physical sensor and a number of virtual sensors that may do additional value added processing/refinement. 

    1) Is there a use case (or capability) where by a single physical sensor would trigger a sequence of multiple virtual sensors? Is each virtual sensor chained to a previous virtual sensor? 

    2) Is there a capability for a virtual sensor to depend on data aggregtated from multiple physical sensors in order to draw a conclusion and report to the host? 

    Thank you. 

    5 REPLIES 5

    Chrisbao
    Member

    Hi not_karl,

    Before answering the question, first have to classify if the designed customer's virtual sensor is a BSX related sensor (of which the physical source is ACC, GYR or MAG). If the virtual sensor is a BSX related sensor, we should not use the physcial source directly as trigger source, but through BSX library and use BSX custom virtual sensor as our sensor source. The custom BSX virtual sensor is designed as source for customer's sensors implemented in the SDK.

    If the customer's sensor is not using ACC, GYR, or MAG as data source, then the trigger source can be the physical source, such as a virtual Barometer sensor with trigger source from a physical pressure sensor.

    Chrisbao_0-1632378954539.png

     

    To answer your question, besides the obvious case of one virtual sensor triggered by another sensor, there are 2 cases here might be of your interest as you mentioned:

    Case1. Multiple virtual sensors triggered by one same sensor.

    Case2. Single virtual sensor depending on multiple sensor as source.

    The first case is vey common, for example, the ACC source can be used as trigger source for both step counter and motion detector. (keep note for the virtual sensor design in this example, we should use the custom BSX ACC as source.) So when designing the virtual sensor descriptor, under structure variable triggerSource.value, put the sensor type of the source. We may have the same sensor type of the source for the other virtual sensor. The triggering sequence is based on the value virtual sensor's priority, which is also under virtual sensor descriptor's structure variable.

    The second case, so the designed virtual sensor is a fusion sensor, and very possible an algorithm would be required inside the designed virtual sensor, as it is based on multiple data sources. The tricky part for this case, is that the timestamp should match from the multiple sensor sources that feed into the designed virtual sensor algorithm. During implementation, the multiple sensors data should all be handled in the same function to store all data and match the timestamp. When all sensor data source is ready, this function shall trigger the designed virtual sensor, and proceed the algorithm handling at the designed virtual sensor if any.

     

    Thank you, this is helpful. I have a tangible use case where I would like to use the combined data from the accelerometer with readings from an ambient light sensor in order to have a virtual sensor provide a derived data stream. 

    I would like to have the samples from both physical sensor available to the virtual sensor in order to derive a new outcome and report it to the end user. Without sharing variables between the drivers, is it possible to accomplish this? 

    From a triggering perspective, my preference would be to trigger this on the accelerometer (recognizing a tap activity) and allow the virtual sensor to combine this with data from the ambient light sensor. 

    Trying to better understand how to accomplish this within the architecture of the BHI260. 

     

    Hi not_karl,

    For the case of utilizing accelerometer and light sensor data, besides the BSX_custom_accelerometer_corrected virtual sensor (from BSX4 algorithm), and the light virtual sensor (from your own coding), you will need a third virtual sensor maybe called TapActivity virtual sensor. You need to direct the trigger source of theTapActivity virtual sensor from the first two virtual sensor.

    In the TapActivity virtual sensor, you should create a buffer to store the data and timestamp of the two virtual sensor values. The timestamp is to make sure the data from various virtual sensor source matches. You may do your tap activity algorithm in the virtual sensor data handle, and report the algorithm output solution to the host.

    Thanks, this poses a number of questions for me. 

    1) In the VirtualTapActivity virtual sensor do I have two triggerSource clauses or indicate multiple virtual sensors within the same clause? 

    2) Do I need to specify both physicalSensors as well in the descriptor?

    3) In order to determine which sensor's data I am dealing with at the time of trigger, I assume I am looking at VirtualSensorDescriptor.triggerSource? 

    4) If I understand correctly, I need to use the timestamp from the two trigger sources in order to record and compose the data when there has been an event from both sensors in the same meaningful time window? 

    Thank you. 

    Icon--AD-black-48x48Icon--address-consumer-data-black-48x48Icon--appointment-black-48x48Icon--back-left-black-48x48Icon--calendar-black-48x48Icon--center-alignedIcon--Checkbox-checkIcon--clock-black-48x48Icon--close-black-48x48Icon--compare-black-48x48Icon--confirmation-black-48x48Icon--dealer-details-black-48x48Icon--delete-black-48x48Icon--delivery-black-48x48Icon--down-black-48x48Icon--download-black-48x48Ic-OverlayAlertIcon--externallink-black-48x48Icon-Filledforward-right_adjustedIcon--grid-view-black-48x48IC_gd_Check-Circle170821_Icons_Community170823_Bosch_Icons170823_Bosch_Icons170821_Icons_CommunityIC-logout170821_Icons_Community170825_Bosch_Icons170821_Icons_CommunityIC-shopping-cart2170821_Icons_CommunityIC-upIC_UserIcon--imageIcon--info-i-black-48x48Icon--left-alignedIcon--Less-minimize-black-48x48Icon-FilledIcon--List-Check-grennIcon--List-Check-blackIcon--List-Cross-blackIcon--list-view-mobile-black-48x48Icon--list-view-black-48x48Icon--More-Maximize-black-48x48Icon--my-product-black-48x48Icon--newsletter-black-48x48Icon--payment-black-48x48Icon--print-black-48x48Icon--promotion-black-48x48Icon--registration-black-48x48Icon--Reset-black-48x48Icon--right-alignedshare-circle1Icon--share-black-48x48Icon--shopping-bag-black-48x48Icon-shopping-cartIcon--start-play-black-48x48Icon--store-locator-black-48x48Ic-OverlayAlertIcon--summary-black-48x48tumblrIcon-FilledvineIc-OverlayAlertwhishlist