DS18B20 on WiPi reading "none"
Hi I have a DS18B20 and IU'm using the following code. I gave the data pin on the DS18B20 connected to Pin10 on my WiPi.
However, its constantly just writes out "none"
import time from machine import Pin from onewire import DS18X20 from onewire import OneWire # DS18B20 data line connected to pin P10 ow = OneWire(Pin('P10')) temp = DS18X20(ow) while True: print(temp.read_temp_async()) time.sleep(1) temp.start_conversion() time.sleep(1)
@cbourne Well done!
@cbourne Glad you found the problem! This thread was getting metaphysical as to why your code didn't work, haha.
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.
@robert-hh Yip, that is definitely sound advice.
@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.
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.
optimho last edited by 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.
@cbourne This does not make sense in my mind, but I've only ever used pin
P22for my onewire temp sensors, so maybe try using that pin? Also recall
P18are 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
VDDpin connected to the
3V3output 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
onewire), so maybe attempt downgrading to
1.20.2.r0for example and test the code with that.
@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.
@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.
@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.
@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 last edited by 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.
@cbourne And the same jumper wires?
@robert-hh yes exactly the same components on the same breadboard.
@cbourne Did you use the same set-up with pull-up resistor for the Pico test?
@optimho thanks yep already done that.
@cbourne Hello, Might be an obvious one, but check that the pull up resistor is connected
@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.
@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.