Young Project Engineer

On April 6th 1995, four members of gopsi participated in a project which earned them a gold CREST award. Although sections of this report are missing (many were hand written), the remaining details of this project are laid out below.


Section one : (Introduction)


Section 2: (Main body)

Design Brief
Initial Ideas
Final solutions
Description of commercial solution
Production of prototype
Evaluation /Recomendations
Initial and actual time plans

Section 3: Appendices

A- Program listings + Explanations
B- Trumpet curve diagrams explained
C- Corespondance


Thanks are in order for a great many people who helped us to get the project organized, and who helped by giving information, materials or advice. The people to be thanked are:

Mr B Carter, the Technology teacher at Beaumont School St. Albans. Mr Carter helped by Getting us interested in the project, and by setting us up with the link company. Also later on into the project, Mr Carter helped by giving us information on materials to use in the construction of the scale model of the sensor, and of how to go about producing.

Mr Raph Weyman, the Chief Software engineer at Graseby Medical. He helped by collecting us from watford station, when we went to visit the company and by showing us around after we had arrived there. He also helped us by looking over our ideas for the sensing device and by giving us information regarding the complexity and possiblity of certain ideas. He was also our link person in Graseby, and all faxes were sent to him. Later on, he helped by explaining in detail how a mouse or similar pointing device worked, and by helping us to choose an appropriate programming language for our control program.

Mark Bennett, the electronics engineer at Graseby. He was a past student at Beaumont, and also one who had benefitted from doing the Young Project Engineers course. He was helpful because he told us about the deadlines, and how to deal with them, and he also showed us around the Graseby building on the first day. It was useful for us to draw information from him at times when Raph was busy, and he was able to soothe our nerves about the up and coming project.

Mr T Pearson, the Physics teacher at Beaumont School. He was Kind enough to let us miss the odd one or two lessons when we were working in the Technology Block Designing and making the scale model.

Mr D Graves, The Father of Simon Graves, for providing some help while selecting ideas, and for providing the resources used whilst compiling the report.

Thanks to all who helped with the project, especially;
Mr Carter for all the advice he gave.
Raph Weyman and Mark Bennet at Graseby for putting up with us.
Mr Fernandez for finally not being able to help us, when we wanted it!
Mr Graves for the computer printer ink and paper!

This section is missing


First of all, the members of our team are:

John Finney
Stephen Penney
Simon Graves
David Edgar

John has been elected as team leader.

Our project has been set by Graseby medical, based in Watford. Graseby Medical is a reasonably small company, which has several departments. The department that set our project, manufactures infusion pumps, which are special pumps designed to deliver quantities of dissolved drugs into patients.

Our project, therefore, is based around these pumps.

There are two engineers in the company who are working with us. These are Raph Weyman, a Software Engineer, and Mark Bennett, an Electronics Engineer.

This section is missing


After we were given the design brief, we decided that the project should be divided into three main sections, which we would work on. These were:

1: The Flow rate sensor mechanism
2: The Computer interface
3: The Computer software


The design brief gave us an idea as to how the sensor should operate. However, this needed some clarification. After looking at the brief in detail, and after discussions with Raph Weyman, the Graseby engineer who set the problem, a list of specification for the sensor was formed...

The sensor must, to an accuracy of +/-1%, measure the flow of a liquid (any liquid which is free flowing) flowing along a small (about 1mm diameter) pipe.
It is purely coincidental that this pipe will be attached to an infusion pump, i.e. the sensor can't be based on some movement of the pump, just on the liquid output flow.
The sensor (and the rest of the system) should be able to measure flow rates between 1.0ml/hr and 1500ml/h (which are really quite slow).
The system should interface with the liquid low using standard leur fittings.
The sampling period of the liquid flow should not be greater than that which would allow 0.25ml of fluid to flow without a sample being taken in that time.
Ideally, the measuring hardware should not enter into the path of the liquid, so that the liquid could be a sterile liquid, which would not be contaminated.

Although these seem like very strict guidelines, we were told that this specification would be the totally ideal situation, and that it was not totally necessary to fully fulfil all the specifications.


This did not need to be described in such a detailed way as the sensor. However, to guide us in the production of an interface, we decided on a few of our own specifications:

The interface should convert information from the sensor into a format which could be used by an IBM PC or compatible.

This was because all except one of us has an IBM PC, and since it is the industry standard these days, it would make sense to go with this.(Not to mention the fact that the offices of Graseby Medical are littered with IBM PC's all over over the place!).What we didn't want was having to interface to, say, a Sinclair ZX81 because we couldn't find any ways to interface to a more modern computer.
The only other criteria was that it had to work, really, and produce an output which could be read by the software. This was a major part of the system, since without it the sensor would be useless, and the software wouldn't have anything to do.


The specifications for the software in the Design Brief were:

The software should be able to process the readings from the flow rate measuremnt system.
The Software should be able to produce a graph of flow rate against time, and also produce a trumpet curve graph (What is a trumpet curve? - See appendix B) for display and further analysis on the computer program.

As with the interface, the only other specification is that it should work, by whatever means, and produce the desired results; it does not matter, for example, what programming language it is writen in, as long as it works.

This section is missing


On the next few pages are some of the initial ideas we had, along with details of each design. Some of these could be seen to be instantly useless, but others were a little more promising and were looked at further.
All the initial ideas were faxed to our Graseby Engineer, Raph Weyman, to see what his comments on them were, and to obtain some constructive criticism, which helped highlight the better ideas from the really not-good-at-all.

+To Simon: +
+ First page = what is below this message. +
+ Up to fifth page = hand written ideas +
+ sixth page = Electromagnetic thing sheet +
+ Last page = what you find in INITI3.txt +


On the next few pages are some of the initial ideas we had, along with details of each design. Some of these could be seen to be instantly useless, but others were a little more promising and were looked at further. The ideas are (mostly) all based on some sort of sensor in the tube, which is connected at one end with the infusion pump under test.
INFUSION PUMP->-->-->-->--SENSOR->-->-->----- - -
(liquid flow)

The details given are details of the sensor involved in each idea, and also some indication of how this could be transfered into an electical reading which can be read by the computer is given.

All the initial ideas were faxed to our Graseby Engineer, Raph Weyman, to see what his comments on them were, and to obtain some constructive criticism, which helped highlight the better ideas from the really won't-work-ever ideas.


After looking at what to do about the interface and software in terms of finding a design for them, we decided that it would work best if we could look at these when the sensor design is finalised, since then we would know what sort of information will be recieved by the interface and the program.

[Several Handwritten Pages ommited]

initial ideas continued..

After having some input back from our engineer, we could decide which ideas would be worth thiking about further. Some of the ideas would work, but would be inaccurate due to the very small scale measurements which would need to be taken. For example, in idea number 7, using a flexible optical fibre in the flow, would require a large array of very small light sensors to pick up the minute movements of the fibre (remembering that the pipe diameter which would be involved would be about 1mm, the optical fibre would sway, probably, at maximum 0.3mm when under a very fast current).

Looking back, then, the ideas which were marked as useless (or good) were:
X 1: This idea almost cheated, because it measured something in the actual infusion pump. This was 'not allowed' because the flow meter should be able to work with any type of infusion pump (some, which we were shown, do not have syringe feeds). Also, the defect in the pump that we were trying to detect could be to do with the syringe used, as so it would not show up when testing the pump.
2: This was a hopefull idea, which could work, although because the resulting pressure differences would be small when working at low liquid velocities, the distance 'd' would be hard to measure. This could wor well if combined with another system, though.
3: This was also a hopefull idea, although the friction from the wheel may be a problem. It is certainly the simplest.
X 4: We were not sure if this would work or not, but even if it did then the movement of the membrane would have been hard to detect.
X 5: No, this wouldn't work; so that's that.
X 6: This may work, but friction could be a big problem, and the sensor would have to remain perfectly horizontal to work. So, er, maybe not such a good idea.
X 7: Same sort of problems as with idea 6, and, as mentioned earlier, the range of movements of the fibre would be very small, and hard to detect.
X 8: With this idea, there would be the same problems with measuring the distance the light would move as in 7. Also, there is no evidence that the refractive index of the liquid would change if it was travelling faster.

Electromagnetic Flow Rate Measurer:
Our engineer hadn't heard of this idea, and consequently couldn't give us any clues as to if this could be implemented, or even how it worked. Our physics teachers couldn't tell us anything either, so this idea was marked with a 'we couldn't use it' flag.

With the feedback from the engineer, he also sugested that we could use some sort of thermal marking of the liquid, to find the its velocity. However, we could see nothing but problems with this idea, and so it was abandoned.


After selecting the good initial ideas for the sensor, we had to elaborate on these, to produce several good designs which could then be thought about as proper solutions to the problem.

From the initial ideas, two ideas were feasible:

Using a Venturi, to produce a movement in a pipe which is proportional to the velocity of the liquid in the tube.


Using a water-wheel type arrangement, which would spin at a speed which is proportional to the velocity of the liquid in the tube.

The first idea, unfortunately, has several down-sides to it. One, as mentioned in the Initial Ideas, is that it will not give accuarate readings when the liquid is travelling at low velocities (if any reading at all). The lower limit, as set in the design brief, should be 1ml/hour, which is very slow. Using the Venturi based idea, this will produce as good as absolutely no output reading at all (even when at 1l/hour, not much of a reading will be able to be obtained since this is really quite slow too). Another problem is that when the liquid rises up the second tube, this liquid is removed from the flow, of water, until the speed of the liquid drops again, and the liquid flows back into the main flow. This creates a fluctuation is the very flow that is being measured for fluctuations, which would be a problem if the sensor was being used while connected up to a patient.

The second idea, though, using the water wheel, should be able to cope with all the velocities of liquid that can be given to it, since when the liquid moves, so does the wheel, so there is always some reading being taken. This is a good advantage over other methods.
Another advantage is the relative ease with which an electronic signal could be produced from the rotation of the wheel. From the axle of the wheel (which would extend to outside the tube) a disc could be attached to it, which could then be used to measure the speed of rotation optically. The disc would have to have slits or holes at regular intervals around the circumference, and an LED and LDR (Light Emitting Diode and Light Dependent Resistor) pair could be used to detect whether if, at a certain place or a certain time, a hole is there. Using the result pattern of holes and non-holes at certain times, the speed of the disc, and consequently the speed of the liquid, can be worked out.
The only, and major, problem with this method is the friction of the wheel. If the wheel does not spin totally freely, then the liquid will need to overcome this resitance before it starts to tuen the wheel, and the reading for the velocity will be slower than it actually is.

So, the second idea will be used. On the next page is a diagram to show how it will work.

On the facing page to this,
put the page of the file
and a new page after this.

Production of the Sensor.

Having thought about how we were going to produce the sensor, we have to think about the interface, and the software (more urgently the interface). Since the interface should connect the sensor circuitry to an IBM PC (from the specification), we looked at the back of one.
There are several connections that we could use...
1: The Parallel Printer port
2: The RS232 communications port (two of them)
3: The Mouse port

and that is it. Most interfaces which are used with computers are conncted to the RS232 port, since this has the scope to send and recieve information from the outside world. The parallel printer port can only send information from the computer, and so wouldn't be useful for this application, where we require information to be taken fomr the sensor. The mouse port also has the ability to take information, but it only deals with mice.

So, the choice for the interface would be a RS232 connection, together with the appropriate circuitry. This circuitry would have to perform the following:
+ Convert the signals from the LED/LDR pair into a stream of pulses
+ Convert these pulses into a byte of information which can be quickly sent to the computer for real-time analysis of the results.

This is what would be the ideal Situation.

However, after looking to finding circuitry (and failing), we decided that for the prototype we produced, we would have to find a simpler method.
We thought about using a different computer, but finally

This section is missing

This section is missing

This section is missing

This section is missing


This piece of software, written in Zortech C++, reads movement in the adapted mouse, and sends the readings to a file call DATA.DAT. The software works by detecting the position of the mouse, writing this to a file, adn then detecting the new position of the mouse. However, since the mouse position is only allowed to have values from 0 to 640 (one full screen sweep, if you are using the mouse normally), the values need to be manipulated each time the mouse reaches a value of 640, to still get an output result. The software has a sample rate of one reading per second. This needs to be known to calculate the actual angular velocity of the wheel. When the STOP button has been pressed, all the values are flushed to the file, and the program finishes.

This software, written in QBASIC, uses the values produced in the first program to work out the velocities of the wheel, drawing a graph, and it also uses these to produce a trumpet curve error graph (see display board). This software has not been calibrated yet, so it does not give actual velocities, since first it needs to be given a known, steady velocity to compare against the readings it gets.

As we were designing how we were going to produce the computer programs to recieve and analyse the information sent to it from the sensor, we were planning to write the entire program in Zortech C++, but soon discovered thatthis would be rather hard to do, and would take a long time, as we only had a basic knowledge of the language. However, we did all know Microsoft Qbasic inside out, and so decided to program in that. We had problems in that, as Qbasic has no mouse support, and so the receiving part of ther program would be impossible.
We then decided that it would be best if we did half the program in Zortech C++ (The half that receives information from the sensor), and the other (Analysing) half in Qbasic.
To run the program you need to run the first part first by typing:


You can then follow on screen insructions to receive information.
When you want to stop sensing, press the "STOP" button, which will terminate the program.
To analyse this data, you need to run the Qbasic program, you need to type:


You can follow the instruction on the screen toanalyse the data.

You can download some of the source code for this project here:

This section is missing

This section is missing

This report compiled 6th April 2005, by S W Penney