cancel
Showing results for 
Search instead for 
Did you mean: 

Difference between VL53L1X_Gui and ULD API

rastik
Associate III

When comparing the data sent from VL53L1X ULD and from VL53L1X_Gui I can see some differences.

In particular, I was comparing values sent to registers 0x005e and 0x0061 that are used to configure timing budget. I'm not going to write all measurements here, but e.g. for long distance mode and 50 ms budget the ULD sends 0x00ad and 0x00c6, while GUI sends 0x02f9 and 0x038e. Why such a difference? Which one is correct?

Same problem applies to some other registers:

  • 0x005b - ULD: 0x08, GUI long: 0x00, GUI short: 0x01
  • 0x005d - ULD: 0x00, GUI long: 0x00, GUI short: 0x02
1 ACCEPTED SOLUTION

Accepted Solutions
John E KVAM
ST Employee

​The GUI was written before the chip was built and we used it to test the chip's performance. The ULD was written a year later when people asked for a much smaller driver.

Inside the timing budgets are bits to turn on some modes of the chip and how much time to spend of these. VHV is one of the modes. This adjusts for temperature changes. The decision was made in the ULD to only adjust for changes within a +/- 2 degree change per range as it was faster. The GUI allows a much bigger change. But we determined it would be a strange setup indeed that the temp could change that much from range to range, so we 'cheated' a little bit to make the driver smaller.

In Lidar - as in Radar there is a concept of Aliasing.  (Google 'Radar Aliasing' if my explanation is lacking.) This is where light from pulse N comes back after pulse N+1 goes out. So a distance of 5M would read 1M if your max range was 4M. To lessen this effect there is a range A with one pulse repetition rate and a range B with a different rate. How long one spends in A and B and VHV and a couple of other things are all tied up in the Timing Budget.

But you shouldn't have to go through the pain of knowing which combinations work and which do not. We did that work for you. And we chose the best numbers. And apparently the designers of the ULD had the benefit of a lot of testing.

Both work.

And before you ask for how to set those numbers, the spread sheet we use is really, really complex. You don't want to get into it.


Our community relies on fruitful exchanges and good quality content. You can thank and reward helpful and positive contributions by marking them as 'Accept as Solution'. When marking a solution, make sure it answers your original question or issue that you raised.

ST Employees that act as moderators have the right to accept the solution, judging by their expertise. This helps other community members identify useful discussions and refrain from raising the same question. If you notice any false behavior or abuse of the action, do not hesitate to 'Report Inappropriate Content'

View solution in original post

2 REPLIES 2
John E KVAM
ST Employee

​The GUI was written before the chip was built and we used it to test the chip's performance. The ULD was written a year later when people asked for a much smaller driver.

Inside the timing budgets are bits to turn on some modes of the chip and how much time to spend of these. VHV is one of the modes. This adjusts for temperature changes. The decision was made in the ULD to only adjust for changes within a +/- 2 degree change per range as it was faster. The GUI allows a much bigger change. But we determined it would be a strange setup indeed that the temp could change that much from range to range, so we 'cheated' a little bit to make the driver smaller.

In Lidar - as in Radar there is a concept of Aliasing.  (Google 'Radar Aliasing' if my explanation is lacking.) This is where light from pulse N comes back after pulse N+1 goes out. So a distance of 5M would read 1M if your max range was 4M. To lessen this effect there is a range A with one pulse repetition rate and a range B with a different rate. How long one spends in A and B and VHV and a couple of other things are all tied up in the Timing Budget.

But you shouldn't have to go through the pain of knowing which combinations work and which do not. We did that work for you. And we chose the best numbers. And apparently the designers of the ULD had the benefit of a lot of testing.

Both work.

And before you ask for how to set those numbers, the spread sheet we use is really, really complex. You don't want to get into it.


Our community relies on fruitful exchanges and good quality content. You can thank and reward helpful and positive contributions by marking them as 'Accept as Solution'. When marking a solution, make sure it answers your original question or issue that you raised.

ST Employees that act as moderators have the right to accept the solution, judging by their expertise. This helps other community members identify useful discussions and refrain from raising the same question. If you notice any false behavior or abuse of the action, do not hesitate to 'Report Inappropriate Content'
rastik
Associate III

Thank you John for the explanation. I take the answer as I should stick with ULD register values and ignore those from GUI. We use GUI to test various settings to get reliable measurements with shortest TB (and therefore lowest power consumption). But your answer indicates that it's not possible to transfer the findings easily into the code, because the sensor could behave differently due to different TB to register setting transformation.

Does the 2 degree max change assumption apply just to those two measurements that the sensor is performing together or to any two consecutive measurements? Because in our use case we can have minutes or even tens of them between measurements. And it is performed outdoors (without direct sunlight though), so the temperature could vary a lot.