UnexpectedResponse - DS18B20

[sousandrei]

Hey!

I'm testing this with a DS18B20 sensor and it does not find it :/ Update: setting the board to 80Mhz system clock allows it to detect it, but I get UnexpectedResponse in the device address

Just to be sure I the sensor works I plugged it in the same way to a RaspberryPi 4 and it works

What could this be?

[kunerd]

Hi, I had the same issue. It is a timing problem in the read_bit function. The timing is configured to the outmost end of the sample window. For me this meant out of four DS18B20 one worked reliable, one worked sporadically and two didn't work at all. After changing the timing a bit all sensors work fine.

[bartweber]

Same issue here. Like @kunerd suggested I did tweak the timing of the read_bit function. For the values of the delays I copied the values from the OneWire library written by @PaulStoffregen.

pub fn read_bit(&mut self, delay: &mut impl DelayUs<u16>) -> OneWireResult<bool, E> {
    self.set_bus_low()?;
    delay.delay_us(3); // Maxim recommended wait time

    self.release_bus()?;
    delay.delay_us(10); // Maxim recommended wait time

    let bit_value = self.is_bus_high()?;
    delay.delay_us(53); // Maxim recommended wait time
    Ok(bit_value)
}

For the functions write_1_bit and write_0_bit the values for the delays differ from that of those in the library of PaulStoffregen as well, but that doesn't seem to be a problem so far.

I created a fork which contain the copied values. If it stays working stable for a while I might create a PR: https://github.com/bartweber/one-wire-bus

Update (Feb 16, 2023): The few things I learned in the mean time:

1. I noticed that reading temperature data from a DS18B20 with a STM3f3Discovery in debug mode (with OpenOCD) always resulted in a UnexpectedResponse. Running in release mode (with OpenOCD) with adjusted timing in the one-wire-bus lib, the readings resulted in correct responses.
2. When reading temperature data from a DS18B20 with a Raspberry Pi Pico it was the implementation of the (emulated) "open-drain output" that caused issues. I used the implementation as mentioned in this example: https://github.com/rp-rs/rp-hal/blob/main/rp2040-hal/examples/dht11.rs. I implemented an open-drain output in the rp2040-hal by myself. Then the timing as is in this one-wire-bus lib was just fine. No any adjustments in the timing were needed. Regarding the UnexpectedResponse while running in debug mode (see 1), the same also applies to the Raspberry Pi Pico. Reading temperature data while in release mode, the first (few) readings result in an UnexpectedResponse and 'CRCError`.