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

[KJ7BZC <herbertclan4@xxxxxxxxx>]

On Friday, January 14, 2022 at 11:29:32 AM UTC-7, Bager2700 wrote:
> On Thursday, January 13, 2022 at 8:02:25 PM UTC-8, alar...@xxxxxxx wrote:=
=20
> > On Thursday, January 13, 2022 at 11:57:27 AM UTC-5, herber...@xxxxxxxxx=
 wrote:=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 lookin=
g for the specs for the timing of the protocol.=20
> > > >=20
> > > > AKA from Dialer going on line to waiting for station receiver onlin=
e panel data tone bursts --- ACK -- kissoff etc.=20
> > > >=20
> > > > Although the timing is fairly flexible i would like to know the act=
ual specs for the sequence and timing.=20
> > > >=20
> > > > I have the SIA, Contact ID, FSK, etc but 4/2 formats i have not fou=
nd 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 fo=
rmats, 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 slight=
ly different 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 seconds. I haven't ever had a panel really have trouble with tones that a=
re around 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=
 program entry guide, as it has defaults for how long the receiver waits fo=
r the next round of digits, and how long it looks for the next digit. The r=
eceiver defaults to waiting up to 6 seconds for the next round of digits fr=
om the 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 fo=
r the next digit in a round by default. Effectively, the panel shouldn't ha=
ve 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 lon=
ger than 1.4 seconds before sending the next round of digits, so that the r=
eceiver 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 t=
o give suggestions on what you should use, but those maximums are good thin=
gs to keep in mind. If you'd like, l could take some measurements of what t=
he various systems reporting to my receivers are using, perhaps it could be=
 useful to you to have recordings of multiple different panels reporting?=
=20
> > >=20
> > > In terms of the time between the panel dialing and the receiver answe=
ring, it really depends on how long it takes for the call to be routed to t=
he receiver, and for the receiver to detect and answer the ringing call. Mo=
st panels will wait about 30 seconds for this process, but some have an opt=
ion to extend it to 45. I have never seen it actually take that long for th=
e receiver to answer, but you also have to consider that most receivers wil=
l provide multiple different handshake tones for different formats, and som=
etimes 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 attem=
pt.=20
> > >=20
> > > I'm not sure if you're trying to make a dialer or receiver, but if it=
s the receiver, you should also remember to wait about 2 seconds after answ=
ering the line before sending the handshake tone, this lets the line stabil=
ize 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=
 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 informati=
on on the really old formats is quite hard. I'm personally trying to find i=
nformation on the Radionics BFSK format.=20
> > >=20
> > > Keith=20
> > So Kieth - - - - That's really cool that you know all of this but the q=
uestion is ;=20
> > how is it that you know all this info? It's not something typically an =
installer would know.=20
> > .=20
> > As an aside. I think the OP won't benefit from your info. He's not a re=
gular here and will likely not check back
> Hey Keith=20
> Thanks for the info, it sounds like you enjoy actually knowing how things=
 work instead of just, working or not working.=20
> I do not have info on Radionics BFSK but if I fined some I will let you k=
now.=20
>=20
> Regarding 4/2 at 20BPS=20
> I have reversed engineered the data stream and have found the following:=
=20
> The digit pulse are 32-40ms depending on the TX unit used=20
> The space between digit pulse are 12-17 ms=20
> and then repeat for the number of digits required for the account. Then, =
the spacing this is followed by 663-672ms of time between the first set of =
pulses to the next set. The spacing between rounds of data is 3.25-3.76 sec=
onds.=20
>=20
> if the account number was 0000-AA then the complete data transfer time is=
 75.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 s=
tandards but that was how it use to be.=20
>=20
> The ACK/Kissoff for approx 750ms is all that is required in most cases ho=
wever 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 A=
LL.... here is to your Receiver Unit you are building looking forward to he=
aring more.

Interesting findings, though I think that your timing values for the pulse =
on/off time may be a bit off. At 20pps it is 25ms on, 25ms off (10pps is 50=
ms on, 50ms off), typical space between digits is about 300ms, and time bet=
ween rounds is about 3 seconds. The longest possible transmission is FFFF-F=
F, an "F" is 15 pulses, which takes about 20 seconds for the whole double r=
ound transmission. Using 10pps with the same timings takes longer, but is n=
owhere near 75 seconds, maybe 40 at the most. This was taken from a Scantro=
nic SC800 panel transmitting to a Radionics D6500 receiver, It is about the=
 same for other panels and other receivers, but this seems to be the averag=
e based on tests I've done earlier. You may have been measuring the 40pps o=
r otherwise knows as "Radionics Superfast" format, which has 12.5ms on/12.5=
ms off for the pulses.

I'll probably make some form of post here showing my receiver whenever I ge=
t around to finishing it. I have the design for the phone line interface do=
ne already, just need to figure out how I'll be detecting the pulses from t=
he panel. It'll be supporting Contact ID, pulse formats, BFSK if I can deco=
de it, my custom modem format, and maybe a few other DTMF formats.

Keith