MEMS and sensors

I am using a VL53L0 ToF sensor.If an interrupt occurs, repeat the measurement using the "VL53L0X_GetRangingMeasurementData" function and the VL53L0X_ClearInterruptMask function.Normally, it operates, but the sensor outputs data that seems to be looking in the air due to unknown causes such as static electricity.From the IR camera, there is no light in ToF.Two functions, VL53L0X_GetRangingMeasurementData and VL53L0X_ClearInterruptMask, do not return errors.When I initialized the phenomenon after checking it, the sensor operated normally.I'm wondering if there's any data I can check because the data is similar to what I'm seeing in the air about the above phenomenon.

Dear ST Support Team,I am writing to express my interest in the VD55H1 iToF sensor for an upcoming project.Currently, we are preparing for development using the i.MX8MP platform running on a Linux Kernel. Upon reviewing the technical specifications, I noted that the VD55H1 utilizes a MIPI-CSI data interface.Could you please confirm if ST provides an official Linux driver for the VD55H1?As driver availability is a critical factor for our initial integration and development phase, we would appreciate any information regarding existing software support or a roadmap for Linux integration.Thank you for your time and assistance.Best regards,seobi

raw ID and is_alive() work Hello,I am using a Chinese VL53L8CX module from AliExpress, not the official ST evaluation board. I want to stress that in the first sentence because this may be important: this is a Chinese AliExpress breakout, not the original ST hardware. The same module works on my setup over I2C, but I am trying to bring it up over SPI on an ESP32-S3 and I am stuck at a very specific point.What already works:- The same sensor/module works over I2C on this board.- In SPI mode I can repeatedly read the hardware ID correctly: `dev=0xF0`, `rev=0x0C`.- `vl53l8cx_is_alive()` often returns `status=0, alive=1`.What fails:- `vl53l8cx_init()` never completes successfully.- The failure happens around the software reboot / boot polling stage.My hardware/software context:- ESP32-S3- custom firmware using Arduino + ESP-IDF SPI path- Chinese AliExpress VL53L8CX module- `SPI_I2C_N` forced HIGH for SPI mode- level-shifted module, jumper wires about 20 cm- SPI mode 3- SPI clock curre

In the getting started guide there is a programmable audio buzzer names SPK1 but I can't find reference of it anywhere, where I can enable it in the .ioc file and how to interact with it? Please could someone advise me on this.

I am trying to implement Time-of-Flight data acquisition using an STM32F405 microcontroller running FreeRTOS, with the MCU and the VL53L8CX communicating via SPI. However, the vl53l8cx_check_data_ready() function keeps failing, and I have been trying to track down the root cause.Here is what I have verified so far:After loading the firmware to the VL53L8CX and starting it, I confirmed that the sensor is emitting infrared light (observed using a camera).I checked the status return values from the API functions, and no errors were reported.There were no issues with the 3.3 V power supply, and no temporary voltage drops were observed during sensor reboot.I probed the INT pin with an oscilloscope to check if the VL53L8CX is outputting an interrupt signal at the interval set by vl53l8cx_set_ranging_frequency_hz. However, no interrupt signal was observed.For comparison, I tested a bare-metal (non-FreeRTOS) SPI implementation on a NUCLEO-F446RE evaluation board. In that setup, the interrupt s

Hi, ST Community, I am working with an LSM6DSOX on a custom board, using an ESP32S3 with the Arduino framework, and I'm unable to get the Machine Learning Core (MLC) to run.The problem is that the output register MLC0_SRC (0x70) always reads 0x00. I am also monitoring the is_mlc_ok status bit in the EMB_FUNC_STATUS register (0x15), and it never gets set to 1. Basic communication (reading WHO_AM_I and raw accelerometer data) works perfectly.I am not using a library and am writing directly to the registers. My initialization sequence is as follows:Software Reset: Write 0x01 to CTRL3_C (0x12).Wait: A 100ms delay to ensure the reset is complete.Enable Embedded Functions Access: Write 0x80 to FUNC_CFG_ACCESS (0x01).Load UCF Data: Write the entire .ucf file (288 bytes) byte-by-byte by setting the address in MLC_A_ADD (0x02) and writing the data to MLC_B_ADD (0x03). I have verified the data is being written.Disable Embedded Functions Access: Write 0x00 to FUNC_CFG_ACCESS (0x01).Enable ML

I connected the VD55G1 promodule on the LS-CAM-I3C and connected it to the NUCLEO-H563ZI.The Display X-NUCLEO-GFX02Z1 is also connected.This is exactly the same configuration from the README.md.I get always an error in "ret = platform_i3c_assign_dynamic_address(p_dev->p_ctx);" (Line 82 display_qvga_streaming_i3C.c) I3C ErrorAccording to https://www.st.com/resource/en/user_manual/um3224-how-to-integrate-and-configure-the-vd55g1-sensor-stmicroelectronics.pdf Page35 I assume a ACK at the second W=0x7E (ENTDAA).I have a very shot cable between the NUCLEO Board and the LS-CAM-I3C.What could be the Problem

The sensor box pro is a neat device.  If I use the CLI Example program and the USB cable, I can get 8000 data points per second, if I use a traditional C# program I get 8 data points per second.  The CLI yields dat files, which can be read with a simple C# program, although why you would mix 6 and 4 data groups is beyond my skill set to understand, but it is easier to use than Python and MEMS Set.   And it is easier to do the byte data in C#.  (It took less time to write this program than I spent trying to get Python to work.)CLI Example makes me type enter to start.  I have many ST.COM accelerometers all over the world and I am not going to type enter to start, but the main.cpp and main.h and the cmake lists file will not compile in CMAKE or Visual Studio.  So I cannot fix the challenging feature. Could we get VS SLNX file and the C++ code for this program as part of the SLNX so it is easy to take out the enter statement and break the outpu

Hello, I have a setup with a processing unit connected to two IMU sensors via SPI.One of those IMU's is the IIS3DWB.I am configuring the IIS3DWB with FIFO in continuous mode and I can read data properly from FIFO.I decided to make long run tests. With these tests, I noticed that some times after 10 minutes, after 2h or more, I can't read data from the IIS3DWB FIFO since the values read from FIFO_STATUS1 and FIFO_STATUS2 are 0.I wrote a piece of code to only run after this transition from proper read to read 0's, where I read the CHIP_ID and the FIFO_CTRL registers. The result is a proper read of the CHIP_ID and the all FIFO_CTRL registers are read as 0.It looks to me that some reset occurred to the internal registers. Aren't the capacitors of the STEVAL board making his job?As a note, the other IMU continuous working properly and SPI bus also does not present any issue.Do you have a suggestion on how to mitigate or debug further?Thank you. 

Greetings - I would like to request consideration for a Latched INT option similar to that of the STHS34PF80 sensor (Register: CTRL3 22h). I typically utilize the VL53 with Min/Max threshold values and would like the option to have the INT signal latched when the object is within threshold values.Thank you for the consideration,Terry

Is there a way to change the Horizontal front and backporch?   This is a addon to this question* https://community.st.com/t5/imaging-sensors/vd56g3-camera-change-the-frame-start-and-frame-end/m-p/888134#M6406@Jean_Poire 

I am using the VL53L7CX to measure a black object. When the object is placed at a distance beyond 200 mm, the readings become very unstable and a large number of erroneous points appear. Additionally, when a highly reflective object enters the sensor’s field of view, the points that were previously showing valid data for the black object also start returning errors. Once I remove the highly reflective object, those points recover and start reporting correctly again. In the error state, the affected points return no data at all — it seems as if the sensor does not detect any object. However, the black object is still present in the scene. The only change is the removal of the white object, which causes the sensor data to change significantly. Has anyone encountered a similar issue? Could this be related to crosstalk, or are there specific configuration settings recommended for black targets at longer distances? Any advice would be greatly appreciated.

Hello,I am currently working on a drone project based on the STEVAL-FCU001V2 board. My hardware setup consists of:Motors: 4x 8520 Coreless DC motors (3.7V).Battery: 1S LiPo 600mAh (30C).Frame: Custom micro-drone frame (~60g AUW).I am looking for a reliable and fully functional firmware (source code or .bin) that is compatible with the latest mobile application for flight control of STM.I’ve noticed that the original ST Drone (or ST BLE Drone) application sometimes has connectivity or stability issues with recent Android/iOS versions.My questions are:Is there a specific version of the STSW-FCU001 firmware that you recommend for best stability in 2026?Is the "ST Drone" app still the official way to fly this board via BLE, or is there a community fork or a newer ST app recommended for this specific FCU?Are there any known patches for the PID values or PWM frequency (specifically for 8520 motors) to improve the hover stability?Any advice, GitHub links, or updated STSW packages would be gre

I have an application where I run the VL53L1X in lite ranging mode and short distance mode with a timing budget of 10 ms (100 Hz) as described in AN5263.I recently noticed that on at least one unit (and probably more) the VL53L1X reports a spurious distance reading of 0 mm with no errors even though the sensor is pointing into an empty space and there are no objects within the 1.3 meter range of short distance mode.  This spurious reading happens about 10 times per minute, and the rest of the readings are regular expected errors.I am not using the API (STSW-007) directly, but have implemented code that does the equivalent thing.Here are some VL53L1X register values from these spurious readings:The lower 5 bits of the VL53L1X result__range_status register (0x89) is always 9.  That corresponds to VL53L1_DEVICEERROR_RANGECOMPLETE and that is the value that the API maps to 0.The result__stream_count register (0x8B) is between approximately 130 and 250.  The&nb

We are designing a lens cover to be used with VL53L9CX. Can you share any more data on the FoV of the time of flight sensor? The attached data sheet on the part page is for a different sensor "VL53L7CX" is there a data sheet for the "...9CX" version? In "Description of the fields of view of STMicroelectronics' Time-of-Flight sensors" Sections 3.2 & 3.3 reference exclusion cones which are given in a product data sheet. Could you please share this file? Also, 3.3 references keep-out cones which can be shared by contacting support. Any additional information would be helpful to ensure our lens does not interfere with the required FoV. Thank you! 

I have questions regarding estimated_reflectance and range_sigma in VL53L5 and L8The reflectance: how is it calculated? Is it R=signal_rate_per_spads*depth^2/K? the number_of sapds_enabled seems a useless parameter for a user? Can we know this calibrated constant K?The ambient_light has nothing to do with the R calculation?For these multi zone TOF, if we place a flat target in front of TOF, it shall give the same R. ST’ already does the internal compensation for the depth and for the angle of incidence. Right??  I can not find this kind of info in ST’s doc. Can only guess. If it has, please point out the Docs sourceThe range_sigma: for L5, if the resolution is 4 x 4, the readout is zero. I can read out  this parameter if it is 8 x8What is the default sigma_threshold for distance in L5? Is it the same for resolution  8x8 and 4 x4? Also, when I change this threshold, it is unclear if this threshold, e.g.,100mm shall multiply with a scale factor 128. Please confirm thatThan

I'm using the library here: https://github.com/stm32duino/VL53L1, and it seems to stop measuring around 3.2-3.5 meters. I may be wrong, but think that means that it is not using the histogram? I set it to long distance ranging mode.Here is my code:bool Sensor::ConfigureSensor(TOF &tofSensor) { Log.noticeln("Configuring [%s]", tofSensor.name); if (tofSensor.sensor_object == nullptr) { Log.fatal("No TOF sensor object initialized."); return false; } VL53L1_Error status; status = tofSensor.sensor_object->InitSensor(tofSensor.address); delay(10); if (status != VL53L1_ERROR_NONE) { Log.fatal("Failed to initialize %s. Status: %d. Halting.", tofSensor.name, status); while (1){;} return false; } Log.noticeln("%s address set to 0x%x", tofSensor.name, tofSensor.address); status = tofSensor.sensor_object->VL53L1_SetPresetMode(VL53L1_PRESETMODE_RANGING); delay(10); if (status != VL53L1_ERROR_NONE) { Log.errorln("Failed to set preset mode for %s", tofSen

Hello, I am using this sensor for a project where it is mounted on a cane to detect overhanging objects that could hit visually impaired people. This works fine indoors, but outdoors, when the ambient light is around or greater than 10k Lux—and keeping in mind the sensor is pointed upwards and hit directly by sunlight—it only catches obstacles when they are very close. I am currently using a 4x4 resolution with continuous ranging at 30Hz. My question is: is there a way to increase its efficiency? By efficiency, I mean increasing the detection distance through hardware, structural, or software solutions.

 Dear all,I am struggling with getting a good SFLP result, that does not drift too much and does not appear jittery. I went trough most of the posts here but I am still not able to get good results (approx. factor 10 higher drift then according to the data sheet). in one of the posts I found the explanation about the chain of the SPFL:  that was the one im ent: For now, you have the answers: SFLP (as MLC/FSM and other embedded functions) take its input from LPF1 in the accelerometer chain, and from LPF2 in the gyroscope chain; their setting will therefore impact SFLP. Higher ODR leads to a more accurate gyroscope integration, but sensor RMS noise will also be higher. Gyroscope saturation should be avoided, accelerometer saturation matters less. Lower full scale will increase the resolution and therefore the accuracy, but the risk of saturation will be higher. It is a delicate balance that is specific to every application. Post in forum According to th

We are currently experiencing issues with the LPS28DFW.We observe pressure values dropping to 0 or even negative ranges (e.g., around -400 mPa), as well as unexpectedly high values (up to approximately 1200 mPa), while the expected range should be around 950 mPa. We are also seeing abnormal temperature outputs, including unrealistically low values (e.g., around -400°C).this happens when the sensor is in contact only with air and also when it is in contact only with water. When the sensors from the field they are brought back in the lab the sensors seem to recover on their own and return to normal readings.

Hi,I'm using the LIS2DUXS12 in FIFO Stream mode with DEC_TS_32. FIFO watermark is set to 64. Looks like every ~17 FIFO reads (~1055 XL samples), exactly 1 accelerometer sample is lost. The pattern is consistent and repeatable.Each FIFO read of 64 entries normally contains 62 XL samples + 2 timestamp tags. However, every 17th read contains 63 XL + 1 timestamp tag. Looks like before this batch with 63 XL samples, there is 1 XL sample gap in data.I use only the timestamp present in the FIFO batch to calculate timestamp for each sample. And with that approach samples in that FIFO batch aligns with next FIFO batch exactly - no gaps, no overwriting, fixed period. So despite the fact that this FIFO batch contains one XL sample more than the other, there's still a gap in data. Configuration:- ODR: 200 Hz (HP mode)- FIFO mode: Stream (continuous)- bdr_xl: ODR- dec_ts: DEC_TS_32- xl_only_fifo: 1- FIFO watermark: 64I couldn't find errata for LIS2DUXS12. Questions:1. Is th

I've installed MEMS Studio v2.3.0 and trying to evaluate ST1VAFE3BX sensor -- in particular the vAFE ONLY operation in FIFO mode -- using the STEVAL-MKI109D evaluation board with STEVAL-MKI250KA evaluation kit plug-in module. Previously I had MEMS Studio v2.2.0 installed and that was working. I've just updated to v2.3.0 and now the setup is not working.- I did update the FW on the MKI109D board; MEMS Studio indicates "FW: 2.6.17".- I see a tiny fraction of a second of data in the plot window, and then nothing.- The pink "Run" button becomes grayed out/deactivated.- Most options typically under the "Sensor Evaluation" panel disappear. How do I use MEMS Studio to evaluate the ST1VAFE3BX sensor in "vAFE only" mode?

Hello,I am using MEMS Studio (latest version) with the LSM6DSV320X to configure the Machine Learning Core with 2 decision trees.Steps I follow:Open MLC tool, set workspace via BrowseImport mlc_settings.json — data patterns load correctlyARFF Generation tab — add features, click Generate ARFF File — generates features.arff successfullyDecision Tree Generation tab — set 2 trees, assign labels to each treeClick Generate Decision TreeError:Unable to open features_DT0.arffI notice two problems happening:MEMS Studio generates features.arff but then looks for features_DT0.arff when generating 2 trees. With 1 tree it works fine.When the error occurs, the file features_DT0.arff (which I manually copied/created) gets deleted from the workspace folder.After the error, mlc_settings.json gets reset — the dectrees[].filename fields are cleared back to empty strings, and sensor settings revert to defaults.What works:1 decision tree generates successfully every timeWhat fails:2 decision trees — always

Hello ST Community, I am currently in the hardware selection phase of a product development project and am evaluating STMicroelectronics accelerometers for our production design. I am hoping the community and ST engineers can help clarify driver availability and support options for our target platform.Platform OverviewOur production platform is based on the Quectel SC200U module running Android 14. The key processor specifications of this platform are as follows: Application Processor: Octa-core 64-bit ARM Kryo™ 260 CPUDSP: Qualcomm Hexagon DSP, Dual-HVX @ 512 MHzGPU: Adreno™ 610 @ 950 MHzOperating System: Android 14A critical hardware design constraint of this platform is that the dedicated SENSOR_I2C interface exclusively supports sensors operating under the ADSP (Audio Digital Signal Processor) architecture. Specifically, the hardware design document explicitly states:"SENSOR_I2C only supports sensors in the ADSP architecture"Accelerometer Candidates Under EvaluationW

Hello, I am trying to build a simple firmware for my SensorTile.Box PRO to stream any data. Using MEMS Studio's AlgoBuilder, I have set the correct Toolchain (STM32CubeIDE), and the target (SensorTile.box Pro). Then I built a simple design with Quaternions 9X attached to the Sensor Hub (Data Rate: Timer/100, Accelerometer Full Scale: 2g, Gyroscope Full Scale: 245dps), outputting to a Fusion component. I can generate C code and build and program my device in DFU mode.However, when I connect it over Serial after rebooting the device, I can connect to it but the "play" button is grayed out and I cannot stream any data.Using STM32CubeProgrammer to flash other compatible firmware that came with MEMS Studio (steval-mkboxpro, steval-mkboxpro-ble), I can connect and stream (play button is enabled) data as per normal so I doubt the problem lies with the hardware.I have also tried other designs with SensorHub -> Any other sensors -> Value instead of Quaternions 9X, but none of it work