[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

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



On Tuesday, December 28, 2021 at 2:25:52 PM UTC-7, Bager2700 wrote:
> 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 pane=
l data tone bursts --- ACK -- kissoff etc.=20
>=20
> Although the timing is fairly flexible i would like to know the actual sp=
ecs for the sequence and timing.=20
>=20
> I have the SIA, Contact ID, FSK, etc but 4/2 formats i have not found inf=
ormation.=20
> Does anyone have the info?=20
> Thanks inadvance

Hello,
I'm not really sure that there were standardized timings for pulse formats,=
 I have many systems that have different delays in them.

I can tell you that the duration for the ACK/HANDSHAKE tone is slightly dif=
ferent between receivers, my Radionics D6500 defaults to a 1.2 second tone,=
 my ITI CS4000  is about 2 seconds, and my Radionics D6000 is about 2.8 sec=
onds. I haven't ever had a panel really have trouble with tones that are ar=
ound 1 second, though I'd suggest going slightly longer than this, as the r=
eally old panels will need it to detect the tone reliably.=20

A good reference for the digit timing and such is the Radionics D6500 progr=
am 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 receive=
r 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 send t=
he 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 mor=
e than 1.4 seconds in between digits, and shouldn't take longer than 6 seco=
nds to send the second round. Additionally, the panel should wait longer th=
an 1.4 seconds before sending the next round of digits, so that the receive=
r 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 var=
ious systems reporting to my receivers are using, perhaps it could be usefu=
l to you to have recordings of multiple different panels reporting?

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 rec=
eiver, and for the receiver to detect and answer the ringing call. Most pan=
els 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 rece=
iver to answer, but you also have to consider that most receivers will prov=
ide multiple different handshake tones for different formats, and sometimes=
 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.

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 answering =
the line before sending the handshake tone, this lets the line stabilize an=
d is a standard feature of most receivers. Another thing to consider if mak=
ing a receiver, is to support the pulse formats other than 4+2. There are a=
lso 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.

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 informa=
tion on the Radionics BFSK format.

Keith


alt.security.alarms Main Index | alt.security.alarms Thread Index | alt.security.alarms Home | Archives Home