Re: 4/2 4/1 Timing Protocol Spefications wanted (Alarm protocols)

[KJ7BZC <herbertclan4@xxxxxxxxx>]

On Thursday, January 13, 2022 at 9:02:25 PM UTC-7, alar...@xxxxxxx wrote:
> On Thursday, January 13, 2022 at 11:57:27 AM UTC-5, herber...@xxxxxxxxx w=
rote:=20
> > On Tuesday, December 28, 2021 at 2:25:52 PM UTC-7, Bager2700 wrote:=20
> > > Hey I know 4/2 protocol is older than the days, however I am looking =
for the specs for the timing of the protocol.=20
> > >=20
> > > AKA from Dialer going on line to waiting for station receiver online =
panel data tone bursts --- ACK -- kissoff etc.=20
> > >=20
> > > Although the timing is fairly flexible i would like to know the actua=
l specs for the sequence and timing.=20
> > >=20
> > > I have the SIA, Contact ID, FSK, etc but 4/2 formats i have not found=
 information.=20
> > > Does anyone have the info?=20
> > > Thanks inadvance=20
> > Hello,=20
> > I'm not really sure that there were standardized timings for pulse form=
ats, I have many systems that have different delays in them.=20
> >=20
> > I can tell you that the duration for the ACK/HANDSHAKE tone is slightly=
 different between receivers, my Radionics D6500 defaults to a 1.2 second t=
one, my ITI CS4000 is about 2 seconds, and my Radionics D6000 is about 2.8 =
seconds. I haven't ever had a panel really have trouble with tones that are=
 around 1 second, though I'd suggest going slightly longer than this, as th=
e really old panels will need it to detect the tone reliably.=20
> >=20
> > A good reference for the digit timing and such is the Radionics D6500 p=
rogram entry guide, as it has defaults for how long the receiver waits for =
the next round of digits, and how long it looks for the next digit. The rec=
eiver defaults to waiting up to 6 seconds for the next round of digits from=
 the panel, indicating that it won't take longer than this for panels to se=
nd the next round of digits. The receiver also waits up to 1.4 seconds for =
the next digit in a round by default. Effectively, the panel shouldn't have=
 more than 1.4 seconds in between digits, and shouldn't take longer than 6 =
seconds to send the second round. Additionally, the panel should wait longe=
r than 1.4 seconds before sending the next round of digits, so that the rec=
eiver doesn't count it as part of the first round. There doesn't seem to be=
 an industry standard for a minimum for these values, so it is not easy to =
give suggestions on what you should use, but those maximums are good things=
 to keep in mind. If you'd like, l could take some measurements of what the=
 various systems reporting to my receivers are using, perhaps it could be u=
seful to you to have recordings of multiple different panels reporting?=20
> >=20
> > In terms of the time between the panel dialing and the receiver answeri=
ng, it really depends on how long it takes for the call to be routed to the=
 receiver, and for the receiver to detect and answer the ringing call. Most=
 panels will wait about 30 seconds for this process, but some have an optio=
n to extend it to 45. I have never seen it actually take that long for the =
receiver to answer, but you also have to consider that most receivers will =
provide multiple different handshake tones for different formats, and somet=
imes the 1400hz or 2300hz one isn't early in the list. I'd say 30 seconds i=
s a reasonable amount of time to wait before making another dialing attempt=
.=20
> >=20
> > I'm not sure if you're trying to make a dialer or receiver, but if its =
the receiver, you should also remember to wait about 2 seconds after answer=
ing the line before sending the handshake tone, this lets the line stabiliz=
e and is a standard feature of most receivers. Another thing to consider if=
 making a receiver, is to support the pulse formats other than 4+2. There a=
re also 3+1, 3+1 with checksum, 3+1 extended, 3+1 extended with checksum, 4=
+1, 4+1 extended, 3+2, the list goes on and on.=20
> >=20
> > Hopefully I can be some help to you, as I know that finding information=
 on the really old formats is quite hard. I'm personally trying to find inf=
ormation on the Radionics BFSK format.=20
> >=20
> > Keith
> So Kieth - - - - That's really cool that you know all of this but the que=
stion is ;=20
> how is it that you know all this info? It's not something typically an in=
staller would know.=20
> .=20
> As an aside. I think the OP won't benefit from your info. He's not a regu=
lar here and will likely not check back

I'm actually not in the industry yet, I just got a job at a local alarm com=
pany, so soon I will be, but I haven't actually done installations yet. I h=
ave been studying the older central station equipment and reporting formats=
 for a little over a year now, as I am designing my own receiver, so I have=
 figured out the normal timing for pulse formats after dealing with them fo=
r a while. Working with those three receivers I listed has helped a lot in =
understanding how the pulse formats work and learning the timing that they =
use as well.

I don't really expect the OP to respond, but thought I'd share what I know =
anyways in case they do.

Keith