MEMS and sensors

We are using MotionMC v2.9.0 on STM32F407 with an LIS2MDL magnetometer and LSM6DSV16X IMU.Our application is an astronomical Alt-Azimuth mount, therefore the sensor can rotate around azimuth and altitude axes, but cannot be freely tumbled around all three axes.MotionMC is updated approximately every 10 ms (100 Hz), with LIS2MDL magnetic data converted to µT.During a test session we performed multiple azimuth sweeps at different elevations. After approximately 54,000 MotionMC updates the observed raw magnetic coverage was approximately:X span: 533 mGY span: 738 mGZ span: 616 mGDespite this relatively wide 3-axis magnetic coverage, MotionMC remained at quality 0 (UNKNOWN) for the entire session. Hard-iron bias remained {0,0,0} and the soft-iron matrix remained identity.With unrestricted manual 3D tumbling of the same hardware, MotionMC is able to reach GOOD calibration.We would like to understand whether MotionMC requires unrestricted 3-axis tumbling, or whether a two-degree-of-freedom A

 ContextWe are currently using a 3 year old VL53L8CX ULD API version v1.1.0. According to the changelog in the latest ULD API here:ULD API for VL53L8CX version 1.2.0 introduces wrap around filter to limit false positives and an improved rad2perp coefficients which makes corner zones range better. Additionally v1.2.1 adds periodic temperature compensation without stopping and restarting ranging.We are currently facing an issue with a customer where there are missed car detection with VL53L8CX ToF sensor installed in an outdoor setting (in certain situations like in a bright afternoon) and version 1.2.1 might resolve these issues. ProblemThe only available ULD API version on st website is the latest one i.e. 2.0.1. This is a major revision change which increases the porting effort for not a lot of gain from v1.2.1 to v2.0.1 for our specific use case. AskCan you share an older version of ULD API, specifically v1.2.1, to download?

Hi all. We're streaming the IIS3DWB10IS FIFO over 4-wire SPI, mode 3, at 8–10 MHz (on a STEVAL-MKI253KA with a ~15 cm cable). Now and then the part loses its configuration. Registers 0x01–0x12 all read 0x00, while 0x13 and above keep their values and WHO_AM_I still reads 0x50. The zeroed registers include PLL_CTRL_2, which we never write, and PIN_CTRL, IF_CFG and CTRL3, which have non-zero POR values. So it isn't a reset.On the logic analyser (500 MS/s), CS stays low for the whole burst, SCK has exactly the right number of clocks, and SDI is 0x00. Then, 50–80 bytes into the FIFO burst, the sensor stops driving SDO at a byte boundary. INT1 rises within ~100 ns of that moment and falls again 9 bytes later. That is exactly when a "write from 0x00" re-framed at that byte would reach FIFO_CTRL3. It looks as if the SPI frame restarts internally and our 0x00 dummy bytes are taken as a write.The eval board ties DBG1 to GND only through 1 MΩ, where the datasheet says it must be tied to GND. Bri

In Section 5.1 of datasheet for VL53L9CX, it says “Refer to the postprocessing technical note (TN1596) for more details of the data formatting, processing, andfilter functions.”But I cant seem to find the TN1596 document. I am looking for information on the distortion correction on the raw depth output.

We use the VL53L4CD TOF inside a container which is either 390mm long or 260mm long. Our current process during manufacturing/testing is to perform the calibration procedure either using 390 or 260 depending on the container length. This is a manual process.I am looking for a way to automate this.  A way for the device to auto calibrate and auto determine its own length.  Or,  at the end of the day,  we are only interested in the delta between tof readings (items are placed into containers) and only need the 390 or 260 in order to calibrate so we can get an accurate delta.I gotta believe I am not the first to have this issue? The calibration procedure having to “know” the length creates issues in terms of manufacturing hundreds or thousands of bin.  Slows it all down.Any idea?Thanks,Will 

Hi,I am trying to understand the temporal structure of a single VL53L9CX depth-map acquisition for measurements of moving objects.From UM3683 and the register documentation, I understand that a frame is produced using 6 or 7 ranging steps, with successive channel illuminations within those steps.I have a few questions: Are all 54 × 42 spatial zones effectively observed over the same sequence of ranging steps, or are different zones/groups of zones acquired at different times within a frame? If there is any spatially varying acquisition timing, is the mapping from zone (row, column) to acquisition step/channel deterministic and documented? Is the timing of each ranging step and Channel 0/1 illumination deterministic relative to an external SYNC_IN trigger? If so, is there documentation giving these offsets or enough information to calculate them from the configured number of shots/blanking periods? Are intermediate 54 × 42 measurements available after individual ranging steps or c

Hi, I’m trying to use a VL53L9 with a microcontroller which have 128kB of RAM. For this I use the STM32CubeExpansion_53L9A1_V1.0.0 package. The problem is the streaming library delivered within the package is not made for low RAM usage. It’s stack usage is high. Too high for the microcontroller I use.Is there VL53L9 software implementation available for low RAM usage ? Regards,Nicolas

I am using an LSM6DSV320X (STEVAL-MKI251A) read over SPI.Settings: high-performance mode, ODR 1.92 kHz, gyroscope ±4000 dps, LPF1 off, low-g ±16 g, high-g ±320 g, BDU = 1.Problem: after a sharp mechanical shock the gyroscope X and Y outputs become noise swinging up to ±4000 dps from one sample to the next. It lasts from 60 ms to 1.7 s and then stops abruptly, as shown in the first picture. The shock is along Z, about 250 g for about 2 ms.- Y is always affected, X nearly always, Z hardly at all.- Both accelerometers and the temperature output are normal during it. All FIFO tags are valid and no samples are lost. Also, here is a comparison of an ISM330DHCX with the same strikes; only small gyro ringing is observed.What is the issue, and is the new LSM6DSK320X immune to this? 

Hello,I understand that ToF sensors inherently have limited performance under daylight conditions. However, I would like to know which ST ToF sensor family currently offers the best performance in daylight, regardless of whether it is a single-point or multi-zone sensor.The VL53L9 series looks very promising for our application, but unfortunately, its cost is above our target budget. Therefore, I am looking for a more cost-effective alternative that still provides good performance under daylight conditions.A wider FOV would be preferable for our application.Would it be reasonable to select a sensor based primarily on its maximum specified detection range? If so, the VL53L1 series seems to be a good candidate. However, I am not sure whether the maximum specified range is the best parameter to use when comparing sensors for real-world daylight performance.I also assume that a wider FOV reduces the number of photons received per unit area, which could potentially reduce the sensor's perfo

Although the data sheet specifies a field of view of either 27 degrees or 36 degrees (depending on where about it is mention in the data sheet, I have found the effective FOV to be aound 8 degrees. Setup as follows  sensor.setDistanceMode(VL53L1X::Medium); sensor.setMeasurementTimingBudget(33000);  sensor.setROISize(16, 16); startcontnuous(100);with all other sensor settings at defaultA large all black target set up at 140 cm from the sensor, reulted in a invalid reading. I then moved a white target in from one side until a valid reading was made, marked the position and repeated this for the other side top and bottom.This resulted in an area in the middle of about 20 x 25 cm which represents a FOV of around 8 degrees. Any target outside this selected area will reults in an invalid reading (i..e canot be trusted). Targets with in ths area will be detected although the accuracy is very dependent on the refectivity of the oblect, the variation between measured and actual by as much as 30

Hi,We found an issue in VL53L4CD_CalibrateXtalk() (ULD v2.2.2, as shipped in X-CUBE-TOF1 v3.4.3).When the measured average distance is slightly greater than the target distance, the computed crosstalk is negative:ctmp_xtalk = (float_t)1.0 - (AvgDistance/TargetDistance);tmp_xtalk *= (AverageSignal/AverageSpadNb);The function only checks the upper bound (tmp_xtalk > 127.0). It then casts the negative float to uint16_t, which is undefined behavior in C. On our platform the value wraps. For example, −3 kcps is returned as 65533 and reported as a successful calibration, and the register is written with 64000, which corresponds to about 125 kcps.With that value applied, crosstalk compensation removes nearly the entire return signal: 125 kcps/SPAD × 77 SPADs ≈ 9,600 kcps, against a raw signal of about 9,700 kcps. Every subsequent measurement fails with "signal below threshold" (range_status 2, distance 8191 mm).Setup: offset calibrated at 100 mm, then crosstalk calibration on a white targe

 Hi ST team,I am using the ST VD66GY image sensor connected to a Rockchip RV1106 processor with the Rockchip hardware ISP.I have successfully enabled the camera pipeline and can capture images, but the image quality has a strong greenish color cast and the colors look desaturated, even under a bright indoor room with white LED lighting.Current setup Sensor: ST VD66GY Processor: Rockchip RV1106 ISP: Rockchip RKISP (hardware ISP) Capture: RAW from VD66GY → RKISP → Image output Observed issue Strong green tint across the entire image Skin tones appear gray/green Low color saturation Indoor lighting is much brighter than what the captured image suggests I have attached three sample images captured with the current ISP settings.Questions Does ST provide an IQ tuning file or reference tuning parameters for VD66GY when used with a third-party ISP such as Rockchip RKISP? Are there recommended AWB calibration, Color Correction Matrix (CCM), or Lens Shading Correction (LSC) values

I purchased  X-NUCLEO-53L9A1 with NUCLEO-H563ZI as it was recommended by ST. I just want to load the binary and see a simple ranging output value array. The binary provided didn´t work. Now it seams like they recommend  Nucleo N657X0. Could please someone clarify what board should I use so that there is a working binary provided?

Hello ST Team,We are using the VL53L8CX (VL53L8CXV9GC/1) ToF sensor with an NXP i.MX8MP running Linux over I²C.We understand that the VL53L8CX has an internal MCUWe would like to clarify: Does ST provide firmware updates/releases for the VL53L8CX? If yes, how can we obtain the latest compatible firmware? What is the recommended procedure to update/load the sensor firmware from a Linux host? Does ST provide any recommended firmware version-check or firmware update API for production devices? Please provide the recommended procedure, documentation, and any required ST software package/API. Thanks.

SummaryOn my STEVAL-VL53L9, the VL53L9CX boots, installs FW patch 0.17, reaches STREAMING with all error bits clear — and then faults on the very first frame. The reference SPAD array reports zero amplitude on every channel, as if the VCSELs never fire.I have reproduced this with two different VL53L9CX parts and three independent host implementations, each of which is known to work on another STEVAL-VL53L9. I have run out of things I can change from software, and I would like to understand what the firmware error codes mean.SetupBoard: STEVAL-VL53L9, VL53L9CX hand-soldered by me Host: ESP32 (DevKit v1) through the J2 header, plain I2C at 400 kHz, address 0x29 Clock: on-board 12 MHz Y1 (R25 removed, R24 fitted, R23 removed); EXT_CLOCK = 12000000 J3 (Host IO) = 3.3 V; VDDA_CFG = 2.8 V, VDDIO_CFG = 1.8 V XSHUT driven by the host, SYNC_IN tied high, INTR not used (FRAME_READY polled) FW patch 0.17 (9,865 bytes, byte-identical to vl53l9_patch.h in STSW-IMG053 / 53L9A1 BSP)SymptomDefault pro

Hello Team,I am integrating the VL53L8CX ToF sensor over SPI with an NXP i.MX8MP LPDDR4 EVK running Yocto Linux with kernel 6.18.20.I have created a Linux SPI driver based on the VL53L8CX communication requirements and added the sensor as an SPI device through the Device Tree.The SPI bus itself appears to be configured correctly, and the driver is being loaded. However, I am currently unable to successfully read the VL53L8CX device ID/registers from the sensor.Hardware:NXP i.MX8MP LPDDR4 EVK VL53L8CX sensor/module SPI interface SPI controller: ECSPI2 Chip Select: GPIO5_IO13 SPI device: spi1.0Device Tree configuration:&ecspi2 { #address-cells = <1>; #size-cells = <0>; pinctrl-0 = <&pinctrl_ecspi2 &pinctrl_ecspi2_cs>; cs-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>; status = "okay"; vl53l8cx@0 { compatible = "st,stmvl53l8cx"; reg = <0>; spi-max-frequency = <1000000>; };};The driver is successfully loaded

Subject: X-NUCLEO-CCA02M2 PDM-over-SPI capture issue on STM32MP257F-EV1 - discontinuous clocking suspectedHello ST Support Team,I'm working with an X-NUCLEO-CCA02M2 dual PDM microphone expansion board interfaced to an STM32MP257F-EV1 evaluation board, and I'm running into a data-quality issue I'd appreciate your guidance on.Setup:- X-NUCLEO-CCA02M2 board, using onboard microphone M2 (MIC_PDM34_OB), routed via SB10 solder bridge to CN10 pin 15- Connected to the STM32MP257F-EV1's SPI8 peripheral in Linux userspace via /dev/spidev, MISO on mikroBUS pin 5 (PZ1), clock supplied from SPI8's own SCK (mikroBUS pin 4, PZ2) to CN10 pin 29 (MIC_CLK_NUCLEO)- Power from CN6 pin 3 (3.3V), GND from CN6 pins 6/7- Capturing via repeated SPI read calls (spidev, bufsiz increased to 65536, Mode 0)Issue:Short, isolated SPI captures (around 2000 bytes at a time, with pauses between reads) show clearly responsive behavior - bit density in the captured stream increases noticeably when speaking near the microp

UL have requested CDRH certificate for VL53L8CX. Can anyone help?

I am currently working with the VL53L1X Time-of-Flight (ToF) distance sensor and am experiencing inaccurate and inconsistent distance measurements.The sensor is able to detect objects and provide distance readings, but the measured distance does not consistently match the actual physical distance. I have observed variations/errors in the distance readings even when the target position remains unchanged.Could you please help me identify the possible cause of this issue and suggest the recommended configuration or calibration procedure?I would appreciate your guidance regarding the following points:* Recommended initialization and configuration settings for the VL53L1X.* Recommended timing budget and ranging frequency settings.* Calibration procedure for accurate distance measurement.* Recommended offset and crosstalk calibration procedure.* Effect of target reflectance, ambient light, and target size on measurement accuracy.* Recommended sensor mounting and target conditions for reliabl

Hello, I am using VL53L9CX with adapted drivers for ESP32 / Arduino environment. I am able to read values and play with the settings but I am a bit worried with the precision I get. I run the sensor in precision mode, 4ms exposure time. My bench is indoor. Sensor facing the ground ( 1 m ish, wood) or the roof (1.6m ish, white ceiling). Resolution is 8 x 6 (Binning 12). I have radial to perpendicular conversion enabled so I am expecting to see all distances being equal +/- precision across the cells of the frame (excluding corner cells maybe). According to table 34: Precision for “ambient mode 24x20” profile from the sensor datasheet: (results are better for 24*20 then they are for 54*42, so I assume it is the same or better for 8*6 compared to 24*20)I am expecting less than 0.8 mm difference between the values but instead I get 50 mm - 100 mm or more of difference. So I was wondering, is there some specific settings to enable to achieve such precision / accuracy ? PCB is of my own (not

Hi, STNow I followed the X-NUCLEO-53L7A1 User guide connection for the SATEL-VL53L7A TOF breakout boards LEFT and RIGHT Connection as Shown in the attached image and it worked well, even if there are 2.2K pull up resistors for each sensor which makes the equivalent pull up resistor = 2.2K / 3 but I worked well till I also added another 2 SATEL-VL53L7A TOF breakout boards in addition to 1 Barometer Sensor breakout board which has the part number STEVAL-MKI225A it started to make undefined behaviors such as (TOF sensors Initialization fault, Barometer Sensor Initialization fault, Barometer wrong readings).So, could this problem caused by another 2 SATEL-VL53L7A TOF breakout boards with there Pull-up resistors?and If yes, Should I remove the 0 Ohm resistors on solder bridges to disconnect the pull-up resistors from each sensor as shown in the second attached image?

I designed a small PCB for LSM6DSV but I got no signal on SPI-MISO and got NACK on I2C-SDA.I have replaced several chips but all the chips have the same behaviour(no signal reply).I'm very sure the SPI and I2C pins are correctly connected to LSM6DSV.(1)Custom PCB designThis is the PCB design of my custom board. All the net label are connected to pads on board. Never mind "LSM6DSOTR" in the schematic. Actually I soldered LSM6DSV on board since LSM6DSV has the same chip package with LSM6DSO.VDDIO and VDD are 3.3V and this board shares the same ground with stm32.(2)SPI communication issueSPI_SCK and SPI_MOSI signal is correct but SPI_MISO has no signal.I configured STM32H743XIH6 SPI in STM32CubeMX like this. No NVIC, no DMA.I implemented the SPI polling read/write function for official ST LSM6DSV driver code. int32_t lsm6dsv_spi_read(void* handle, uint8_t reg, uint8_t *data, uint16_t len) { reg |= 0x80; LL_SPI_SetTransferSize(handle, len+1); LL_SPI_Enable(handle); LL_SPI_StartMas

I have a problem with identifying the sensor type from the marking on the housing. My understanding is the first two digits of the code are how you identify the part, but I could not find a good key to decipher it.The two digit code is “3B”Would it be possible to identify the part number based off this code?

Hi I would like to clarify the exact behaviour of the BDU function. According to the datasheet and application note, BDU should prevent the output registers from being updated until both the LSB and MSB have been read.After enabling BDU, I repeatedly read only the LSB register without reading the corresponding MSB. However, I receive a new LSB value with each read. This means LSB is getting updated, eventhough the condition of reading both LSB and MSB is not fulfilled. Why acceleration data appears to update even though the corresponding MSB register has not been read?I’m using the following notations to explain better. Time LSB MSB t1 L1 M1 t2 L2 M2 t3 L3 M3 t4 L4 M4  Could you please clarify whether the LSB is allowed to update while the MSB remains frozen? If so, when the MSB is eventually read, should it correspond to the first LSB value or to the latest LSB value? i.e. If i read LSB only 4 times and then read MSB, would it be M1 or M4?  Is the BDU behaviou

Hello,We are observing what seems to be unexpected behavior when using the Sharpener feature with an 8×8 autonomous ranging profile in VL53L5.Configuration:- Ranging profile: 8×8 autonomous- Integration time: 60- Frequency: 2- Target order: Closest Our primary target (marked in red) is a surface parallel to the field of view axis. The FoV intersects the surface at approximately 30 mm, which is correctly reported by the Distance measurement.Initial measurements: Sharpener = 0%Signal per SPAD:    6.00     3.00     3.00     2.00     3.00     3.00     2.00     3.00    7.00    13.00    15.00     5.00     3.00     4.00     2.00     0.00   67.00    56.00    43.00     9.00     7.00     6.00     3.00     3.00  131.00   131.00    44.00    18.00    19.00    12.00     7.00     4.00  154.00   142.00    44.00    36.00    38.00    29.00    17.00     4.00  230.00   148.00   105.00    85.00    69.00    55.00    31.00    14.00  303.00   314.00   171.00   120.00   112.00    82.00    48.00    27.00  561.0