Skip to content

DS1820 read timings are incorrect #1582

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

Open
rpv-tomsk opened this issue Mar 26, 2025 · 3 comments
Open

DS1820 read timings are incorrect #1582

rpv-tomsk opened this issue Mar 26, 2025 · 3 comments

Comments

@rpv-tomsk
Copy link
Contributor

rpv-tomsk commented Mar 26, 2025

Datasheet https://www.analog.com/media/en/technical-documentation/data-sheets/DS18B20.pdf clearly states:

Output data from the DS18B20 is valid for 15µs after the falling edge that initiated the read time slot. Therefore, the master must release the bus and then sample the bus state within 15µs from the start of the slot. Figure 17 illustrates that the sum of TINIT, TRC, and TSAMPLE must be less than 15µs for a read time slot.

The same is for DS18S20 in https://www.analog.com/media/en/technical-documentation/data-sheets/ds18s20.pdf

But code has two delays before data sampled from bus: delayA = 6us and delayE = 9us. So, requirements are not met - read occurs after 15us after slot start.
Yes, I know about https://www.analog.com/en/resources/technical-articles/1wire-communication-through-software.html . And that article is incorrect too - at least about grey line on figure 1. Slave with 2-wire connection has no way to get energy between read slots with a such timings.

Oscillograms confirm that the data is valid on the bus for no more than 30 µs (for my test sensor).
30us is gt than 15us, but such violations could produce failures.

Currently I'm trying to find the cause why my sensor stops responding after reaching 92C (the case is reproducible).
And it seems timings could be an issue (unfortunately, sensor is mounted, so I could not connect scope there. Another sensor, bought recently, works perfectly in lab - just because it is seems to be from another vendor, and behaves differently).

Will update here when do "problematic sensor" tests with modified firmware.

Image

@rpv-tomsk
Copy link
Contributor Author

With timings and port settings updated, read becomes more stable on high temp. No hw changes was made, only firmware upgrade:

Image

rpv-tomsk added a commit to rpv-tomsk/OpenBK7231T_App that referenced this issue Apr 4, 2025
 * Do not use HAL_PIN_SetOutputValue() when reading sensor response - output must be open-drain.
 * Use Input_Pullup when reading sensor response instead. That allows to connect sensor w/o adding pullup resistor.
 * Fixed OWReadBit timing, read must be done within 15us, instead of after. Closes: openshwprojects#1582
rpv-tomsk added a commit to rpv-tomsk/OpenBK7231T_App that referenced this issue Apr 4, 2025
 * Do not use HAL_PIN_SetOutputValue() when reading sensor response - output must be open-drain.
 * Use Input_Pullup when reading sensor response instead. That allows to connect sensor w/o adding pullup resistor.
 * Fixed OWReadBit timing, read must be done within 15us, instead of after. Closes: openshwprojects#1582
rpv-tomsk added a commit to rpv-tomsk/OpenBK7231T_App that referenced this issue Apr 4, 2025
 * Do not use HAL_PIN_SetOutputValue() when reading sensor response - output must be open-drain.
 * Use Input_Pullup when reading sensor response instead. That allows to connect sensor w/o adding pullup resistor.
 * Fixed OWReadBit timing, read must be done within 15us, instead of after. Closes: openshwprojects#1582
rpv-tomsk added a commit to rpv-tomsk/OpenBK7231T_App that referenced this issue Apr 4, 2025
 * Do not use HAL_PIN_SetOutputValue() when reading sensor response - output must be open-drain.
 * Use Input_Pullup when reading sensor response instead. That allows to connect sensor w/o adding pullup resistor.
 * Fixed OWReadBit timing, read must be done within 15us, instead of after. Closes: openshwprojects#1582
rpv-tomsk added a commit to rpv-tomsk/OpenBK7231T_App that referenced this issue Apr 4, 2025
 * Do not use HAL_PIN_SetOutputValue() when reading sensor response - output must be open-drain.
 * Use Input_Pullup when reading sensor response instead. That allows to connect sensor w/o adding pullup resistor.
 * Fixed OWReadBit timing, read must be done within 15us, instead of after. Closes: openshwprojects#1582
rpv-tomsk added a commit to rpv-tomsk/OpenBK7231T_App that referenced this issue Apr 4, 2025
 * Do not use HAL_PIN_SetOutputValue() when reading sensor response - output must be open-drain.
 * Use Input_Pullup when reading sensor response instead. That allows to connect sensor w/o adding pullup resistor.
 * Fixed OWReadBit timing, read must be done within 15us, instead of after. Closes: openshwprojects#1582
rpv-tomsk added a commit to rpv-tomsk/OpenBK7231T_App that referenced this issue Apr 4, 2025
 * Do not use HAL_PIN_SetOutputValue() when reading sensor response - output must be open-drain.
 * Use Input_Pullup when reading sensor response instead. That allows to connect sensor w/o adding pullup resistor.
 * Fixed OWReadBit timing, read must be done within 15us, instead of after. Closes: openshwprojects#1582
@divadiow
Copy link
Contributor

divadiow commented Jun 1, 2025

how does this tie in with @MaxineMuster's recent work with DS1820 driver?

@MaxineMuster
Copy link
Contributor

I included all @rpv-tomsk fixes in the "extended" driver
(quote from #1627 "... Use "HAL usleep" as proposed by @rpv-tomsk with his implementation for Beken").

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants