The construction is proposed of a ``browser'' for Greek NT texts. This would be a tool, perhaps similar to Adobe Acrobat, which would allow the user to navigate the Greek text. The programming task is essentially that of implementing a word processor, except that - unusually for word processors - this one has read-only access to the text. (Changing the NT is frowned upon!)
Some of the groundwork was done by Matthew Calamatta, whose project report  explores some of the issues. Matthew chose to use Java, and the present project would also use this language in order to make a browsable Greek NT available over the World-Wide Web.
The following are among the problems which have to be addressed: the efficient storage of text; efficient indexing; portable rendering of Greek fonts; efficient client-server partitioning and protocols.
The program should be extensible to allow the later implementation (not in this project) of tools which might be useful to scholars: automatic concordance generation; analysis of parallel passages in the four Gospels; automatic generation of variant readings; correlation of Old Testament quotations; etc.
A familiarity with the Greek alphabet is required, but beyond this no knowledge of Greek is expected.
It has been suggested that the Smalltalk user interface components might be a good starting point for your design.
This is a design project. You are not expected to implement the interface you design, although clearly you will discuss implementation issues in your report. Because of this limitation of scope, the design is expected to be very thorough indeed.
Mkfilter designs infinite-impulse-response filters. The user specifies a ``shape'' for the response curve by choosing from a fixed set of alternatives: Butterworth, Bessel or Chebyshev; low-pass, high-pass, band-pass or band-stop.
This project proposes the design of a finite-impulse-response version of the mkfilter web page. The usual approach to designing FIR filters is to specify a response graph of arbitrary shape numerically, together with a set of tolerances. In other words, one says (for example) ``I want the response at 1 kHz to be -3 ±1 dB'', and similarly for a number of other spot frequencies. There are well-known methods for designing an optimum filter which fulfils the specification.
The main distinguishing feature of this project is the input of the response graph. Whereas the existing mkfilter page allows the user to select from a fixed set of alternatives, which suffices for an IIR design, to design an FIR filter it is necessary to allow the user to input the response graph directly. This project proposes the use of Java for this purpose.
The project will interest the student with a mathematical bent, who is at home with complex algebra, and who intends to take the DSP module.
The design of a PLL is seen by some as a ``black art'' whose technicalities make even seasoned engineers turn pale. What they need is an expert system to guide them through the choices. Complete this project successfully, and you will have earned the gratitude of all who have ever wrestled with the standard work on PLLs  and its successor .
I should like the end result to use a World-Wide-Web form-based interface, similar to that used by my own digital filter design package.
An interest in artificial intelligence and human-computer interfaces would be a disadvantage in completing this project. Mathematical competence is essential, but a deep or broad knowledge of Computer Science is not required.
The making of oboe and bassoon reeds is a skilled business. Minute quantities of cane are pared from the reed, using a special knife; and the reed is ``crowed'', or blown in a particular way, at frequent intervals to see what effect the scraping has had. The reed-maker uses his or her experience to judge where to scrape: as one bassoon reed-maker said to me recently, ``I blow it, and then I just know where to scrape!''
The aim of this project is the construction of software to help the maker of oboe or bassoon reeds. The software will run on a Silicon Graphics Indy workstation, and will use the audio input facilities of that machine. To use the system, one would ``crow'' the reed into a microphone. The processor would analyse the sound - possibly computing its spectrum - and suggest an appropriate place to scrape. The device would be ``trained'' by recording and analysing the sound at many stages of scraping, so building up a picture of what effect a scrape at a particular place on the reed has on the sound. The device could then suggest where to scrape in order to approach the sound of that mythical object, the ``perfect reed''.
This project would ideally suit a student who plays the oboe or the bassoon.
What I have in mind is a large box which sits in the middle of the circle of players. On the top of the box is a large pointer (say 2 ft long), like a weather vane, which swings (driven by a motor) to point to the offending player. At the end of the pointer is a display which indicates to the second oboe whether he or she is flat or sharp. An arm, say 3 ft long and perpendicular to the pointer, carries a microphone at each end. When the pointer is pointing at the second oboe, the sound signals from that instrument arrive simultaneously from each microphone. By measuring the Doppler shift of signals from the two microphones while the pointer is swinging, and carrying out some clever digital signal processing, one can isolate the contributions of each instrument, and so tell whether each is in tune.
The software will be written in C and will run on a Silicon Graphics Indy workstation, whose stereo audio input facilities would be used. The ``weather vane'' device will be designed by me and built by the Department's hardware technicians. It will be controlled by the Indy via an RS-232 port.
Alan Wood has pointed out that, from a theoretical point of view, tuning a chord is a fixed-point problem: one takes a chord and makes an adjustment to it; that gives a second slightly different chord, to which one makes a further adjustment; and one hopes to converge eventually to a solution at which (fixed) point ``improvement'' is the identity operation.
The aim of this project is:
Alpha is written in C++. A working knowledge of C, and a willingness to learn the necessary modicum of C++, will be required.
A radionavigation system allows a user to determine his position on (or above) the earth by receiving and comparing radio signals from several transmitters. There are two types of radionavigation system: satellite-based (e.g. GPS) and terrestrial, of which Loran-C is the best known. ``Terrestrial'' here simply means that the transmitters are on the surface of the earth. General information about Loran-C is published in several text-books, e.g. , and the paper by Frank , as well as giving a useful synopsis of Loran-C, contains a large bibliography.
In January 1995 a new chain of Loran-C transmitters, the Northwest European Loran-C System (NELS), was commissioned. Coverage in the U.K. is excellent, an accuracy of ~50m being readily attainable.
You will construct a Loran-C radionavigation receiver, of conventional design, using an MCP 64180 development board.
Output will be in hyperbolic coordinates, because the conversion in real time from hyperbolic to (e.g.) Ordnance Survey coordinates is probably beyond the capabilities of the 64180. The design will entail a large amount of 64180 assembly language programming, and a certain amount of analogue radio-frequency electronics design. Don't be put off by the latter; you can base your R.F. design on my own circuitry . Culver's paper  gives a readable description of the conventional receiver architecture.
If you are successful in completing this project, your receiver will be used as the basis for final-year projects in future years. Because of this, it is important that you document fully all aspects of your design.
The Iridium system is a satellite-based, wireless personal communications network designed to permit any type of telephone transmission - voice, paging, fax or data - to reach its destination anywhere on earth.
To complete this project, you will construct a model of the Iridium system in the hardware laboratory, using infra-red links instead of radio links. The ``satellites'' will be suspended from the ceiling, in ``low laboratory orbit''. They will communicate with one another and with the ``ground stations'', each of which will have an interface to a standard telephone. Standard call progress tones, ringing, etc. will be employed. As far as possible, the protocols and techniques used will be based on those used by the real Iridium system, but some scaling down will be required to match the small scale of the hardware.
To make this project reasonably realistic, I propose the construction of two satellites and two ground stations. You will design and construct all of these, using the MCP 64180 development board as the basis for the hardware for the ground stations, and possibly for the satellites. You will be expected to develop the system to the extent that a user on one ground station can call a user on the other and conduct a conversation.
Osmium is the element just below iridium in the periodic table of the elements.