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

[Bager2700 <bager2700@xxxxxxxxx>]

On Thursday, January 13, 2022 at 8:02:25 PM UTC-8, 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
Hey Keith
Thanks for the info, it sounds like you enjoy actually knowing how things w=
ork instead of just, working or not working.
I do not have info on Radionics BFSK but if I fined some I will let you kno=
w.

Regarding 4/2 at 20BPS
I have reversed engineered the data stream and have found the following:
The digit pulse are 32-40ms depending on the TX unit used
The space between digit pulse are 12-17 ms
and then repeat for the number of digits required for the account.  Then, t=
he spacing this is followed by 663-672ms of time between the first set of p=
ulses to the next set.  The spacing between rounds of data is 3.25-3.76 sec=
onds.

if the account number was 0000-AA then the complete data transfer time is 7=
5.12 seconds which is about as bad as it can get.  If the account was 1111-=
11 then this can be reduced to 3.53seconds which is very slow to today's st=
andards but that was how it use to be.

The ACK/Kissoff for approx 750ms is all that is required in most cases howe=
ver older panels like a 750ms to 1500 ms depending on the format used.=20
I guess this info will just pass-over most "installers" on here but not ALL=
.... here is to your Receiver Unit you are building looking forward to hear=
ing more.=20