The CX version of the chip, gets its distance and accuracy from the fact that after each range, it uploads the range’s raw data to your microprocessor. It is your processor that runs the final algorithm. This algo is more complex than what is running on the sensor and you get more distance. The downside is that is your processor is running and there is more I2C traffic, which uses more power. And you cannot set the threshold interrupt because your processor determines the final range.
Because the L4CD version runs its algo entirely inside the sensor your MCU can be in a low power state waiting for a distance threshold interrupt - if you’ve set one.
Every L4CX can run in CD mode- it’s a true superset.
(And if pushed, the L4CD can run in CX mode - sort of. You will hate the production fall out. So best to not do that. )
The ULP driver obtains its low power by giving up accuracy. The sensor integrates very quickly and with short integration times, you only get a rough estimate of where a target might be but you save a lot of power. For some customers, this rough estimate is enough.
There is some software that shows how one might run in ULP mode and then switch - rather quickly - to ULD mode to get a more accurate reading. This is how the VL6180 used to work. It might help you.
(A careful reading of this code will show the major difference between ULowPower and ULiteDriver modes is the ridiculously fast integration time.
| STSW-IMG049 | Active | Example code for Time-of-Flight (ToF) migration from VL6180 to VL53L4CD, a high accuracy and low power proximity sensor |
"If this or any post solves your issue, please mark them as ""Accept as Solution"". It really helps the next guy.And if you notice anything wrong do not hesitate to ""Report Inappropriate Content"".I am a recently retired ST Employee. My former username was John E KVAM."