Imaging (sensors)

I am using the exaple1 ranging basic (VL53L5CX_ULD API ) on microcontroller nrf52840.during vl53l5cx_init(&Dev) we get stuck on "do while loop" in the below Function (vl53l5cx_poll_for_answer() line number 304 ). I'm include the I2C driver (Read&Write) and also I attached the image of (where I got stuck with the Function)

Hello,the VL53L5CX is a really nice senor. I have done some measurements using the Windows GUI and was impressed, so I wanted to write a driver for the sensor and do some further evaluation.I then tried to initialize the sensor using the ULD-API and my Nucleo-Board, but the sensor is not detected via I²C, I double checked with the Windows GUI - everything works just fine - so the Hardware should be alright.I tried using the provided example in the API - same problem. I did not do anything fancy yet, are there some known issues? What is the Firmware in the Windows GUI doing different than the API? The init() loads the default firmware to the sensor, how long does that take?Background:I am using the latest API V1.1.2I am using the platform.h and .c from the exampleI²C address is VL53L5CX_DEFAULT_I2C_ADDRESSbefore calling init() I set GPIOs PWR_EN_C, LPn_C, and reset I2C_RST_CI make sure to wait long enough for the power supply to be stableWhat else could go wrong?Thank You for Your help!

..

I'm using the X-NUCLEO-53L1A1 and the STM32F401. As the user manual suggests. The GUI opens, but cannot detect the sensor. "Sensor Not Detected. Please ensure sensor connected then Press Black Reset Button on the Nucleo". The X-NUCLEO-53L1A1 is seated correctly in the STM32F401.Pressing the black button LD2 turns off briefly then turns back on but noting happens in the GUI. I've installed STSW-LINK007. Current Firmware: Version: V2.J39.M27Type: STM32 Debug+Mass storage + VCPThe host PC has the STLINK VP drivers installed. The ST virtual COM port is shown in my device manager. LD1 is lit red, so the Nucleo Kit is connected to the PC. I also have the VL53L5CX GUI. This works fine. I've seen that a few people have also run into this problem, but there does not seem to be any answers. Do you know what is happening @John E KVAM​ ?

In order to test the X-NUCLEO-6283A1 I installed its GUI (en.VD6283_Setup_v1.0.0.exe).I also installed the ST Link USB driver (as suggested in the GUI Guidelines) and the board is correctly recognized by the host. The GUI seems working fine the very first time. However the communication between the GUI and the Nucleo board is glitchy/faulty and errors are reported when the GUI is started the next time or Start button is clicked. If bluetooth is disabled (as suggested in the GUI guidelines) I cannot even establish the communication with the Nucleo board. The Flash FW button is not working. I have to manually load the BIN file (console_app_VD6283.bin) by dragging it in the NOD_F401RE drive.Could you check the application FW and GUI SW?Notes: on the same host I can correctly run GUIs for VL53L0X, VL53L1, VL53L1X and VL53L5CX.

Hello. I have problems with VL53L0X sensor. I will list my observations here.First, I carry out the calibration procedure. The sensor passes all initialization steps correctly (Data Init(), Static Init() and so on). Then calibration is performed. For example, the following values were found:spad_refSpadCount = 3,spad_isApertureSpads = 1,temperature_VhvSettings = 27,temperature_PhaseCal = 1,offset = 10000,xtalk = 127.Then, when starting the sensor, I first apply 0 to XSHUT for 1 second, then 1 for 1 second and then start initialization procedure, load calibration parameters to the sensor and then start reading values from the sensor. The problem is that at first launch it outputs 8191 (with a period of 200 milliseconds OR 30 milliseconds). I stop the program, start it again and the sensor outputs the correct values. An example of this situation is in the log file. It shows that at first (correct) launch sigma value is 1.5 and signal return value is 16. But at second (wrong) launch

We are using VL53L3CX evaluation board to dig out some information from the histogram.The 24-bin histogram are retreived by calling the Get_AdditionalData function. Two consecutive sets of histograms are got, when we use a white wall as target and the distance between EVM and the wall is 70cm. As shown below, there are two peaks in each consecutive histograms, which make me confused. Is it reasonable to get histograms just like these? Or I got something wrong on retreiving data?Many thanks,XM

..

I am trying to use the VL53L5CX with an AVR128DB48. The .h file "vl53l5cx_buffers.h" seems to be too large for the MCU to handle. I think, as it stands, it breaks the 32727 byte limit that AVR is capable of. Is splitting "VL53L5CX_FIRMWARE[]" into smaller 'chunks' to send to the SPAD a reasonable solution? Has anyone else encountered this problem?  Is there an alternative that I have missed that is more compatible with an AVR MCU?Is there any reason that this will not work with the VL53L5CX? 

I try to find the schematic, but I only see the gerber files on ST web site (CAD ressources)Regards,

ST,Another non-IR sensor we have worked with has something called 'static object removal' in its microcode. When this function is turned on for a given range, it internally histograms the environment so that objects within this range 'get deleted from consideration' after a few seconds- this allows intruders which subsequently enter within this zone to then be detected. Happily, human intruders (elbow tip, hand etc) are not stable enough or of consistent surface regularity/ reflectance to - even if slow & not moving - get 'deleted', so intrusion detection is not lost even though a fixed object left 'in view' will get 'deleted' after a few seconds. Is there anything like this on the latest ST VL5xxx sensors or would this require substantive external processing? Bill WieseSan Jose CAbill@bwiese.org

Enjoyed your nice presentation...We need almost hemispherical coverage (maybe 160+ degrees etc) for intrusion/prox detection;we are not power sensitive.Are there optical ways of increasing FOV of the latest 60+ degree FOV sensor to well beyond this FOV angle?Otherwise, how many sensors might be needed to get reasonable 'dome' coverage? (In this latter case, will sequencing/interleaving sensor inquiries btwn multiple sensors reduce inter-sensor crosstalk risk? Would this situation require special add'l optics? FYI, we need to 'read the world' around ~10 X per sec.Thanks!Bill WieseSan Jose CA

 the expected results on the temp_buffer are: if((p_dev->temp_buffer[0] != p_dev->streamcount)            && (p_dev->temp_buffer[0] != (uint8_t)255)            && (p_dev->temp_buffer[1] == (uint8_t)0x5)            && ((p_dev->temp_buffer[2] & (uint8_t)0x5) == (uint8_t)0x5)            && ((p_dev->temp_buffer[3] & (uint8_t)0x10) ==(uint8_t)0x10)I got:temp_buffer[0]=255temp_buffer[1]=0ttemp_buffer[2]=2temp_buffer[3]=1streamcountr=0after successfully calling the vl53l5cx_init() function, so check_data_ready is never true. Is there any other function that must be called before running the  vl3l5cx_check_data_ready? At which point in the initialization is the correct data to be read on the temp_buffer set?

If I point my VL53L5CX unit at the ceiling which I have measured to be 2.13m above my device, I get some readings that are status 5 of around 2100 mm and some readings that are status 255 of around 2100mm. Why is this the case? Because 2.1m is within the 4m rated distance (I have no coverglass as well), shouldn't every zone of my sensor be getting a proper reading? And also what does it mean for the reading to be status 255 but the distance is correct? Can I trust these status 255 numbers?

first i test the code with the black board and I read data normally,I designed my round board by reverse engineering of the black board,I test my round board with the same code, but I got an error as shownin the attached picturesif any one can help pleasethanks

I'm doing tests on the VL53L3X evaluation board, and trying to reproduce the detection rate issues.In fact, it is hard to get the 50% and 94% valid outcomes out ofcertain large number of tests using the quoted reflection material, ambientlight condition, etc. If I understood correctly, the detection rate is defined by theratio between the 0-RangeStatus tests and the total number, right?Is there any algorithm to predict the detection rate based onsome experimental parameters? For example, the signal/ambient rate, or anyother ones?Hope to get responded, thanks!

Hello,Well i have read the documentation on the VL53L0X and it is a clear as MUD with respect to the usage of the function VL53L0X_PerformOffsetCalibration how to use it and why i should use it. I thought these devices where factory calibrated, but i have four of them, three are ok but one is way off by some 100mm at test distance of 100mm eg reads 200mm. So i am wondering if ST or anyone has a VL53L0X Calibration program example they would like to share please. Or do i simple measure what it returns under normal read working and add or subtract to error in my application Many thanks imk

I am using a VL53L1X with the VL53L1X_ULD library.I have one ToF sensor that I initialize at the default address 0x52 and reset to an address of 0x56. It works at that address (I am planning to add more sensors, but haven't hot there yet.)When I power down my microcontroller to save power, I send the XXSHUT terminal low.When I power up again, I send the XSHUT high, at which point the controller doesn't find it at 0x56. It finds a sensor at 0x52, the default, but attempts to reinitialization at that address fail.I can only restart it if I turn power off completely to the whole sensor.Is there a way around this? Is there a reset command or some other way to restart?

My use case would benefit from high speed but I'm having trouble getting it to run at 60Hz. I'm using the X-NUCLEO-53L5A1 on an NUCLEO-L476RG board with the XCUBE-TOF1 software. I'm using the SimpleRanging example program: XCUBE-TOF1\Projects\NUCLEO-L476RG\Examples\53L5A1\53L5A1_SimpleRanging I have tried this in polling mode with a short polling period and also in interrupt mode. Neither will go faster than 17Hz.I edit this line in app_x-cube-tof1.c to increase the speed:Profile.Frequency = 60;I inserted a simple HAL_GetTick() and calculate the actual frequency and it wont run faster than 16.67Hz. 5Hz and 10Hz work great but then it maxes out as shown here:Profile.Frequency = 5; /* Actually runs at 4.97Hz */ Profile.Frequency = 10; /* Actually runs at 9.95Hz */ Profile.Frequency = 20; /* Actually runs at 16.59Hz */ Profile.Frequency = 30; /* Actually runs at 16.61Hz */ Profile.Frequency = 60; /* Actually runs at 16.67Hz */Any ideas what is limiting it or where I should optimize the co

I used X-NUCLEO-53L5A1 + 2 VL53L5CX-SATEL, and the data read output speed has a delay in the code: HAL_Delay(POLLING PERIOD), POLLING PERIOD == 1s, and then I want to quickly, so I canceled HAL_Delay() (Picture1), But it took a long time to check (Picture2: SDA-2/SCL-2), does multi-sensor ranging reading must be delayed?

root@yocto-linux:~# ./phio -s -Z=1 -S[V]open fd 3 for /dev/stmvl53lx_ranging[V]started status 0[V]keep using fd 3[ 195.463147] STMVL53LX IPP Err in send_client_msg 115 :fail to send data size 608 to pid 1[ 195.463147] [ 195.472822] STMVL53LX IPP Err in stmvl53lx_ipp_do 205 :fail to send msg -1[ 195.479736] stmvl53lx_ipp_do_wrapper: stmvl53lx_ipp_do err -1#I   0 dts=      0   range ts     168               StreamCount(0), SpadCount(0.00) - [0] *NOTARGET* st 255     d=8191mm       min/max=8191/8191      sigma= 0.00   rate=   0.00/   0.00[V]keep using fd 3[V]stopped status 0d cl endAny idea? It seems like the error came from line 113 of stmvl53l1_ipp_nl.c, &nb

Hi,I'm building a project that uses 20 VL53L1x sensors to detect any people or objects that go in the danger zone of a machine.The sensor will detect any objects or people below 2 meters distance. We set up the sensor 30cm above the ground.The measure configure of sensor :  - Timing Budget MicroSeconds: 30ms. - Inter measurement period MilliSeconds: 70ms. - Do not use the glass cover.I tested the reliability of the sensor and the result like below: - People with blue, white pants are reliably detected. - People with black khaki can not be detected by the sensor. - People with black jeans can not be detected by the sensor.I tested indoor.​I try​ to calibration. And I success to calibration RefSPAD, but I fails Offset and Crosstalk. It return error.I called function in API:1.VL53L1_WaitDeviceBooted2.VL53L1_DataInit3.VL53L1_StaticInit4.VL53L1_PerformRefSpadManagement5.VL53L1_SetMeasurementTimingBudgetMicroSeconds // I setting 300006.VL53L1_SetInterMeasurement

Has ST done any research into the level of vibration these sensors can safely withstand? I'd like to use these on an application which experiences intermittently high vibration (up to 15m/s^2, mostly parallel to the sensor measurement direction). Accurate measurement during periods of vibration is not important (but the sensors failing obviously is)Would the models which include a lens (VL53L1x, VL53L5x) be less tolerant to vibration than those without?

Let's say I want to limit the field of view to be 200mm wide at a distance of 1500 mm.Can I do this using the ROI settings?If so, how do I calculate what my ROI settings need to be?

As reported in the datasheet, "a 47 KOhm pullup resistor is required" on the LPn signal. In that case the power state machine goes from POWER OFF to HP IDLE during the power up sequence. What would the device state be if the LPn signal was low during the power up sequence?Is it conceivable to assume that the subsequent device state would be the LP IDLE?I am asking that because I would need to share a control signal that is normally pulled down at startup.Thank youBR