[solved] Onewire DS18X20 reading not stable with LoPy4 (no problem with LoPy)

[affoltep]

The following example code from the doc, with the newest onwire.lib and firmware v1.14.0.b2 does not run stable on LoPy4.

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_convertion()
    time.sleep(1)

Often you will get a "None" as response or sometimes the correct values, but with runaway values to 0.0.
I tried to bring more reliablilty with external pull-up, but it does not help.
Tested on two independent LoPy4, same behaviour. LoPy is reading DS18X20 sensors stable.

[livius]

@robert-hh
Yes, it looks like better choise.

You could try if the figure changes if you add a smaller pull-up resistor, like 4k7 Ohm.

I use already 4k7.

[robert-hh]

@livius Then it's better to keep the second sleep_us(1)'s in both the read_bit() and write_bit(). In the latter, it does not hurt anyhow. It just ensure a minimum time between two write_bit() events.
For read_bit() it also depends on the rise time of the output. You could try if the figure changes if you add a smaller pull-up resistor, like 4k7 Ohm.

[livius]

@robert-hh
WIthout second sleep it fail for me on my Wipy2 and Lolion32.
Without first sleep it work ok

[robert-hh]

@affoltep Looking at the data sheet, that seems OK. Faster is better. For reading, it says:
"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."

[affoltep]

@robert-hh @livius Ok, just do a short summary:

• I removed the 4 sleep_us(1) from the actual onewire.py lib (2 from read_bit() and 2 from write_bit()
• Tested both LoPy4 and LoPy with the new onewire.py lib
• LoPy runs similar stable as with the "old" onewire.py lib (including sleep_us(1))
• LoPy4 runs much more stable with the new onewire.py lib, no missreadings anymore

From my point of view no sleep_us(1) is needed for Lopy.

I just have done tests with a DS18X20 (no other onewire devices)

[robert-hh]

@livius @affoltep Just tried the same code on the LOLIN32 pro, which should be similar to a WiPy3. That devices behaves the same way as the FiPy (not surprising).
Next attempt on a Wemos LOLIN32 lite, which is closest to the WiPy2 I can get, which shows the same figures as the LoPy.
All tested with the "if addWait" addition.
(sorry @daniel and @jmarcelino, that I do not have the full set of Pycom modules here)

[robert-hh]

@livius I agree about the second sleep, but even on WiPy2 it should work without the first sleep. Did you try that it fails? The D18B20 requires a minimum low time of 1µs. On my LoPy, the pin(0)/pin(1) sequence creates a low pulse of ~2 µs. Changing that to:

        addWait = False
        pin(0)
        if addWait:
            sleep_us(1)
        pin(1)

changes the pulse to ~3µs on the LoPy, sometimes extended to 4 µs.
On the FiPy with that change the basic pulse width is too 3 µs, but pulses are more frequently extended and up to more than 15 µs, breaking the communication with the DS18B20.
And @affoltep could try the variant w/o sleep with his LoPy too. I have no DS18B20 here, otherwise I would have tried that already.

[affoltep]

@livius Hm, but LoPy, which is from architecture view similar to Wipy2 can as well not generate a 1us break. Is it really needed?
I tested the new lib as well on Lopy and it did work without the seleep_us(1)

[livius]

@affoltep
not be too fast.
This is braking change for e.g. Wipy2.
The second wait is critical here and must stay.

Then i suppose parameter like addWait is required here
default=True and for LoPy4 set to False.

[affoltep]

@robert-hh @livius It works! Removing the sleep_us(1) in the code did the trick. Measurements are now stable like with LoPy.
I will place a pull request for the onewire lib.

Thanks again for all the help, you made my day

[affoltep]

@robert-hh Wow, this could mess up the whole communication at the beginning. I have done now all modifications, including the gc.collect() command in the beginning of read_bytes and write_bytes.
I will let the device run during night to check, whether the communication is more stable. Will let you know more tomorrow.

BTW. Your support is incredible! Many thanks

[robert-hh]

@affoltep I made another test, rebuilding just the initial part of write_bit(1) (which is similar to read_bit()). It shows the Initial low period with and w/o the sleep_us(1) lines.
Timing with sleep_us(1)

Timing without sleep_us(1)

With the sleep_us(1) call, this initial period can extend to about 30 µs, effectively writing a 0 or missing the read window at 15µs. Without that sleep, the initial pulse time is still sometimes extend, but much more seldom and shorter than 10µs, being still in the safe range.

[robert-hh]

@affoltep Looking at the example code for readbit(), both sleep_us(1) are obsolete, since the shortest effective distance I have seen between a pin(x) and pin(y) is 3 µs, and the call of sleep_us() alone takes at least 3-4 µs.

    def read_bit(self):
        sleep_us = time.sleep_us
        enable_irq = machine.enable_irq
        pin = self.pin

        pin(1) # half of the devices don't match CRC without this line
        i = machine.disable_irq()
        pin(0)
        sleep_us(1) # should be deleted
        pin(1)
        sleep_us(1) # should be deleted
        value = pin()
        enable_irq(i)
        sleep_us(40)
        return value

write_bit() is less critical, although the sleep_us(1) may also not be needed.

[robert-hh]

@affoltep It should be sufficient to put it at the start of read_bytes() and write_bytes().

[affoltep]

@robert-hh, @livius I included a gc.collect() in the reset, read_bit and write_bit functions of the onewire lib.
Of course it takes now ages to get a temperature value (~15s) but it seems a little bit more reliable. There are still missreadings, but it seems indeed a little bit better. Will do some tests over night to proof...

Any other ideas to get a workaround? Would it be possible to solve this issue by firmware?

[robert-hh]

@livius This is on a plain board, nothing else started after boot expect for connecting the WiFi to an AP.
The FiPy was sitting on an expansion board, the LoPy on a breadboard, Firmware 1.14.0.b1. No sensor module attached, just the output on P11.
Besides that, from similar test, like IRQ latency, the results are NOT surprising. Making timing precise on chips with serial flash (and serial RAM) requires a lot of consideration.

[livius]

@robert-hh
This result is on clear boards or on some extension board? And same sensor module?
Because it looks strange.

[robert-hh]

@affoltep @livius I made little test, letting this simple script run on both a fipy and a lopy.

from machine import Pin, enable_irq, disable_irq
from utime import sleep_us

pin = Pin("P11", Pin.OUT)

while True:
    state = disable_irq()
    pin(1)
    sleep_us(20)
    pin(0)
    enable_irq(state)
    for _ in range (100):
        b = bytearray(200)
        b[0] = _

So it outputs a 20 µs pulse and then consumes some memory. I logged the output with the oscilloscope in pertinence mode, so you see the varying pulses (fipy yellow, Lopy green):
FiPy:

LoPy:

Both results are not good, like there is no pulse shorter than ~40 µs, but the result on FiPy is worse, extending the pulse sometimes to over 500 µs.
Adding a gc.collect() immediately before the pulse creating sequence improve the situation drastically. The longest pulse seen then for FiPy is 65 µs, and Lopy shows always about 30 µſ. Please note that the time scale has changed in the pictures below.

[affoltep]

@livius , @robert-hh : Thx guys. Think we are on a promising track.

I have done some additional investigations. I flashed back to firmware 1.9.2.b2. (the newest firmware 1.15.0.b1 generates a problem running LoPy with deepsleep shield with ,and only with battery power --> always wakes up due pin interrupt. Apparently newest firmware generates a problem if there are not 5V present.

So both LoPy4 and LoPy are running with 1.9.2.b2 identical code. I use a 10kOhm pull-up on the LoPy4 and no resistor on LoPy (just internal pull-up by the onewire config). As I discovered the instability of reading values on LoPy4 I add the resistor. Unfortunately I didn't had a 4.7k, so I took a 10k, but it shouldn't be an issue.

So at the moment, the assumption from @robert-hh seems to be the most possible. Does one of you work for pycom? It would be nice if you could integrate a C lib for onewire communication in the firmware.

One of the LoPy4 I tested is slightly more stable than the other, but never on the bullet proof level of the LoPy