Hi there. Just acquired the vl53l1x module from you and it works fine under python 2.7. using pip to install smbus2 and vl53l1x libraries.
Is it possible to build the library to work under python3?
I tried sudo pip3 install vl53l1x and although it completed without and problems, when I try and run the graph example under python 3 it can’t find a library .so file for vl53l1x
I want to use it with python-osc to export readings using OSC but that only works with python3.
Drat! Looks like the Python3 version of the .so file is: vl53l1x_python.cpython-35m-arm-linux-gnueabihf.so - I was re-using the same code that I found for the VL53L0X to build a driver for this module, so I inherited some possibly not optimal dependency management.
If you’re using Python 3.5, give this a try: sudo pip3 install VL53L1X-0.0.1-cp35-cp35m-linux_armv7l.whl
Potentially! I’ve not built installers for any of our breakouts yet since I’m trying to get a consistent API for installing them beforehand (for reasons which should become clearer tomorrow).
Further question on the VL531LX How easy is it to change the i2c address so you can use more than one at a time on a Pi? Do you need to cut a track as on one of the other beakout boards, or can it be done with software calls in the library?
There is, in fact, a change address feature on the VL53L1X. IE: You can change it, I believe, to any arbitrary address and it will remember this change as long as it’s powered.
The trouble I’ve had actually using it, is that I can never seem to communicate with the device after changing the address. I think this is something to do with the VL53L1X confusing 7-bit and 8-bit addresses in the datasheet/code, and this confusion confusing me.
It’s something I want to look into again, 'cos it would be a neat feature to support!
Yes it would. I did play with this a bit. I looked at data from the SparkFun data site, which was quite extensive. They also brink out and use the (overscore)SHUT pin form the sensor, which I don’t think is available on your breakout board. (or is it get-attable?)
However I think form my purposes where I am exporting the data via OSC another solution is to run a second sensor on a separate PiZero and send out OSC data with a different address. They two data streams from the separate detectors can then be processed at the receiving end. This makes it easier to space the sensors, and also avoids wiring difficulties with two devices sharing the i2c bus.
On a separate point I have been investigating the jitter effect I was getting. I found that it could be solved by initialising the sensor with tof.start_ranging(2) instead of tof.start_ranging(1) I could then use version 0.0.2 of the library OK instead of 0.0.1 However it would still be interesting to find what the difference was that is causing this.