Get Firefox!

Project planning information, Technology upgrades

We need to bring our fire departments into the 21st century. We are far behind the technology curve. Here are some links worth reading that we may want to pursue. If you can help us in any of these project areas, please , thank you.

Some of these links are new software projects in need of some love.

  1. http://www.azchiefs.org/technology.html
  2. http://www.govtech.net/[...]/index.phtml
  3. http://pad-prg-mgt.sourceforge.net
  4. http://sourceforge.net/projects/opennfirs
  5. http://sourceforge.net/projects/opendisp
  6. http://www.nfic.org/[...]/nfirs5_0splash.html
  7. http://www.nfirs.fema.gov
  8. http://e-gads.sourceforge.net

One of the ideas we have on the table is adding a cellular text messaging capability to the current dispatch method. Our Motorola Minitor II based paging system is antiquated and prone to inadequate signal strength and limited range. By capturing the dispatch messages sent via the public domain LPR/AppSocket protocols (UNIX™ print system), filtering them for sensitive information and routing, then transmitting them as text messages to cell phones, we leverage the current technologies of the communications industry to our distinct advantage. Update: we now have our dispatches sent over our phones and we've come to rely on its considerable usefulness.

Open Source icon

All of our technology solutions must incorporate an Open Source solution. That is to say, the software behind the project must provide the source. Please visit open source™ for a study on the ideals of open source. I as the site maintainer and gadget guru strongly desire to keep everything Linux based. Well written software will run on a variety of platforms as well as Linux.

My intent is to have a Linux based network to provide all the project services and features. The web server is Apache, and the software generating dynamic pages will be a mixture of PHP and C. The relational databases supplying site data are built using PostgreSQL. Software that is intended for web based interaction will be PHP based. Software such as the CAD message router mentioned below will be written in C. All software written for this website will be licensed under the GPL license. This means that the source code will be freely available to everyone.

If you can help us with technology, software, time, or with other donations, we would greatly appreciate it. Let me say we would greatly appreciate this. As a volunteer fire department, our financial resources are very limited. Our advances in technology will be mostly supported by our own hard work and come out of our own pockets. The community directly benefits from this as our responses become faster and more accurate.

If you have any suggestions, comments, or critiques, if you have any references to software or software vendors that you think would help us then by all means . Please keep in mind, we're not rich. Like most volunteer departments, we run on little more than a shoestring budget and the current economy isn't helping much.

People and agencies that are involved in getting their departments up to speed.

Please see this page of resources that we are developing.

Phase I

(Some sections withdrawn until reviewed.)

  1. checkmark Capture filtered dispatch messages and route them to firefighter pagers, cellular phones, email clients, AIM, and SMB popups or et cetera as plugins are developed.

    For patient confidentiality reasons, the information broadcast to cellular phones and pagers may be filtered for sensitive information and distribution may be limited. The intent of this dissemination method is to ensure reliable delivery of dispatch information to authorized firefighters. This information is not for the general public. To receive this information, you must be an active firefighter with the South Meriden VFD, City of Meriden Fire, or have permission from a respective SM or MFD chief.

    The dispatch events are sent using the UNIX™ LPR system. No reverse engineering needed; the LPR protocol is fully open [ref: http://www.faqs.org/rfcs/rfc1179.html] and widely known. Events are captured, restructured as needed, stored in SQL, and dispatched to cellular phones and/or text message devices. Current methods are by way of text messages to cell phones and emails. More coming soon. This information is also used to provide data for the real-time incidents page (link temporarily removed). The site for this software can be found at http://fireground.org/DispatchBuddy/.

  2. checkmark Real-time status page on the website indicating current incidents

    This is a mostly informational help to firefighters and visitors to the website. This project depends on the successful implementation of the software which integrates with the CAD software. Visit the real-time incidents page.

  3. Status page also includes current vehicle locations

    We now have incident data but until we have GPS in our vehicles we won't be able to display vehicle location.

  4. Capture Audio of our dispatches and broadcast it over the internet

    Here we simply need to setup a radio scanner (done), computer with sound card (need a PCI sound card), and the appropriate software to do the broadcasting (icecast on linux). This isn't going to be to difficult I understand but bandwidth will probably be our biggest concern. There has been significant interest shown from people wanting to listen to it and from the other fire departments in the area also wanting to jump on the bandwagon. Streaming audio costs bandwith. If you have some bandwidth and would be willing to act as a reflector for this audio content, please .

    This streaming audio is for public consumption. You and we are required to respect the appropriate laws regarding the listening to and dissemination of emergency traffic by way of radio.

    I am currently investigating Icecast on Linux. What I need is a variable bit encoding software that only sends data when there is actual audio to listen to. This will save bandwidth significantly. I simply haven't had any time to devote to this. If somebody has a simple solution for this please let me know. I have two channels of audio that I want to encode, one goes to the Left side, one to the Right side. The broadcast needs to not send any stream data except markers/keep-alive data when there is no significant audio signal.

  5. Establish a database of GPS Lat/Long for all hydrants in the SMVFD district

    We are searching for someone with a high resolution GPS tool. If anybody can loan us such a tool for a couple days, we would really appreciate it, we would even be happy to keep our paws off your equipment and just feed you lunch and dinner. smiley We currently have a Garmin GPS 12 handheld, but it's accuracy is about 15 meters, or roughly 49 feet. Draw a circle around you 25 feet out, and you'll see how inaccurate this is if you have four feet of snow on the ground. We need to drill this down as much as possible. We want to be able to locate a hydrant in the middle of a heavy snowbank with as much accuracy as possible. Reminder, the Selective Availability (SA) imposed by the US Government was shutoff in May of 2000.

    Naturally the equipment that manages true sub-3m accuracy is pretty pricey, several grand per device. If you have information on where SMVFD might be able to borrow or rent, we would appreciate it. We do have the option of inpterpolated accuracy which is only a couple hundred per device. This yields a similar sub 3 meter accuracy. This is possible with the WAAS features. However, I do not know if we can acquire the WAAS signal in Meriden.

Phase II

  1. Acquire high resolution photo maps in TIGER, DER, DEM, DLG formats etc, as applicable and appropriate for software in preparation for GPS and GIS projects
  2. Acquire software URLs, whitepapers, etc for the GPS and GIS projects

Phase III

  1. GPS and GIS online maps aboard fire and rescue vehicles

    Much less error prone response to incidents by providing a direct path to the incident from the fire station on the display of an onboard computer. In addition, data might be relayed back to dispatch to keep them appraised of vehicle location.

    These maps will have streets, waterways, and simplistic building line art. Complementing these maps will be overlays for water supplies, hydrant locations, hazard locations, hazard annotations, etc.

  2. Draw up integration plans for keycard or RFID tag entry system and the webserver.

    The goal here is to have the computer system pre-fill run form data to ease the workload of the responding firefighters and increase the accuracy of the report data. This isn't a big brother system and nothing will be put in place to enforce accounting for location.

    If possible, an RFID monitor will be onboard the vehicles as well which will automatically identify firefighters on board. This system will be tied into the station system so the inhouse server knows which firefighters have responded.

Phase IV

  1. Integration of GIS data with GPS data in onboard modules

    We want to overlay geospatial pictures (satellite pictures) with mapping data to match up structures, hydrants, streets, etc. This will enhance our capabilities significantly. We want to be aware of what kind of area we are responding to, what resources are there, what MSDS sheets are attached to this structure, etc, etc. We want to to be able to plot a pictoral path from the fire station to the incident scene while avoiding known issues such as road work, other incidents, etc.

    Wouldn't it be nice if your firefighters knew that the building next to the one that is burning was full of highly toxic fuels that needed extra attention? How about their being aware of all the hazardous materials within the building that's on fire? Knowing the dangers, knowing the layout, knowing the scene, all of these things are very important to a firefighter and the more he knows, the more quickly and safely the incident can be resolved.