<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0" xmlns:webfeeds="http://webfeeds.org/rss/1.0">
    <channel>
        <title><![CDATA[Bosch Sensortec Community]]></title>
        <description><![CDATA[Bosch Sensortec Community]]></description>
        <link>https://community.bosch-sensortec.com</link>
        <generator>Bettermode RSS Generator</generator>
        <lastBuildDate>Fri, 19 Jun 2026 18:43:00 GMT</lastBuildDate>
        <atom:link href="https://community.bosch-sensortec.com/rss/feed" rel="self" type="application/rss+xml"/>
        <pubDate>Fri, 19 Jun 2026 18:43:00 GMT</pubDate>
        <copyright><![CDATA[2026 Bosch Sensortec Community]]></copyright>
        <language><![CDATA[en-US]]></language>
        <ttl>60</ttl>
        <webfeeds:icon></webfeeds:icon>
        <webfeeds:related layout="card" target="browser"/>
        <item>
            <title><![CDATA[Development Desktop 4.5.0 remains stuck on loading indefinitely]]></title>
            <description><![CDATA[Bosch Shuttle Board 3.0 (8× BME690) connected to the Application Board 3.1 remains stuck on the loading screen indefinitely when using Development Desktop 4.5.0. The Application Board is connected ...]]></description>
            <link>https://community.bosch-sensortec.com/mems-sensors-forum-jrmujtaw/post/development-desktop-4-5-0-remains-stuck-on-loading-indefinitely-pjXBq6cHEscBfw6</link>
            <guid isPermaLink="true">https://community.bosch-sensortec.com/mems-sensors-forum-jrmujtaw/post/development-desktop-4-5-0-remains-stuck-on-loading-indefinitely-pjXBq6cHEscBfw6</guid>
            <dc:creator><![CDATA[TermiteChiu]]></dc:creator>
            <pubDate>Fri, 19 Jun 2026 08:35:12 GMT</pubDate>
            <content:encoded><![CDATA[<p>Bosch Shuttle Board 3.0 (8× BME690) connected to the Application Board 3.1 remains stuck on the loading screen indefinitely when using Development Desktop 4.5.0. The Application Board is connected directly to the computer via USB.<br></p><figure data-align="center" data-size="best-fit" data-id="1WFuzJOwNjtjKtakJ0wbP" data-version="v2" data-type="image"><img data-id="1WFuzJOwNjtjKtakJ0wbP" src="https://tribe-eu.imgix.net/1WFuzJOwNjtjKtakJ0wbP?auto=compress,format"></figure><p><br></p><figure data-align="center" data-size="best-fit" data-id="lWhBTpNcEsk7QXdgT1aup" data-version="v2" data-type="image"><img data-id="lWhBTpNcEsk7QXdgT1aup" src="https://tribe-eu.imgix.net/lWhBTpNcEsk7QXdgT1aup?auto=compress,format"></figure>]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[BMM350/BMA456/BME280/BMP390 Sensor Full range test]]></title>
            <description><![CDATA[Hi Team,

As per the Sensor BMM350/BMA456/BME280/BMP390, I wanted to know the full range test procedure of factory and how we are actually tested Full range of All mentioned Sensor.

and

I wanted to know ...]]></description>
            <link>https://community.bosch-sensortec.com/mems-sensors-forum-jrmujtaw/post/bmm350-bma456-bme280-bmp390-sensor-full-range-test-dkxDwlZ1ezA2L5K</link>
            <guid isPermaLink="true">https://community.bosch-sensortec.com/mems-sensors-forum-jrmujtaw/post/bmm350-bma456-bme280-bmp390-sensor-full-range-test-dkxDwlZ1ezA2L5K</guid>
            <category><![CDATA[BMA456]]></category>
            <category><![CDATA[BME280]]></category>
            <category><![CDATA[BMM350]]></category>
            <category><![CDATA[BMP390]]></category>
            <dc:creator><![CDATA[Harsh]]></dc:creator>
            <pubDate>Thu, 18 Jun 2026 02:56:31 GMT</pubDate>
            <content:encoded><![CDATA[<p>Hi Team,</p><p>As per the Sensor BMM350/BMA456/BME280/BMP390, I wanted to know the full range test procedure of factory and how we are actually tested Full range of All mentioned Sensor.</p><p>and </p><p>I wanted to know is thr any Test chambers to check full range and how!</p><p>1) How we can test full range of all sensors Indoor and Outdoor </p><p></p><p>Regards,</p>]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[[SOLVED] BMI270 current consumption elevated when no motion state entered]]></title>
            <description><![CDATA[I am using the BMI270 and the associated Bosch API, running in zephyr RTOS environment. I have it configured for:

        BMI2_ACCEL,
        BMI2_ANY_MOTION,
        BMI2_NO_MOTION,
        BMI2_STEP_COUNTER,
        BMI2_STEP_ACTIVITY,

...]]></description>
            <link>https://community.bosch-sensortec.com/mems-sensors-forum-jrmujtaw/post/solved-bmi270-current-consumption-elevated-when-no-motion-state-entered-eXBSQKYhQxGkW5W</link>
            <guid isPermaLink="true">https://community.bosch-sensortec.com/mems-sensors-forum-jrmujtaw/post/solved-bmi270-current-consumption-elevated-when-no-motion-state-entered-eXBSQKYhQxGkW5W</guid>
            <category><![CDATA[BMI270]]></category>
            <category><![CDATA[ZEPHYR]]></category>
            <dc:creator><![CDATA[Kyler]]></dc:creator>
            <pubDate>Wed, 17 Jun 2026 17:29:50 GMT</pubDate>
            <content:encoded><![CDATA[<p>I am using the BMI270 and the associated Bosch API, running in zephyr RTOS environment. I have it configured for:</p><pre class="language-c"><code class="language-c">        BMI2_ACCEL,
        BMI2_ANY_MOTION,
        BMI2_NO_MOTION,
        BMI2_STEP_COUNTER,
        BMI2_STEP_ACTIVITY,</code></pre><p>Monitoring the current consumption the behavior I see is while system is mostly idle with a bit on motion the current consumption is around 10 to 15uA. I have my no motion duration set to 30 seconds so after 30 seconds I get an IRQ indicating no motion then the current usage of the device steps up to ~55uA</p><p>As soon as I move the device at all I get an any motion IRQ and the current drops back again</p><p>Anyone else observe this? The application currently does not do anything with these events so I don't think it is something like my higher level FW is in some other strange mode when this occurs</p><p>Thank you!</p><p>-Kyler</p>]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[BMM350 shows significant X/Y/Z changes with almost constant temperature after wake-up from sleep]]></title>
            <description><![CDATA[I am using the Bosch BMM350 magnetometer in a battery-powered parking sensor based on an STM32WL MCU.

During installation, when the parking slot is confirmed to be empty, I collect 5 magnetometer ...]]></description>
            <link>https://community.bosch-sensortec.com/mems-sensors-forum-jrmujtaw/post/bmm350-shows-significant-x-y-z-changes-with-almost-constant-temperature-Z5FyW5hxkjUKv4K</link>
            <guid isPermaLink="true">https://community.bosch-sensortec.com/mems-sensors-forum-jrmujtaw/post/bmm350-shows-significant-x-y-z-changes-with-almost-constant-temperature-Z5FyW5hxkjUKv4K</guid>
            <category><![CDATA[BMM350]]></category>
            <category><![CDATA[False Detection]]></category>
            <category><![CDATA[LOW POWER MODE]]></category>
            <category><![CDATA[MAGNETOMETER]]></category>
            <category><![CDATA[Smart Parking]]></category>
            <category><![CDATA[STM32]]></category>
            <dc:creator><![CDATA[NagaSubrahmanyam]]></dc:creator>
            <pubDate>Mon, 15 Jun 2026 13:35:55 GMT</pubDate>
            <content:encoded><![CDATA[<p>I am using the Bosch BMM350 magnetometer in a battery-powered parking sensor based on an STM32WL MCU.<br><br>During installation, when the parking slot is confirmed to be empty, I collect 5 magnetometer samples and average them to create a baseline calibration (X, Y, Z). Every minute, the device wakes from sleep, reads the compensated magnetometer values, computes the difference from the baseline, and determines whether a vehicle is present.<br><br><strong>The problem is that even when the parking slot remains empty and no vehicle has moved into or out of the slot, the measured magnetic values occasionally drift enough to exceed my detection threshold, resulting in a false "occupied" indication.</strong><br><br>I have also logged the sensor temperature together with the magnetometer readings. In several instances, I observed significant changes in the X, Y, and Z values while the reported temperature remained nearly constant (or changed only by a very small amount). Therefore, the observed drift does not appear to be explained solely by temperature variation.<br>Please go through this <strong>xl</strong> sheet to see the sudden drift. and <strong>.c</strong> for configurations of Sensor APIs.</p><attachment data-id="Z9OKbsjm1IJ6thx7k9irl" data-type="attachment"></attachment><pre class="language-c"><code class="language-c"> // Defines
#define T_AVG			3

// Exponential Moving Average (EMA) coefficient used to slowly update the baseline 
// when the parking slot is confidently detected as empty
#define ALPHA			0.05f

#define CALIBRATION_SAMPLES	5

// Private Typedef
typedef struct
{
	float x;
	float y;
	float z;
	float temperature;
} BMM350_data_t;

// Global Variables
bool parked = false;
float THRESHOLD = 4.5f;
BMM350_data_t BMM350_CALIBRATED_BASE;

// Private function prototypes
static int BMM350_Init(void);
static int BMM350_Read(BMM350_data_t *s_data);
static float ComputeMagnitude(BMM350_data_t *reading);
void timer_callback();


int main(void)
{

	int status = 0;
	float mag = 0;
	BMM350_data_t reading;
	BMM350_data_t BMM350_CALIBRATION_DATA[CALIBRATION_SAMPLES];

	// Initialize the BMM350 sensor
	status = BMM350_Init();

	// ------------------------------------------------------------------ 
	// Initial calibration: 
	// Collect 5 readings while the parking slot is known to be empty. 
	// These samples are averaged to create the baseline magnetic field. 
	// ------------------------------------------------------------------
	for (int i = 0 ; i &lt; CALIBRATION_SAMPLES ; i++)
	{
		if (BMM350_Read(&amp;reading) != 0)
    		{
      			APP_LOG(TS_ON, VLEVEL_L, "BMM350 read failed — skipping scan\r\n");
      			return 0;
    		}
		
		BMM350_CALIBRATION_DATA[i] = reading;
	}
	
	// Reset baseline accumulators before averaging
	BMM350_CALIBRATED_BASE.x = 0;
        BMM350_CALIBRATED_BASE.y = 0;
        BMM350_CALIBRATED_BASE.z = 0;
        BMM350_CALIBRATED_BASE.temperature = 0;

	// Average of 5 Samples 
        for (int j = 0; j &lt; CALIBRATION_SAMPLES; j++)
        {
          BMM350_CALIBRATED_BASE.x += BMM350_CALIBRATION_DATA[j].x;
          BMM350_CALIBRATED_BASE.y += BMM350_CALIBRATION_DATA[j].y;
          BMM350_CALIBRATED_BASE.z += BMM350_CALIBRATION_DATA[j].z;
          BMM350_CALIBRATED_BASE.temperature += BMM350_CALIBRATION_DATA[j].temperature;
        }

        BMM350_CALIBRATED_BASE.x /= CALIBRATION_SAMPLES;
        BMM350_CALIBRATED_BASE.y /= CALIBRATION_SAMPLES;
        BMM350_CALIBRATED_BASE.z /= CALIBRATION_SAMPLES;
        BMM350_CALIBRATED_BASE.temperature /= CALIBRATION_SAMPLES;

	// ------------------------------------------------------------------ 
	// Main detection loop 
	// Executed once every minute after the MCU wakes from low-power mode. 
	// ------------------------------------------------------------------
	while(timer_flag)
	{
		if (BMM350_Read(&amp;reading) != 0)
    		{
      			APP_LOG(TS_ON, VLEVEL_L, "BMM350 read failed — skipping scan\r\n");
      			return 0;
    		}
		
		// Compute Euclidean distance between current reading and Base values
		mag = ComputeMagnitude(&amp;reading);
		
		//Detection Logic
		if (!parked)
      		{
        		if (mag &gt;= THRESHOLD)
        		{
          			//Threshold crossed 
				parked = true;
        		}
      		}
      		else
      		{
        		if (mag &lt; THRESHOLD * 0.9f)
        		{
          			// Threshold crossed
				parked = false;
        		}
      		}

		// -------------------------------------------------------------- 
		// Adaptive baseline update 
		// When the slot is confidently empty and the measured magnetic 
		// field is still close to the baseline, slowly update the 
		// baseline using an Exponential Moving Average (EMA) to 
		// compensate for gradual environmental or temperature-related 
		// drift. 
		// --------------------------------------------------------------
		if (!parked)
      		{
          		// Check if the current reading is reasonably close to the baseline
			if (mag &lt; (THRESHOLD * 0.5f))
         		 {
              			// Apply an ultra-slow tracking factor (Alpha)
              			// This allows the baseline to smoothly absorb ambient temperature drift
              			BMM350_CALIBRATED_BASE.x = (BMM350_CALIBRATED_BASE.x * (1 - ALPHA)) + (reading.x * ALPHA);
              			BMM350_CALIBRATED_BASE.y = (BMM350_CALIBRATED_BASE.y * (1 - ALPHA)) + (reading.y * ALPHA);
              			BMM350_CALIBRATED_BASE.z = (BMM350_CALIBRATED_BASE.z * (1 - ALPHA)) + (reading.z * ALPHA);
              			BMM350_CALIBRATED_BASE.temperature = (BMM350_CALIBRATED_BASE.temperature * (1 - ALPHA)) + (reading.temperature * ALPHA);
          		}
      		}

	}
	return 0;
}

// ------------------------------------------------------------------ 
// Initialize the BMM350 sensor 
// ------------------------------------------------------------------
static int BMM350_Init(void)
{
	HAL_GPIO_WritePin(MAGNETIC_PWR_GPIO_Port, MAGNETIC_PWR_Pin, GPIO_PIN_SET);
	HAL_Delay(1);
	uint8_t chip_id;
	uint8_t int_ctrl, err_reg_data = 0;
	struct bmm350_pmu_cmd_status_0 pmu_cmd_stat_0;

	rslt = bmm350_interface_init(&amp;dev);

	rslt = bmm350_init(&amp;dev);
	chip_id = dev.chip_id;
	if (chip_id == 0x33)
	{
		  /* Check PMU busy */
		  rslt = bmm350_get_pmu_cmd_status_0(&amp;pmu_cmd_stat_0, &amp;dev);

		  /* Get error data */
		  rslt = bmm350_get_regs(BMM350_REG_ERR_REG, &amp;err_reg_data, 1, &amp;dev);

		  /* Configure interrupt settings */
		  rslt = bmm350_configure_interrupt(BMM350_PULSED,
		                                    BMM350_ACTIVE_HIGH,
		                                    BMM350_INTR_PUSH_PULL,
		                                    BMM350_UNMAP_FROM_PIN,
		                                    &amp;dev);

		  /* Enable data ready interrupt */
		  rslt = bmm350_enable_interrupt(BMM350_ENABLE_INTERRUPT, &amp;dev);

		  /* Set ODR and performance */
		  rslt = bmm350_set_odr_performance(BMM350_DATA_RATE_100HZ, BMM350_LOWPOWER, &amp;dev);

		  /* Enable all axis */
		  rslt = bmm350_enable_axes(BMM350_X_EN, BMM350_Y_EN, BMM350_Z_EN, &amp;dev);

		  rslt = bmm350_set_powermode(BMM350_SUSPEND_MODE, &amp;dev);

		  return 0;
	}
	return 1;
}

// ------------------------------------------------------------------ 
// Read the BMM350 
// For each measurement:
// 1. Switch the sensor to FORCED mode. 
// 2. Read compensated X/Y/Z and temperature. 
// 3. Repeat T_AVG times. 
// 4. Return the average of all samples. 
// ------------------------------------------------------------------
static int BMM350_Read(BMM350_data_t *s_data)
{
    int_status = 0;

    sx = 0;
    sy = 0;
    sz = 0;
    st = 0;

  	  for (int i = 0; i &lt; T_AVG; i++)
  	  {
  		  	rslt = bmm350_set_powermode(BMM350_FORCED_MODE, &amp;dev);
  		  	if (rslt != BMM350_OK)
  		  	{
  		  		return -1;  /* I2C/sensor fault — caller must not act on this read */
  		  	}
            rslt = bmm350_get_compensated_mag_xyz_temp_data(&amp;mag_temp_data, &amp;dev);
            if (rslt != BMM350_OK)
            {
                return -1;
            }
            sx += mag_temp_data.x;
            sy += mag_temp_data.y;
            sz += mag_temp_data.z;
            st += mag_temp_data.temperature;
  	  }

  	  s_data-&gt;x = sx/T_AVG;
  	  s_data-&gt;y = sy/T_AVG;
  	  s_data-&gt;z = sz/T_AVG;
  	  s_data-&gt;temperature = st/T_AVG;

    return 0;
}

// Compute Euclidean distance between the current magnetic field vector 
// and the calibrated baseline.
static float ComputeMagnitude(BMM350_data_t *reading)
{
  float dx = fabs(reading-&gt;x - BMM350_CALIBRATED_BASE.x);
  float dy = fabs(reading-&gt;y - BMM350_CALIBRATED_BASE.y);
  float dz = fabs(reading-&gt;z - BMM350_CALIBRATED_BASE.z);
  return sqrtf((dx * dx) + (dy * dy) + (dz * dz));
}

// Timer callback executed every 1 minute to trigger a new measurement cycle.
void timer_callback()
{
	timer_flag = 1;
	return;
}</code></pre><p><strong>Questions:</strong><br><strong> </strong>1. How to handle this kind of issue?<br>2. Are there any recommended register settings or operating modes for low-power periodic wake-up applications?<br>3. Is this amount of X/Y/Z variation expected for the BMM350 after waking from sleep every minute?<br>4. Is there any known offset drift or baseline drift that should be compensated separately from temperature?<br>5. For parking detection applications, is it recommended to continuously update the baseline (slow adaptive filter) while the slot is known to be empty?</p><p>Any guidance or recommended best practices for using the BMM350 in this type of low-power parking sensor application would be greatly appreciated.</p><p></p>]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[BMV080 SDK RAM usage too large for SAMD21 (Feather M0 / 32KB SRAM) – any minimal or stripped build available?]]></title>
            <description><![CDATA[When integrating the precompiled BMV080 SDK on a SAMD21-based system, RAM usage increases to ~94% of available SRAM.

Since the SDK is not source-available, I cannot reduce internal buffers or disable ...]]></description>
            <link>https://community.bosch-sensortec.com/mems-sensors-forum-jrmujtaw/post/bmv080-sdk-ram-usage-too-large-for-samd21-feather-m0-32kb-sram---any-oVKCayM2yZBoZlA</link>
            <guid isPermaLink="true">https://community.bosch-sensortec.com/mems-sensors-forum-jrmujtaw/post/bmv080-sdk-ram-usage-too-large-for-samd21-feather-m0-32kb-sram---any-oVKCayM2yZBoZlA</guid>
            <category><![CDATA[BMV080]]></category>
            <dc:creator><![CDATA[SBonadurer]]></dc:creator>
            <pubDate>Tue, 09 Jun 2026 21:01:17 GMT</pubDate>
            <content:encoded><![CDATA[<p>When integrating the precompiled BMV080 SDK on a SAMD21-based system, RAM usage increases to ~94% of available SRAM.</p><p>Since the SDK is not source-available, I cannot reduce internal buffers or disable features.</p><p>My questions are:</p><ol><li><p>Is there a minimal or sensor-only version of the BMV080 SDK with reduced SRAM usage?</p></li><li><p>Are there any configuration options to disable debug/logging, history buffers, or optional processing modules?<br></p><p>Any guidance on reducing RAM footprint or a recommended minimal configuration would be greatly appreciated.</p></li></ol>]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[BMV080 sparkfun breakout chip ID incompatible?]]></title>
            <description><![CDATA[SDK version: v11.2.0

Hardware: SparkFun SEN-26554

Chip ID (0x0079)

Can you possibly confirm whether this hardware revision is supported and whether a newer SDK build is available?]]></description>
            <link>https://community.bosch-sensortec.com/mems-sensors-forum-jrmujtaw/post/bmv080-sparkfun-breakout-chip-id-incompatible-nuhNzW9OfJAktZt</link>
            <guid isPermaLink="true">https://community.bosch-sensortec.com/mems-sensors-forum-jrmujtaw/post/bmv080-sparkfun-breakout-chip-id-incompatible-nuhNzW9OfJAktZt</guid>
            <category><![CDATA[BMV080]]></category>
            <dc:creator><![CDATA[jalanbonner]]></dc:creator>
            <pubDate>Tue, 09 Jun 2026 11:03:16 GMT</pubDate>
            <content:encoded><![CDATA[<p>SDK version: v11.2.0</p><p>Hardware: SparkFun SEN-26554</p><p>Chip ID (<code>0x0079</code>)</p><p>Can you possibly confirm whether this hardware revision is supported and whether a newer SDK build is available?</p>]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[BMI270 Z-axis gyro signal exhibits DC bias and higher noise content]]></title>
            <description><![CDATA[Dear Sensortec Team,

we use BMI270 for our mini drones in series production. From a recent batch however, a few drones (around 5%) show weird flight behavior. After inspecting the flight log, we figure...]]></description>
            <link>https://community.bosch-sensortec.com/mems-sensors-forum-jrmujtaw/post/bmi270-z-axis-gyro-signal-exhibits-dc-bias-and-higher-noise-content-XrAd3BZwhaeqNFj</link>
            <guid isPermaLink="true">https://community.bosch-sensortec.com/mems-sensors-forum-jrmujtaw/post/bmi270-z-axis-gyro-signal-exhibits-dc-bias-and-higher-noise-content-XrAd3BZwhaeqNFj</guid>
            <category><![CDATA[BMI270]]></category>
            <dc:creator><![CDATA[mluo]]></dc:creator>
            <pubDate>Mon, 08 Jun 2026 10:12:21 GMT</pubDate>
            <content:encoded><![CDATA[<p>Dear Sensortec Team,</p><p>we use BMI270 for our mini drones in series production. From a recent batch however, a few drones (around 5%) show weird flight behavior. After inspecting the flight log, we figure out that the Z-axis gyro signal of the "faulty" drones has significant DC bias and higher noise content in comparison to the "healthy" drones, which led to deviations in yaw estimation.</p><p>We are aware that mechanical strain on the IMU can lead to abnormal gyro sensing. The layout of the PCB has been designed following this guideline "<a href="https://www.bosch-sensortec.com/media/boschsensortec/downloads/handling_soldering_mounting_instructions/bst-mis-hs000.pdf" rel="noopener noreferrer nofollow" class="text-interactive hover:text-interactive-hovered">https://www.bosch-sensortec.com/media/boschsensortec/downloads/handling_soldering_mounting_instructions/bst-mis-hs000.pdf</a>" (e.g. off-center of strain line, no vias under the chip). Also soldering process was configured according to it.</p><p>Any idea about what can be the reason? Is there any extra advice that we should pay attention to?</p><p>Please let me know if you need more context.</p><p>Thanks,</p><p>Min  </p>]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Adding BME model inference to our platform]]></title>
            <description><![CDATA[Hi there,

We're a startup from Munich that built a platform for assembling AI solutions out of reusable building blocks, such as IO connector blocks, model inference blocks, rules, tracking or ...]]></description>
            <link>https://community.bosch-sensortec.com/mems-sensors-forum-jrmujtaw/post/adding-bme-model-inference-to-our-platform-0WVz1G4dm2udNhs</link>
            <guid isPermaLink="true">https://community.bosch-sensortec.com/mems-sensors-forum-jrmujtaw/post/adding-bme-model-inference-to-our-platform-0WVz1G4dm2udNhs</guid>
            <category><![CDATA[BME]]></category>
            <dc:creator><![CDATA[Iki]]></dc:creator>
            <pubDate>Sat, 06 Jun 2026 11:12:15 GMT</pubDate>
            <content:encoded><![CDATA[<p>Hi there, </p><p>We're a startup from Munich that built a platform for assembling AI solutions out of reusable building blocks, such as IO connector blocks, model inference blocks, rules, tracking or denoising algorithms, etc.</p><p>Once you train your model with AI studio, the next bottleneck becomes how to use it to build different applications. This is where we come in. <br><br>Anyone interested in collaboration to add connector blocks for your sensors and inference blocks to be able to assemble solutions fast?</p><p>Please reach out and share any technical contact we should talk to. Happy to organize a short call to showcase a live demo.</p><p>Thank you! -- Iki</p>]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[BHI360]]></title>
            <description><![CDATA[Dear Team,

I have successfully built the sample SDK example from BHI360_SDK_1.1.18.2_rc7 and generated the firmware image.

I would like to understand the expected functionality of this firmware. ...]]></description>
            <link>https://community.bosch-sensortec.com/mems-sensors-forum-jrmujtaw/post/bhi360-8TSdL8wGF7xiskk</link>
            <guid isPermaLink="true">https://community.bosch-sensortec.com/mems-sensors-forum-jrmujtaw/post/bhi360-8TSdL8wGF7xiskk</guid>
            <category><![CDATA[BHI360]]></category>
            <dc:creator><![CDATA[India]]></dc:creator>
            <pubDate>Fri, 05 Jun 2026 06:52:01 GMT</pubDate>
            <content:encoded><![CDATA[<p>Dear Team,</p><p>I have successfully built the sample SDK example from <strong>BHI360_SDK_1.1.18.2_rc7</strong> and generated the firmware image.</p><p>I would like to understand the expected functionality of this firmware. Specifically, could you please clarify:</p><ul><li><p>What is the intended purpose of this sample application?</p></li><li><p>What sensor features or algorithms are enabled in this build?</p></li><li><p>What output data should I expect after flashing this firmware onto a BHI360 Shuttle Board?</p></li><li><p>Are there any specific host commands or interfaces required to observe the expected output?</p></li><li><p>Is the output available through I2C, UART, or another communication interface?</p></li></ul><p>For my setup, I am not using the Application Board. Instead, I am using a custom board and transferring the firmware to the BHI360 device over I2C. I would like to verify whether any additional configuration is required and what behaviour or output I should expect after the firmware is loaded.</p><p>Any documentation or guidance regarding the functionality of this sample firmware would be greatly appreciated.</p><p>Thank you for your support.</p>]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Open Source and Linux Driver Collaboration Opportunities]]></title>
            <description><![CDATA[Hello Bosch Sensortec Team,

I am a graduate student at the University of Southern California (USC) interested in Linux kernel, embedded systems, and open-source software development.

Recently, I have ...]]></description>
            <link>https://community.bosch-sensortec.com/mems-sensors-forum-jrmujtaw/post/open-source-and-linux-driver-collaboration-opportunities-NBqo8GSs1hmOk1J</link>
            <guid isPermaLink="true">https://community.bosch-sensortec.com/mems-sensors-forum-jrmujtaw/post/open-source-and-linux-driver-collaboration-opportunities-NBqo8GSs1hmOk1J</guid>
            <category><![CDATA[BMI323]]></category>
            <category><![CDATA[EMBEDDED]]></category>
            <category><![CDATA[LINUX]]></category>
            <category><![CDATA[OPEN SOURCE]]></category>
            <category><![CDATA[SENSORAPI]]></category>
            <category><![CDATA[SOFTWARE]]></category>
            <dc:creator><![CDATA[Denny]]></dc:creator>
            <pubDate>Wed, 03 Jun 2026 11:41:19 GMT</pubDate>
            <content:encoded><![CDATA[<p>Hello Bosch Sensortec Team,</p><p>I am a graduate student at the University of Southern California (USC) interested in Linux kernel, embedded systems, and open-source software development.</p><p>Recently, I have been studying Bosch sensor software, including the upstream Linux BMI323 driver and Bosch SensorAPI projects, to learn more about sensor driver development and Linux upstream processes.</p><p>I would like to ask whether Bosch Sensortec has any current or upcoming Linux, embedded software, open-source, or driver development efforts where community contributors or students may participate.</p><p>I am particularly interested in Linux driver development, testing, validation, and upstream open-source contributions.</p><p>Thank you for your time and consideration.</p><p>Best regards,</p><p>Hung-Yu Lin<br>Graduate Student<br>University of Southern California (USC)</p>]]></content:encoded>
        </item>
    </channel>
</rss>