The University of Queensland School of Information Technology & Electrical Engineering ENGG3800 Semester 2 2011 Product Specification v1.

0 Stolen vehicle alarm and tracking system

Note: This specification is subject to clarification and change. Overview: Your client requires a complete solution to track their fleet of high-value bicycles and provide an alert when a bicycle leaves a defined region. The system will consist of hardware to be fixed to the bicycle, radio telemetry and a PC based software platform to provide the central monitoring and display the position of the stolen vehicle. GPS positioning will be the basis of location determination. Constraints and provided equipment will be defined below. A demonstration will be basis of the product evaluation in combination with assessment of overall design, hardware layout, workmanship, software quality and software operability. A mid-project review consisting of an oral presentation and demonstration of progress is to be delivered at a time determined by the client (during week 7 of semester). Outline of Specification This document is divided into the following sections describing the requirements for each component: Alarm trigger and GPS transmitter, Demodulator and PC interface and, PC software and notification system, Level B additional features, and Level A additional features

Alarm Trigger and GPS Transmitter A hardware system to be fixed to the bicycle will consist of a defined GPS module which will be configurable to provide continuous digital output of position and time/date stamp. Relevant information extracted from this data stream will be transmitted via a provided UHF handheld transmitter. A fixed frequency within the citizens radio service (CRS) band will be used. The only connection to this device will be via an interface to the manufacturers microphone input, audio output and push-to-talk (PTT) sockets. RF power output (1 watt) will be adequate for localized testing. It is expected that an embedded system based on the Atmel AVR range of microcontrollers will be used to interface to the GPS module, extract relevant data, modulate or control the modulation of an audio signal suitable to be input to the UHF transmitter. Position updates should be transmitted at least once every 60 seconds. This processor will also control the PTT input of the transmitter. Receive functionality will be available if required for signal integrity or if needed for an advanced feature. All transmissions must abide by the Radiocommunications (Citizen Band Radio Stations) Class Licence 2002 (as amended) with regard to data transmission in particular the permissible duty cycle of such transmissions.

When the movement alarm is enabled (on the PC) then any movement of the bicycle greater than 10 metres from its fixed position will trigger the alarm (on the PC). The detection method for this function is unconstrained it need not use the GPS data. The system will be powered by two AA dry cells and a battery life of 8 hours is expected when in idle mode i.e. not actively transmitting. The UHF transceiver will be powered by its own internal battery and is not able to share power with the processor board. Your system must provide a single power switch, an LED power-on annunciator, and an LED transmission annunciator (which should be illuminated when a transmission occurs). The Alarm trigger and GPS transmitter will be constructed in a double sided FR4 PCB of defined size. This board will contain the GPS module and battery in addition to your circuit. Four holes for board mounting will be defined by a provided .pcb file and keep-out regions must be adhered to around each hole on both sides of the PCB. Demodulator and PC interface A fixed base UHF transceiver will deliver received audio on the fixed CRS frequency. A demodulator or decoder circuit is required to deliver a digital representation of the received signal from the Alarm trigger and GPS transmitter. Similar to the remote device, the microphone in, audio out and PTT will be accessible to the design team. The transceiver will be powered independently to your demodulator and interface. Your system should be able to automatically support a range of volume settings on the audio output of the transmitter. The interface to the PC on which the alarm functionality and position display will be implemented is via USB. Power to this device is also to be provided by this bus. Default maximum supply current from the PC may be changed if appropriate. PC Software and Notification System The display of alarm status and live position updates will be provided by a PC. The PC software (running on the standard Windows lab computer) must be a server which communicates with the USB interface to the receiver and provides its user interface via HTTP on port 80 to one or more web browsers (which may or may not be running on the same PC). The browser interface must display a zoomable map (implemented using a Google Maps API) showing the current location of the bicycle and which tracks the bicycle as it moves (i.e. adjusts the map so that the bicycles position is always shown on the map). Position updates should occur at least every 60 seconds. The browser interface must also provide the alarm functionality: being able to turn the position alarm on and off and sounding the alarm (sound and visual indication) when the bicycle moves outside the 10m region defined when the alarm was switched on, or when data is lost (no data received in some defined transmission window). The 10m radius circular region must also be shown on the map. It must also be possible for the user to choose any point on the map and obtain the direction (compass bearing) and distance of the bicycle from that position in order to permit an efficient means of apprehending the thief. Different browser sessions connected to the same server may show different maps and have different alarm settings. The server (and any associated helper programs and packages, USB interface drivers etc.) must be able to be installed by a single installer program on standard laboratory PCs.

Level B Features Multiple transmitter capability The system must be able to handle transmissions from multiple bicycles. This requires: transmissions must include a bicycle ID and the provided transmitter must provide a means for easily switching between at least four different IDs to allow this functionality to be tested the user interface must allow alarms to be individually enabled for each bicycle and separate bearings/distances to be shown from some selected point when alarms are triggered the user interface must allow selection of which bicycles are tracked (i.e. have their positions shown could be one or many) and must (a) be able to distinguish between bicycles, and (b) reposition the map automatically to ensure all selected bicycle positions (and alarm circles, if enabled) are shown on the map as the bicycles move

Archive and replay The system must provide a means for bicycle positions and timestamps to be archived in a database as they arrive at the server. The browser interface must provide a means for replaying the archived path (position points joined together) which a bicycle took over a user-selectable time-period at a user-selectable replay speed ranging from real-time to 100x real-time. (The points should be displayed as well as the interpolated path.) For testing purposes, when the server application is installed, the database must be initially populated with suitable dummy data (at least one weeks worth) which enables this functionality to be tested. (New positions and timestamps will be added on top of this.) If the multiple transmitter capability is implemented, then this feature must include the ability for a user to select which bicycle path to display, or permit all paths to be displayed. Quarantine / out-of-bounds handling The user interface must provide a means of defining a collection of arbitrary polygonal shapes as the alarm or non-alarm regions for a bicycle. The shapes will serve either as the regions into which the bicycle is not permitted to enter (in which case the alarm will be activated if the bicycle enters that region) OR as the regions in which the bicycle is permitted to be (in which case the alarm will be activated if the bicycle is not in one of those regions). (Adjacent or overlapping regions should be treated as a single region.) The map display must include the display of these region shapes as the bicycle is tracked and the map is zoomed etc. If the multiple transmitter capability is implemented, then this feature must support the ability to define different regions for each bicycle. Different users (i.e. different browser sessions) must be able to define different regions for the same bicycle. Server authentication and third party notification The system must provide support for user accounts on the server users must be required to login via the browser before accessing position information. Login via an OpenID account must be supported. One local user account must be designated an administration account and this user account is permitted to add other users to the system. The username and password of this local administration account must be able to set during the server installation process.

It must be possible for each user to configure the server about notifications which are sent when an alarm event occurs. The server must use some means of persistent storage (file or database based) which enables these preferences (and user accounts) to be stored and available if the server is stopped/restarted (e.g. due to a power outage). Notification options to be supported are: Email. It must be possible to specify an SMTP server and destination email address to which the alarm messages will be sent. Twitter. It must be possible to specify Twitter account details and a #tag which will be used to send a tweet when an alarm event happens.

Users may configure each notification method separately. Each message sent must include the last known coordinates of the bicycle. Messages are only sent by the server when the alarm condition is first violated. Messages will not be sent again until either (a) the alarm is disabled and re-enabled and the region constraint is violated, or (b) the bicycle returns to a valid region and then violates the region constraint again. This feature will require alarm status/regions to be stored on the server not just a feature of the current browser session. Alarm status/regions must be able to be set and stored on a per-user basis. Level A Features SD card trip-logger (Prerequisite: Archive and replay feature above must be implemented.) The system must support an SD card interface on the transmitter into which an SD card can be inserted. (The SD card itself need not be budgeted for and will be provided for demo purposes.) Timestamped positions must then be logged to the SD card at least every 30 seconds. When the SD card is inserted into a suitable card reader on the server machine, the server must automatically detect the insertion, read the appropriate file(s) from the card (if present), populate the database with the trip data, and then delete the relevant file(s) from the SD card. The data must be appropriately merged with any position data already in the database from that bicycle (i.e. received via radio). The system must gracefully handle various capacity cards, non-writable SD cards and SD cards that fill up. It must be possible to replay the path. Bi-directional communication alarm and error correction (Prerequisite: Quarantine and out-of-bounds handling.) The system must implement bidirectional communication, i.e., the PC server side must be able to communicate back to the bicycle and implement both of the following: A bicycle-based voice-synthesized alarm. When any alarm event happens for that bicycle (based on alarm regions set by any user) then the bicycle-mounted part of the system must sound an alarm in the form of an appropriate voice message. Message error detection / handshaking. The system must implement a suitable handshaking protocol to ensure reliable transmission of all position information. The bicycle side of the system must be able to buffer at least 5 minutes of position information and regularly attempt transmission of this data until error-free receipt is confirmed.