RaspberryPi doesn't recognize OneWireHub

[ecnelson]

RaspberryPi doesn't recognize OneWireHub

[lindenaar]

I am trying OneWireHub with an Raspberry Pi (Zero 1.3) and also experienced that a 1w hardware component (used an ds18b20) worked fine while emulated devices didn't. Found this thread and can confirm that setting:

constexpr timeOW_t ONEWIRE_TIME_MSG_HIGH_TIMEOUT     = { 38000_us };

in OneWireHub_config.h does make the hub with simulated devices visible on the Pi and they seem to work fine then. Looks to me indeed like a specific quirk of the Raspberry Pi, which does a lot more than just 1-wire.

Bumping the timeout also allows me to mix emulated and physical devices (only tried with one to see if I could reproduce the issue @ecnelson encountered) and it looks pretty stable so far. Please note that I had the bus running on 3.3v as the Pi is not 5v tollerant though I don't think there is another way to connect it properly anyway.

So thanks @orgua for this library, it works great for me with this minor change on both an Arduino Nano (AVR ATmega328) as well as a DigiSpark (AVR ATtiny85).

Perhaps a matter of documenting this odd behavior and the work-around for the Raspberry Pi to close this issue (as it seems quite old and describes the solution) ?

[orgua]

The RPi doesn't have built in OW support. So how are you doing it? GPIO or a real OW-Master?
Probably connected to issue #43, #35, #23.
or maybe just #25

[orgua]

oh and please read through the help-section of the readme.md in root-folder

[ecnelson]

My problem seems to be identical to issue #25
RPi reads "real" ds18b20 with no trouble; just cannot see emulated ones. Also sounds like there isn't a fix for it. Is there a way for OneWireHub to tell what it doesn't like (e.g. protocol error)?

[orgua]

please try the offered solution in the other issues first.
And please reduce the used code to absolute basics first, so just one emulated ds18b20.
and yes there are a couple of ways but the good ones rely on a logic analyzer.
and again, please read through the readme. i can't solve your problems for you, just give you hints.
I doubt that it is a bug in the hub.

[ecnelson]

First two images below are OneWireHub emulating a ds18b20. The one called "owhub reset" shows the RPi's reset pulse followed by the hub's presence pulse. The one called "owhub not talking" shows the RPi attempting to communicate, giving up and giving another reset pulse. The hub responds with presence and the RPi tries again with the same result.

The next two images are from a real ds18b20... reset and presence then the full conversation. I don't speak OneWire so I don't know what they're saying, but the conversation goes on for awhile.

[orgua]

i think i can't help you like that. you don't respond to my hinting comments (timing mod), don't RTFM and give me sparse information (i didn't established a help-section for nothing). And did you notice that your pictures have no names any more but heavily rely on them?

There is so much documentation for the OWhub and yes, OW is not easy, but you have to try to find clues and help yourself first. i am offering you the code for free, and i am happy do fix bugs if there are any. But you have to find them or make sure that it is not just a fault from a inexperienced user. It still is my spare time, and i don't like to waste it.

You could also look at your scope pictures and read a datasheet of a slave device like the ds18b20. you will notice that the reset pulse in the first scope picture seems very odd. it isn't strictly forbidden by ow-standard, but the master does not behave like other masters in this part. nevertheless, owhub should be ok with handling that.

[ecnelson]

I started on the assumption that OWHub should work with RPi with no modification, and that it would be a bug if it didn't. That was my mistake—sorry about that.

I ran calibrate_by_bus_timing for a long time and mainly got 13 for IPL, but occasionally it reported 12.

It turns out the RPi waits 30+ms after it resets the OW bus before starting what I think is the address search. It's necessary to set ONEWIRE_TIME_MSG_HIGH_TIMEOUT to a minimum of 38ms in order for RPi to read an emulated ds18b20.

OWHub alone on the bus:

pi@xenon:~$ for f in `ls /sys/bus/w1/devices|grep 28`; do echo $f; cat /sys/bus/w1/devices/$f/w1_slave; done
28-00da18b20000
71 01 4b 46 7f ff 00 10 4e : crc=4e YES
71 01 4b 46 7f ff 00 10 4e t=23062

However, if I then add a real ds18b20 to the bus, it gets read correctly by RPI but OWHub can no longer be read

OWHub plus a real ds18b20 on the OW bus:

pi@xenon:~$ for f in `ls /sys/bus/w1/devices|grep 28`; do echo $f; cat /sys/bus/w1/devices/$f/w1_slave; done
28-000005eb0b45
99 01 4b 46 7f ff 07 10 79 : crc=79 YES
99 01 4b 46 7f ff 07 10 79 t=25562
28-00da18b20000
ff ff ff ff ff ff ff ff ff : crc=c9 NO
71 01 4b 46 7f ff 00 10 4e t=-62

Plodding through the rest of OWHub's timing parameters is beyond the scope of my little project so I think I'll give up on the RPi and use an Arduino as a master.

[orgua]

The hub can't work like a real device on a simple microcontroller. Well, it could, but then there would be no way to do other things beside emulating the device. Normally we have a sequence of:

• reset
• presence
• ow-command
• further data

there should be minimal wait time between these elements. Yes, the standard doesn't demand it, but it is the only way to handle the communication by a µC. From the last data to the next reset we can do what we want and just have to check from from time to time if a reset occurred.
So if you have nothing else to calculate on the emulating arduino, the code of the hub would be easy to change to make it work.
So i hope you see that is no real bug of the hub, but rather an odd behaviour of the master. it would be better to change that to make it more conform.

[djungelorm]

I also had the same issue, and can confirm that increasing the msg high timeout to 38ms fixed it.

My setup is:

• Three real DS18B20 temp sensors
• An ATtiny85 running a OneWireHub emulated DS18B20 sensor (does a single ADC read between calls to hub.poll())
• One-wire bus connected to GPIO4 on a Raspberry Pi 4 B