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

[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

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

@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)

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

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

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

@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."

[livius]

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

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