Field Report 2015-08-12: Success with DS18B20 1-Wire Temperature Chains!

OMG! It worked. Woot!

Yep, that’s me grinning like a fool. It might not be an X-prize, but it worked! IT WORKED!

We were already happy with the flow & drip sensor data from this trip because, despite the TMP102 problems, most of the units had performed brilliantly.  But for me, the real prize of the season was going to come from the underwater temperature strings that began their first ‘real-world’ trials on the last trip. Because the cave they were in presented some challenges, we didn’t pull those units until we had a few good dives under our belts. Back in March, I had just changed over to slimmer builds in 2″ PVC pipe,  and the flow meters at this site were the deepest deployment so far for those new housings. So every unit in this cave was testing something important, and I hoped to take plenty of photos despite the fact that we were right at our little cameras limit.

Trish had line duty (for this part of our dive), and she captured a reasonable shot of me inspecting first flow meter from there. Though I had only been at the sensor for a few moments, you can already see a ball of dust starting to form overhead:

After that we installed a new ceiling anchor, with a descender rod to put a Pearl in the deeper saline flow.  Unfortunately, all that faffing perc’d out the site, so I only managed a tiny clip of one temperature string in-situ before the cloud of pea soup drifted over:

That logger supported a fairly short 5m sensor chain, with 19 nodes spaced at 25cm. It was installed across the halocline, and I admit that I was concerned that (with a minimum increment of 0.06°C) those humble DS18B20’s would not have enough resolution to track the fresh/salt water interface. In addition, I had assembled the string in segments that were linked by my new diy underwater connectors, so these builds had more potential failure points than I even wanted to think about.  It’s probably a good thing that that our dive schedule was so full that I didn’t have time to look for LED heartbeat pips while we were still under water.

Following that long dive, we had a bumpy crawl back to the main road which put more than a few new scratches onto the rental car. After one bone-shaker, Trish observed a logger going through it’s startup sequence on the indicator LED.  A power blip like that during an SD write could toast the card, destroying all our data!  I asked her to cradle the new babies till we got back to the paved highway. When we reached Tulum, we returned our tanks, stowed the gear, and bolted down a couple of tacos in record time. I might even have exceeded the speed limit a bit on the way back to the room…

But after some tough dives, and months of waiting, this was the result from #045:

Cave Pearl data loggers - DS18b20 Temperature string
Note: I inverted the temperature axis (left side) to match the physical situation: the saline water was warmer at depth, with a cooler fresh cap layer. The black traces are 96 point (1 day) moving averages.

The deeper saline water was a full degree warmer than the shallow fresh water, giving plenty of spread for the DS18’s.  And with 25cm spacing we managed to plant one sensor right in the middle of the halocline, capturing its cycles of expansion and shearing away. And that’s just the raw data!  Even without the calibration corrections it was easy to see that we nailed it. Unit #046 gave an equally complete log, but with its larger 50cm spacing the sensors straddled that fresh/salt boundary, so we simply have an empty gap on the plot. Of course to a karst hydrologist, knowing the limits of mixing zone is also useful information

After the initial excitement over that temperature data died down, I proceeded through my usual set of post deployment checks. I was keen to compare the power curves from the two loggers we had deployed:TempLoggerPowerCurves

I knew those sensors were going to pull a substantial amount of juice during 12-bit conversions, but putting twelve AA batteries in the housing was still something of a shot in the dark for me back in March. While both curves looked smooth , there was something odd about #046 using less power than #045, because it had one more sensor (total of 20) and they were stretched out over 10 meters of cable so #046 also had a more aggressive pull-up resistor on the bus.  A bit more poking around and I noticed that I had accidentally reversed a cell in one of the banks  (those with sharp eyes probably  spotted that in the photo above) so #045 had actually run on only three sets of AA batteries. Shottky’s isolate each bank against battery failures, but it’s nice to know that they also protect the little loggers from my own dumb mistakes. With 46’s full complement of 4x3AA batteries only loosing 0.5 v over almost four months, I’m confident these loggers could approach my one-year operating target on a fresh set.

The marine heat shrink tubing adhesive after four months

After four months under water the adhesive on that marine-grade heat shrink looked a bit flaky, but there is ECL30 potting the wires inside the adapter so I’m not worried about the seal.

Of course that’s predicated on everything staying water-tight, so I examined each temperature sensor very carefully: looking for evidence of water damage. Most of the nodes were filled with hard epoxy (E-30CL), and for some I was trying out a more flexible urethane. (U-09LV )  They were all remarkably clean, with only one node showing yellowing, and that one was a botch where I had split the original sheathing under the heat gun, and had to re-wrap it. I was also pleased to see that my DIY underwater connectors proved to be robust. They were all were bone dry inside, with no hint of oxidation on the contacts. It was looking like we would be able to re-deploy these units right away!

While I was examining the hardware, Trish had been chewing on the data from both of the loggers. At one point she started making funny “Hmmm…” noises which I know she only makes when she disagrees with something, but is being too polite to say so.  (You hear that kind of thing a lot at academic parties…)  When I asked her what was wrong, she showed me the pressure log from one of the MS5803’s:

045_PressureLog

Damn! Even with surface barometric corrections it was obvious that the rising trend in this record was out of sync with our other water level recorders.  And with 1 millibar of pressure being approximately equivalent to 1 cm of water depth, the implied 4m delta is simply ridiculous. I immediately suspected that the Qsil 216 I had put over the pressure sensor was doing something weird. I’ll need to do some homework to sort out what actually happened, but I’m guessing the silicone started absorbing moisture at depth since the stable cave environment is unlikely to cause problems from thermal expansion.

#046 was ready to roll the next morning.

#046: ready to roll the next morning.

So we didn’t get a hat-trick on these first builds, but by 2 am I had new batteries in place, the clocks updated, and I had carefully peeled away the silicone over the MS5803s. (hopefully without damaging the factory gel caps). If the overnight run looked good, we hoped to install #046 in deeper cave (~24m) the next day.

<— Click here to continue reading the story—>

6 thoughts on “Field Report 2015-08-12: Success with DS18B20 1-Wire Temperature Chains!

  1. nivagswerdna

    Great stuff! I need to monitor some animals in hibernation so need a string of five temp sensors and your solution looks ideal. So all in all are you happy with the DS18B20s?

    1. edmallon Post author

      They have several issues which are slightly annoying. But the strengths of the 1-wire bus, especially that long cable length (and you can use MOSFET’s to boost that…), means I keep coming back to them again and again. In fact I am starting to breakout the one wire bus on all my loggers now just because it’s so easy to do.

      If you sleep the processor while they do 12-bit 750ms conversion they are not too bad on your power consumption because DS18’s sleep at low current afterwards. I wish that they had better accuracy because ±0.1 is what you would really want to see for research work. I always buy the waterproof units in the stainless steel cans so that I calibrate them in a water bath, but also because it is really easy to cook the raw sensors if you linger while soldering the pins. I’ve lost a few there.

      Sometimes I get a batch that have a high number of sensors that are out of spec, so beware that some of the cheaper vendors are selling dodgy stuff. I don’t know if that’s because they soldered them badly, or if they were counterfeit, etc.

  2. Brian Davis

    Do you hard-code the sensor strings for this application, or does your code autodetect upon startup to log these? I’m trying to work out just how much I can run off an Uno… I don’t have the power issue currently (for my application I can run “plugged in” to power, although I’m using an SD card to keep the computer out of the loop right now). But I’m trying to run a pressure sensor (or two!) as well as several temperature sensors spread over distances of a couple meters or more (so I2C on the temperature sensors is out). That nearly 1 sec time resolution on the DS18B20’s is annoying, but might be acceptable, but trying to manage all these different sensors is getting… memory intensive :). Since I have to reconfigure very often I’d *like* to code it to auto detect the sensors upon startup, but that seems to take memory…

    1. edmallon Post author

      Yep, I hard code the sensor addresses. I think most of the one-wire libraries will auto-detect but the catch is that they will only read the sensors in numerical order, whereas I am epoxying them into strings and I want my data files to reflect the physical order of the finished sensor chains. On a standard 328p this approach runs low on memory after about 24 sensors, but if you want to use more than that you can look at Arduinos based on the 1284 chips (like for example, the Moteino Mega)

      Also, you can broadcast a “global” convert command if you are NOT using parasite power, so you only wait the time for a single sensor conversion no matter how many you hang off the bus (provided you dont exceed the power available from you voltage regulator with them all pulling 1.5mA at the same time)

      1. Brian Davis

        “…you can broadcast a “global” convert command…”

        Huh, I hadn’t thought of that… issue a “skip ROM” command on the line so everything is ‘selected’, then issue a “convert” command that goes global, before selecting each device in turn to poll for results? I’m currently cycling through the devices issuing “convert” commands, and only then going back and poll each individually. But I think I like your suggestion better. 🙂

Comments are closed.