Links to the feeds have moved here, and this page has reverted to being about the service.
SApaging.com is a not-for-profit, free to use service provided for emergency services staff, volunteers and general public.
If you would like to acknowledge your appreciation for this site, please make a donation to the CFS Foundation (cfsfoundation.org.au/donate) and mark it as a donation on behalf of SApaging.com.
If enough people support the CFS foundation in this way, I will continue to pay the bills to keep this site running and the only people to benefit financially will the be the CFS Foundation.
Acknowledgements A big thank you to Alex Maddern for all his work with cfsres.com over the years. Thanks again to Alex Maddern, David Fitch, Matt Sachse and Chris Macco-Palmer for running pager decoders which send me the raw pager messages which are merged to create a cleaner feed. Thanks to Gary Mann and his team of contributors at NZ-Air for the aircraft tracking.
SApaging.com was created in January 2018 based on code I (rob h) wrote for the cfsres.com website that ceased operating in unfortunate circumstances. SApaging.com operates as a completely free service and offers no subscription features and no ads. Basically, publicly broadcasted pager messages are plucked out of the airways, converted to text, parsed to pick out the information, published as a ‘pager feed’ and stored in a database for future searching.
The reason I started doing this work in 2016 was because I did not like the formatting on the pager feeds that existed at the time. They took the raw pager messages and displayed them, as-is. Pager messages are hard to read quickly. I knew I could parse the messages and display them in a more user friendly format, e.g. using colours to represent agencies, removing most of the UPPERCASE TEXT THAT’S HARD TO READ and tabulating the information so that it can be scanned very quickly for specific info, e.g. an incident number, is always easy to find.
I then realised that the map coordinates in the messages could be converted into GPS coordinates and then shown on a Google map. The job of converting the maps to GPS coordinates required viewing each map and manually building a giant lookup table. That took a few weeks of work.
Why do I do this ?. programming keeps my brain active. Fixing, improving and extending code is problem/puzzle solving that is addictive to me.
In SA the emergency services (SAAS, MFS, CFS and SES) use the GRN paging service to send messages to members. The messages are sent unencrypted over the airways. For many years people have been 'listening' in on these broadcasts. With a $15 usb device called a SDR (Software Defined Radio) and open source software (multimon-ng and pdw), anyone with reception from a GRN paging tower can read the pager messages. Encryption is possible on these systems, so authorities could encrypt if they wanted to stop the public reading the messages.
SApaging.com uses messages decoded by SDR devices in 6 or more locations in SA. Each "decoder" sends messages to a central server in the cloud (Amazon AWS). Once the server sees any given message from two different decoders it knows the message is correct and free from corruption. No single decoder will see all messages and decode them without occasional corruption or partial messages (corruption is inherent in radio transmission without error correction). Any corrupted or partial message will never (almost 0 probability) be corrupted in the same way by two decoders, so this method guarantees a high quality output.
SApaging.com's goal is to be the most reliable and customisable feed and still publish messages within a few tenths of a seconds of them being transmitted over the airways.
Once a message is confirmed by the server it gets parsed. For this I use my favourite old programming language Perl which is fantastic at manipulating text. Each message is broken down into data fields, e.g. CFS incident type (Grass Fire), the alarm level (Level 2), the incident address and incident map grid reference (ubd or CFS mapbook). Data fields are added based on the recipient, e.g. a message to Middleton CFS will get tagged as one for the Mundoo Group and the CFS Region 1 and CFS. Only after the message is parsed does it get published and this allows for highly customisable feeds. The parsing process also uses Google's mapping services to convert addresses and map references into suburb names and postcodes. So after a few milliseconds of parsing, each message can be delivered to an individual feed. At any given time SApaging is serving scores of individual customised feeds to hundreds of web browsers.
As each message is published it is also checked to see if it is message for an incident, and if it is, new information from the message is added to a record that tracks the incident. When you click/tap on an incident message in the feed you are shown the incident record, not just the message details. This means that if there are 30 messages for a given incident you will see a collated view of the entire incident, not just 1 message from the incident. This is really useful for crews that have reached the station and need to know everything about the incident. If they can only see their own pager messages they may have no idea that 10 other appliances have also been responded since they got their page.
The feeds require a fair amount of monitoring, e.g. to detect new or reassigned capcodes and changes to the formatting of messages. SApaging.com is constantly evolving to keep up with a moving target.
Contact me via RobHsomething@gmail.com
Facebook
© SApaging.com All rights reserved.