Hi, I’m trying to calibrate the Piico Dev VL53L1X laser sensor to operate in short mode instead of the default long mode. I’ve looked through the Piico Dev library and the API code for the laser sensor. My understanding is that the VL51L1X_DEFAULT_CONFIGURATION needs to be modified to write to the register that configures the ranging mode. My problem is that I haven’t found anything that tells me what the register is for ranging mode and what it needs to be changed to.
Kind regards,
Jack
Hi @Jack249945 - welcome to the forums.
Aaaah the PiicoDev_VL53L1X.py file… we’ve learned a lot about driver code creation since we put this one together… Even so, it seems that ST has hidden the full workings of this device behind their driver implementation software (source) which means the workings of each register are not readily available.
see the Note in DS12385 Datasheet, 4.2: “The customer must use the VL53L1X software driver for easy and efficient ranging operations to match performance and accuracy criteria. Hence full register details are not exposed . The customer should refer to the VL53L1X API user manual (UM2356 ).”
Document UM2356 is just the API user manual containing instructions on how to use that proprietary API.
You’re correct in that the driver could be updated to change that default configuration. Ideally, we update the driver so you can change the configuration from user-code.
It seems to me that there might be two ways to achieve this end:
PiicoDev_VL53L1X.py fileCan i ask what the motivation is?
Hi Michael. The motivation is that we’re looking to use the sensor in the range of 10mm to 40mm. We want it to measure the position of a ballast tank syringe so we can calculate the water taken in. Some basic testing of the sensor has shown that the sensor can have some large errors at this range. We purchased two of them. One is fairly accurate, but the other is experiencing an offset of up to 30mm. It does still measure changes in distances well, so we can manage the offset value. I just wanted to see if there was an easy way to set it into short mode. Thank you for your assistance.
Hi @Jack249945 ,
I am working with a VL53L1X… and have managed (I think) to add the required functions to calibrate, change distance mode etc to the driver for these devices. Are you still interested in this stuff? Would be good to compare notes if you are.
I am about to start testing, I am most interested in increasing the accuracy (reducing the variability) of measurements, I hope to do this by increasing the TimingBudget. I have added this ability also to my custom driver.
Cheers, T.
To set the distance mode to short, use the following function call in your code:
VL53L1_SetDistanceMode(dev, VL53L1_DISTANCEMODE_SHORT);
That ref appears to be for a C library.
I have ported the required functions to the MicroPython driver… if anyone else is interested.
I have yet to do testing to confirm if the methods actually achieve what I am hoping for… better accuracy! I will possibly get to this later today… and will report results.
Cheers, T
@ahsrab292840 did you actually get SHORTMODE (or MEDIUM) working? If so, what platform were you using, and can you provide a direct link to the driver? The link above to docs.ros.org doesn’t seem to actually provide the driver code… just documentation.
My reason for further inquiry is my port of the SetDistanceMode stuff is not working correctly for short and medium distance settings… but it does work for long. So I am trying to identify what I have wrong…
EDIT: I found my error… fixed and all modes now working!
Cheers, T
Hey @Jane Maybe because I’m often working on this real late.. like 1 or 2 AM, I just screwed up some device register addresses. Basic transcription error. D’oh.
Anyway, I now have an enhanced Python driver for the VL53L1X… the PiicoDev driver with added functionality, which enables me to:
I’ve done both bench tests and in-the wild… on the bench, the standard deviation of measurements dropped from 4mm down to about 0.5mm, at the expense of significantly increasing the TimingBudget, which impacts the frequency of measurements.
I sampled 30 times, in controlled lighting, in all 3 distance modes, with TimingBudget ranging between 90 ms (close to the default value) and up to 800 ms, over 3 different distances - between about 500 mm up to 2400 mm
In my use case, I only read distance once per second, so it works fine for me;-) If you need to read 10 times a second… you’re kinda stuck with what the default settings give you - which has a fairly poor margin of error/high standard deviation. I have not tested absolute distance accuracy - for my app, that’s not as critical as consistency.
Neither have I tackled the RefSPAD, offset and crosstalk calibration methods. I’d be interesetd to hear from anyone who has done this… either in C or in Python.
I also tested the XSHUT function… works fine. My next improvement to my app will be to use this so I can put my widget into sleep mode when nothing interesting is happening.
Final observation: my widget kinda stopped functioning recently. Turns out there was some sort of film over the transmit & receive elements. I had cleaned these with isopropyl alcohol and a cotton bud not long ago, so was a bit surprised when it basically stopped working! Looking at the device under a microscope showed the smeared look. Rectified by using proper camera lens cleaning sheets… with more alcohol… and checking under the scope. Took several attempts before both TX and RX elements looked reasonably clean. After that… everything was working fine again.
Cheers, T.
Perfect, thank you for posting @Trevor277988. Hope that information will help the next person coming along. 
Hi Trevor,
A real midnight engineer 
Amazing work!
If you would like to share your work, feel free to send through a PR on the repo: GitHub - CoreElectronics/CE-PiicoDev-VL53L1X-MicroPython-Module: Firmware repo for the Core Electronics PiicoDev Laser Distance Sensor VL53L1X
Love this dedication to Maker culture and sharing your work!
Liam
Still making improvements… doing further testing as we speak…
My analysis of results showed that every once in a while, the driver would return a fairly wild value… like, even with increased Timing budget, so I’m consistetly reading within 1 maybe 2 mm accuracy… then up pops a value like 10 or 15 mm different to the last value!! Worst case I saw was 22mm. Hmm… something fishy going on still. So…
I speculated that maybe there was occasional interference between the default continuous ranging operation, and my calibration tests’ periodic reads, once every 5 seconds (mimicing my in-prod app behaviour). So, I went back and made a further change to the driver… effectively enabling single-shot reads.
My test is still running…it looks much better, but not quite perfect. In about 45 mins I’ve registered only a few “dodgy” readings, with worst-case variation of 5 mm in 560 mm.. so less than 1% variation … but, that said, in this initial test, ambient light might be affecting the result. The other two outlier readings are less than 0.6 % from the expected value. I will now test in totally controlled (dark) lighting.
More experimenting required to confirm if my suspicion is on the money…
Cheers, T.
Hey @Trevor277988 ,
Nice work! Looks like you are making good progress.
From what I can find in the VL53L1X datasheet, you may be close to, or currently, running into the limitations of the sensor itself.
In short-range mode, they expect a ranging error of ±20mm in darkness and ±25mm in ambient lighting, which sounds pretty close to the outlier readings you are getting.
Section 7.5.2 of the datasheet has a bit more information on this if that would be useful to you:
https://www.st.com/resource/en/datasheet/vl53l1x.pdf
Hope this helps!
I have those datasheets…and yes they state 20mm, but that does not account for the ocassional burst of wildly bad readings… when the steady-state is consistently returning values within 1 or sometimes 2 mm, statistical testing shows standard deviations of around 0.6 mm over a large number of reads. Test just done was going fine… and then I saw a handful of terrible readings (like 10-15 mm wrong), before it returned to reading the normal/correct values. Huh??? This does not look like inherent device inaccuracy/inconsistency. Something froopy going on…
My test setup is using my prototype… ie, breadboard with various other bits connected, even though I am not using anything except the VL53L1X… perhaps there is some voltage spikes occuring, eg if a Dupont wire moves a bit.
I have taken this almost as far as I can with what I have. I am designing a PCB for my project, and will do some more tests when I have that… which will eliminate any spurious crap, hopefully!
I’ll update the community if I have any more improvements to report.
Cheers, T.
Hey @Trevor277988,
That’s an interesting issue. It could be related to communication with the device, sometimes I2C can behave unpredictably. I came across this forum thread that might offer some useful insights: https://forum.pololu.com/t/vlx53l0x-timeout-issues/18553/10
In the meantime, averaging your readings should help smooth out those wildly off values.
Had a look at that blog… not convinced it is the same issue. They seemed to have the device locking up…and/or returning utter nonsense values. Mine does not, it keeps returning data… just with questionable distance measures.
Yeah I could average, but I am trying first to resolve the root cause of the issue, not apply band-aids 
This arvo, I ran a test in total dark (my device measures distance in a 90 mm PVC pipe painted black both inside and out, so effectively ZERO ambient light) With my new driver, settting timingbudget to 333ms, medium distance mode, using my singleRead thing, rather than continuous reading. I let it rip sampling once per second. I got 2035 readings - ALL GOOD. By which I mean, they were within 0.5 % of the previous reading… or, in absolute terms, never more than 2mm difference (over 675 mm). The sample standard deviation was 0.68 mm. I’m VERY happy with that consistency!
As said, I will do more exhaustive tests when I have a PCB-mounted Pico. I guess I could just use a PiicoDev Platform-mounted Pico, and have ONLY the VL53L1X on the I2C bus…maybe tonight/tomorrow I’ll try that combo, but I really want to work on my PCB design… and some other software issues
But for now, my fairly frequent dodgy distance issue appears to be solved… and I have a driver that supports more useful stuff!
Cheers, T.
Hey @Trevor277988,
Glad to hear you’ve had such solid results with this setup! Really impressed with the depth of testing you’ve done, definitely a step above my usual “bandaid and tape” approach before calling it a day 
Definitely keen to see how this project progresses. Keep us updated with some images or feel free to make a new thread about the project once its done!
@Liam I will be happy to do a PR… after I’ve stopped messing about with the code
Last night I cleaned it up a little… am still pondering adding in some more methods (eg to return the count of things like ambient light etc, or maybe even setting the ROI. Shouldn’t be too difficult to add.. but I am so time-poor (sorting out my PCB/KiCAD issues, doing more calibration tests… whatever. Sometimes, I even get to bed before 2 AM… but not often!
Cheers,
In bed before 2am? Look at this sleepy head 
In all seriousness, I’m very keen to see how this project comes along.
And you can get our latest projects and tips straight away by following us on:
