Unstable onewire

xenon
Tags: #<Tag:0x00007fe22247e5a8>

#1

Im using the oneWire library to try to read a bunch of DS18B20’s connected to a single IO pin. They all have their Vcc connected as well.
So far, im only scanning which addresses are on the bus with the provided example. but half of the time, it finds none at all. other times 1 - 3, sometimes 4 and sometimes even more (it finds duplicates, which should not happen in the search function).

I have hooked up a scope and the signals look fine. sharp edges, timing seems to be OK.

It does not seem to be related to the number of devices on the bus. with just 1 sensor connected, it still misses that single one a lot of the time.

Anything else i can look for to solve this issue ?


#2

Hey remcohn, I am just about done with my foray into this topic. Don’t know if the xenon is similar to the photon but I think this is a big break for Photon users…

Also, I’m not using the libraries (except OneWire), the DS18B20 libraries have a number of issues …here was my solution to your problem. I haven’t updated with my latest code, yet. It works really well, I don’t know if you absolutely need the address searching. The “fix” to the OneWire bus in the first pointer should help resolve problems with that as well.


#3

Hi,
I am not using the DS18B20 part (yet?) either.
I have copied your modified version of oneWire.cpp/.h with the atomic blocks, and im still getting the same issue.

to narrow down the issue, i switched to a single device and using ‘ReadRom’. and i noticed its making single-bit errors. its always reading a (different) bit as 1 while it should be a zero.

Reducing the delayMicroseconds in the read_bit() funciton from 12 (from your example) to 1 seems to reduce the number of errors.
I also noticed that in your example, you use both noInterrupts() followed by an ATOMIC_BLOCK(). If i read the manual correctly, this should not be needed?

I will try it with an Argon later today. may be the mesh connection is messing with the timing even inside an ATOMIC_BLOCK()


#4

I played with the numbers as you have too (going to extremes in some cases, like you have to test them). That particular spec, Read Data Valid, is one I also had down at ‘1’ for a while (zero didn’t work, haha). And yes it improves things (because it reduces the chance of some type of interrupt coming in and messing up your data bit read)…but keeping it at ‘1’ will really ruin any chance of extending the OneWire very far or putting more devices on the same line. In fact, I think that particular spec (Read Data Valid) is the ONE timing that is key for the entire bus. It sets both the “drive 0 time” (falling edges) and the “RC timeconstant pullup time” (rising edges). I am making up terms because I don’t know the right ones. Once I realized it was some type of interrupt still getting into those data bit moves, I moved the timings back to “spec” numbers.

And, yes. I realize that ATOMIC BLOCKs and interrupts are redundant for the Photon…but I don’t know about all the other devices that use this library and didn’t want to mess those up, so I left them in there for discussion.

But…since I want the bus to be fixed, can you ask any further questions on the other thread?..I want to get more eyes on the Library thread so that it gets fixed for everybody.


OneWire Library Bug / Proposed FIX (June 2019) Affects DS18B20 and other OneWire devices