Possible issue in example

[MauroMombelli]

The proposed example set inter-measurement period to 50ms and setMeasurementTimingBudget to 50ms too.. but the datasheet state you need to set inter-measurement at least 4 ms higher or you will get an error. Have the example been tested and working?

[kevin-pololu]

Hi,

Could you refer me to where the datasheet says the inter-measurement period must be at least 4 ms higher than the timing budget? I might have missed something.

The API user manual says this on page 10: "If the inter-measurement period is shorter than the timing budget, once the device completes the ranging, the next ranging starts immediately." So it sounds like it should be able to handle the two being equal, although the measurements might not be taken as frequently as intended. I've tested the examples and I haven't noticed any problematic behavior.

Kevin

[MauroMombelli]

Is in another document :) UM2356, API user manual, chapter 2.2 "timing consideration".

…

On Mon, Sep 10, 2018, 21:13 Kevin (Pololu) ***@***.***> wrote: Hi, Could you refer me to where the datasheet says the inter-measurement period must be at least 4 ms higher than the timing budget? I might have missed something. The API user manual says this on page 10: "If the inter-measurement period is shorter than the timing budget, once the device completes the ranging, the next ranging starts immediately." So it sounds like it should be able to handle the two being equal, although the measurements might not be taken as frequently as intended. I've tested the examples and I haven't noticed any problematic behavior. Kevin — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGE80Zo0rwWOnhcnL4tiM1kwM6gsgJ68ks5uZrnfgaJpZM4Wf58x> .

[kevin-pololu]

I haven't been able to look into this for a while, but I just checked the UM2356 document and noticed that it is revision 2 on ST's website (what I quoted above was from the rev 1 manual). That seems to correspond to version 2.3.3 of the API, which is dated 5 June 2018 and includes this in its release notes: "Check coherency between timing budget and inter-measurement period."

I believe this library was based on the previous version of the API, V2.3.1, so it makes sense that the timing requirement that was added in V2.3.3 is not present in the library. I will try to look more into whether this is a change I should make to the library so that it matches the API. (I suspect that it might just be an API behavior change to return an error instead of producing less frequent readings than requested if the requested timing is too aggressive.)