Atlas Knowledge Base
Dashboard
Supported receiver types

Supported receiver types


Every receiver line names the receiver it is talking to by number — the TYPE= value in its concport configuration. That number selects the decoder, and it is the same number on both generations of the Concentrator: a line that ran as TYPE=52 against SBNConcentrator.exe runs as TYPE=52 against sbn-concentrator.

Sixty-one receiver types are supported — every receiver type the previous generation supported.

The table

TYPE=ReceiverNotes
10ITIPolls the receiver once a minute
11FBIPolled
12Ademco, older receiverSuperseded by type 13; still supported for existing lines
13Ademco 685Carries Contact ID inside the 685's own framing
14Radionics 6000 / 6500 / 6600
15Silent Knight 9000Handshakes: sends a heartbeat to the receiver and carries a counter between messages
16DataVision
17Aritec TAC-90
18Robofon, original
20FranklinUp to 26 records in one message
21McCulloh IISends a line-open handshake
22HSLSession protocol — the line negotiates a session before signals are accepted
23DMP / SCS1
24Veritech V300 / MooseThe panel repeats each record; a matching pair is required
26SESCOA 3000
27Seaboard RF
28SPC-5000Polled
29IEI E6800 (Australia)Sends no acknowledgement
30Care-net
31Securitel — Honeywell Australia STU/ATUCarries state between messages
32Scancom
33HSL text readerSends no acknowledgement until a pattern matches
34SIA
35Derived Channel 1
36Pro-Com Extended
37Sensus SafeCom
38SurGard CPM2Multi-format: SurGard, SIA and Ademco on one line
39TAR-200 (Audiolite)
40Debug receiverDecodes nothing — logs what arrives, for commissioning a new line
41Robofon RBM-600
42MorsePolled
43RC-4000 printerA CFGFILE= rules file is tried first, then the built-in decode
44InfraNetSession protocol; sends no acknowledgement
45Audiolite on a parallel portNo framing; sends no acknowledgement
46DomiTech DM8
48Receiver testDials out and sends; decodes nothing
50Keltron
51Multicom
52 and 63SurGard MLR2One decoder under two type numbers; the wire format is the same
53Vigilante fire panelReassembles messages across reads
54IBS GSM
55Osborne-HoffmanSeveral message formats on one line
56SECOM CTIPReassembles messages across reads
57TFS F1Handshakes: polls, answers each message with an acknowledgement built from that message, and resets the connection after three unanswered polls
58SDN SMS gatewayReads messages from the file named by IFILENAME=
59AlarmNet — Danish national alarm transportSession protocol with its own link layer; sends no plain acknowledgement
61Alarm Force
62SDS
64Emerson / Emergency 24Session protocol; sends no acknowledgement
65Cellularm
66OzVisionSends no acknowledgement
67ComputechPolls every six seconds
68Atlas
70Stealth
71BT Redcare gatewaySends no acknowledgement by default; carries state between messages
72Dualcomm
74Risco Cloud
75SIA DC-09 over IPEncrypted payloads are decrypted with the keys in SIADC09AesKeys.ini
76Rules-driven receiverThe receiver is defined by the file CFGFILE= points at, not by the type number
77RSM-02Field mapping comes from the file CFGFILE= points at
900Contact IDBare Contact ID on a data line. There is no equivalent number on the Delphi Concentrator

What the notes mean

Session protocol. The line is not a plain stream of messages. The receiver and the Concentrator exchange control frames first, and signals only count once the session is up. Types 22, 44, 59 and 64 work this way. Types 15 and 57 handshake in a smaller way — they carry state between messages and answer with something computed from what arrived, rather than with a fixed byte. A line of one of these types can be connected and quiet for a while after it opens — that is the session coming up, not a fault.

Polled. The Concentrator sends to the receiver on a timer instead of only answering it. Nothing extra needs configuring; the cadence belongs to the receiver type.

Sends no acknowledgement. Some receivers expect nothing back, so the Concentrator answers with nothing. A quiet outbound side on those lines is correct.

Rules-driven. Types 43, 76 and 77 read their behaviour from a file, so adding or changing a format is a configuration change rather than a new release. Point CFGFILE= at the file. Type 76 accepts either the JSON rules format or the older text grammar; a missing file stops the line from opening.

Contact ID (900). Contact ID reaches most sites inside a receiver's own framing — through type 13, type 38, or types 52 and 63 — and those lines stay as they are. Type 900 exists for the case where bare Contact ID arrives on the line on its own.



Was this helpful?