New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor DS18B20 Temperature Conversion Time Handling #1823
Comments
echavet
added a commit
to echavet/johnny-five
that referenced
this issue
May 26, 2023
Currently, the DS18B20 driver uses a fixed delay of 1 millisecond (board.io.sendOneWireDelay(pin, 1);) after requesting each sensor to perform a temperature conversion. However, the DS18B20 datasheet specifies that a conversion actually takes up to 750 milliseconds. This misalignment could potentially lead to inaccuracies when reading from multiple DS18B20 sensors simultaneously, particularly if the requested frequency (options.freq) is shorter than the time required for a temperature conversion. Additionally, it's important to note that the implementation of the delayTask function on the Firmata side is not fully functional and relies on the inclusion of a "FirmataScheduler" module, which merely adds processor cycles and does not provide a true delay mechanism. rwaldron#1823
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, the DS18B20 driver uses a fixed delay of 1 millisecond (
board.io.sendOneWireDelay(pin, 1);
) after requesting each sensor to perform a temperature conversion. However, the DS18B20 datasheet specifies that a conversion actually takes up to 750 milliseconds.This misalignment could potentially lead to inaccuracies when reading from multiple DS18B20 sensors simultaneously, particularly if the requested frequency (
options.freq
) is shorter than the time required for a temperature conversion. Additionally, it's important to note that the implementation of the delayTask function on the Firmata side is not fully functional and relies on the inclusion of a "FirmataScheduler" module, which merely adds processor cycles and does not provide a true delay mechanism.I propose refactoring the DS18B20 driver code as follows:
With these changes, the DS18B20 driver seems (but should I need review) to correctly handle temperature conversion times, potentially improving the accuracy and reliability when reading from multiple DS18B20 sensors.
Could you review these changes and confirm that they correctly address the issue?
The text was updated successfully, but these errors were encountered: