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

[Jim Davis <alarminex@xxxxxxx>]

On Thursday, January 13, 2022 at 11:57:27 AM UTC-5, herber...@xxxxxxxxx wro=
te:
> 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 fo=
r the specs for the timing of the protocol.=20
> >=20
> > AKA from Dialer going on line to waiting for station receiver online pa=
nel data tone bursts --- ACK -- kissoff etc.=20
> >=20
> > Although the timing is fairly flexible i would like to know the actual =
specs for the sequence and timing.=20
> >=20
> > I have the SIA, Contact ID, FSK, etc but 4/2 formats i have not found i=
nformation.=20
> > Does anyone have the info?=20
> > Thanks inadvance
> Hello,=20
> I'm not really sure that there were standardized timings for pulse format=
s, 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 d=
ifferent between receivers, my Radionics D6500 defaults to a 1.2 second ton=
e, my ITI CS4000 is about 2 seconds, and my Radionics D6000 is about 2.8 se=
conds. I haven't ever had a panel really have trouble with tones that are a=
round 1 second, though I'd suggest going slightly longer than this, as the =
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 pro=
gram entry guide, as it has defaults for how long the receiver waits for th=
e next round of digits, and how long it looks for the next digit. The recei=
ver defaults to waiting up to 6 seconds for the next round of digits from t=
he panel, indicating that it won't take longer than this for panels to send=
 the next round of digits. The receiver also waits up to 1.4 seconds for th=
e next digit in a round by default. Effectively, the panel shouldn't have m=
ore than 1.4 seconds in between digits, and shouldn't take longer than 6 se=
conds to send the second round. Additionally, the panel should wait longer =
than 1.4 seconds before sending the next round of digits, so that the recei=
ver doesn't count it as part of the first round. There doesn't seem to be a=
n industry standard for a minimum for these values, so it is not easy to gi=
ve suggestions on what you should use, but those maximums are good things t=
o keep in mind. If you'd like, l could take some measurements of what the v=
arious systems reporting to my receivers are using, perhaps it could be use=
ful to you to have recordings of multiple different panels reporting?=20
>=20
> In terms of the time between the panel dialing and the receiver answering=
, it really depends on how long it takes for the call to be routed to the r=
eceiver, and for the receiver to detect and answer the ringing call. Most p=
anels will wait about 30 seconds for this process, but some have an option =
to extend it to 45. I have never seen it actually take that long for the re=
ceiver to answer, but you also have to consider that most receivers will pr=
ovide multiple different handshake tones for different formats, and sometim=
es the 1400hz or 2300hz one isn't early in the list. I'd say 30 seconds is =
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 th=
e receiver, you should also remember to wait about 2 seconds after answerin=
g the line before sending the handshake tone, this lets the line stabilize =
and is a standard feature of most receivers. Another thing to consider if m=
aking a receiver, is to support the pulse formats other than 4+2. There are=
 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 o=
n the really old formats is quite hard. I'm personally trying to find infor=
mation on the Radionics BFSK format.=20
>=20
> Keith

So Kieth - - - - That's really cool that you know all of this but the quest=
ion is ;
how is it that you know all this info?  It's not something typically an ins=
taller would know.
.
As an aside. I think the OP won't benefit from your info. He's not a regula=
r here and will likely not check back