[KeithO]

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.

[KeithO]

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.

[KeithO]

Ray,
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.

[KeithO]

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.

[KeithO]

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 🙂

[KeithO]

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: https://rayshobby.net/wordpress/understanding-24vac-sprinkler-valves/ 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.

[KeithO]

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…

[KeithO]

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.

[KeithO]

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.

[KeithO]

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.

[Author]

Posts