DS18B20 on WiPi reading "none"

[cbourne]

OK so I just tested my DS18X20 on a Raspberry Pico & Circuit Python using this code:

import time
import board
from adafruit_onewire.bus import OneWireBus
from adafruit_ds18x20 import DS18X20


# Initialize one-wire bus on board pin D5.
ow_bus = OneWireBus(board.GP16)

# Scan for sensors and grab the first one found.
ds18 = DS18X20(ow_bus, ow_bus.scan()[0])

# Main loop to print the temperature every second.
while True:
    print("Temperature: {0:0.3f}C".format(ds18.temperature))
    time.sleep(1.0)

It worked first time:

Temperature: 28.750C
Temperature: 28.750C
Temperature: 28.813C
Temperature: 28.750C
Temperature: 28.688C
Temperature: 28.625C
Temperature: 28.625C
Temperature: 28.625C
Temperature: 28.563C
Temperature: 28.563C
Temperature: 28.625C
Temperature: 28.688C
Temperature: 28.625C
Temperature: 28.625C
Temperature: 28.625C
Temperature: 28.625C
Temperature: 28.688C
Temperature: 28.625C
Temperature: 28.625C
Temperature: 28.625C
Temperature: 28.688C
Temperature: 28.688C
Temperature: 28.813C
Temperature: 28.750C
Temperature: 28.750C
Temperature: 28.750C
Temperature: 28.750C
Temperature: 28.750C
Temperature: 28.750C
Temperature: 28.750C
Temperature: 28.688C

So obviously there's something different happening here and it proved that the DS18X20 is working properly. Can anyone shed some light on this problem please.

[robert-hh]

@cbourne I tried to replicate that on my lopy, only to find that I seem to have a completely different set of functions, which however work. Since I am not allowed to upload them here, i've put it to a different place:

https://github.com/robert-hh/Shared-Stuff/blob/master/ds18x20.zip

[cbourne]

@robert-hh Thanks, I'll try this again later. So are these different to the ones here: https://github.com/robert-hh/Onewire_DS18X20 ?

[robert-hh]

@cbourne No. That should be the same. I simply forgot that I had made a repository for them. Quite a while ago. We never could convince Pycom to use these.
So take the files from the repository. They are proper documented.

[cbourne]

@robert-hh OK I’ve already tried the ones from the repository and get the same result. ‘Roms=[]’ I don’t understand this took me 5 mins to get working on the PI pico. So far I’ve spent 5 days and still can’t get it to work on a Wipy3.

The bigger issue here though is clearly the stock examples in the Pycom docs don’t work, so if they don’t work not sure if there’s much hope.

I think I need to look at a different ecosystem for my development boards. I also spent hours trying to find a workable ‘uRequests’ example because again the docs were not current.

If Pycom can’t provide and more importantly maintain, basic working examples for the most common use cases, then why should I waste my time and money here.

[robert-hh]

@cbourne That's strange, because that code works here and also for other people. So it must be something else. Are you sure that you have it connected to P10 and that P10 works? Did you try a different Pin? Do you have a logic analyzer? Even the 10 € devices you can get at Amazon and othe rplaces are very helpful.
About the Data Pin. If you do not send data, the data pin should be at about 3.3V.

[optimho]

@cbourne Hello, Might be an obvious one, but check that the pull up resistor is connected

[cbourne]

@optimho thanks yep already done that.

[robert-hh]

@cbourne Did you use the same set-up with pull-up resistor for the Pico test?

[cbourne]

@robert-hh yes exactly the same components on the same breadboard.

[robert-hh]

@cbourne And the same jumper wires?

[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.