OneWire.py problem

andreas

Sorry no. It was my mistake. I did not notice that I had onewire.py on that device. Notably the one which had modified. But that one seems stable.

Thank you very much for this. We are also running that and are quite happy with it. However, we see occasional bumps where the CRC check probably hits the fan. Seeing this happen, it is way better than getting any misreadings out of it.

@robert-hh said in OneWire.py problem:

Pycom does not really react to Pull Requests. Especially PR's for the library are completely ignored. And also for the firmware there seems no on to be in charge of that.

It's a bit sad yes. We understand the core team must be pretty busy and are more than happy to see MicroPython 1.11 finally came to Pycom MicroPython with the most recent release. Kudos to all who made that happen!

Saying this, we would be more than happy if someone would pick up the work from [1]. Maybe someone capable and lucky enough to tackle that problem will be the one we could salute here?

[1] https://github.com/pycom/pycom-micropython-sigfox/pull/356

kjm

@kjm I made a little mod to def scan

def scan(self):
        """
        Return a list of ROMs for all attached devices.
        Each ROM is returned as a bytes object of 8 bytes.
        """
        devices = []
        diff = 65
        rom = False
        for i in range(2):
            for i in range(0xff):
                rom, diff = self._search_rom(rom, diff)
                if rom:
                    devices += [rom]
                if diff == 0:
                    break
            if devices!=[]: return devices
            self.reset()

and got 100% on an overnight run, looks like the DS18B20 sometimes needs a reset after a deepsleep.

andreas

@kjm said in OneWire.py problem:

I made a little mod to def scan

if devices!=[]: return devices
self.reset()

Thanks! It looks like we already did that to be better safe than sorry. Good to know we have not been dreaming here.

# The 1-Wire bus sometimes needs a fix when coming back from deep sleep.
self.adapter.reset()

-- https://github.com/hiveeyes/hiveeyes-micropython-firmware/blob/0.6.0/terkin/sensor/core.py#L212-L216

kjm

@andreas All of us reinventing the wheel Anrdeas.

crumble

@kjm

as long as the hard-/software on which the pycom devices base has timing problems, you have to make your software fault tolerant. Playing around with timings is playing tic tac toe. You cannot win as long as you do not control the exact state of hardware and OS.

You have to deal that the device is only 99% reliable and how it can get back into a good state after failure. The high rate of failure makes the ESP 32 a good learning system for this kind of software ;)

kjm

@crumble It's a real shame. The idea of a python capable micro with integrated 4G looked so good in the advert.

crumble

@kjm

Pycom ran into this damn ESP 32 trap.

Don't expect that Itell you, that the actual firmware solved my problems. I did that too many times and a few hours later everything crashed. But it seems that I2C is now as reliable as the old one core version of the firmware.

andreas

Dear @kjm, @crumble and @robert-hh,

@andreas said in OneWire.py problem:

I was too quick on that detail. After getting into the MicroPython code, I see that porting/enabling the modonewire.c from Genuine MicroPython on Pycom MicroPython will require more efforts than I will be able to dedicate to this topic for now.

Finally, we have been able to add support for the native 1-Wire/DS18X20 driver on Pycom MicroPython and published respective firmware images called 1.20.1.r1-0.7.0-vanilla-dragonfly-onewire. See also Inofficial firmware bakery for Pycom/ESP32 devices.

Please be aware that you will have to use a set of different Python drivers to access the lowlevel API available through https://github.com/micropython/micropython/tree/master/drivers/onewire.

If you are willing to test this, we will be happy to hear about the outcome for you.

With kind regards,
Andreas.

John Baird

Jumping in a bit late, but FWIIW - I've been running DS18B20 sensors in many devices that regularly go to deepsleep for months now. They work very well, with few (if any) missed reads. I think the difference here is that our application is very power sensitive, so the DS180B20 is powered from a supply that turns off every time the module goes into deepsleep. Perhaps you could try parasitic power? That would also turn off the sensor during deepsleep.

robert-hh

@John-Baird Parasitic power is not easy, because it has to be supported by the driver. For using it, the data line has to switched to a string pull-up aka Vcc when the temp conversion takes place. This strong pullup has to be set within 10µs after sending the start conversion command. That is not possible at app level, but must be done at the bit level driver. I know it because I just have implemented it yesterday.
And it does not solve the problem that sometimes the sensors do not respond. A full powercycle helps, including pulling the data line to 0. If the data line stays high, then the devices stay powered, and that could be the problem here.
b.t.w.: The driver is here: https://github.com/robert-hh/Onewire_DS18X20. It follows the API of the micropython.org version.

andreas

@robert-hh said in OneWire.py problem:

The [refurbished] driver is here: https://github.com/robert-hh/Onewire_DS18X20. It follows the API of the native MicroPython driver.

Taking this chance, we want to thank @robert-hh so much for taking care of all the details regarding this driver. It was a real pleasure to work together with you getting this a real home and - to top it all off - big thanks that you also made its API match the one of the native driver, so people can swap them in and out. We have been doing this through [1] already and are very happy about it.

[1] https://github.com/hiveeyes/hiveeyes-micropython-firmware/commit/2a23af47

Explore Pybytes | Official Documentation | Report a Firmware Bug/Issue | GitHub

OneWire.py problem

Pycom on Twitter