Summary of Meeting 2017-11-14

[TerryJC]

Here is a summary of the points discussed this morning after the Butts Pi Hardware had been removed:

1. We discussed the modified Overall System Configuration Drawing that Penri posted at http://wmtprojectsforum.altervista.org/ ... p=758#p750 and agreed some minor changes. I will post an updated version of this diagram in the same Topic later today. Page 3 will take the place of the current Page 1, which will be deleted.
2. Discussion centred around Page 3 of the drawing (which will be Page 1 in V03) and the operation of this system was agreed. (The references in these notes refer to the updated Version (V03):
   1. Each Butts Farm Group will be physically slightly higher than the previous one, so that gravity may be used to return water to the sump, ie, as the current Butts Pi system works.
   2. The Wendy House Butts Farm Group (G4) will remain largely as it is (for the moment at least).
   3. The new Railway Room Butts Farm Groups (G1 to G3) will be fed by pumping the water back up the drain pipe, rather than by using a separate pipe feeding into the top of the barrels as is done with the current Butts Pi system. To enable this to work the arrangement shown in the middle of the drawing will be used to create what is in effect a system of diverter valves. When water is being taken from the butts, then Gate Valves V6 and V9 will be closed and V7 and V8 opened. This will allow water to flow from Groups 1 to 3 to the inlet side of the pump and from there to Group G4. (As an alternative, if sufficient head of water exists, then valves V6 to V9 could be opened and the pump turned off.)
   4. To return water from the Wendy House Butts Farm (G4) to the G1 to G3 butts, valves V6 and V9 will be opened and V7 and V8 closed, so the water will be pumped from right to left.
   5. Gate Valves V5 and V11 will be used to control the flow of water to 'leaky hose' watering systems around the garden. In its simplest form, these might be a timed event each evening or based on environmental factors such as temperature and soil moisture content. This is for future development.
3. Some software considerations were also discussed:
   1. Addressing of the sensors at each Butts Group will be as follows:
      • Each sensor will be connected to four GPIO pins to carry Binary Coded Decimal (BCD) data and up to six GPIO pins to carry addresses. The data pins pins will be programmed as inputs and the address pins programmed as outputs. These GPIO pins will be bussed to all sensors.
      • To read from a particular sensor the associated Remote Pi will assert the sensor's address on the address pins and then read the value on the data pins.
      • The remote Pi will then precede the data with an ID Code so that the Master Pi can establish the sensor's identity. For example a magnatic Probe Reading from Butts Group G2, might be encoded as G2:M300 to show that the data is from the magnetic levels probe at the second Butts Farm Group behind the Railway Room.
   2. It will be necessary to take some care when opening and closing Gate valves and operating the pump. It is expected that it may take some time to move the gate from fully open to fully closed and vice versa. There are therefore two factors that will need to be considered. If the pump is turned off before a valve is closed, then water may siphon the wrong way through the system setting up a potential for 'hunting'. On the other hand, the gate valve might be closed before the pump is turned off, causing too much pressure in the system and the potential for damage.
   3. There is also the potential for damage if the gate valve motor is run too long, so that the gate is forced against the wall of the pipe.
   4. Two precautions are therefore recommended to mitigate the risks just outlined:
      • The Gate Valve motors should either be stepper motors, so that the position will be based on how many pulses have been sent, or micro switches should be fitted; one at each extreme end, that interrupts the power to a linear motor, and one just before each end to allow the software to be made aware of the state of the Gate Valve.
      • A pressure relief valve should be fitted, downstream of V3 with it's output connected to the top of the butts, so that excess pressure may be released. This will be shown on V03 of the drawing.
4. Finally there was some ideas mooted about how the power and Ethernet should be distributed:
   1. PoE should be utilised to carry power to all external devices to avoid the need to protect mains cabling in an external environment.
   2. However, advantage should be taken of any mains supplies that might be available close to the devices needing power, rather than trying to route all power from a single DC PSU Module, since this would involve the use of a multiple PoE Splitters all drawing power from a single Poe Injector which might be some distance away. Either way, it is likely that several Ethernet Switches will be required to avoid running multiple Ethernet cables around the site. An additional Page will be included on V03 of the Overall System Configuration Drawing.

If I have missed anything please post it here and I'll update the post.

[hamishmb]

Note:

2a) Each group will be higher than the last, but only because the ground slopes, not because we want it that way - I think we decided against deliberately raising them.

[TerryJC]

2a) Each group will be higher than the last, but only because the ground slopes, not because we want it that way - I think we decided against deliberately raising them.

I thought that we simply said that it is likely that they will be higher because of the slope of the ground, but either way that was what we wanted anyway.

[hamishmb]

Yep, you're right

[Penri]

Hello

The only thing I want to comment on is 3a) bullet one, and its more a discussion really, all the other point are as I remember them, thank you.

We did discuss using BCD coding for signals from the probes, so sending 4 parallel data bits instead of sending signals from each of the 10 hall effect sensors; I'm happy with it and have a vision of how to achieve it in hardware (although I don't have design yet), I'm just wondering if it's a cop-out on my part and what is really required is a more universal, less bespoke, communication mechanism. I don't thing that Ethernet TCP/IP would be appropriate, there's too much overhead, but what about a serial bus based around RS485 with a simple protocol? is there something suggested within the IoT world we could piggy-back on? (I haven't found anything yet).

This questions are aimed more at you Terry because of your experience, but feel free to chip in Hamish and Clive.

There may be an issue of realising any design at an acceptable cost, of course, but I thought putting the question out there would not hurt.


Hwyl

Penri

[TerryJC]

We did discuss using BCD coding for signals from the probes, so sending 4 parallel data bits instead of sending signals from each of the 10 hall effect sensors; I'm happy with it and have a vision of how to achieve it in hardware (although I don't have design yet), I'm just wondering if it's a cop-out on my part and what is really required is a more universal, less bespoke, communication mechanism. I don't thing that Ethernet TCP/IP would be appropriate, there's too much overhead, but what about a serial bus based around RS485 with a simple protocol? is there something suggested within the IoT world we could piggy-back on? (I haven't found anything yet).

Penri,

Th Pi arrives with a number of serial interfaces built in (see https://www.raspberrypi-spy.co.uk/2015/ ... -feb-2015/). I did look at these some time ago with a view to utilising one or more, but the general issue is that they are really designed to interface to devices that are on board or very close, eg less than a metre away.

It would be possible to do a conversion to RS485 because the Pi does have a UART connected to pins 8 and 10 (see https://pinout.xyz/pinout/rs485_pi and https://www.abelectronics.co.uk/p/77/RS485-Pi. Obviously that would significantly reduce the number of wires, but more research would be needed to ensure that the Pi (and this device) is capable of supporting multi-drop.

I'll have another look at this over the next few days.

[Penri]

Terry

Thanks for the reply, I'll continue to ponder a more streamlined hardware interface for the probes.

Hwyl

Penri

[TerryJC]

Penri,

I've had another quick look at RS485. As you know RS485 only specifies the hardware interface, but the device that I flagged up does seem to be capable of multi-drop (see https://thepihut.com/products/rs485-pizero). The protocol that needs to be used will be UART at the low level and there seems to be support for that in the wiringpi-python library, so that's OK. On top of that, we can use any protocol that we like since we own the whole system. However, there seems to be a couple of protocols commonly used, which we should be able to use. The first is Asynchronous serial communication (see https://en.wikipedia.org/wiki/Asynchron ... munication), but the most appropriate seems to be Simple Sensor Interface (SSI) protocol (see https://en.wikipedia.org/wiki/Simple_Se ... e_protocol).

Either way, the sensors would need to be semi-intelligent, in that they would have to respond with the sensor data when addressed and otherwise keep stuhmm. On the other hand it would be easy from the RPi end with the software simply constructing a string that contains the appropriate address and command and then listening for the response.

Do you think that it is relatively easy to respond to an address in the form of hex chars in hardware? If not then the BCD approach may be the answer.

[Penri]

Terry

Thanks for the research and resulting references, I’ll take a look and see what I can come up with.

Hwyl

Penri

[hamishmb]

Note: We're using RPi.GPIO right now, and honestly now isn't a great time to try rewriting the code XD

I have some refactoring to do and other things first, but my personal projects need some time dedicated to them as well