DS18B20 on WiPi reading "none"

[optimho]

@cbourne It can be a bit of a frustration - but there is the pure joy when you get it to work, you know how it goes.
An oscilloscope is what you need for these tricky ones.
In absence of one, I would and you possibly already have inserted an LED between your pull up resistor and the supply to the resistor then add some code to turn on and off that LED, temporarily comment out some of your other code so that you can just revert back to it afterwards, then bridge out or remove the LED with out disturbing the circuit.
This might seem like such a basic thing to do, but rules out faulty componentry, wiring and so on.
Recheck the the value of your pull up.

[jcaron]

@cbourne maybe check if the code does not set an internal pull up or pull down on the pin? Or explicitly disable it?

What voltage do you see on the pin with nothing connected?

[optimho]

@jcaron Yes, that's a good one, or try without the pullup, as jcaron mentioned it possible that a pull up has been set already, I don't think that the PI or PICO has that facility.

[optimho]

@optimho Read the forum posts about I2C Pullup Resistors, looks like for I2C there may already be pullup resistors on pins 9 and 10, read the thread for yourself. Try route your code to another pin not dedicated to I2C or try with no pull up. Hopefully that works for you.

[robert-hh]

@optimho There are no pull-up resistors at Pins 9 and 10 of a development module. The labeling as I2C port has not special meaning. And even if: the DS18x20 needs a pull-up resistor, since the port is operatin in open-drain mode. And even if there were two resistor of 4k7 in parallel: the ds18b20 output can drive resistor loads down to 820 Ohm at least, and the ESP32 can drive down <100 Ohm.

[d.alvrzx]

@cbourne This does not make sense in my mind, but I've only ever used pin P22 for my onewire temp sensors, so maybe try using that pin? Also recall P13 to P18 are input only and cannot be used for onewire.

Further ideas: what firmware version are you using? 1.20.2.r4, the most recent? Do you have the DS18B20 VDD pin connected to the 3V3 output of the WiPy? If using some other supply to feed the temp sensor, make sure you have the grounds connected between that supply and the WiPy.

Pycom devices can be a pain when they don't work, but a charm when they do 🤷‍♂️

EDIT: I've been having some weird issues with 1.20.2.r4 (unrelated to onewire), so maybe attempt downgrading to 1.20.2.r0 for example and test the code with that.

[optimho]

@robert-hh Thanks for that, I did however see that in Pycom's example code of setting pull up resistors in machine.pin documentation, pin 10 is used in the example code, not sure if that's just a generic micropython example?

On a bit of a tangent, when looking for some more information on pull ups in Pycom I came a cross an interesting discussion on the PICO, despite having said that it does not have pull up resistors, It actually does have pull up resistors, but they default to floating and this was causing some problems in firmware requiring or expecting a pull down resistor as the PICO documentation wrongly suggested that the pins default to pull down.

That leads me to wondering if the Wipy defaults to pull down and we have wired an external pull up on to the same pin? I imagine that would cause problems?

I am under the impression that the following line:

p_in = Pin('P10', mode=Pin.IN, pull=Pin.PULL_UP)

would make the pin 'P10' an input, plus selects the pullup resistor on that input?

Are you able to try and add this line to your initialisation? No guaranties

p_in = Pin('P10', pull=Pin.PULL_UP) ?
       or 
p_in = Pin('P10', pull=None)  ?

so your code will look something like

import time
from machine import Pin
from onewire import DS18X20
from onewire import OneWire

# DS18B20 data line connected to pin P10
p_in = Pin('P10', pull=None)
ow = OneWire(Pin(p_in))
temp = DS18X20(ow)

while True:
    print(temp.read_temp_async())
    time.sleep(1)
    temp.start_conversion()
    time.sleep(1)

I hope that that helps, I have ordered a DS18B20 myself so I can try it myself, but we have a bit of a lockdown going on that might delay its appearance.

[robert-hh]

@optimho There is no need to fiddle with the Pin setting before calling onewire, becase the onewire code sets the input to open drain mode, and enables the ESP-internal pull-up.

self.pin.init(pin.OPEN_DRAIN, pin.PULL_UP)

That will override all setting that have been made before. The internal Pull-up of the ESP32 is rather weak, The datasheet tells 30kOhm. That's usually to high for I2C or DS18B20 operation, unless you use low clock frequencies. I do not, if and what expansion board is used by @cbourne. That may add another circuitry. But something on that set-up is wrong. My best assumption is some wiring problem. Could be in the development module, could be in the expansion board, could be external. Using a different Pin is surely an option. And testing the signals if the key in situations like these. That's why I recommend getting at least a low cost logic analyzer in addition to a volt meter. You can get them for ~10€. They are good for signals up to ~2 MHz. You will not see any analogue issues with the signal, but at least you can tell whether there is communication or not, and what the timing is.
b.t.w.: There is a PIO example code for the Pi Pico making it a simple logic analyzer with sample rates up to a few MHz. But there is no interface for visualization. Of course you could use pulseview for that.
https://www.hackster.io/markkomus/using-a-raspberry-pi-pico-as-a-logic-analyzer-with-pulseview-e12543

[optimho]

@robert-hh Yip, that is definitely sound advice.

[cbourne]

OK - I think I've resolved this. The problem is due to the what I think is the confusing pinouts/documentation for the Wipy. It seems the "physical pins" (grey) are completely different from the actual pins (teal) on the diagram. I was working of the physical pin layout. Guess this is a classic 101.

Things seem to be clearer with the Pi Pico since I no issues with their docs.

Thank you all for helping out on this one, its much appreciated. I'm still learning here and hopefully won't be so stupid next time.

[d.alvrzx]

@cbourne Glad you found the problem! This thread was getting metaphysical as to why your code didn't work, haha.

[optimho]

@cbourne Well done!