Saratoga County Advisory Board Rip and Run Presentation

  Wednesday, September 30th 2009

I gave a presentation to the Saratoga County Fire Advisory Board regarding all the work we have done in the GFD extending the dispatching capabilities of our volunteer responders.

This is commonly referred to as the "Rip and Run" system, but perhaps, and more importantly, it should be referred to as an "extension" to the county "Rip and Run" system - as all of my work has been focused on extending its capabilities. I commonly refer to all this work as the "Rip and Run" system collectively, just because its easier to do.

Essentially I gave a very brief overview of the various efforts we've been doing here in the GFD: text messaging, voice-dialing, email and AIM instant messages - which have all been highlighted here before. But what was "revealed" for the first time during this presentation was the next step of this effort - and that is the "Rip and Run Display" initiative.

Currently in Saratoga County, there is no ability to add any automated GIS capabilities to our dispatching protocols. Many large municipal departments (FDNY, Chicago, Los Angeles, etc.) have these types of systems - because they can afford them due to their large budgets. In Saratoga County however, our volunteer departments do not have the ability to spend that kind of money to purchase these types of systems.

Fortunately, there are free tools which provide acceptable (i.e. accurate) GIS capabilities - and if you have the skillset and capabilities - its really just a matter of putting them together to create a new product - one that we can use to enhance our dispatching.

Essentially, in developing the "Rip and Run Display", I wanted to provide the following four capabilities:

1. provide GIS capabilities: map and illustrate the exact location of the given emergency on a map and computer display. The obvious advantages of this are that you can easily identify where the incident location actually is. And if you think about this some more, you can easily identify just how significant this can be - for example, while I may know where a given road is, I do not necessarily know where the "123" address is located on that road. This could mean the difference between turning right or left at an intersection, a mistake that can cost precious minutes during an emergency.
2. provide driving directions: all departments participate in the County Mutual Aid plan, so its not unheard of that a northern Saratoga department gets called for help to a southern Saratoga department - or vice versa (this is particularly true during the bad weather season like during ice storms, etc.) I'll be the first one to admit that I couldn't begin to tell you where a given road was 6 districts south of me (and 20 miles away). Having the ability to print driving directions to a given address provides a significant advantage for mutual-aid calls.
3. provide pictures of destination (a.k.a. "street view"): its not hard to imagine the advantage to a responder that we are looking for a yellow house with green shutters rather than "123 Lincoln Blvd"
4. provide hydrant mapping capabilities: using a standard GPS unit (<$100) I was able to acquire the latitude and longitude for the majority (I am admitedly missing a few) of the fire hydrants in the GFD. Naturally, having a map with the specific locations of hydrants when you are responding to a fire provides a significant advantage when fighting a fire.

Here is a screen shot of the "Rip and Run Display" in action:

In the screenshot above (and you click to see a larger version), you will note a few interesting features of the system:

1. First and foremost, all the data from the county is readily displayed - things like the county run number, dispatcher notes, the call type and location.
2. There is also a call history listing (located on the left) so that a firefighter can query the system to see the last calls. The idea here is that if there was a previous call at the given location, you could possibly pull up information from the last time you were there - which could indeed be relevant.
3. The hydrant functionality is displayed in this screenshot, you'll not the "push pin" icons displayed around the various buildings in the "satellite" view.

But this just the beta version of the system, which is naturally due to change in the future, and I hope to begin field-testing by the end of the year. One final note, I am also experiementing with alternate layouts of the screen - based on available resolutions of the given monitor. You'll note that the current screenshot is in more of a square (traditional) monitor resolution - but "widescreen" monitors are becoming more and more prevelent, and so the layout of the display should take advantage of the extra monitor real-estate.

The ultimate goal of this project is to provide a "computer display" in each firehouse and ambulance company throughout the county. With current computer technology, the use of "touch screens" is becoming the norm, and this makes keyboards and mice (for the most part) unnecessary.

So a properly designed computer system with a touch-screen can be very intuitive, even for those who ordinarily wouldn't consider themselves "computer literate".

For example, a button on a screeen labeled "print directions" is both pretty self-explanatory and easy to use. And these computers are becoming very cheap - in fact, Dell has a variety of these types of computers starting at just $700.

So what has traditionally been out of reach for "rural volunteer fire departments" simply because of the cost ($$$) factor, has now become cheap and available - which was a very strong point I tried to focus on during my presentation.

You can download and view the presentation here:

1. Saratoga County Advisory Board Presentation (09-28-2009) (.ppsx 4.3Mb)
2. Optional (if you don't have PowerPoint): Microsoft Office Powerpoint Viewer

Eventually, I have a (hopefully relatively soon) goal to get up a "rip and run" section on this site - to more specifically go over the particulars of how my software works and it's design.

I am now actively investigating the potential to get this system installed at the county level - so that all fire and ems agencies in the county can benefit from the work that we have been pioneering in the GFD. More on this as details become available...

Any questions, just let me know.

posted by spackmann in Rip and Run Development at 10:45 PM (302 day(s) old)  Permalink

SMS Text Messaging Testing Update

  Thursday, August 6th 2009

In the short period of field testing, I have found a few minor bugs which I am working on fixing - but these are relatively minor.

A few points however worth mentioning:

1. As we depend on Twitter for our text messaging - the "free" price comes with a dependency. If they are down, then our text messaging won't work. As reported in news reports on TV, radio and online - today Twitter was the subject of a Denial of Service Attack.
   
   You can follow Twitter's progress online:
   
   http://status.twitter.com/
   
   It's an important point to make that our stuff won't work if Twitter isn't working. While this is an important condition to keep in mind regarding the text messaging system in place, service disruption is something that happens to all systems. Be that as it may, we ultimately want to have a dependable text messaging service - even if we are dependent on another system.
   
   And like most services, Twitter strives to have a 99% uptime, and you can see this in their freely posted "uptime page":
   
   http://www.pingdom.com/reports/vb1395a6sww3/check_overview/?name=twitter.com%2Fhome
2. The text messages contain information from the Rip and Run faxes - this seems like an obvious statement to make, but the point I am trying to make here is that if there are type-o's or mistakes made in the Rip and Run fax itself - then the software, including the text messages will contain these errors.
   
   I am hoping to work with the county to keep these at a minimum, but the point is, incorrect data inputted to the software, will produce incorrect results.
   
   For example, one goal of the text messaging component of my software is to keep the text message length at a minimum - these are supposed to be quick and easy messages to read - ultimately notifying firefighters of an emergency. Thus, the text messaging logic is to include the location of the call, rather than the address - as it is easy to the human eye to comprehend where the call is.
   
   For example, there are two addresses at 3070 Route 50: Panera Bread, and Giavano's Pizzeria.
   
   So having the text message read "...emergency at Panera Bread" is much more informative to the end user rather than "...3070 Route 50" for a variety of reasons. First, most people don't memorize addresses of businesses (or other popular locations) and secondly, it doesn't differentiate between the two separate businesses.
   
   So its a much better logic scheme to have to include locations rather than addresses (if a location is given in the Rip and Run). That said, we had a call two days ago where the location was the last name of the caller - so for example, the text message read "....emergency at Spackmann" - which doesn't really make sense when read.
   
   Typically resident information is not given in the "location" field of a Rip and Run - its generally put in separate fields. Anyways, I am hoping to work with the county to correct this in the future.

Any questions, just let me know.

posted by spackmann in Rip and Run Development at 12:06 PM (357 day(s) old)  Permalink

Twitter SMS Text Messaging Testing

  Sunday, August 2nd 2009

I have finally pushed the finished and refined code to the Rip and Run server - and I am happy to say that so far the Twitter text messaging is working perfectly, and I'm anxious to get other GFD people to sign up for this service.

I've posted about the Twitter concept in the past, but to sum it up quickly - it provides a free and simple way for our firefighters to receive SMS text messages on our cell phones notifying them of a given emergency. This has become somewhat of a pressing issue, considering the deficiencies in the county radio system.

The process to enroll is pretty painless. To "sign up" to receive SMS text messages for Rip and Run updates, follow these steps:

1. You will need to create a "Twitter" account to recieve text messages.

   Note that you do not actually need to "use" your Twitter account, this can be a simple "placeholder" account that you create only to use for the purposes of Rip and Run.
   
   If you do have a personal Twitter account that you use regularly, and you do enable it to receive Rip and Run SMS updates, you will receive SMS text messages from other Twitter people you are "following". It is for this reason that I suggest you setup another separate Twitter account just to receive GFD Rip and Runs.

   For example, you could create an account named "mafd123" if your membeship ID was "123" and then follow the steps to enable your cell phone to receive SMS text messages, described in the next step.
2. You can enable SMS messaging in Twitter by accessing your account settings.
   
   The "Settings" menu can be accessed by clicking on the "Settings" link in the upper right hand corner of your profile once you log into your Twitter account.
   
   From the "Settings" menu, go to the "Devices" tab (third from the left) and you can then enter your mobile phone number.
   
   Click the "It's okay for Twitter to send txt messages to my phone" check box (to give Twitter permission to send SMS messages to your phone, and then click the "save" button
3. Visit the "Greenfield Fire District Rip and Run" Twitter account online at:
   
   http://Twitter.com/greenfieldfd
   
   And ask to be added as a "follower" of "greenfieldfd". Basically a "follower" in the Twitter system is just a phrase to denote that you want to be "notified" of any updates of a particular user - in this case, you are asking to be notified via SMS text messages of any updates to the greenfieldfd user - which will occur every time a Rip and Run fax is sent.
4. Once the administrator of the twitter account (me), accepts you as a "follower" - you will still need to select "to receive SMS each time follower updates" in order to receive text messages from the greenfieldfd account.
5. One last step, and this is a suggestion, is to add the number "40404" to your address book as "Rip and Run" - as this is the SMS number that Twitter sends the messages from. This way, you'll know when you get a new text, who its from and not to disregard it.

One final note, remember that these text messages are sent when we receive faxes from the county Rip and Run system. If we get dispatched to a call, and receive the fax 20 minutes later - then you won't receive the text message until 20 minutes after the call. You can judge this for yourself by reading the TOC included in the text message - it will clue you into the time difference.

Here are a few example text messages that you will see:

Alarm for Maple Avenue. P1B TRAUMATIC INJURY at GAVIN PARK. TOC 0926. Run number 062694

Alarm for Maple Avenue. P1C CHEST PAIN at BON TON. TOC 1201. Run number 073635

Alarm for Maple Avenue. STRUCTURE FIRE at 32 LADY SLIPPER LANE. TOC 1029. Run number 076732

Alarm for Maple Avenue. MVA at NORTHERN PINES AND ROUTE 9. TOC 1826. Run number 071479

A few notes about the examples above:

1. The priority of the medical call is provided before the call type (CHEST PAIN, etc.). Sometimes this information is not included in the dispatch Rip and Run, and if its not provided by county dispatchers, then it will not be provided in the text message.
   
   The call priorities are abbreviated to three character abbreviations. The given priority abbreviations are listed here:
   1. P2A: a "priority two alpha" call
   2. P1B: a "priority one bravo" call
   3. P1C: a "priority one charlie" call
   4. P1D: a "priority one delta" call
   5. P1E: a "priority one echo" call
   6. P3: a "priority three standby" call
2. If the location field of the Rip and Run is specified, then it will be used - and not the address. Otherwise, just the street address is used in the text message.
3. Subsequent text messages will be truncated and only provide "updates" to the call - so it will only contain enroute, onscene, and inservice times. This is why the run number is included in the text message, so you can follow the call progress.
4. This system is configured not to sent text messages for a call that is 1 hour old (this is a configurable parameter) - the idea being that there's no reason to send texts to someone's phone about a call that is an hour old - this includes call updates described above.
5. Naturally, the company text will change depending on which company the call is for - once we enable the system for the other GFD sister companies. Note that you will receive text messages for all companies, not just your own if you enroll in this service.

Remember - this is a system to complement the county pager system, not replace it.

As always, any questions regarding this setup, can be forwarded to Richard Spackmann via email at RichardSpackmann@greenfieldfd.org

posted by spackmann in Rip and Run Development at 6:33 PM (361 day(s) old)  Permalink

Rip and Run Twitter Integration

  Friday, May 29th 2009

First a disclaimer, I'm not a Twitter "fan", advocate, user or opponent. Obviously there's been plenty of press and news regarding twitter - if you watch TV, follow the news, or surf the net, you've no doubt heard about Twitter.

But I started to hear reports that Twitter will allow you to receive and send SMS text messages to interact with their service. The software that I wrote to send text messages does require a (albeit small) fee - and by using Twitter, we could eliminate this overhead for a fire department. I found this particularly appetizing as fire department budgets are becoming increasingly lean, and some smaller departments, already have constrained budgets. Secondly, text messaging is probably the preferred method to receive call notifications on your cell phone (compared to say email or voice dialing) - so having this service free, is that much more appealing.

So is this all about cost?...Absolutely not! When I started investigating the feasibility of using Twitter, I began to see that the "twitter methodology" does suit itself nicely to the concept of our "Rip and Runs" and "call records".

Now what do I mean by this? Well Twitter is basically a way to record a quick status about your life, so if you consider a fire call (or an emergency) an event, you can quickly abstract this concept out to see that using Twitter can essentially provide a method of recording all emergencies that a fire company is dispatched to.

With this listing of calls, a fire company could - in effect, be getting a "quick and dirty" call listing (for reporting perhaps), and also a "quick and dirty" website for some public relations. Some may choose not to publish the content of the emergencies that the company responds to, and there is a way to hide all of the postings so that only "friends" can see them - i.e. the people that are granted permission to see them can.

So you can see that right out of the box, Twitter provides functionalty that readily lends itself to call recording. If a department doesn't have this type of reporting available, you could simply go to the Twitter page of the rip and run for your company, and see the most recent calls for your agency - for free. So no software costs - no installation costs, its all available easily for all your members to see online.

Additionally, I have found that its very easy to include "tweets" (individual messages posted on the Twitter webpage) on another website via a widget. So you could, for example, provide a listing of a fire company's calls on the fire company's webpage - which is completely separate from Twitter. This way, you can get real-time updated call information on a fire company's home page, without having to pay development costs (you can view some of these free apps on the twitter webpage: http://twitter.com/downloads).

Perhaps the biggest reason to move towards Twitter, is because then the subscription and permissions concerns are pretty much taken care of separately from the Rip and Run software. So there would be no "development" or configuration changes that need to happen on the Rip and Run server - which is a big plus. So the way I envision that firefighters will "subscribe" to recieve SMS text messages from my Rip and Run software is:

1. Simply create a Twitter account
2. Configure with your cell phone information (directions available on twitter.com)
3. Request to be a "follower" of the given "Rip and Run" Twitter account. For example, GFD's Rip and Run account is http://www.twitter.com/greenfieldfd
4. The administrator then either grants permission to this requests, or denies it. This provides a level of security to ensure that only the authorized people (granted by the administrator).

And that's it - pretty easy and it requires no configuration changes on the Rip and Run server - which as I said, is a big plus. Anytime you make changes to the server, you typically have to take it off line for a small amount of time - and that's a hassle.

I am currently working on Twitter integration and so far things look very good - it does look very possible to get this to work as a "Rip and Run" text messaging service.

I'll post more information as it becomes available and in the meantime, if you have questions, please feel free to ask! Hopefully it won't be too long until we start field testing this!

posted by spackmann in Rip and Run Development at 1:12 PM (426 day(s) old)  Permalink

New Rip and Run Development Testing

  Friday, May 22nd 2009

As always, there is plenty of Rip and Run testing going on "behind the scenes" that members don't necessarily see - which is the norm in software development. People use the "end product", i.e. the actual software package to perform some type of job, but the end product doesn't necessarily show all the effort that went into creating it.

For example, every fire call that Maple Avenue gets dispatched to (for the most part), my rip and run server gets a fax. This fax is just another "test case" that is used to validate the logic in my programming code, and testing its robustness and longevity. To date, I have not had any of my code crash - so it is proving to be pretty robust. Additionally, each fax is sent through a myriad of tests and analysis after the call as part of the development process. So even though there may not be active conversation or posts on my blog regarding my rip and run initiative, it does not mean that there isn't anything going on - you just can't see it.

On average, I would say I spend probably 20+ hours a week on "rip and run" related stuff.

I have released another software version to development testing on my test server at the Maple Avenue firehouse. The latest release has these features:

1. a variety of minor bug fixes in the OCR (optical character recognition) to increases the software's accuracy. I would approximate that we are now running around 99% accuracy for character recognition - this is a major accomplishment.
2. I spent some time and actually listed out and created "road files" for Greenfield Center, Porter Corners and Middle Grove hamlets. These files are used to, for lack of a better way of explaining it, "confirm" the road address listed on a given fax. This helps to correct OCR errors or dispatcher spelling mistakes, and greatly increases the accuracy of the software.
3. fixed bug in OcrParser when a town is null (would crash via NPE). Now it will just remain null.
4. There are conditions sometimes where a dispatcher may omit the town in the rip and run fax. So my software must be able to "guess" (intelligently and accurately) which town the call (most likely) is in for mapping purposes. This functionality is now included.
5. added ability to determine TOC when time is specified *before* the TOC token. Also, added the ability to use the "TOA" (time of alarm) token to set the TOC (sometimes dispatchers use TOA rather than TOC). This is necessarily because there is an inherent latency between the time a dispatcher receives the call via 911, and when the fire company is actually dispatched (notified of the emergency).
6. Added ability to have a "default" address for FireTracker when one isn't available from the rip and run fax.
7. Finalized functionality to clear out all the temporary files generated from this service. This job can be scheduled at any given interval - this is very useful and necessary to clear out the large fax files (data size wise) that can accumlate on the server.
8. Modified address logic to take into consideration the situation where dispatcher selected the wrong road suffix - i.e. "Road" instead of "Lane".

I have another phone call scheduled with the county this Saturday to get an update on the software upgrade initiative. We spoke earlier this month, and apparently they ran into issues with their redundant SQL server. As always, I'll try and post updates once I hear them.

I have been asked often about when the other sister companies of the GFD (Greenfield Center, Porter Corners and Middle Grove) with my rip and run software and that depends on when the county can upgrade their software. The county has agreed to send rip and runs for these companies as well, its just a matter of completing this upgrade. Rest assured, this will happen eventually.

I also wanted to comment on "text messaging" capabilities. The capability does exist with my software to text message call information to firefighters - this was briefly tested and was very successful. I haven't yet launched this into full beta testing yet - because I have decided to roll in a different direction with this. There are some online services that will provide *free* text messaging capabilities - one such service is Twitter and I am now working on integrating my rip and run service with the Twitter service. More on this later...

Any questions, just let me know!

posted by spackmann in Rip and Run Development at 11:23 AM (433 day(s) old)  Permalink

Version 4.0 In Development

  Monday, February 9th 2009

I have pushed the latest Rip and Run code into live testing.

Here is a break down of the latest developments (in no particular order):

1. added new functionality to filter the dispatcher notes section of the rip and run fax, this improves the accuracy immensely of that section
2. emails sent out now include the call type in the subject line, along with company name and "run number"
3. the new version of FireTracker automatic run upload has been running for nearly two weeks now, very stable and very accurate.
4. new version of voice dialing has been running for nearly two weeks now and has shown no problems. I will most likely test this for another week or so, and then move onto the SMS text message testing.
5. The GIS (mapping) component is due to be delivered at the end of this month. As I have previously posted, I collected hydrant information, which is ready for integration into the GIS software.
6. An assortment of bug fixes...
7. I am still working with the county to integrate the other stations, I have yet to sync up with their personnel via phone, but I plan on trying again this weekend.

Any questions, just let me know!

posted by spackmann in Rip and Run Development at 10:50 PM (535 day(s) old)  Permalink