> >
> John R. Haggis wrote:
>
> > Are they saying the R/T have fixed code prefixes inside?  Would they
> > distribute matching sets to the same areas?  That would be bad.  Who's to
> > say they don't do this?
> >
> > Anyone have any hard information on this?
Batching sets to an area would be uneconomical given the sales rates of alarms.
There are at least half a dozen different coding chips on the market, each uses
a slightly different way of producing the code.
_Most_ of them use at least 12 bit code.
A couple of Motorola devices use 3-way sensing on the inputs
i.e. pos, neg, or floating input gives a code differ.
Thats 12 x 3 x,,, er, who's got a calculator ? :)

Now if you did it with a PIC, you could have 8 bits user selected and a couple
of locs. with random nos pre-programmed. Mix and match before transmitting and
have the decode routine learn it's relevant Tx code. That gives you 24 bit code
with one 8 way dil-switch. Then transmit the code twice, the second time
inverted and code samplers will just fall over.

Then Werner wrote ;
> >
>
> Even if they do have longer codes than just the eight bits, the code could
> still be sampled by a fast microprocessor in much the same manner as the
> multiple IR remote control devices work which "learns" a code.  Unless the
> code is different every time you press the button, there will be an easy
> option to decipher the code.  I have experimented with this and it is
> definetely possible.

Possible, but an unrealistic time-scale. The micro does'nt have to be fast BTW
'cos the code is not transmitted all that fast, a PIC running at 8 Meg would
still take, from memory over 3 hours to cycle.
__
   TAK