By Dale Reagan | July 21, 2011
Long is, of course, relative… After much tinkering/testing with Arduino and 1-Wire networks I discovered what seem to be some limitations:
- using an Arduino Uno I reached a maximum of 54 sensors on a large bread board – add sensor #55 and the network stops working when using parasite power
- on my ‘real lan’, during my testing the maximum was reached at ~90 feet of cable with eleven (11) temperature sensors (DS18B20 sensors) – the network would fail when I added the next sensor node.
Hardware: Arduino & LinkUSB
An Arduino solution is attractive since it could operate in a stand-alone, battery powered, SD card data backup solution. Of course various Arduino ‘shields’ would also be needed and I may revisit this approach at a later date.
At this time I am using a LinkUSB (iButton) USB 1-Wire interface – this is being used for my (relatively) long 1-Wire network until/unless I can resolve the Arduino limitation (note that it may be possible to use Arduino in ‘hub fashion’ – see previous Arduino/1-Wire posts - to resolve this limitation; I did a ‘mini-test’ but the LinkUSB option worked ‘out-of-the-box’ and I was ready to deploy…) My current MicroLan contains 34 temperature sensors with an estimated combined cable length of 400+ feet.
I created three types of sensors which I describe as:
- box sensors – the DS18B20 is attached to a keystone jack in either a 2 or 4 port box and
- string sensors – the DS18B20 is attached to the end of CAT5e cable.
- rope sensors – [update, 7/31/2011] multiple DS18B20s attached to 18 gauge bell wire via ‘quick splices‘ at 10 foot intervals (currently testing two ~40ft ‘ropes’) bringing the active sensor count on this micro-lan to 44 and the micro-lan length increases ~480ft. Since the wire gauge is heavier (than CAT5e) a terminal block is used on ‘rope ends’ to bridge a connection to the CAT5 cable at a ‘hub’. Note that DS18B20s were soldered to ~2″ of the same bell wire (similar to what is described below except that pins 1&3 were connected for this group of sensors – as wired, the ‘rope sensor’ will only work using parasite power.) Also, this connection creates another 8-node star from a stub/star connection (note that this is not the suggested approach using parasite power for ‘long networks’…)
The assembly of sensor ‘nodes’ was something like:
- ** solder three wires to each of the sensor terminals (I used blue wire for pin 2 [DQ, center pin], green wire for pin 1 [GND], and blue-white wire for pin 3 [Vdd] – I had to re-do a few sensors when I reversed pins 1&3 – note that when reviewing the DS18B20 documentation the the pin numbering for the TO-92 carrier shows the ‘bottom view’… The wires make it relatively simple to add/remove/change sensors from any connection point – this approach does add to the ‘weight’ of the network. Shrink-wrap tubing is installed on two of the lines prior to soldering (I covered pins 2 & 3 – the point being to avoid any sort of short-circuit on the sensor.)
- test, test, test modified sensor (install on bread board and test using Arduino)
- shrink-wrap tubing is added to cover the entire sensor area of un-shrouded wires and the bottom portion of the sensor. [The shrink-wrap tubing provides a bit of protection for the soldered connections and creates a relatively rugged unit that should be able to take modest handling. You could also use electrical tape products.]
- I matched the above colors to CAT5e cable when I connected sensors to cables
- All CAT5e cable connectors were wired ‘straight through’ (all pins connected)
- RJ45 connecters are attached to one end of each cable using the 586B (mostly US/ North America standard) wiring option; other countries may be using 586A with the difference being the placement of GN-WH/GN and OR-WH/OR wires. Each cable is tested using a RJ45 cable tester after an RJ45 connector is attached to the cable end; I had previously attached an RJ45 jack to the bitter end of the cable – once the connector passes the test then the cable is then cut from the ‘roll’ for use with a sensor/box. Any connector failing the test was discarded and replaced (yep, made some bad crimps…)
- DS18B20 sensors were either directly attached to cable ends via soldering (creating what I call a ‘string sensor’) OR
- the modified DS18B20 sensors with added wire (noted above) were punched down on keystone jacks as the ‘top wire’ (it is not appropriate to double-wire keystone jacks for ‘production networks’, but in this case it works and provides a really simple solution for adding/replacing sensors…) And yes, as constructed I could connect the string of sensors on the primary network jack to any CAT5e cabled computer/hub/router – and the cable should work for Ethernet transmissions – I have not tested this and note that it would require Ethernet connections on both ends instead of the current USB end point…)
- keystone jacks are installed in 2 or 4 port boxes (I suppose that you could call these boxes ‘hubs’, however, a ‘real hub’ would probably need to maintain connections across all eight CAT5e wires for all keystone jacks in the box – which is not how I am currently wiring these boxes – see below.)
- 2 port boxes may contain one or two keystone jacks. If more than one, then the primary jack (the one connected to the CAT5e cable) is ‘fully wired’; secondary jacks are connected via three wires using the standard pins for Blue, White/Blue and Green wires.) When using more than one keystone jack the DS18B20 is connected to the second jack, otherwise it is connected to the primary jack. The second jack becomes a ‘network spur’, creating a ***’star topology‘. The DS18B20 ‘floats’ inside of the box. Note that the Maxim documentation indicates that while ‘stubs’ and ‘star networks’ may work that they may also be prone to problems… The box becomes both a network sensor node and a connection point for extension of the 1-Wire network.
- 4 port boxes are wired as the 2 port boxes with one additional keystone jack (total of three jacks.) The DS18B20 is connected to a non-primary jack. Each non-primary jack may be connected to a secondary cable or string-sensor (a cable with a DS18B20 attached to the end.)
- each box or string sensor is assigned an ID and the DS18B20 serial number (each of these sensors has an internal, unique serial number – part of the reason for using them…) is noted in a master file (used to correlate with a sensor placement map showing the physical location of the sensor, i.e. in the attic rafters, above/below insulation, etc.)
- CAT5e cable
- keystone jacks
- 2 and 4 port keystone jack ‘boxes’ (CAT5e)
- DS18B20 temperature sensors
- Arduino Uno prototype board
- LinkUSB interface
- RJ45 connectors and crimping tool
- solder & soldering iron (~20 year old gear…)
- wire cutters/strippers/pliers
- RJ45 cable tester
- shrink wrap tubing & heat gun
- ~500 feet of CAT5e cable
Open Source Software for reading 1-Wire devices
- OWFS – One Wire File System; sensors are ‘mounted’ under a special file system and accessed via a simple ‘cat /mnt/1wire/28.xxxxxx/temperature’ (or similar path) – I found OWFS to be somewhat slow and quirky – sensors ‘left’ the list [could be due to my using the same USB device via Digitemp...]
- Digitemp – it simply works but does require specific USB interfaces like the LinkUSB; I run a custom Bash script from cron every five minutes that makes two ‘passes’ on the network; currently takes ~60 seconds with 34 sensors.
** The DS18B20 temperature sensor can operate on ‘parasite’ power using just two lines; for a parasite powered MicroLan you connect pins 2 & 3 (GND + Vdd.) In this case I opted to assemble the components such that I could ‘convert’ to a non-parasite, powered MicroLan (needed in instances of longer distance that what I am planning or, needed by other types of sensors.) I do connect GND + Vdd at my data collection point (currently, the LinkUSB interface is connected to a 4 port box with appropriate wires crossed…)
*** Star Topology – network nodes branch off from an existing, original-base-primary network source. If there is only one additional connection then we have a network ‘stub’ node (an end point.) In the scenario described above the 4 jack boxes create star nodes that branch from the box using the three wires mentioned above – and yes, this solution could have been done with only two wires. Also note that the product documentation does indicate that star topologies can be problematic and should be avoided if possible – I will use the star topology approach until I encounter a problem.
Comments are closed.