Viewing 21 posts - 1 through 21 (of 21 total)
  • Author
  • #39609


    Anyone working on a 2-wire config solution for OpenSprinkler? I’m no engineer but I’m curious about the effort involved in order to make 2-wire a reality via OpenSprinkler.



    Hi, 2-wire system has been brought up on the forum, for example, this thread:



    I too am very interested in 2-wire system since I have a lot of valves spread over a lot of area and don’t want to run lots of wires or multiple controllers. I have lots of trees that need irrigation, and in practical terms this means one valve per tree. The number of valves add up quickly.

    First, a small amount of background on 2-wire:
    2-wire is a generic term for systems that employ a single pair of wires to drive all valves in the irrigation system. The two wires carry 60 Hz 24 VAC power. Modulated onto the 24 VAC power is signal that implements a communications protocol designed to talk to a solenoid driver located at each valve station. Some implementations clip a portion of the AC waveform to indicate a digital ‘1’ or ‘0’. For example, clip one positive cycle of the 24 VAC waveform at half amplitude for a ‘1’, clip the negative half of the 24 VAC waveform for a ‘0’. The electronics in the solenoid driver demodulate the data riding on the 24 VAC power and provide switched power to the valve when that particular solenoid driver is addressed by the system. So the solenoid driver extracts a stream of command data and 24 VAC power. Each solenoid driver has to have a unique “station address” to enable each solenoid driver to be uniquely addressed. Some method must be provided to program the station address into the solenoid controller. Commercial systems uses a dedicated (expensive) programmer for this purpose. Typical systems can address hundreds of valves. Commercial systems cost many thousands of dollars.

    I think the main problem with commercially available 2-wire systems is the high cost of components. It is ridiculous that a 2-wire valve adapter is more than $60 per valve (and often much more). Looking online, I see 4 valve solenoid driver for $240. That is nuts. The controllers themselves are over $1000. The solenoid driver programmer is $600.

    Seems to me that if OS used an existing 2-wire protocol that would work BUT adapting an exiting serial protocol to OS plus a simple/cheap design for the valve solenoid driver would be straightforward – and avoid potential patent infringement For example:

    1. Add a serial-to-modulated power interface to the OS controller hardware. Use whatever serial protocol makes sense – async serial as used in the RS-232 standard would work fine. Maybe this could simply be a serial-to-2-wire converter that could be added to the OD hardware as an option.
    2. Design a solenoid valve driver. Analog electronics to demodulate the signal from the AC carrier on the 2-wire cable that runs to all valve drivers plus digital electronics to interpret valve commands. A small/cheap microcontroller with some non-volatile, reprogrammable memory plus a few analog components. Make it small, cheap, easy to assemble. Include LEDs for: 2-wire power detected, command detected, command-to-me detected, valve on/off. Users could then assemble and pot the board in a small plastic cup (or medicine bottle, or whatever). Low cost at the solenoid is key, i.e. low cost-per-valve-station.
    3. Need to engineer the system for lighting protection. A 2-wire system could span many thousands of feet.
    4. Add support to OS firmware.

    Each valve driver would need to be programmed with a unique valve address. I think a good way to do this is to use a custom command for the driver that sets the address and have the OS firmware include a programming mode in which only a single solenoid driver is connected to the 2-wire interface. Also include a test function to check that the address was set.

    I’d love to see this feature as it really makes sense for large systems spread across a lot of area.



    OK, in the 30 min or so since I originally posted, I did more research OS and the RPi platform and my thinking is as follows:

    1. Implement the 2-wire interface as a GPIO plug in module for the RPi.
    2. Optionally implement a bidirectional valve driver interface. 3 wires would be easy (common, 24VAC/xmit, receive). Would make valve driver diagnostics easy and also support sensor networking.
    3. Look at automotive single chip solutions for distributed power control. The networked vale problem is similar to the distributed automotive “switches and loads” problem. Perhaps there is a single chip solution out there.



    Just found a low cost powerline model chip (TDA5051A) which looks pretty good. Now need to see how many can sit on a single 2-wire line.
    perhaps with his chip plus cheap microcontroller and power driver and we’re done.



    ATtiny85 for the processing at the valve controller. Program it with a USB programming adapter and put in either the application or a bootloader. usign a bootloader enables firmware updates over the 2-wire interface…



    There are many 2 wire systems out there. Not for sprinklers. The problem is energy. You cannot shove enough power over a very very very long 24ga wire to actuate a solenoid even at 24v. The people who want 2 wire want to daisy chain them from valve to valve which also means if anywhere the wire is cut it takes all the solenoids after that out of production.

    You want to do 2 wire then use 14 or 12ga romes and bury it. You wanna spend $200 on 200 feet of “sprinkler wire” then?

    The only way to get around this is raise the voltage. But above 24v requires a licensed electrician to install.

    The commercial systems have the same problem. I am sure they use remote power or power extenders (step up step down transformers) to solve this. They probably per code require licensed electricians to install.



    Actually, all major sprinkler controller manufacturers offer 2-wire systems specifically designed to drive long strings of 24 volt AC valves. The systems are in widespread commercial use and have been for many years. String length can be up to several thousand feet (some as much as 15,000 feet) long and include hundreds of valves.

    A casual Google search on “2-wire irrigation” will yield lots of information.

    Power is not an issue. Using some approximations:
    Voltage drop at 3000 feet assuming 500 ma:
    3000 ft * 6.3 ohm/1000 ft * .5 = 9.5 v.

    24V – 9.5 = 14v. This is plenty for pull in for an irrigation solenoid. This also assumes 300 ma to power all solenoid and interfaces on the string. This estimate ignores inductance and AC effects. This link: does a good job of explaining things in detail.

    The National Electric Code does not define “low voltage” per se, but 30V is generally considered the limit. No issues with licensed electricians. Also note that in general, homeowners doing improvements on their private homes are not required to use licensed electricians as long as they adhere to applicable NEC codes and have the required permits and inspections. This varies by local jurisdiction.

    So the implementation of a 2-wire system is not only practical, it has already been done – a lot.

    I am starting implementation of such a system using ASK (amplitude shift keying) to bidirectionally communicate with many (100 is design goal) valves using two wires. The challenge with is approach is the current required by each ASK modem in the valve string. If the current per station is too high, I might have to change the comm approach.

    I plan to design for cat5 wiring as it is cheap and low cost valve nodes are the goal. A node cost of $12 for control of 4 ball valves would be fine. Motorized ball valves are $15 each from China.

    As I have undergrad and graduate degrees in electrical engineering with an emphasis on embedded software and digital electronics, I expect development to be straightforward.

    I’ll let you know when I have the system finished. I might consider selling the components.



    Go ahead and try it. A couple things you might go back to Ray’s page and look at again:

    1) Inrush current. Ray mentions this on the page. The solenoid needs a spike of high current to get the slug of iron in the solenoid moving. For a very long run of wire at 18ga it’s not going to be reliable because for the few microseconds that it’s pulling 20A or more the voltage is going to be way too low. Which is why I said I’m pretty sure the commercial systems are using a boost/buck system.

    2) Regular cat-5 ethernet is 24ga not 18. Also, the jacket of regular ethernet will not remain intact in water. I’ve seen enough of it pulled out of pipes that had water in them to know what happens to regular PVC ethernet cable jackets. They make underground rated ethernet and it has the same tough PVC case that the 18ga sprinkler wire has. I think you will find underground rated ethernet to be the same cost as sprinkler wire. You are also ignoring that the largest cost in ANY sort of large distributed network is laying the wire. NOBODY in charge of a large system is going to put in an untested system that specs DIFFERENT cabling than all the other existing competitive 2 wire sprinkler systems on the market.

    3) The reason sprinkler systems don’t use motorized ball valves is so that if power is lost the sprinkler valve shuts off. Otherwise you have your sprinkler going and there’s a power failure or the controller craps out and then the sprinkler is running all night long and you just lost $200 worth of water and caused a flood. Of course that then means that the valve has to be held open by continuous current. And if you have 5-6 valves actuated at the same time you run out of current carrying capacity on the wire.

    4) Sprinkler system plumbing is organized as follows, valves are generally star topology to the water source, zones are daisy chain from the valve. In small home systems the valves are usually placed next to the water source. In large systems the valves are out in the field. Think about what happens to a daisy chain system that is mapped over a star topology – for every valve you are going to be running TWO pairs to it – one from the hub out to the valve and one from the valve back to the hub then out again to the next valve. This is because they are only going to dig 1 trench for the water pipe and the cable for the valve it’s a lot cheaper. That’s why the cable length in theses systems is so long.

    You did mention the issue of powering the controller at each valve so I’ll give you that.

    You are also ignoring the inherent flaw in a daisy chain config which I mentioned already which is if there’s a break in the system then all the valves after that are dead. If you had any experience in this sort of thing you would have known that this could be solved by creating the daisy chain in a loop with both ends of the loop terminating at the sprinkler controller.

    If I was running a golf course for me to send a tech out to replace a failed valve in a sprinkler is 2-3 hours of labor which dwarfs the piddly amount of money I might save on a cheaper node. If I buy your cheaper nodes and they have a higher failure rate my savings will be eaten up.

    I am sure that if you were to keep at this after a string of failed hardware behind you and a pile of wire pulled out from underground and a long enough time you would be able to create a running system. But in half the time a lesser schooled guy could have probably reverse engineered the most popular 2 wire commercial sprinkler system on the market and produced a compatible controller that works with all their valves, and that way the greenskeeper can buy all -their- valves and the cheapo controller and been watering his lawn by the time you get something working.

    If you absolutely must design your own then why not use the cheapest wire possible – 28ga telephone wire – and run a high frequency on it like 600 Hz AC at 200volts and then you can use tiny toroid core transformers at each valve to drop it down to 20v AC, and it’s also easy to rectify that and get as much current you want to power a controller and a valve. And you can make frequency shifts to carry data to the controller. That system probably will carry the signal a few miles….



    I’m not quite sure why you’re spending so much time giving me lots of reasons 2-wire systems are bad and don’t work. Fact is that 2-wire systems are in widespread use. The engineering is well understood. They are the preferred solution for large scale systems.

    Seems like you’re hung up on wire gauge. Use whatever you want as long as it has the current carrying ability. Personally I run wire in conduit, so other than dampness I don’t sweat mechanical issues. Yes “2-wire” wire works great.

    Personally I have no interest in system compatibility since commercial systems are expensive and not attractive for homeowners.

    If all the inrush current concerns you mention were legitimate, you’d see something other than a long wire with valve nodes attached. BTW that inrush would be an issue in a “wire per valve” system too…

    Ok, I’ll be sure to come back here if I need any help listing all the reasons something can’t be done that has already been done 🙂



    I think one obstacle to interface with a 2-wire system is I am not sure if there is any open standard for it — most companies use proprietary systems and they don’t publish any details on the inner workings of their systems. This would either require some reverse engineering (which could be very difficult) or have a way to interface with their controllers, but this sounds more like a DIY / Hack project than an elegant solution.

    It’s also possible to develop our own 2-wire system that uses open standard, but it’s likely not worth the cost — each valve adapter probably needs to have a microcontroller and power circuitry to convert 24VAC to 5VDC, as is the cost is going to be quite expensive.

    Regarding @tmittelstaedt’s point 3: I did recently come across U.S.Solid’s motorized ball valve, 24V AC/DC 2-wire auto return type — it’s quite interesting, it has a super capacitor inside so when the power is lost, the charge in the super capacitor will be able to drive the motor back to closed position. As a result, it does shut off the water supply when power is lost. It’s completely compatible with any 24VAC sprinkler controller, so an interesting solution to keep in mind if motorized ball valve is required.



    I designed & built a prototype 2-wire system using a simple protocol about 10 years ago for a Freescale microcontroller design contest. At that time, the estimated single channel decoder BOM cost for the PCB and components was under $2 (not including the case & potting). I posted a document & video with more details of the design, see the links below.

    I would like to contribute to the definition of an open standard and design. The initial goal would be to build enough units for widespread field testing to prove the design. The end goal would be for the major irrigation companies to adopt the open standard and integrate the decoder hardware in solenoids for residential use.



    @bzublin: very interesting. This is probably the first open design of 2-wire system I’ve ever seen. It’s very intriguing and I will take a closer look at your design and documentation soon. Thanks for sharing!



    Real engineering and facts for the win!

    Interesting use of loading by the slaves to communicate back to the controller. I had seen that in one other design while doing my research.

    Also interesting that you did this in all the way back in 2007.

    I’m looking at a solution that uses amplitude frequency modulation for bi-directional communications but the use of PWM is just fine also. I think your approach is going to have a lower parts count and lower cost for the valve nodes.

    Regarding engaging with commercial manufacturers to develop a standard interface: I don’t expect you’d make much progress on that. It’s in a manufacturer’s best interest to keep a closed system closed. If you look at the prices for commercial two wire systems they are outrageous. That market is ripe for disruption. An open source solution could probably become very popular.

    A valve node design that would allow four or eight individual valves to be controlled would be very useful. Lower cost per valve and and many times valves occur in clusters.

    Pot those circuit boards in a short piece of PVC pipe and they are ready to go. The controller would make a pice Raspberry Pi hat.

    At the end of the day it looks like all you would need for your design is an easy means to program individual valve nodes and your design is ready to go. I imagine the controller could be set up with an interface to do that.

    If your design was open sourced it would take off.



    @bzublin: I read the document, very nice and detailed write-up. One thing that I noticed is you use DC voltage (30V) and PWM to drive 24VAC solenoid. I’ve never thought about it. Is this a known method to drive 24VAC solenoid? It sounds similar to the control circuit for step motors. I find it fascinating because I’ve always disliked the AC-based system — it’s the industry standard for decades and nobody bothers to change anything, but in modern days DC adapters are way cheaper, lighter, and easier to find than AC adapters, due to their demand. So I really hope the manufacturers will move towards more DC-based controller and solenoids. That’s what motivated me to design the DC-powered OpenSprinkler, which does not use PWM, but the underlying design principle is similar to yours, that is, use DC to drive the solenoid, and making sure the current through the solenoid is roughly the holding current. In any case, I am interesting in hearing more about the PWM method, what frequency do you use, how well does it work, any potential issues you are aware of etc. Thanks.



    Those are the ball valves I was talking about. They have some useful characteristics:
    1) The valve body is made of metal, not plastic.
    2) The ball valve is full flow
    3) The ball valve will tolerate higher pressures

    1), 2) and 3) mean that the values are well suited to hot climates like Arizona, where the sun will break down plastic. A potential issue is the electronics and plastic electronics housing, but that can be mitigated by shade, paint and a valve box.

    4) The ball valve is cheaper than plastic valves when bought through Alibaba.
    5) It is, as you mentioned, a “fail close” design.
    6) No rubber diaphragms to repair constantly. If a system contains a lot of valves, this is a regular chore, especially at higher water line pressures.

    For those of us who have to implement a system with a lot of valves, ball valves like these are worth looking at. Pair them with a two-wire control system and the result is an easily manageable and scalable system.



    Seems like programming the decoders could be accomplished as follows:
    1) Disconnect the 2-wire cable from the controller and attach a single decoder
    2) Put the controller in “programming mode” via a command
    3) Run a programming cycle:
    – Program decoder to specified address using decoder’s programing command protocol
    – Query decoder to confirm communication at programmed address
    – Report status of programming operation – and perhaps bounce an attached solenoid with a “click code” for user feedback
    4) Remove decoder from controller’s 2-wire port
    5) Repeat with next decoder until done with programming
    6) Reattach 2-wire cable to controller’s 2-wire connector

    BTW, a little circuit with a LED (or small alphanumeric display) could be substituted for a solenoid at a specific decoder station to generate diagnostics messages fro end user troubleshooting.

    Finally, seems like having a controller that accepts inputs from a commercial timer would not be as useful as a controller with a serial interface and command set that would enable attachment to a computer (raspberry pi or similar). Reducing wiring for a 6 or 12 zone timer versus a 48 zone system spread out over acres.



    I posted a reply a few days ago but it seems to have disappeared after I edited it to fix a spelling mistake. Luckily I kept a copy so here it is again:

    The PWM to drive the solenoid had a fixed ON time of 10 usec and OFF time of between 90 usec and 0.125 usec. This results in a duty cycle of 10% to 99% and a frequency of 10 kHz to 99 kHz. The 10 bit A/D converter that was used to measure the current through the solenoid had a sampling period of about 6 usec. The 10 usec PWM fixed ON time was chosen to ensure that the sampling point was consistent for each PWM cycle and there was only one sample required per PWM cycle. The current control loop was simple and consisted of increasing or decreasing the PWM duty cycle by a fixed amount if the measured current was below or above the target value.

    The most basic installation of a controller with multiple decoders would be for the case when the inputs to the controller are from a separate irrigation timer with standard 24 VAC solenoid outputs. I have been thinking of a simple method to program the decoder addresses for this case. One method would be to turn ON one of the irrigation timer outputs which would command the controller to send out the decoder ON command and specific address. At the desired decoder, some manual input would be required to tell the decoder that the specific address is intended for that decoder and to store that address permanently. A simple method would be a loop of wire on the decoder that gets cut to program it. Another method would be to use a magnetic sensor and a small magnet.

    For the voltage waveform to send commands from the controller to the decoders, the original design used 1 msec and 2 msec pulse widths for logic 0 and 1. Another option would be to use an asynchronous method with fixed bit times similar to standard RS232 serial interface so that the interface would somewhat follow an existing standard.

    One challenge of the hardware design is how to create a regulated low voltage (5V or 3.3V) from the 30V source for the decoder’s microcontroller, with high efficiency at low load current to minimize the total power consumption of the many decoders connected in parallel. My original design uses a discrete linear voltage regulator that is very low cost but not very efficient and would not be viable if additional loads were added such as an LED indicator for each decoder. Since that time, there are newer switching regulators that can operate at high input voltage and have very good efficiency at low and high load current. Although more expensive and complex, it is probably the preferred solution for system performance.

    Another design challenge is surge protection to ensure that the decoders have some level of protection in case of nearby lightning strikes. I have experience in this area and a good target is for the decoder to be able to withstand 6000V 3000 amp 1.2/50 µs–8/20 µs Combination Wave as defined by IEEE standard C62.41.2-2002. This level is similar to what is required for external power supplies connected to the AC mains.



    @bzublin: thanks (and sorry to hear that your post disappeared: I did recently discover our spam filter had false positives so several posts got incorrectly flagged). About PWM control of solenoid: very clever. As I said, it reminded me of motor or stepper controller: it would be interesting to see if we can use a monolithic motor controller to do the job, releasing the microcontroller from having to carry out the sampling and control loop, though using microcontroller does provide the benefit of software-defined current control, which is handy. I am mainly thinking whether I could change the current OpenSprinkler main controller design to use this method as well, but since each controller can handle up to 72 zones, it’s probably not feasible for one microcontroller to perform that much ADC sampling (which also takes a lot of cycle time). What’s why I am thinking whether you can delegate the job to a monolithic motor controller. In contrast, the nice thing with your 2-wire decoder design is that each decoder has its own dedicated microcontroller, so it doesn’t require one central mcu to handle all valves.

    Regarding setting addresses: one method is as you said, turn on each decoder one by one. The main controller can be set in ‘discovery’ mode and continuously send out probing signals, any decoder that has already received a permanent address would not respond, while a newly turned on decoder will respond and obtain the current address, then the main controller increments the address and the user turns on the next decoder. This way the user can simply turn on each decoder one by one, and they will get sequential addresses that way.

    Another method is by using the ‘old-school’ dip switch: a 8-bit dip switch can set up to 256 unique addresses. This way there is no need for the controller to discover decoders, however the burden is on the user to make sure each decoder gets a unique index.

    About ‘regulated low voltage (5V or 3.3V) from the 30V’ — I have plenty of experience with using switch regulator for this. You are correct that linear regulator is not efficient (unless if we are talking about very low current draw). I’ve seen commercial sprinkler controllers that simply use a zener diode based linear regulator, which really only works if the circuit draws less than 10mA, otherwise too much power will be wasted on the current limiting resistor. Using switching regulator, the old school MC34063 is super cheap and can supply up to 500mA, though it’s relatively low frequency and noisy (under small load you may hear inductor humming). The current OS 3.x design uses XL1509, which is also a low-cost chip that can supply up to 1.8A.

    Regarding surge protection, the typical approach is TVS diode and/or MOV (sometimes in conjunction with each other). I’ve taken apart some motorized ball valves which have built-in circuit, and those are pretty much what they use for protection.



    Well I’m going to bump this from last year with an “I told you so” to the question of “I’ll be sure to come back here if I need any help listing all the reasons something can’t be done that has already been done” and reiterate what I said in my original post:

    Reverse engineer the most popular 2 wire commercial sprinkler system on the market and produce a compatible controller that works with all their valves, and that way the greenskeeper can buy all -their- valves and the cheapo controller.



    Just because I have stopped posting here does not mean that have stopped development. I have a day job as an engineer and lots of other tings going on as well, so time is at a premium and it’s always a question of priorities.

    At this point I have a design done (RPI Hat). I’d encourage anyone who thinks that this kind of things is not possible and practical to go and do the engineering.

Viewing 21 posts - 1 through 21 (of 21 total)
  • You must be logged in to reply to this topic.