This one's for Richard

Richard! Look at the chart!

Fair warning: this is going to be one of those posts that rambles on and on with little to do with beer and a lot to do with technology.

My troubles with getting multiple Maxim DS18B20 temperature sensors working reliably with my Arduino Duemilanove microcontroller and my CAI WebControl board have been noted here many times. I think I may have finally figured out what was causing my problems. As with most things I resolve, it turns out to have been equal parts unreasonable expectations and learning curve. Rather than backtrack through all the previous postings I think it would be easier to describe what I have arrived at compared with what I had hoped to achieve, and then explain how the differences have arisen through this journey.

As of this moment, I have the following configuration working:

• Arduino with 3 "parasite mode" probes connected via 1/8" mono phono plugs, two of which are using 50' headphone extension cables with the other simply on its 6' base lead, with one 50' probe on a separate digital input pin from the other two.
• Arduino temperatures are displayed on the 2x16 LCD connected to the board and printed to the serial port. The temperatures are collected about every 6 seconds or so as the display loops (not interrupt driven).
  
• WebControl with 1 "active mode" probe connected via 1/8" stereo phono plug and using a 50' headphone extension cable.
  
• WebControl temperature reading collected remotely over Ethernet using its CGI capability, then stored and charted using RRDTool.

The graph to your left shows a thumbnail of the last hour of the WebControl-attached probe's reading of the ambient temperature in the garage. Clicking the chart will take you to a page showing a larger version of that graph and some graphs showing more historical timespans. The traces start about 10:30 PM on January 27, 2010.

What I had hoped to achieve, at various times during this escapade, included

• Multiple probes on the Arduino with 50' extensions (at least 3 and as many as 7 or 8).
  
• The Arduino providing on-demand updates via its serial port and a web service on another host.
• The Arduino managing temperatures in the kegerator and fermentation chamber, activating an SSR to cut the compressors on and off as needed.
  
• Multiple 50' probes on the WebControl (which is alleged to support as many as 8 DS18B20 devices).
  
• The WebControl using its digital logic feature to manage the temperatures in the kegerator and fermentation chamber via SSR.

The principle sticking point in most of these scenarios has been getting the probes to work reliably, and that's where today's ramble will focus.

I selected the DS18B20 digital thermometer for the probes because I didn't want to mess with managing A/D conversions with something like the LM34. There are numerous working examples of DS18B20 to Arduino projects all over the Internet, and the Arduino home page even has links to a predefined library for handling the DS18B20's 1-Wire interface. The promise was simple: multiple DS18B20s, which can exist in a bus structure because they're independently addressed, without fear of signal degradation or need of op-amp amplification due to run lengths of sensor cable. Maxim (who purchased Dallas Semiconductor, the originator of the DS18B20 and 1-Wire) claims distances of 300m or more for the 1-Wire bus. How could this possibly go wrong?

Chasing Resistance is Futile

Well, the first place it could go wrong is with basic topology. The Maxim IC application note on reliable 1-Wire networks is very clear that the "star" (hub and spoke) network layout is the most difficult to arrange reliably. Maxim describes the issue as one of reflections and mismatched impedances causing clashes among different devices on the bus when a star topology is used.

I must have read that document a dozen times before it finally sunk in. One of the major contributors to my challenges has been my desire to have multiple probes attached via a single digital bus point, creating a star topology. This was much more evident (in hindsight) with the work I did with the WebControl board than the Arduino. I have written about some of that work already but the short version of my problem was lack of reliability. I could, at various times, get one, two, three, or no probes working with the exact same wiring configuration on the WebControl board. It didn't occur to me until very recently that the problem was the impedance issue introduced by the star topology I was wiring.

What finally tipped me off was something I read later in that application note regarding the use of stub drops off a single long line connecting the DQ of all DS18B20s in a long bus. The note talks about the optimum length of said stubs as being under 3m. Suddenly it occurred to me that the majority of time that I had anything working, all the run lengths were individually less than 3m long, so essentially I had a zero-length long line with a handful of stubs. Things went south when I added the 50' extensions to one or more lines.

I had spent hours chasing line resistance as the cause of this problem, thinking that the power supply from the board wasn't able to source enough current to overcome the resistivity over the length of the cable. I came to realize I was seeing the reflectivity issue instead. That's how I have ended up with the three probes on the Arduino on separate digital inputs and why I have cut down to a single probe on the WebControl board. I now have only one device on any given bus, so there's no cross-talk and reflection among devices. Each of the buses supports a 50' combined length of probe and extension, providing me with the maximum flexibility in configuration.

How does that fall short of expectations? The main issue is pinout. Three's about all the digital inputs I have to spare on the Arduino after all the pins that are used to support the LCD display are accounted for. (I know the analog pins can be used as digital inputs too, but I don't want to give them up just yet.) It would have been much better if I could have run the probes off one pin. The WebControl is more problematic, as it has a single port purpose-built to support DS18x20 devices. I am approaching this as meaning I can use one of my probes reliably, or set up a more conventional long-line with drops. The long-line strategy would be good for relatively fixed device measurements, so I may yet do that, but for now I'm going to concentrate on just the one probe and leave the other 7 the board supports as undiscovered country.

I promise to post some schematic drawings of the final configuration of this stuff soon. In the meantime, enjoy the chart showing the ambient temperature in my garage.