Introduction
We designed a multi-zone fire alarm system with a VT100-compatible user interface. The system is microprocessor controlled using the Mega32 microprocessor. The system communicates to the VT100-compatible user interface via a RS232 connection. A fire is detectable by a number of fire detection devices in each of as many as eight zones.
Screen shot of user interface during a Zone 1 alarm.
High-level Design
Fire alarm systems in commercial, industrial and large residential buildings can be fairly complex. Most of the fire alarm systems on the Cornell University campus are microprocessor controlled. The microprocessor will control the system for a particular building or part of a building, and report data back to a centralized computer. In Cornell's case, the centralized computer system reports data to Cornell's Environmental Health and Safety, as well as to the Cornell Police dispatch center.
We tried to design a fire alarm system which was much like the large systems discussed above. An Atmel Mega32 microcontroller was used. The system is capable of eight different zones. Each zone reports a zone alarm, or a zone trouble back to the microcontroller.
Overall Design
The maximum number of devices possible in the system is completely independent of the MCU programming. There are a maximum of eight different zones. Each zone is limited in the number of detection devices (smoke/heat detectors, flow detectors, pull stations) only by the zone circuitry. The system is customizable, so that zones can be enabled or disabled; all eight zones do not have to be in use at all times.
If at any time a device in the zone, or the zone itself becomes disconnected, or has another problem, a trouble condition is detected. This is reported to the VT100 terminal. As an extra failsafe, the time is reported to the VT100 terminal and always running. If the time ever stops being reported at the terminal, that would symbolize that the system has been disconnected from the terminal, or that another problem has occurred. An alarm is also reported to the VT100 terminal. The system can be set so that an alarm can be silenced so that the audible and visual alarms in the building do not go off upon an alarm. An alarm can also be triggered manually via the user interface.
The user can program customizable names for either the system and/or the zones. Additionally, the system can be password protected. The system password, customized names, as well as zone enable information, is stored in nonvolatile memory so that if the power is disconnected, settings will be saved.
Program Design
The program begins by using initialization code to set up state variables. Following that, Timer0 interrupts are utilized at 1 millisecond accuracy. The outputted clock is updated each second. Alarm and trouble pins are polled every quarter second that the clock is not updated. Additionally, input via the user terminal is updated once almost every 50 milliseconds. A glitch in the code allowed for extremely slow input to the system. It was found that the text was being polled every second, 50 milliseconds after the time was updated. This glitch was corrected and the code now runs smoothly.
Finite state machine diagram for user interface
EEPROM was utilized for the nonvolatile system settings (names, enable/disable states and the password). The very first time after MCU programming, initialization code is executed to initialize these EEPROM variables. It was found that standard C functions, such as printf could not utilize EEPROM strings and variables directly. This seemed to be the result of address space problems. Instead, an indirect method was created where strings were first copied into SRAM and then the SRAM variables were outputted to the interface. This indirect method was both more memory intensive and required additional programming, however it seemed to be the easiest and more reliable solution.
The VT100 standard was used to display the user interface. The standard allows for a variety of display commands and includes the ability to place text at different places on the screen, clear areas of the screen and change the way text is displayed (flashing text for example). This helped allowed us to have a clean, easy to read interface. Originally, Java had been considered for the user interface. This idea was abandoned due to software problems with the lab computers.
In order to produce clean, nearly artifact-free text display, the code had to be designed carefully and efficiently. The screen is only updated when required. Originally, this had not been the case and the cursor very visibly moved around the screen. This was solved by having flag variables and the like keep track of what needed to be updated on the screen, so that only those things would be updated; no unnecessary updates are made to the screen. This proved tricky at times and required careful coding. Displaying text to the interface was one of the most time consuming parts of this project.
A complier bug prevented the code from being properly linked and programmed to the chip. Unfortunately, when the compiler programs the chips for optimized speed, it can sometimes require a relative jump which is beyond the allowed PC. This happens when there are complex switch and if statements. This problem was corrected by recompiling the code with size, not speed optimized.
Hardware Design
Parts:
Amount Type
1 OpAmp LMC7111
1 10K Potentiometer
3 Visible LEDs (Yellow Green and Red)
1 7404/7400
4 330ohm
2 20Kohm
1 Infrared Detector
1 Infrared Emitter
Note: Emitter & Detector Radio Shack # 247-142
Typical smoke detectors use a phototransistor to detect the smoke in a room. The detector that we backward engineered had an emitter and a transmitter for a detection scheme working in the infrared wavelength. The emitter and detector are set in a certain position that when smoke is present the light diffracts from the smoke and the light is detected. For future reference this is the “A” set up. A typical layout of this is shown below:
Another way to construct a smoke detector is to put the detector right across from the emitter and when smoke is present some of the signal from the emitter is diffracted and the signal becomes weaker. For future reference this is the “B” scheme.
Both ways of detection can be implemented by the circuit designed specifically for smoke detection. The circuit runs in 3 modes; Normal, Alarm, and Trouble mode.
Normal Mode: Green LED
A) No Infrared is detected
B) Infrared is detected
Alarm Mode: Red LED
A) Infrared detected
B) No infrared is detected
Trouble Mode: Yellow LED
A and B) Occurs when the detector breaks or is removed
The following is the circuit diagram:
The LED to the left is an infrared emitting diode. The infrared is detected by the phototransistor and converted to a voltage. When first testing the phototransistor a 5 volt collector voltage was applied and an output at the emitter was measured. The measured output was close to 5 volts. If the infrared light from the sun is blocked from the phototransistor and a voltage close to 0 was measured.
The voltage just obtained by the infrared emitter at a distance of 3 centimeters length apart was around 2.1 volts. Varying the amount of exposure to the infrared detector we were able to detect a voltage of a volt when the detector should be tripped. This is when about half the single is transmitted and the other half is blocked by smoke.
To determine when to go from the normal state to alarm state an operation amplifier was implemented to work as a comparator. The input to the comparator is the phototransistors voltage at the emitter. This voltage to which the emitter is being compared to is at V- of the op amp. The output is either +5V, if the input is higher than the compare value, and 0V if it is smaller. The sensitivity of the detection is controlled by a potentiometer which changes the voltage at which the alarm changes state.
Depending on if scheme A or B is used while the normal LED is on the alarm LED is off and when the alarm LED is on the normal LED is off. To accomplish this from the one output from the op amp an inverter was used to invert the voltage and have it going to one of the status LEDS. The trouble output is taken from the infrared emitting diode to ground. If the detector is removed this would cause an open circuit. The LED turns on when this occurs.
For testing purposes both A and B schemes were implemented in lab and tested. A photo of the circuit is below:
The clear looking bulb shaped parts are the phototransistors and the blue bulbs are the emitters. Ideally the smoke detector structure would be built in a way which enclosed the emitter and the detector but time constraints and wiring issues made this a hard task to complete. Also, since we are not allowed to start fires or smoke up the lab testing the alarm voltage cutoff for the phototransistor was guess work rather than experimental. The potentiometers should be adjusted in real world application to achieve the correct sensitivity.
The outputs of the detectors created in lab are inputs to the fire detection software.
System Operation
Main Menu
1. Silence System/Zone - The system could be silenced so that any alarm in the system, or an alarm occurring in a specific zone would not trigger the system's public address devices (such as alarms, strobes, etc. in the building). Instead an alarm state would be reported to the console notifying the user that there was an alarm. This feature would be useful if there was a problem with a detection device or a number of detection devices in the system falsely reporting alarm conditions. It is also useful in the even that fire personnel were going to be standing by in the building for an event or other special purpose; they could be directly notified of the alarm condition and take assess if a building evacuation was warranted.
2. Setup System - This feature allows the user to configure the system. The setup system feature can be protected by a five number password set and changed by the user. The factory default password is 12345. The system name and zone names are customizable by the user. These should be set to meaningful names such (for example, for a zone "East wing, 3rd Floor"). Zones may also be enabled and disabled; although the system supports eight zones, any number less than eight may be used. The time can also be set from this menu. 24-hour time format is used by this system as it is the standard for emergency personnel.
3. Reset System - Resets the system's alarm state to no alarm. This is the only means of returning the system from an alarm to a normal state. In the event an actual fire is first reported as an alarm state, and then damage is done to the fire detection device and the zone goes from alarm to trouble, the system would remain in alarm.
4. Alarm System - This sends the system into an alarm state even if all zones are reporting a normal state. This is useful for fire drills or if a fire is reported to a dispatcher via telephone and an evacuation is warranted.
Results
Our results were very successful. We were able to build a working fire alarm system much like the ones in large buildings.
Safety was a big concern of ours. We used no more than 5 volts in our system at a safe current ensuring that electrocution was not a concern. Additionally, there were no mechanical or other devices which could provide harm to the user. The system was designed with several fail-safes so that a zone disconnection would be noted by the user. The user should therefore be aware if the system is rendered useless and a building is without adequate fire detection. Additionally, in the event of an alarm, the user interface beeps until the alarm is acknowledged. This feature could be very useful in a busy dispatch room where only a visual notification would go unnoticed.
Interference with other projects was not really an our fire alarm system. There are no wireless circuits and the circuit was at a low DC voltage, the interference with other projects is probably less than the interference caused by the fluorescent room lights.
Along the same idea of safety and interference, an actual alarm could have been implemented without very much difficulty (via standard buzzers/sirens available), however, we chose not to for the sanity of those around us. An audible alarm was a concern presented to us by several TAs.
Our clocking code was found to be very accurate. Theoretically, the accuracy of our design is dependant on the accuracy of the microcontroller interrupts. In testing, the time was found to be accurate when compared with a clock.
The system was designed with usability as a top priority. The VT100 specification allowed for accurate text placement. In addition, features such as flashing that the system was in alarm, along with beeping the console, provided for increased visibility to the user during alarm states. The user interface uses numbers and the system is customizable by the user so that zone and system names are easily read and understood by the user.
One thing that was tried in the development stage was to use a 24VDC detector system using detectors obtained by Cornell's Environmental Safety (please see acknowledgements). Unfortunately, due to a lack of documentation, this was abandoned and the detector circuits were built from scratch using concepts similar to the commercially produced smoke detectors.
Conclusions
Our results did meet our expectations, with the exception of the 24VDC detectors. We had spent a large amount of time trying to get the system working and eventually had to abandon the 24VDC system and build our own system. In retrospect, we probably should not have wasted so much time on the 24VDC system and went sooner to the homemade system.
The coding was done completely without the use of outside code; all code was written by our group members. The analog circuit was also designed by group members without outside assistance. The 24VDC system was being reverse engineered with the help of EH&S personnel.
This project was done completely by group members and no outside code or circuits were used. Therefore, University ethics were not violated.
Screenshots
System in normal state, zones disabled
System in manual alarm state
Zone 1 alarm, other zones disabled
0 comments:
Post a Comment