Bird observation system

A bird observation system is used by dedicated observers to track birds in specific and dedicated time slots/events. This first part is just a pilot to check how well this concept works. The system consist of thee parts. 1. Server that allows the observation data to be displayed in real time, i.e. with a maximum of 1 sec delay (given "normal" network conditions). 2. Client to run on a Sony Ericsson or Nokia cell phone (Midlet is assumed but I am open for suggestions). 3. PC simulator to test the server. The server software will be installed on a Linux server. The clients will fetch XML files from the server to allow easy configuration. Mora about this in the description. The system needs to be delivered with a full documentation. ## Deliverables Here is a specification of the three modules covered by this project. ** 1.1 CELL PHONE CLIENT DESCRIPTION** ** 1.1.1 Start page **At start up the client application (Midlet) list all observation events/slots available. The events are fetched from the server and displayed line by line in the client. The observer initiates an observation by selecting a line, and a specific session id is established. This id is used for identifying a command string sent to the server. ** 1.1.2 Tab 1 - Observation tab **In this tab the observer can enter a code for a bird type, it's age, it's color pattern, etc. For example the following sequence could be inserted by the observer and later sent to the server. #4*5*3# The meaning of this is defined by a XML file. # denominates the start and end of a code sequence. 4 could for example be defined as a falcon by the XML syntax. 5 could for example be defined as a color pattern by the XML syntax. 3 could for example be defined as an age estimate XML syntax. Note that the XML should be read by the Midlet on start up; hence the actual meaning of a code can changed relatively easy. In addition to the text GUI we have the following *softkeys* ([login to view URL]): **Send** - sends the code to the server, or buffers the date if no network connection is present. Each time the send is invoked the buffer should be flushed/sent. **Retract** - retracts a command. For example #4# would retract the latest reported falcon observation. Please design the XML language in a way that allows easy addition on all levels, i.e. bird types, attributes, tab data, tabs, etc. In the future we maybe need a code with five levels, i.e. #4*5*3*8*7#. ** 1.1.3 Tab 2 - Weather tab** In this tab the observer will have the possibilities to set a range of weather related parameters. These parameters are defined by the XML file. Commonly it would be temperature, how cloudy it is, rain, humidity, etc. Softkeys: **Send** - Resends all data. **Update** - Just Refresh the data that was changed in the client. **1.1.4 Tab 3 - Customized message **This tab is used for sending specific messages. One could for example insert the code: #4*Only one leg.# This would signal the rare observation of a falcon with only one leg. Softkeys: **Send** - send the inserted all data. **1.2 COMMUNICATION PROTOCOL** A simple protocol would, apart from the definition in the XML file, consist of session id, counter to track if we loose any messages (and need to improve the communication protocol) and a time stamp. Initially a XML file containing all the active observation events will be sent to the client. This is the data listed in the Start page. In addition a clock synchronization and a the version of the XML file need to be sent. If the client has an outdated XML file version, an automatic download from the server of the latest XML file should be invoked. By allowing this we can easily update all clients configuration file. One could also consider sending the the base station ID to track where the actual phone is broadcasting from. This can decrease the chances to fraud by just simulating the in field presence (observers are in some cases paid). This would be sent in the initial communication sequence. **1.3 SERVER DESCRIPTION** The server displays all the observations in a relative real time. Sometimes 1-2 seconds can be to much when correlating occurrences of various individuals, hence we need real time constraints to some extant. A head observer can A) create new monitor slots (field observation slots) and B) monitor all incoming observation events. ** 1.3.1 New observation** By choosing "New event", the head observer can create a new slot/event by entering a name, a date and time frame. The event will be assigned a unique session id and when the head observer press "Broadcast" this observation event will be added to the event page on the web server and the XML file all the clients download in the start page scenario. Now the field observers can start to contribute by observing in the stated time frame. **1.3.2 monitor the observations** By marking one or several of the ongoing slots/events the head observer can choose to monitor (look at) the field observations as they come in to the server. Each observation window is basically a ticker. On the top we find data concerning the event (name, date and time frame). Under this information the observation data ticks in. Last info comes in on top. If the head observer marked the monitoring of more than 9 (3*3 grid) observations a second tab with windows/tickers. An unlimited amount of tabs can be started, i.e. the head observer can monitor an unlimited amount of events. In each window, to the left, we see a small configuration window where the head observer can mark specific events of interest. The head observer can also set general events of specific interest that applies for all observation windows (if not suppressed in a specific event window). Let us say that the head observer if looking at tab 1. In tab 2 we have a window relating to a field observer that got sight of a rare white-bellied sea eagle. The head observer marked this even of special interest; hence the tab indicator flashes and the system sets of a sound alert (if not suspended) to get the attention of the head observer. At any give point the head observer should be able to add events, i.e. add another window to monitor. **1.3.3 Saving data** All events and related data should be saved in the database. A simple search interface allows users to search for a specific event/string of text. **1.4 PC SIMULATION DESCRIPTION** An observation simulator will create observation agents and more or less bombard the server with observations. This is done to test the systems capacity. The observation simulator in as simple PC application that connects to the server and lets the user mark one of several of the existing observation slots/events. Once selected the user press start and the observation simulator will start to send in the randomized (but realistic) code sequences with a randomized time interval. This time interval should be configurable in the observation simulator.