Adding multiple vl53l0x sensors

[ADP1114]

Hi all

I have successfully implemented a single vl53l0x sensor, but wish to add more. I found the "AN4846 Application note Using multiple VL53L0X in a single design" documentation:

https://www.st.com/content/ccc/resource/technical/document/application_note/group0/0e/0a/96/1b/82/19/4f/c2/DM00280486/files/DM00280486.pdf/jcr:content/translations/en.DM00280486.pdf

Under "VL53L0X API management" it specifies:

In vl53L0x_platform.h API file set VL53L0x_SINGLE_DEVICE_DRIVER macro to 0 so that API implementation will be automatically adapted to a multi-device context.

But I cannot find anything called "VL53L0x_SINGLE_DEVICE_DRIVER" in the vl53L0x_platform.h file.

Where can I find it? Or has the files updated without the documentation being updated? If so should this step just be skipped?

[KNawa.1]

John,

thx!, You were right! everything was OK excepts addressing I have changed to:

#define original_addr 	0x52
#define sensor1_addr 	0x54
#define sensor2_addr 	0x56

and now works! I missed address is devided by 2

BTW: AN4846 is not valid any more when 2.2 is not updated to newst API

[SCADE]

Hi John,

To avoid multiplexer,wiring and host GPIO consumtion :

Is it possible to wire the GPIO of sensor n-1 to the XShut of sensor n in order to modify the cascade address of the sensors by switching them on one after the other?

Supposed that when a sensor XShut if down, its GPIO is down too...

If so, have you coded sample of this?

Thanks in advance for your advice

[John E KVAM]

Could you open a new issue on this topic? 

It gets confusing when topics change. 

But the answer is our engineers called those GPIOs when they invented the chip. But then gave the defined roles and don't have any option to change those roles. So, they are no longer GPIOs and should have been renamed. But that is not our way apparently. 

Long story short - unfortunately you cannot cheat. You need one line for the Xshut on every sensor. 

[SCADE]

Thank you John for your quick feedback
I'm very disappointed because it seems that your designers didn't really understand the purpose of a bus like an I2C for us users: to limit wiring and host IOs consumption by connecting many devices in parallel on only 4 wire.

[John E KVAM]

99% of our customers use exactly one of these sensors and put them in cellphones and PCs and kiosks. It's actually a rare case that needs more than one of them. Of course, if you are that rare case then it is important. Adding a daisy-chain initialization system such as you describe gets debated from time to time, but it does not make economic sense to burden the vast majority of our customers with the cost of the extra hardware. 

I feel your frustration. And I agree with you. I keep asking, but then they show me the numbers and I have to agree that the chip designers are making good business choices. 

- john

[SCADE]

Sure your product probably satisfies 99% of your actual customers, but a more conventional use of i2c bus would find new customers you don't know yet...but it is an another subjet

[SCADE]

Hi John !

You wrote "Long story short - unfortunately you cannot cheat. You need one line for the Xshut on every sensor." :thinking_face:

Now loock at this :face_with_tears_of_joy: :

Just 4 I2C wires + only a fifth wire in cascade between GPIO pin and XSHUT pin of sensors and wihtout multiplexer.

It seems that you underestimate your products

[John E KVAM]

So you hooked the GPIO1 (which is the interrupt line) of sensor A to the Xshut of sensor B. And when you are done doing the setup of the first sensor, the GPIO1 goes high (as it is an active low interrupt). But what happens when you start the sensor and you actually get an interrupt? That will drop the interrupt low and turn off the next sensor. 

Or did I miss something?

- john

[SCADE]

You're not far off, that's how the wiring works, you miss some others clever things.:beaming_face_with_smiling_eyes:

Thank you for your non-encouragement and your non-support, it's been a great source of motivation for us. :thumbs_up:

[John E KVAM]

In that case, I'll bet you a beer you can't do it. 

(I do have to admit that I'm frequently wrong. And if you get it to work, feel free to publish how you did it. I don't mind being taught new things.)

- john