Tech question - interface between receiver and central station software

I can't answer your question, but if you look in the back of some of the trade magazines, someone is always advertising programs that will allow a computer to act as a central station receiver. Other than that, I'd say, those programs can't be very comprehensive and digital receivers have been around for a long, long time and computers can do lots and lots of stuff nowdays. If it were that easy to do, someone would have done it already and central stations wouldn't be paying thousands of dollars for new digital receivers.

Just and observation.

Thanks Graeme,

That was incredibly interesting. Yeah, we run Telemate as a backup, during the regular times when Patriot crashes. We are currently still stuck on version 4 (clarion database) and are trying to get them to set training times, so we can upgrade to version 5 with the sql database, which will make things a lot faster and easier to run searches.

I knew how the templates etc work (may I say god bless Contact ID, and boo to old panels that use 4+2 lol) but yeah it was just understanding the serial connection, which you've answered in great detail.

Thanks :D

Yeah we are dying to get version 5, but they won't until we do this training session. We're already using it because one PC here is a remote terminal we monitor for another company, which uses V5.

The only reason I am not a 4+2 fan is because it's such a hassle to program lol. We have a folder with information on the formats to help operators program them up, once you do a couple it's not hard - but Contact ID is just much more "plug and play" from a central station point of view lol.

We have a few IRFast clients, very handy format. We tend to stick to Contact ID, IRFast and 4+2 if needed on those older panels. However we have had a few Cactus clients switch to us and have had to make provisions to support the odd radionics format (I don't know much about it).

We monitor from New Plymouth, Taranaki-wide, mostly local but a few national. One of our biggest selling points is being local, having people who know your area etc... Plus we have our own guards in New Plymouth and Hawera, which avoids the ghastly dispatch centres of ADT/Armourguard or Chubb.

We have > Get up to Patriot 5 asap. We did last year.

The FE100 connects to the Telemate PC via the terminal serial port - this allows you to view incoming signals and set up the receiver and line cards. You can also print out line statistics, etc via the report menu. If you have the FE100 database version, you can do simple monitoring as well (limited to 500 clients, I think).

The FE100 itself decodes the signals from the panels and simply sends the data via the automation serial port to your PC (or server) runnig Patriot. Most Fe100s have been set up to emulate the Ademco 685 receiveroutput, but yopu can choose other protocols as well, such as Surgard.

Patriot then works out what the signals are, firstly by using the account and port number to determine who the signal is from in the database, then looking at the Types template for that client to see how to interpret the message - open/close, burg, etc, depending on what format is being sent by the panel.

The FE100 does the hard work of decoding and handshaking with the panel. Telemate does not need to run at all, but we keep it on anyway - mainly as a tool to check line stats and bad signals.

To set up your own app, you will need some sort aof database (Patriot started with Clarion, now uses SQL) and a means of capturing the serial data. there are many freeware and opensource data capture programs available. We use a real old one called Winlog now and again just to test comms and mimic the serial printer.

You would then need some sort of front end to allow you to interact with the database so you can attend the various signals, set up some templates for the various formats, etc. I have no doubt it is simple for someone to do (I have no idea how to go about writing such a program), and that is how Patriot and many other got started. Could be fun..

You can run two automation packages together on the same serial port from the FE100, as a means of testing it.

If you get yourself a password to the site, you can download the documents, although it is just simple serial data capture in the end.

Good luck

Get up to Patriot 5 asap. We did last year. Everything is much better, although we upgraded our server soon after, so performance increased anyway. The 'training' was an afternoon with one Patriot guy, who asked us more question than we asked him. Sometimes the best way to learn is to just do it.

Patriot are good to us, we have been using their software for about 5 years, and they are very quick to issue updates when we request features.

Don't dis 4+2 totally, at least you know that the signal you get thru was purposely programmed - even if it doesn't match the template. With CID, there are a few manufacturers that use an odd code, that nobody has picked up on, until it comes thru, in the middle of the night.

Best format would have to be IR Fast - everything comes thru in the same english the tech programs in the Concept panel. Everytime they update users, we don't have to - the new name comes thru automatically!

Worst format is Ademco fast - never understood it correctly - the template works perfect, so we don't look into it too much. I tried to work it out about 10 years ago, but then CID came along and we were sorted! have to say, though - it is by far the fastest format I have seen, bar IR Fast. Also it's the best format for the old Solution 8 panels - 4+2 sucks majorly on them - very very slow reporting!

Where are you monitoring? We are in Wanganui, but cover the country, with remote FE100 receivers on different PC ports.

Graeme McKenzie

Hi there,

I'm new to this group, and came across your postings. Interestingly enough, what you are talking about as a theoretical project, I am attempting to do for real. Any advice or assistance I can get along the way would really be appreciated.

I am connecting to an FBII Digital Receiver, model CP-220FB. We currently use an old DOS-based piece of software as the automation package. I am attempting to write my own automation software using Microsoft Access as the front-end, and Microsoft Desktop Engine (the cut-down version of SQL Server) as the back-end. I haven't as yet gotten as far as the serial-port interface, but that will definitely be happening in the not-too-distant future. We also have a SafeCom Radio Receiver, which also outputs on the serial port, so I will be interfacing with that as well.

I am a novice programmer, and can cut VBA and VB code, and have minimal SQL knowledge. Most of my programming is done by way of plagiarism - a snippet of code from here, a snippet from there.

I am doing this for the security monitoring company I work for, as a pet project. They needed something better than the old DOS system, but aren't prepared to pay the $50,000+ for a licence for professionally written automation software. There is no set timeframe for completion.

I'll be keeping an eye on this thread, so if anyone wants to contribute constructive advice (please don't tell me it can't be done!) I look forward to hearing from you.

Robert Frittmann Database Administrator

You dont need to pay $50000 for software, take a look at ADSW by NT SOFTWARE it is simple to use and setup excellent 24 hour support, does everything the more expensive packages do and dont charge extra license fees for additional work stations.

Way to go Robert.

It's definitely a do-able project. I will most likely never write the program, the main problem was just understanding the flow of data from receiver to computer. The rest is easy, matching against templates for Contact ID, retrieving keyholder contacts and response plans from database tables are relatively simple tasks with basic database knowledge.

I sit at work in front of Patriot (versions 4 and 5) and think "I wish they would change that, or do that differently" lol. Someone recommended NTSW's software - which I personally don't like the looks of, it seems very Windows 3.1ish.

I downloaded a demo of Microkey and another of A-Traq, both have nice interfaces, I've also seen screenshots of Bold's Manitou which seems very powerful. However I can only assume very high price tags on these packages.

You may still want to consider using SQL instead of MS Access for its security advantages. It doesn't take that long to master once you have a handle on Access. If you're handy with XML you'll find it a lot easier to set up the receiver, protocol, etc., than hard-coding in VB. You can implement various formats using schemas much quicker and with far less hassle than you can rewrite your code.

You can also edit account data and signal displays much easier in XML than you can with VB. I'd use VB as the backbone and XML as the interface between the app, the data and the receivers. Doing it this way you can more easily create reusable, modular code than by hard-coding everything.

I agree with the benefits of being local - ADT is losing a lot of clients now that the 'free' contracts are ending. People are sick of long despatch delays.

New Plymouth - very close indeed! I assume your RF receiver is the Radionet. We've had one for a few years now, just setting up the CID version this week, so hopefully selling a few more transmitters this year.

Cheers, Graeme McKenzie

In reliance to other software alternatives I would recommend that you also try A-traq. You can download a demonstration version and get it running in any language within a couple of hours. Although it is one of the newer softwares on the market, it is the only automation to be tested by UL for managing 3,000,000 accounts and passed with success. They have the capability of using all sorts of databases (SQL, Oracle, etc) which gives flexibility. If you do want to see how good aftersales support is you best log in to

Good luck.

There have been several threads on this subject in the past. One gentleman has posted a horror story regarding the central station software he purchased. You may want to do a Google search on the subject. I bought BOLD quite a few years ago for my central station. Our operation was very small but the automation system was first rate. Other than one problematic release we had very good experience dealing with Bradley.

When I first bought the BOLD package the price was quite reasonable -- around $10,000 if I recall correctly. That included a PC (our first) and a separate terminal. I have no idea what they charge now but I assume it's several times what I paid.

If you ever decide to go ahead with the project and you need some help, let me know. I own part of a software development firm with extensive experience in machine communications. We've also developed software for the alarm industry. Several thousand fire alarm dealers use downloading software which we wrote for Edwards.

When you wish that Patriot software would this or that differently, send them an email, they are pretty good at modifying things if there is a good reason. Have you made sure that your software is up to date? There have been several updates within version 4 and 5. You should be looking for updates every month.

Graeme McKenzie

I am sure that Patriot software was not anywhere near 50,000 dollars.

The cost of A-traq Monitoring Software starts from 2,250.00?'s. Which is very low compared to rival products. You can add web modules such as the Web User Module for users to log in to your web-site and self-update personal details from as low as 750.00?'s. The Web Technician Module, for field technicians to fill all information through any type of portable internet access instrument (such as Pocket PC's, etc.), cost around 1,950.00?'s. It is the only solution to provide the complete automation for managing installations connected with the central monitorign station.

I guess it is a must for CMS's with more than 2000 accounts. I recommend that you go and download the demonstration version from

This is off the subject but on ul sites isn't the panel polled ever min, hr or day from the cs to determind that all is well, could one of these programs capture the all is well signal from the control panel

Daily yes, hour or minutes no although some are capable of hourly (Caddx for one)

Dear Buco,

Yes indeed. Almost all monitoring stations do capture the test signal sent. Most panels now use up-to hourly controls.

But if you have a more secure region that requires on-line telephone control then you must use either radio networks (of which the initial cost is expensive but the running cost is very low), GSM networks (of which the initial cost is low but the running cost is high) and telecom switchboard monitoring (of which as far as I recall is only valid in A-traq).

The radio network can be used as a primary or backup to the telephone system. This is ok with UL. The GSM is very similiar to the radio network yet much expensive if chosen as a primary communication. The best is using the telecoms software to monitor any phone problems. This information is passed on directly to the monitoring station and all costs a forwarded to the user rather than the monitoring station. This is not mentioned in UL but is used quite frequently throughout Europe.

I hope this does give you some idea of how test signals are captured and what the precautions can be.

Good-luck!

Thank for the info, you guys really know your stuff

Hi there, hey thanks for all the tips and comments everybody. I am very "green" to all this as I have only been working in the security industry for a matter of months now, having spent the last 12 or so years in the computer industry. I understand basically what the templates are, such as Contact.ID, etc. They provide the interpretation for the data stream that comes from the receiver. Simple enough?

The pricing I mentioned, of $50,000 is just something I pulled out of a hat. In reality, I have been unable to obtain pricing for the product I was looking at, which is called Alarm Center

Anyway, yes, I am slowly going to develop my own in-house system, so Robert L. Bass, your offer of assistance and advice is gratefully appreciated. I'm going to need all the help I can get. As for XML, I haven't even looked at that yet.

If anybody has a good database schematic (ERD) for a simple alarm monitoring system I would really like to take a peek. I'm currently finding all kinds of pitfalls with the database design, and can see that my elementary knowledge of Normalisation (sorry, Normalization for the Americans amongst us) is going to be seriously put to the test on this project!

For instance, putting the patrol and monitoring information together in the Client table was dumb, as it slowly dawned on me that you can have a client with monitoring but no patrol, or vice versa, and also either the patrol or the monitoring could be provided by a third party! Oops! As you can see, my lack of experience in the security industry is going to make this a tough ride.

Anyway, thanks again for all the advice.

Rob.