Tech question - interface between receiver and central station software

[[email protected]]

I work in a central station and know our receiver (Fratech FE100 I
believe) which goes to a receiver computer running software called
Telemate which shows basic information (client, zone/user, type etc).

From there I assume it connects to one of our main central station PC's

running Patriot (www.patriot.co.nz)

I understand how to read the raw data e.g. from Contact ID panels, but
was just wondering how this was communicated to the central station PC,
probably by serial cable.

The reason I'm asking is I'm toying with the idea of writing a simple
monitoring app of my own. And the only thing I can't seem to find any
information on is how a program can communicate with, and receive info
from the receiver.

If anyone has any info or links, it would be gratefully received. Just
curious.

 

[Jim]

I work in a central station and know our receiver (Fratech FE100 I
believe) which goes to a receiver computer running software called
Telemate which shows basic information (client, zone/user, type etc).
running Patriot (www.patriot.co.nz)

I understand how to read the raw data e.g. from Contact ID panels, but
was just wondering how this was communicated to the central station PC,
probably by serial cable.

The reason I'm asking is I'm toying with the idea of writing a simple
monitoring app of my own. And the only thing I can't seem to find any
information on is how a program can communicate with, and receive info
from the receiver.

If anyone has any info or links, it would be gratefully received. Just
curious.

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.

 

[Andrew]

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

 

[Andrew]

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 one FE100 receiver, and a Silent Knight which we monitor for a
local medical alarm trust, as well as a standard RF receiver.

 

[Greene Security NZ]

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

 

[Max 351]

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.

 

[Robert L. Bass]

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.

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.

--

Regards,
Robert L Bass

=============================>
Bass Home Electronics
2291 Pine View Circle
Sarasota · Florida · 34231
877-722-8900 Sales & Tech Support
http://www.bassburglaralarms.com
=============================>

 

[Andrew]

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.

 

[A-traq]

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 http://www.a-traq.com

Good luck.

 

[Robert L. Bass]

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.

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.

--

Regards,
Robert L Bass

=============================>
Bass Home Electronics
2291 Pine View Circle
Sarasota · Florida · 34231
877-722-8900 Sales & Tech Support
http://www.bassburglaralarms.com
=============================>

 

[A-traq]

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
http://www.a-traq.com With prices as low as this it would be a waste of
time in going and developing a seperate software.

 

[buco]

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

 

[Mark Leuck]

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)

 

[Okitoki]

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!

 

[buco]

Thank for the info, you guys really know your stuff

 

[Greene Security NZ]

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
(http://www.securitysoftware.com) as they repeatedly ask me for the
configuration of our current system, number of clients, etc, etc, etc
before they will give me pricing. Surely someone in the security
industry would understand that I am not authorised to give out that
kind of information. Duh!

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.

 

[Robert L. Bass]

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?

Basically, yes. There are agreed codes for each condition. If the receiver
sees a given code, it expects the condition to correspond to those listed in
the published format. However, there are a number of popular formats and
variants on each of them. You'll need to provide a means to set deviations
from the standard code in case a given panel or location is not fully
conformed to the standard.

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

I'm unfamiliar with that product. If their salesman isn't being helpful,
you should look elsewhere or, if you're up to it, write your own. One word
of caution though -- central station automation software tends to get pretty
involved. It's not for the feint of heart.

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.

Advice is free. Programming assistance isn't. :^)

If anybody has a good database schematic (ERD)
for a simple alarm monitoring system I would
really like to take a peek...

Other than myself, none of the regular participants here appears to have
much background in software development. Even my experience is somewhat
limited. I own part of a software firm but I'm not one of the coders. I
mostly do help systems, UI design and sales. Between them my partners have
over 60 years of SW development.

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!

Every project is either a learning experience or boring. This one's likely
to be a little of both. If you start with a good relational platform,
develop a modular system that's flexible and easily modified, you'll spend
far less time redoing mistakes.

Some firms offer downloadable demos of their software. It might be a good
idea for you to obtain several of these and familiarize yourself with what
others have done before you even start planning the project. You'll get
ideas about useful functionality which you can plan for in your own system.

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!

You might want to build collections of patrol service data, response
protocols, local and state authority lists, etc. By linking these to
clients based on client location and reported conditions you can avoid a
great deal of repetitive (read: error prone) data entry. This will also
allow you to quickly make changes to all client accounts within a
municipality when the PD of FD decides to change phone numbers or whatever.

The same applies to standardized procedures. Create collections of
procedures (e.g., what kind of authority, responsible party, etc., to notify
in what order under a given condition). Link to your keyholder and
responding authority tables through these rather than directly from each
client's account data. This will allow you to rapidly implement changes to
all affected customers when some PD decides they want a keyholder or guard
service to respond before they dispatch.

There is much more to consider but hopefully this will start you thinking in
the right direction.

As you can see, my lack of experience in
the security industry is going to make this
a tough ride.

Recognition of ignorance is a prerequisite to education. :^)

Anyway, thanks again for all the advice.

You're most welcome.

--

Regards,
Robert L Bass

=============================>
Bass Home Electronics
2291 Pine View Circle
Sarasota · Florida · 34231
877-722-8900 Sales & Tech Support
http://www.bassburglaralarms.com
=============================>

 

[Greene Security NZ]

James, which edition of SIS Alarm Centre do you use? We were looking at
the Small Network Edition, which, from memory, allows for two computers
connected to receivers, and up to 5 supporting computers in a network.
We were also interested in the WebAccess module, to allow our techs to
access the data directly without having to bother despatch at all for
the status and test stuff.

 

[Crash Gordon®]

I still have my copy of the dos version...I think I paid 2500 bucks for it originally...I took my small cs down years ago but kept the software and cables for some reason....yep it was very good for the money...so was the suppport.


| If the Alarm Center Software you are talking about is from SIS you can
| expect to pay between 5k and 10k. We have been using it for about 20 years,
| "we started with the dos version". The DOS version was excellent, the
| windows version could use a little help.
|
| James
|
|
| | > 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
| > (http://www.securitysoftware.com) as they repeatedly ask me for the
| > configuration of our current system, number of clients, etc, etc, etc
| > before they will give me pricing. Surely someone in the security
| > industry would understand that I am not authorised to give out that
| > kind of information. Duh!
| >
| > 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.
| >
|
|
|