Category Archives: Developing a TEMP ℃ chain

A string of underwater temperatures using one-wire DS18b20s

Using multiple 1-Wire DS18B20’s for a DIY Temperature Sensor Chain

Temperature is a fundamental physical parameter which can be used to track how water moves and interacts with the rest of the environment. Most waterways in the world are multi use, and temperature sensors are a simple way to monitor rivers and streams, to see how they are being affected by urban pollutionagricultural runoff,  solar heating, groundwater exchange, etc.  In larger water bodies, we also want to track the cycles of temperature stratification.  Sometimes we deliberately disrupt thermoclines with aeration to preserve game fish, but at other times we depend on metalimnion stability to provide a barrier between the E. coli we dump in, and the water we take out for drinking.  Monitoring hydrothermal plumes can even shed light on geological activity under the ocean floor.

1st attempt: epoxy & 1/2" pipe

My first attempt with epoxy & lengths of 1/2″ pvc was successful enough to keep me going. For shallow water deployments, a simple treatment like this would probably be good enough to last for many months. Epoxy is the most expensive component, so each node cost ~ $4.00 with the benefit that each sensor is very robust afterward. You can also check out Luke Miller’s sensor waterproofing on his blog.

Temperature is also a key metric of ecological integrity because it exerts a profound influence on aquatic creatures. Many species time their reproduction and migration according to seasonal water temperatures and, as temperature increases, the capacity of water to hold dissolved oxygen is reduced. In coastal environments, temperature and salinity are very strongly associated so you can use it as a reliable proxy to record tidal cycles, and saline intrusion into fresh water habitats.

All of these applications require simultaneous sampling at different depths and locations, so arrays of temperature sensors are a standard tool for addressing water quality issues. Today, many researchers are looking to the open source movement to help make these large installations more affordable.  One obvious candidate is the inexpensive DS18b20 temperature sensor because it’s one wire protocol makes it possible to string them together in a daisy-chain configuration.  Electronics hobbyists have taken note, and are putting them all over the place with Cat5 network cables. Reading those pages convinced me to take a closer look at the DB’s from the perspective of the Cave Pearl Project: Would it be possible to turn these humble band-gap temperature sensors into something like a research quality thermistor string?

A review of typical commercial options gives you a sense of how much it actually costs to build a network of temperature sensors:

Sensor Cost/Node Precision ±Accuracy Comments:
iButton $25.00
(stand alone)
0.10°C ±0.70 Thermochrons have made a new class of low resolution networks possible,  with large #’s of sensors (Note: You need to coat these guys in PlastiDip if you are deploying them outside, as they are not really waterproof)
Hobo Water Temperature Pro v2 $129.00
(stand alone)
0.02°C ±0.21 Here is an interesting USDA study using TidbiTs which have identical cost & spec.
 NexSens T-Node FR $250/node + $150/cable 0.01°C ±0.075 Typical of high end sensors used in large well funded projects at NOAA, etc

The iButtons are basically disposable, and I don’t think it would be worth anyone’s time to make them from scratch if all you need is 0.10±0.7°C.  But if you need more precise information, a simple 10 node string puts you around $1500 in the mid range, and $4000+ at the geotechnical high end.  Factory calibration of 0.0625 ±0.5°C puts the DS18B20s somewhere between the Hobo loggers and the low end Themochrons. But with each sensor on the same chain, you would be able to keep all the sensors synchronized better than stand alone units.  After seeing the elegant pro-level system, I knew I also wanted something that could be assembled from interchangeable segments, to customize the chain for each installation.

I googled and grazed my way through various YouTube videosinstructables, etc. looking at how others had water-proofed these sensors. After digesting that, I produced a some prototypes using a modified version of my underwater connector idea that have the DS18b20 potted in an irrigation pipe coupling:

all it took was a slight modification of those underwater connectors

~ $9 each for materials. The barbs are tapped to aid adhesion, JB Plasticweld forms a plug to hold the epoxy in.

The 1-Wire Address Finder and the library from Miles Burton work well with this changeable configuration. I preferred the code over at Paul Stoffregen’s site, as it gives you the raw integer reading, the ROM address, and the temp in °C as soon as you connect a new sensor.  But like most of the scripts that uses address arrays, it will read them in numerical, rather than physical order.  So you will eventually end up hard coding the Rom addresses unless you switch over to something like the DS28EA00 that supports sequence detection through a chain mode function. This allows you to discover the registration numbers according to the physical device location in a chain, and if the DS28 also had better resolution/accuracy than the dirt cheap DS18’s, I’d be converted.

The one-wire guide at the Arduino playground has a most valuable tip for driving a string of sensors like this:

“The master can address all devices on the bus simultaneously without sending any ROM code information. For example, the master can make all DS18B20s on the bus perform simultaneous temperature conversions by issuing a Skip ROM [CCh] command followed by a Convert T [44h] command.”

This means that I can minimize the number of times the Arduino has to wake-up for each set of readings. But these sensors are still going to pull about 1.5 mA each during the 750ms 12-bit conversions, so there is going to be a substantial power demand during each set of sensor readings even if I put the μC to sleep while it waits for the data. (and you can only sleep if you are not using parasite power) Thirty or more sensors on the bus will also generate allot of communication and data buffering. I have no idea yet how much juice all that is going to take so I built some larger housings, with room for twelve AA batteries, to drive these long daisy-chains:

This chain is 13.5m long, with 27 nodes (1m, 0.5m and 0.25m lengths)

This prototype is 14m long, with 1m, 0.5m and 0.25m cables.  I’ve had no data reading errors so far…

Maxim has guidelines for reliable long line 1-wire networks which suggests that longer networks need 100 Ω resistors at each node for distributed impedance matching or you could run into timing/reflection issues. As I am working in reasonably restricted cave environments where the floor to ceiling distances rarely exceed 20m, I did not add these resistors. If I start seeing the dreaded 85°C error after I load the bus, I will try a lower value pullup resistor, or perhaps a barrier diode. There is even an I2C to one wire bridge out there that can adjust the strength of the pull-up dynamically as your network grows, although since the one-wire bus is so easy to get running, I would only cobble the two networks together if I had an unusual situation.

these are using deans xyz - the trick is toget the wires to fold the right way

I am using Deans 1241 Micro 4R plugs, which just barely fit inside the pipe. These connectors are really solid, but the trick is to get the wires to fold without pinching when you mate the o-ring to the seat on the opposite side of the connector.

The sharp eyed will note that there are four conductors on that interconnect.  I used four conductor cable for added strength because silicone jacket cables are so soft and floppy that the sheath really provides no support at all. And this offers the potential for a second one-wire network that is separate from the first if communication errors start to appear. Alternatively, I could add other one wire devices to that second line for more functionality. I have not figured out what this might be yet, but perhaps I could include some kind of leak detector to make the system more robust. I am also keeping an eye on the one-wire weather station crowd to see if an interesting sensor pops up there.  And finally, I wanted a four wire connector that could also be used with I2C breakouts, as most of my other builds use sensors with that protocol.

I think this is approaching the largest string I would want to deploy on a dive.

With 27 nodes, this is approaching the largest string I would want to deploy on a dive.  I need to put some thought into how to handle this massive tangle hazard safely.

I have replaced the cable that came with the “waterproof” DS18B20 sensors, as the insulation was far too thin for the rough handling I expect to see and the 28awg wires would add significant resistance over a long run.  But silicone jacket cable is expensive and I am still searching for an affordable 24awg, 4-conductor option. (If you have a suggestion, please pop it in the comments!)  The PVC and Poly-urethane jacket cables I have tried so far are just too stiff to “hang right” under water without a weight on the line, and this would put strain the data connections.  The standard solution is to run a suspension wire alongside the thermistor string with the data lines connected to this armored stiffener. While this works great off a boat or a buoy, I would prefer not to have to deal with those extra components on a cave dive.

After addressing the issues with the physical build, I still have an elephant standing in the corner.  While an accuracy of ±0.5°C might be good enough to track the refrigerator in the garage,  ±0.1 °C is about as coarse as you want to go for research applications. So a lot of the burden of making this thing really functional will be the calibration. If you replace the Arduino’s 10-bit ADC, then there are thermistors that give you ±0.1°C right out of the box, and I would like to get these DS18b20’s into that ball park before I say the newest addition to the Cave Pearl family is ready to deploy.

Maxim has a document describing how to curve fit the error of a band-gap based digital temperature sensor with 2nd order polynomials to achieve accuracies in the 0.02-0.04°C range,  but they make the assumption that you already have a NIST traceable platinum RTD to determine what the errors actually are. But what if you don’t have that $5-600 piece of kit just lying around? (+another $150/year for the required annual re-calibration) Is there any other way to calibrate temperature sensors like this to improve their accuracy?

Actually, there are verification procedures that use the ice and steam points of water, and I will detail my attempts to use these “old-school” calibration methods in the next post. In theory at least, these intrinsic standards can bring our DS18b20’s well within a mid-range accuracy target of  ±0.2°C.  At the end of it all I will try to borrow a certified pt100 to see how close I actually got.

Addendum 2015-02-23

After handling that long chain for a few days of calibration, I realized that I needed to mount those sensors with a much smaller physical profile or they were going to be a pain the backside under water. So I came up with a simple combination of heat shrink tubing and epoxy that keeps the sensor much closer to the cable than a hard-sided mould:


Using clear heat shrink will let me monitor leaks, aging, etc. There is heat shrink tubing on those solder joins, but it became invisible in the clear epoxy.


Heat from the bottom and as the tubing shrinks the epoxy “flows” up to the other end. When you seal the upper end leave some excess epoxy trapped in the tube. Apply another ring of shrink to cap it off, and with both ends fully sealed & cooled down, gently heat the entire surface. As the leftover wrinkles disappear the heat shrink tube turns into a tension structure creating a smooth rounded profile.

The trick is to seal one end of the clear tubing first, and then inject the epoxy into that from the open end.  Once the tube is about 2/3 full 0f epoxy, shrink the upper open end of the tubing down to it’s minimum diameter. Very gently heat several spots along the tube  – as those areas contract it pushes the epoxy up toward the open end.  Then wipe away any excess so the meniscus is level, and seal the upper end of the outer tube to the cable with a short section of adhesive lined heat shrink tubing, making sure that you trap as few bubbles as possible. I usually use adhesive lined heat shrink for those two end tubes, and I let the upper ring completely cool so that if forms a good seal before heating the rest of the clear heat shrink tube.  I usually use Loctite E-30CL  epoxy as this sets much more quickly after the reheating process, often becoming hard in about 30-45 minutes. This approach to mounting the sensors would also work with ‘naked’ Ds18b20’s, but having the sensors already mounted in the stainless steel sleeve makes it much easier to do the ice & steam point calibrations before you commit to actually using a particular sensor.  At only $1.50 each, you should expect to triage at least some of them for being out of spec.

Completely encasing the sensor like this will induce some thermal lag, if you are really worried about that you could make the tubing shorter and not seal the upper end, leaving the metal sleeve exposed.  If field handling indicates that the hard epoxy is too brittle, I will hunt around for a flexible amine curing silicone, or a low durometer clear urethane, to fill the nodes (typical hardware store silicone gives off acetic acid while curing which is bad for electronics)

Addendum 2015-03-01

With more handling, those epoxy filled tubes did end up feeling a little fragile at the thin ends, so I reinforced them with a few more wraps of adhesive lined 3:1 heat shrink tubing:

I also moved the join so that it overlaps the sensor, so the metal sleeve acts as stiffener

I also moved the solder joins so that they overlap the sensor, this lets the metal sleeve acts as stiffener for the whole unit.

In addition, I decided to make the chain in 2m segments, with sensors at fixed distances along each segment. This reduces the total number of joins in the cable, while still allowing for custom configurations. In the photo (belowyou can see that I used a longer piece of pipe in the segment connectors than was necessary. My hope is that if I distribute some buoyancy throughout the chain there will be less strain on the segment nearest to the datalogger. Those segments will be bearing the weight of the whole sensor string because the logger will most likely be mounted on the ceiling of the cave passages. The real test will be when we actually install them, as there is always some unforeseen factor that comes into play under water.

Addendum 2015-03-02

I just came across a great write up by someone using DS18b20 sensors to track ocean temperatures over in New Zealand. (I knew I couldn’t be the only one…)   Interestingly, he uses a star configuration for the sensor connections. While this is much faster to connect than the daisy-chain approach I have taken, it looks like he ran into some problems with his long cable runs and had to use a very strong 480Ω pullup resistor. There are plenty of photos, and a good explanation of how he used normalization to smooth out between-sensor variations. While this is helpful for tracking relative changes in temperature, it does not necessarily improve the accuracy of these sensors.

Addendum 2015-03-06

The second prototype with 30 DS18b20 sensor nodes, 12 m of cable length

The second prototype with 30 DS18b20 sensor nodes distributed over 12 m of cable with 7 inter connections

I have been putting more segments together for a second prototype. For the newer nodes I used Loctite U-09FL urethane. This stuff is less brittle than the epoxy after curing, however it sets almost immediately when you apply the heat to the shrinkable tubing. The result is that the nodes didn’t “smooth out” like they did with the epoxy, and so they ended up looking like clear Jello raisins.  You can’t be too aggressive with the heat gun or the outer sheath splits, making a bit of a mess.

The hardest part is pulling the sensor wires free of the old cable as it tends to be filled with black epoxy. You will loose a few sensors by accidentally cutting them in the process.

The hardest part is pulling the sensor wires free of the stock cable as it tends to be filled with black epoxy. Expect to loose a few sensors by accidentally cutting wires in the process. Most sources I found recommended using unshielded cables to reduce capacitive coupling, and warned against grounding unused wires for the same reason. Some folks also suggest adding 100-120 Ω resistors to the data leg of each sensor to reduce the load on the data bus, but I have not tested that yet to see if this really works.

Once I had enough segments ready I did some tests to see how far the chain could be extended before the coms failed.  Line capacitance appears to be the controlling factor on these kinds of networks and most try to keep it low for maximum distances, or better performance. But I am packing quite a few DS18’s close together, so the sensors themselves are more likely to limit my system. With 15 minute sample intervals being typical for an environmental monitoring application,  I could even look into slowing down the bus, rather than speeding it up.

With a standard 4.7 kΩ pullup, I was able to get to 30 sensors responding  well on 12m of 4x 26awg silicone jacket cable.  Changing the pullup to 3k3, allowed me to add 15 more sensors on an extra 8m of cabling. And taking the bus to a fairly aggressive 2k2 let me add 19 more sensors and an additional 7m of cable. So my add-hock test reached a total of 63 daisy chained nodes on 27 m of cable before the readings became unstable. I did not see 85°C errors, but when the network approached the R-C rise time limit, the readings started looking like this:       (in a room at 20°C)

2015/03/06 16:58 Cycle: 1, InternalV= 3293
Probe 0 Temp Raw: 268 Temp C: 16.238
Probe 1 Temp Raw: 288 Temp C: 18.0
Probe 2 Temp Raw: 16 Temp C: 1.0
Probe 3 Temp Raw: 322 Temp C: 20.125
Probe 4 Temp Raw: 332 Temp C: 20.238
Probe 5 Temp Raw: 113 Temp C: 7.62
Probe 6 Temp Raw: 323 Temp C: 20.187
Probe 7 Temp Raw: 280 Temp C: 17.244
Probe 8 Temp Raw: 324 Temp C: 20.250
Probe 9 Temp Raw: 17 Temp C: 1.62
Probe 10 Temp Raw: 256 Temp C: 16.0
Probe 11 Temp Raw: 320 Temp C: 20.0
Probe 12 Temp Raw: 66 Temp C: 4.125
Probe 13 Temp Raw: 24 Temp C: 1.244
Probe 14 Temp Raw: 32 Temp C: 2.0
Probe 15 Temp Raw: 268 Temp C: 16.238
Probe 16 Temp Raw: 320 Temp C: 20.0

Adding a couple more nodes after that caused the reads to completely fail. The numbers then become zeros because I use  memset(rawTemps,0,sizeof(rawTemps));  to clear the temperature reading array after the data has been transferred to the eeprom buffer. Doing this between readings makes it much easier to spot when sensors drop out.

Thirty sensors is a bit tight for my application, so I will remove the 4.7K resistors I have on the loggers now and make an in-line adapter that lets me change the pull-up on the fly if a particular installation starts giving me grief.  But going much larger than 10m & 30 nodes might be putting too much data at risk if we have a point failure. Another limitation on the practical side is that my FTDI USB adapter can only source about 50 mA, so I can’t use the skip ROM command to trigger temperature conversions on more that about 33 sensors before I risk hurting the chip during tethered test runs. 

Addendum 2015-04-05

DIY Cave Pearl data loggers based on Arduino MicrocontrollersWe recently had a chance to test the first prototype (with the separate individual nodes) out in open water. To make sure the connections were up to the challenges of “normal” fieldwork, I let students handle & install the unit, with no specific instructions other than letting the last sensor just rest on the bottom. (yes, I cringed a few times…) The lowest sensor was at 6.5m depth, and the unit gathered temperature data in a saline water outflow for about 7 hours with no leaks or problems.  On the same trip we also deployed two “clear epoxy tube” chains in a different cave system spanning depths from 7 to 14m. I don’t have any photos as that deployment was significantly deeper, and beyond the reach of our little point & shoot.  Both of those carried 12 x AA batteries, and the plan is to leave them running in-situ till mid year, at which point I should have a pretty good record of power consumption of these long sensor strings. 

Addendum 2015-04-20

I mentioned using E00CL epoxy earlier, but have since gotten back some cave deployed RH sensors that all failed due to moisture permeability on the E05CL epoxy I used to build them. And those humidity sensors were not even under water!  So for future builds, I will stick with E30CL. It’s gooey to work with, but I have several units that have been under water for more than a year using that epoxy. 

Addendum 2015-07-08

The single sensor chain in the photo above ended up coming home after the field trip, and since it was just sitting there, I set it up on the bookshelf for a power drain test:

Multi DS18b20 power drain test.

Because the DS18’s run on fumes when they are not doing a conversion, this logger slept at 0.11 mA. The units currently in the field have more sensors and longer cables, but seeing that less than half of a three cell battery’s capacity was used on this two month run gives me confidence that the 12 cell loggers we deployed had far more power than they needed. So the only real question is how long they remained water tight* with the crummy epoxy used on some of the nodes. If I am lucky, the marine heat shrink tubing I used for physical re-enforcement will have provided a water tight seal on those ends.

P.S. * Those deployed units survived their first underwater test and worked brilliantly. For more details click HERE

Addendum 2015-10-30

Just an update to that 20-node DS18B20 sensor chain’s power test:

Power drain test with 20 dS18b20 nodes on 3xAA cells

These units save 200 records (~2 days worth of data) to an onboard 32k Eeprom buffer before doing a flush to the SD cards.

So we have already done five months on 3xAA battteries, confirming that those DS18B20s are very nicely behaved sensors in terms of their overall power consumption.  But that P.S. curve is bumpier than I am used to seeing from alkaline batteries read with a 2x 4.7M ohm divider,  so I might go digging on what causes that to happen.  It could just be that simultaneous temperature conversons ( 20 sensors x 1.5 mA x 750ms ) is enough of a load that the batteries feel that hit.

Addendum 2018-12-01

Just an update regarding a problem we ran into on some deeper deployments of 24m x 24 node DS18b20 chains.  I’d been running those with 3k3 pullups and they passed all run tests at the surface – but those strings suffered a slow progressive read failure after about five months between 20-50m depth.  This was a slow bus failure, and the tidal cycle showed up clearly as the sensors fell off, and then rejoined the set. My best guess is that the soft silicone jacket on the cable became progressively more compressed over time, and this raised the bus capacitance just enough to push the timing out of spec.  Adding a second pull-up to the end of the bus brought all the sensors back on line, so my recommendation is to stick with ~2K pullups if you build longer chains like this. Harder PUR insulation cable jackets might also have prevented this very tricky problem.

A Simple DIY Underwater Connector System made from plumbing parts

Up to this point, the Cave Pearls have been self-contained units. But this means that the sensors must be mounted directly on the housings, and the batteries must fit inside.  I already have ideas for new sensors that would require me to overcome these two limitations, so I need to address the issue of how to make electrical connections that are not merely IP68 waterproof, but rugged enough to withstand pressure at depth for a year or more.

I wet-sand the ends (indicated by the red arrows) of that nipple with 600 & 800 grit to smooth away any casting seams.

Wet-sand the ends of that nipple (arrows) with 600 & 800 grit to remove any casting seams. Smooth all o-ring seats.

Use a couple of sizes of heat shrink tube to seal the cable to the pex adapter

On 1/2″ barbs, use a couple of sizes of heat shrink to step down (from Ø12/6 tubing) to the diameter of the cable you are using before sealing the connection with epoxy. Adhesive lined tubing  helps the seal. You can also buy 1/2 NPT x 3/8 PEX adapters for thinner cables, but for some reason they cost twice as much as the larger diameter 1/2 x 1/2″ adapters (?) 

As a diver, I had already seen debates about which connectors are the best on the scuba forums, and a quick Google search quickly finds many suppliers for that market. Most of these are “wet-plugable” connectors encased in delrin/rubber, and they are workhorses in many industrial and military applications. High profile companies like Seacon making a bewildering array of solutions, but their cheapest ones come in around twenty five dollars per socket, so a complete connection will set you back at least $50.



Remove the cone washer before filling adapter with epoxy

Remove the cone washer before filling with epoxy. I score the inside of these 1/2″ barbs with an old 8×125 tap to promote epoxy bonding.

Many of these commercial connectors are rated for deep ocean deployments, able to withstand thousands of psi – far more than I will subject them to in the shallow cave systems. And they often give you a short little pig-tail under the assumption that you will be using it with a cable gland , or a bulkhead connector on a nearby housing ( or at the very least a couple of layers of marine grade adhesive lined heat shrink tubing)  I needed some decent cable runs so I went looking for other applications with longer lines at shallower depths . The pool & underwater lighting folks often use  Bulgin electrical connectors, and the 400 series   Buckaneers  (rated to 10m) occasionally come up on eBay in the $10 range, But again you need to buy two sockets (male&female), and you need to buy the pins which are sold separately. So you still end up around $25 per connection.


Make sure your wires are long enough to extend past the nipple, or you wont be able to make the connection!

Make sure your wires extend all the way through the nipple, or you can’t make the connection! And use soft flexible silicone wires so they fold back into the connector easily.

With all that as background, I went hunting once again through the plumbing section at the local hardware store.  I reasoned that anything that could hold water in, could also hold water out, right?  And I think I have come up with a solution using Nibco pex swivel adapters that is pretty cheap and can be adapted to many different applications. These plumbing adapters are rated to withstand 100 psi, which is roughly equivalent to 230 feet under water.  And that is pressure from the inside out, so my gut feeling is that these things will be able to withstand slightly greater pressure in the other direction, where the forces act to increase the compression of the cone washer.  The thing I like about the swivel adapter mechanism is that it applies pressure to a hard plastic lip on the other side of the washer, so as you tighten the nut there is no rotational force being applied to the parts forming the water tight seal.

And it even looks good!

~$6 for parts, and it looks good too.

These adapters come in a variety of larger & smaller diameters allowing you to use different cable thicknesses, and you can change the length of the pvc riser pipe in the middle to make more space for the internal connectors. This also gives you a way to adjust the amount of air/buoyancy along the run and with a string of connectors this might be a good way to reduce strain on the cable.  I suspect that the schedule 80 tubes in the middle are the weakest point in the system, but filling the internal space with mineral oil would get these connectors to significant depth, as would a filling of paraffin wax, though that would have to be heated again to undo the joint. 



Don’t forget to smooth the seat on that male hose barb side if it has bad casting seams. You want that connection to be as clean as possible. You need to use small connectors for this M-F design.

After building a few of these, I realized that it was possible to make them even simpler if the electrical connectors were small enough.  In the picture here, one side has a Nibco PEX swivel adapter, while the other has a male thread NPT to PEX  adapter. These are both polymer, though it is hard to find an epoxy that will bond to it with an applicator fine enough to put the adhesive into the barb cavity. These fittings are also available in brass for the same price, and the o-ring seats are much cleaner on those than the polymer adapters because there are casting seams on the plastic parts. But I don’t know how well the brass will fare in marine environments. Some of my sensors have stainless shells, so I worry about galvanic effects in salt water?  

After this, pull the cable through so the

Pull these joins into the connector so they are embedded in the epoxy.

In the photo above I’ve used a three wire PC fan connector, and it “just barely” fits inside the cavity of that m/m hose barb. I will use smaller JST connectors in future, or perhaps Dean’s Micro 3pin or 4pin for something more robust.  The internal diameter of the 1/2 pipe is a little over 12mm, so if you need to squeeze more connections in there you could try a couple of “mini micro” JST’s, but I find that soldering all those wires so close together is a bit irritating because it’s easy to accidentally melt the plastic, loosening the tiny pins. 

I also found that the wire inside my cables were too stiff to fold neatly into this much smaller space, so I had to add some flexible 26 AWG silicone wires to the ends. After the jumpers are attached, pull the cable through so that the solder joins get embedded in the epoxy. This has the added benefit of providing a break in the insulation around the wires, so that if you do get a cut in the cable, water can’t work it’s way through the connector by wicking along the copper strands.  I am still hunting for a good supplier of multi-conductor 22-24 awg cable that has a good “handling weight” for underwater applications. It’s hard to shop for something on the internet when what you are really after is something that “feels right” when you hold it in your hands.

A dual connection cap for one of our 2″ underwater housings. We now use harder PUR sheath cables because softer silicone jackets were too easily damaged during deployment dives. A 3/4″ adapter from the pex connector system gives you a way to mount pressure sensors under oil.

I should add the usual provisos here about this being another of my completely experimental ideas so use this at your own risk.  Pex tubing is generally rated to  ~100psi (at temperatures below 74°F) and if the o-rings can withstand that then they should “theoretically” be good to about 60m depth. Translating that into the real world, I expect these connectors to be trustworthy to about 40m, which covers most of our cave deployments.

Addendum 2015-01-30

I just stumbled across a different solution to the expensive underwater connector problem. His method for waterproofing connectors using 3D printed silicone molds is beyond my current capabilities, but its nice to see it explained with such clear documentation.

Addendum 2015-02-01

If those pex adapters don’t have enough room for your cables, I found another great underwater connector project which might do the job for ya 😉

Addendum 2017-01-23

As time goes on I am reducing the number of interconnects, but even with longer chain segments I will probably stick with only 24 sensors per logger.

As time goes on I am reducing the number of interconnects, but even with longer chain segments I will probably stick with only 24 sensors per logger.

Just though I should add an update to mention that quite a few of these connectors have been in service for more than a year on temperature chain deployments. None of them have failed on relatively shallow deployments from 5-15m depth. The only problem I’ve had  is the length of the connector itself can be challenging when you are trying to pack one of those long strings into the mesh bag for an underwater deployment.


Addendum 2018-12-05

I’ve posted a video showing how I build those underwater connectors and use them with epoxy potted sensors:   ( part of our 2017 screw terminal logger series) 

It’s also worth mentioning that you can improve the fit of various parts by taking advantage of the fact that they are thermoplastics:

Rotate & heat the inside corner edge of the tube until ~ 0.5mm of the material ‘softens back’. Don’t over-do it! you don’t want to alter the tube diameter or hurt the threads.

Quickly press the mating o-ring onto the seat while the PVC is still soft enough to conform to the shape.


Before & After heat treatment: the o-rings now form a better seal. This is faster than sanding away any rough casting seams on the parts

Addendum 2020-04-06

These connectors & sensor mounts are part of the housing system we’ve been developing since 2015. You can see the latest underwater housing build @ DIY data-logger Housing from PVC parts

Using a DS18B20 Temperature Sensor “without” a dedicated Arduino library

New housings in production

New housings in production. The sensor wells on top will be filled with epoxy to seal the hull.  Note: some of these housings have unnecessary “chunks” of PVC on the outside, as I made them for latch clamps which I am no longer using in the design.

I haven’t had time to post to the blog lately, as I am now in full-on production mode: trying to get five full units running for deployment next week.  Between all the cutting and sanding of the new underwater housings, I have been investigating sensors, and thinking about how to make the entire unit modular enough to allow quick field repairs.  The I2C bus architecture becomes very attractive here, because so many sensors are available for it, and I found a nifty I2C hub from Seed studios, which gives me a standard plug for connectivity. But most of the sensors I found want a steady 3.3 volt supply, and that is not available on the Tiny Duino  (the lack of a 3.3v rail is a weakness of the platform but I was the one who wanted to run with no voltage regulator in the first place..) So I started designing a power supply module around a NCP1402-3.3V Step-Up Breakout from Sparkfun.  I knew this was going to waste 25% of my power for this deployment, but I figured I could use lithium AA’s to make up for the loss, and look around for a more efficient voltage regulator later.

No luck with the voltage regulator even though it seemed to be working fine...

It seemed to be working fine…

Well, a frustrating day or two later and I still had no joy from the 3.3v regulator. I don’t know if it was an inrush current brownout, or transient spikes, or output ripple…but for some reason the tiny stack simply will not run from this regulator – all I get is one little pip out of the on-board led and that’s it.  Grrr! There goes about half of sensors I planned to use with the nice I2C breakout boards I had just purchased, unless I can somehow power the sensors “separately” from the main mcu stack. (And there is no guarantee I won’t have the same kind of gremlins pestering me there…)

Time to make lemonade: I had a few DS18B20 one wire temperature sensors, and they are not too choosy about input voltage, so I figured I would give them a try, while just running the Tiny’s from unregulated AA’s (…again).  DS18B20’s are common as dirt, and almost as cheap, and there are libraries for them everywhere. So it should not take long to get them going…right?

Well what I thought was going to take me 30 minutes has actually taken me a day of digging to sort out, so I am posting the result here, to hopefully save someone else the trouble.  The standard approach is to install a Dallas control library, and a one wire library to run this sensor. Most sources suggested the library written by Miles Burton, and the one wire library over at PJRC.  And after a few grumbles, like finding out that zip file created directories with the wrong names  ( “dallas-temperature-control” from the zip extraction needs to be renamed to “DallasTemperature” for it to work) I did get the test code running…sort of. Now don’t get me wrong, Miles Burton has created a veritable swiss army knife of a library, but a tiny script for this one sensor weighed in at 8,772 bytes. That’s almost a third of the available program memory, and I already knew my data logger script was around 22 k (with accelerometer) , so that was not going to leave much space for the other sensors I want to add.

Logger units with I2C hub for sensor and RTC connections.

Logger units with I2C hub for sensor and RTC connections.

And while I was sorting all that out, I discovered another problem with the DS18b20: Every once and a while it was throwing out a spurious reading of 85 degrees, but it was frustratingly intermittent. More run tests with different settings showed that the error never happened when I had the sensor set to run at 9-bit, but it popped up more frequently as I raised the bit depth. Back to digging through the forums, which revealed that this is a pretty common issue with the DS18b20. The “default” setting of the registers produces the 85, which is what you get if you read the sensor too soon after a reset. If you sift through the datasheet, you find that when you ask the sensor for the full 12 bits of resolution, you need to wait at least 750 ms for the sensor to embed the temperature data in it’s eeprom before you can read it out. So although the sensor only draws 1.5mA during the conversion, and it goes into standby mode right afterwards,  it was going to hold the whole system in limbo for that conversion time, doing some serious damage my the overall power budget.

More googling, and I came across a great little project blog called BitKnitting, where someone managed to use the sensor without a dedicated sensor library. So it was possible! However, they were only using the integer part of the 12 bit register, and I wanted all of the information, as the temperature variations in cave system is often only fractions of a degree C. I found a floating point capture demonstrated over at the Bildr forum. Combining that with a 1 second Watch Dog Timer sleep (to save power while the mcu waits for the sensor’s temperature conversion) produced this little script which weighs in at 5988 bytes. Not much savings on memory, because of the addition of the wdt library, but hopefully much lighter on the projects power budget. I will be weaving this into the main logger code later. I also have a feeling that I can go rooting through those libraries and delete a few functions I am not using to make them lighter, when I have time.

Addendum 2015-02-25

I think this is approaching the largest string I would want to deploy on a dive.

Addendum 2015: I think this is approaching the largest senor string I would want to deploy on a dive.

I recently started making long chains of these sensors, in an attempt to build a poor mans thermistor string. Here is a link to the post about those experiments.


The DS18B20 is only supposed to draw around 1μA when in standby, and not being interrogated. So it hardly seems worth the bother of turning them on and off to me, but there are a few people doing so by powering the units directly from the digital pins of the Arduino.  I might investigate that later if I have not used the pins for something more productive.


I have also noticed that this sensor seems to warm itself if you have it doing a continuous reads at 12 bit as the script below does (which has the unit at its maximum 1.5 mA current the entire time). So just be warned that if you are using the ‘waterproof’ models, which are encased in a metal sleeve filled with epoxy, you can’t drive the sensor full tilt without internal heat building up & affecting the readings. 

// adapted from
//  and
//  sleep from

#include <avr/sleep.h>
#include <avr/wdt.h>

#include <OneWire.h>
const byte DS18B20_PIN=4;  //sensor data pin
OneWire ds(DS18B20_PIN);
byte addr[8];
float DS18B20float;

void setup() {


//Set up Temp sensor – there is only one 1 wire sensor connected
if ( ! {
Serial.println(F(“—> ERROR: Did not find the DS18B20  Temperature Sensor!”));
else {
Serial.print(F(“DS18B20 ROM address =”));
for(byte i = 0; i < 8; i++) {
Serial.write(‘ ‘);
Serial.print(addr[i], HEX);
delay (200);

void loop() {

DS18B20float = getTemp();
Serial.print(F(“FLOAT temp in celcius: “));
//Note: sensor defaults to a reading of 85 if you read it too soon after a reset!
delay (200);  //just a delay to boot out the coms

// watchdog interrupt
ISR (WDT_vect)
wdt_disable(); // disable watchdog
} // end of WDT_vect

// this returns the temperature from one DS18S20 in DEG Celsius using 12 bit conversion
float getTemp(){
byte data[2];
ds.write(0x44); // start conversion, read temperature and store it in the scratchpad

//this next bit creates a 1 second WDT delay during the DS18b20 temp conversion
//The time needed between the CONVERT_T command and the READ_SCRATCHPAD command has to be at least
//750 millisecs (but can be shorter if using a D18B20 type with resolutions < 12 bits)
MCUSR = 0; // clear various “reset” flags
WDTCSR = bit (WDCE) | bit (WDE); // allow changes, disable reset
// set interrupt mode and an interval
WDTCSR = bit (WDIE) | bit (WDP2) | bit (WDP1); //a 1 sec timer
wdt_reset(); // pat the dog
set_sleep_mode (SLEEP_MODE_PWR_DOWN);
sleep_cpu ();
sleep_disable(); // cancel sleep after wakeup as a precaution

byte present = ds.reset();  //now we can read the temp sensor data;
ds.write(0xBE); // Read Scratchpad
for (int i = 0; i < 2; i++) { // Only read the bytes you need? there is more there
data[i] =;
byte MSB = data[1];
byte LSB = data[0];
float tempRead = ((MSB << 8) | LSB); //using two’s compliment
float TemperatureSum = tempRead / 16; //this converts to C
return TemperatureSum;