Overall System Design Specification

[TerryJC]

Hamish,

Some of your comments need discussion and I think that Penri (and Clive if he desires) should be involved. I don't have any fundamental difficulty with most of your points, but one or two are not particularly practical. For example, in Section 4.1.1.1.1 you appear to favour the use of WiFi, which I am aware that Penri wasn't keen on. Also, if we are to have reliable connections to the WiFi adaptors, we would need to bring the antennas out into line of sight with each other. Easy enough if we are using external WiFi dongles, but unworkable if we are using a Pi Zero W or Pi 3.

Other comments need input from Penri; for example I'm fairly sure he said that the O/Ps from the Probe Sensor were active low.

Can we put these comments onto the back burner until Penri has returned and Clive has had an opportunity to review the document? We can then review everything in one meeting.

[hamishmb]

Hi,

Yes definitely we should talk to them. I was thinking WiFi/Bluetooth could be helpful for eg administering code changes from a laptop or similar without having to open cases. I'm not sure I favour it, but I think there are circumstances like that where it might be helpful

I'm not sure about line of sight, I've never needed that for a reliable connection, as I have several very thick wall in my house the WiFi signal punches through.

Yes, we should do that

[TerryJC]

Hamish,

If our idea of using Power over Ethernet to power the Remote Pis comes off then we should be able to access any of the devices by plugging a laptop into the switch. Obviously we still haven't thought the overall architecture through, but lets say that we chose to use the current WMT web server in the back of the railway room to serve the Visitor and Staff GUIs, then we could use SSH or SCP to make minor changes to the files on any device from there.

[CliveW]

Hi Terry

First post so hope this works!!

Re: Design Doc:
All seems OK to me at first look, only comments are below as suggestions:-
1. Section 8 suggest changing the 'operate at less than 20v'. Change this to 24V as you already have items at this voltage, re: 4.1.1.3.5.1.
It is also a standard automotive voltage and it may be useful when looking for control equipment (valves, motors ect).

2. Section 4.1.1.3.2.1 counting of pulses is easier at either 1 or 60 segments, depending on accuracy required.

That's my first glance comments.

Hamish showed me around the 'Butts' system and sump and I read some of the forum posts to get an idea of what you are doing.

[TerryJC]

First post so hope this works!!

It did.

Re: Design Doc:
All seems OK to me at first look, only comments are below as suggestions:-
1. Section 8 suggest changing the 'operate at less than 20v'. Change this to 24V as you already have items at this voltage, re: 4.1.1.3.5.1.
It is also a standard automotive voltage and it may be useful when looking for control equipment (valves, motors ect).

OK. Will fix.

2. Section 4.1.1.3.2.1 counting of pulses is easier at either 1 or 60 segments, depending on accuracy required.

I'm not sure that I understand this. Why is it easier to count pulses at 1 or 60 segments? Whatever the number of segments on the wheel, the Pi will be able to count them and apply a calibration factor to equate it to flow.

[CliveW]

I'm not sure that I understand this. Why is it easier to count pulses at 1 or 60 segments? Whatever the number of segments on the wheel, the Pi will be able to count them and apply a calibration factor to equate it to flow.

If you count in 1's or 60 then conversion to RPM is easy as 60 is one minute in seconds. It depends on how fast the wheel is turning and the accuracy required. There are instruments/software which are set up to convert automatically. Try converting a segment size of 21 or 133 to rpm.
I forget the formula as it's a long time since last used, sorry.

I'm going back to my engine test days 30 years ago. We used 60 pulses in all our test recording for speed, flow ect 1rpm = 60 secs per turn of the wheel.

Not a good explanation but can't think of an easier way to explain, just from experience.

[TerryJC]

Clive,

I kind of understand where you are coming from, but there are two factors that make this unnecessary:

1. We aren't trying to measure RPM; that is just a means to an end. What we are after is flow rate.
2. Once we have pulses coming off the paddle wheel; lets say 10 per revolution, we will need to establish how long the 10 pulses took to arrive, lets say 2 secs. That is 0.5 revs per second. We then need to multiply the revs by the 'X-Factor' to get flow in litres / minute or whatever we want to measure in.

We may end up with one segment on the wheel because mechanically it is easier to do. On the other hand, one pulse per rotation could mean that we have to wait 30 seconds before we get one (the river isn't very fast). So we might find a way to put a couple of hundred segments on the wheel. That would be much harder to implement mechanically, but give us much more resolution on the readings.

I don't think we should specify anything in respect of this unless we identify a real need. Once we've tried it out we can document what we have done.

[Penri]

Hello

Sorry I can't contributed much to the lively discussion from here but it's good to see it happening. BTW I have nothing philosophically against wireless, providing its secure from tampering, of course!, but practically I'd rather not have to run 240V mains somewhere if we don't have to, so if PoE works for us we have power and comms. in one neat cable/connector!

Looking forward to getting together, when I'm back, to seeing where we all are.

Hwyl

Penri

[Penri]

Sorry, forgot to mention.

Before I left for my holiday I had been badgering Greg about the Environmental/Educational angle for our project, he's got a tentative meeting arranged with the Dorset Wildlife Trust (I think that's right), to visit to talk to me/us about the project. I'd like to get them on board and get some recommendations we could review for incorporation. Greg intimated that they were keen to learn more.

Hwyl

Penri

[TerryJC]

As part of the Canford School Requirements Capture activity we said that we would provide a copy of the Overall Design Specification as an example for their documentation. I just had a look at the latest version (0.4 by Hamish in June) and accepted or implemented the comments, which for the most part have been overtaken by events.

I've also changed the Default Style to Liberation Sans to match the Requirements documents, so I would suggest that this is 'good enough' for them to use as an example and template.

Herewith Issue 0.5. Any comments?

I suspect we won't need to give them this for a week or so anyway, so we have time to make further changes anyway,