2022-04-01 03:40 PM
When filling the struct in my app
typedef struct
{
uint32_t RangingProfile;
uint32_t TimingBudget; /*!< Expressed in milliseconds */
uint32_t Frequency; /*!< Expressed in Hz */
uint32_t EnableAmbient; /*!< Enable: 1, Disable: 0 */
uint32_t EnableSignal; /*!< Enable: 1, Disable: 0 */
} RANGING_SENSOR_ProfileConfig_t;
I am a bit confused about the TimingBudget in it.
I followed function calls starting in the nucleo examples at
VL53L5A1_RANGING_SENSOR_ConfigProfile(i, &Profile);
And this ends up assigning the TimingBudget into a variable named integration_time !
integration_time = pConfig->TimingBudget;
later I miss the footprints of this integration_time when the api sends its value to a memory_buffer with the function "vl53l5cx_dci_replace_data".
Can you confirm this integration_time is the one used in autonomous ranging mode?
Then, in continuous mode, if I want to increase the timing budget I must just set up the proper ranging frequency, disregarding the Timing Budget value set in the RANGING_SENSOR_ProfileConfig_t struct. Right?
Solved! Go to Solution.
2022-04-04 07:35 AM
There are 2 ways you can do this. Tiimed mode, and Back-to-Back. If you are doing B2B, then choosing a TimingBudget will give you the frequency of the results. The sensor will consume all the time allocated to it and provide the answers
But if you want a 'quiet' period between the ranges, then you choose a ranging frequency. Let's say 1 range per second. And to save power, you can choose an integration time of 1/15 of a second. That way, 14/15 of the time, the sensor is just hanging around waiting for it's next time to run.
2022-04-04 07:35 AM
There are 2 ways you can do this. Tiimed mode, and Back-to-Back. If you are doing B2B, then choosing a TimingBudget will give you the frequency of the results. The sensor will consume all the time allocated to it and provide the answers
But if you want a 'quiet' period between the ranges, then you choose a ranging frequency. Let's say 1 range per second. And to save power, you can choose an integration time of 1/15 of a second. That way, 14/15 of the time, the sensor is just hanging around waiting for it's next time to run.