View topic - DSC Keybus Protocol

Search

DSC Keybus Protocol

AVR Freaks Forum Index » General Electronics Technical Forums » General Electronics

Author

Message

mcd1992

Posted: Mar 04, 2011 - 11:42 PM

Joined: Sep 25, 2010
Posts: 3

I am trying to understand this protocol that my DSC 1555 alarm uses between the base and the keypad, but issue is its propriatary of some sorts. There was another thread about it on this forums but it ended prematurely with the guy just checking one bit for stay or away mode.

From what I know about this protcol so far the clock line runs at 1kHz with 50% duty and oddly enough only does so for 41.6ms then it stays high for 5.4ms and starts all over again. The data line seems to transistion on either the falling or rising edge of the clock (or in the middle), which led Kortuk of chiphacker.com to belive that it is NRZ encoding which I'm not sure of yet but here are some OLS dumps of the data and clock lines hopefully with teamwork we can figure this out.

I'm pretty sure the data is the same as whats listed in the PC5401 pdf below just sent via some weird protocol, all I really need help with is figuring out whats a 1 and whats a 0. From there I'm confident I can figure out the rest. Thanks for your time Very Happy

0 is the Data line, 1 is the Clock

DSC OLS Dump
ECP Patent
PC5401 Dev-PDF
Previous AVRFreaks Thread

Last edited by mcd1992 on Mar 05, 2011 - 12:50 AM; edited 1 time in total

peret

Posted: Mar 05, 2011 - 12:36 AM

Joined: May 26, 2004
Posts: 2538
Location: Las Vegas, Nevada

I have a DSC system, but I've never bothered to investigate it. I assumed, since it's a 4 wire connection to all the keypads in parallel, that it used some kind of RS485 multi-drop protocol, or possibly I2C.

I'm not quite sure what I'm looking at in your .ols files - I assume bit 0 is one line and bit 1 is the other, but I can't make sense of the data.

mcd1992

Posted: Mar 05, 2011 - 12:53 AM

Joined: Sep 25, 2010
Posts: 3

Forgot to mention 0 is Data and 1 is Clock

From what more I've read in patent 6868493 it appears that the actual MCU on the DSC alarm speaks RS485 then I'm guessing somewhere else it is changed into the propriatary ADEMCO ECP (Expanded Console Protocol)

The OLS files are for the OpenLogic Sniffer client

peret

Posted: Mar 05, 2011 - 01:19 AM

Joined: May 26, 2004
Posts: 2538
Location: Las Vegas, Nevada

The DSC keypads are so cheap, and so simple, that I find it hard to believe they could afford any external circuitry to change to a protocol not supported by the main chip. Of course we don't know what that is, since the chip is masked and proprietary. Maybe plotting out the clock and data on paper will make sense of it.

You have to go a long way down the "idle_test.ols" to find a state where both clock and data are low at the same time, and then it's only present for a couple of samples.

mcd1992

Posted: Mar 05, 2011 - 01:44 AM

Joined: Sep 25, 2010
Posts: 3

That is true, I never thought about the keypad itself having to TX back to the base.

mrboard

Posted: Mar 31, 2011 - 10:19 PM

Joined: Mar 31, 2011
Posts: 2

I was in a similar situation with a DSC 1580 base central. I have no oscilloscope so I don't know the exact timings but I have figured out the protocol.

Signalling is made with a CLK line (yellow) and DATA line (green). The frequency is 1kHz. Base central acts as a master unit and all panels as slaves.
Before any command is sent by the master, a synchronization occurs where CLK is high for approx. 5-10 ms. After this, CLK is a square wave with 1ms cycle until all data bits has been sent followed by next synchronization.
The tricky part was to realize that data is sent bidirectionally between master and slaves at the same time. On falling CLK flanks, master sends a bit on DATA line and on rising CLK flanks, slave sends a bit.

I don't know the exact timing, but if I read DATA line 400us after CLK flank, it works for me.
I strongly suspect that a slave (panel) just has an open-drain on the DATA line, if nothing is sent it will read back as a logical 1.

Data sent by the master is mostly of the form:
Command (8 bits)
Zero padding (1 bit)
Data (x * 8 bits)
Checksum (8 bits)

Some commands don't have a checksum. It may be to support old panels as it seems that these are mostly followed by another command containing the same data and a checksum.

The checksum is a simple sum of the other bytes.
Slaves respond from the 9:th bit and onward.

For example, to detect which panels are available, master sends 0x11 as command. Each panel respond by sending two zeros at position 9 + ((slot-1) * 2) where slot is the programmed slot for that panel [1-8].

I hope this will be of help, I had no luck in finding any information about this protocol anywhere so I had to do it the hard way.

mrboard

Posted: Apr 03, 2012 - 11:55 PM

Joined: Mar 31, 2011
Posts: 2

Here are some protocol details found by inspecting data and guessing:

Commands sent from master (first byte):

0x05 - Status update (no checksum, no zone info)
0x27 - Status update (extended version of the above, with checksum)
Second byte:
100EBMAR (LEDs: E=Error, B=Bypass, M=Memory, A=Armed, R=Ready)
Third byte:
text message code (0x01=Enter code, 0x03=Close all sections, 0x11=System armed ...)
Fourth byte:
always 0x01
Fifth byte:
always 0x81
Sixth byte:
Open zones 1-8

0xA5 - Time
(Offset is in bits starting with 0 including 1 bit zero-padding after 8 bit command)
Offset Length Data
9 4 Year digit 3
13 4 Year digit 4
19 4 Month
23 5 Day
28 5 Hour
33 6 Minute

0x11 - Query available keypads (no checksum)
Each keypad in slot 1-8 will respond with two zeros if present.
i.e. the response bits are:
aabbccddd ...
a = Keypad in slot 1 present
b = Keypad in slot 2 present
For example:
11110011 ... (Keypad in slot 3 present)

0x0A - Status in menu mode
0xC3 - no idea
0x16 - no idea
0x1C - emergency button acknowledge?
0x5D - alarm memory?
0xB1 - zone configuration?
0x64 - beep command
second byte:
0x06 - 3 short beeps
0x0a - 4 short beeps
0x0c - long beep

Response commands sent by keypads:

0xBB - Fire emergency button pressed
0xDD - Assistant emergency button pressed
0xEE - Police emergency button pressed

Second byte of the response is the pressed key:
xxxxxxcc (x = key, c = checksum)

Code for verifying checksum of the key:
unsigned int l_Key = p_Packet.m_Bytes[1] >> 2;
unsigned int l_ChkSum = p_Packet.m_Bytes[1] & 0x03;
bool l_bChkSumOk = ((((l_Key >> 4) & 0x03) + ((l_Key >> 2) & 0x03) + (l_Key & 0x03)) & 0x03) == l_ChkSum;

riviera65

Posted: Oct 31, 2012 - 11:31 PM

Joined: Oct 31, 2012
Posts: 7

MrBoard, what you posted until now has been true for me, and I want to share. I got and arduino sketch working to try to decipher the code. It works, but not for all possibilities. Code 0x5 works, and is being sent every second or so. Reading the info goes as follows:

Wait for a long HIGH clk signal. Then read data on every clk rise until message is finished.

I get data that seems really good, but I'm missing details. If somebody has more detail on how to interpret the data, I'll be really happy to know

Code is here:

Code:

#define CLK 11

#define DTA 12

String st;

String msg;

long ledActivity;

void setup()

{

  pinMode(CLK,INPUT);

  pinMode(DTA,INPUT);

  pinMode(13,OUTPUT);

  Serial.begin(9600);

  Serial.println("Start");

}

void loop()

{

    // Display led if no activity. Detect activity on bus

    if (millis() - ledActivity > 1000) digitalWrite(13,0); else digitalWrite(13,1);

    if (waitCLKchange(1) > 200)

    {

      // Message start detected

      st = "";

      msg = "";

      while (1)

      {

        // CLK is low. Let's wait until it goes up, max 500 usec.

        if (waitCLKchange(0) > 50) break;

        // CLK is high. Read a bit

        delayMicroseconds(100);

        if (digitalRead(DTA)) st += "1"; else st += "0";

        // Wait for CLK to drop again

        if (waitCLKchange(1) > 50) break;

      }

      // Get command number

      int cmd = getBinaryData(st,0,8);

      // Command 5 is status from panel. If we got a status, we got activity. Reset counter for inactvity for the LED

      if (cmd == 5 || cmd == 0x27) ledActivity = millis();

      if (cmd == 5)

      {

        int zones = getBinaryData(st,9+8+8+8,8);

        msg += "Zones " + String(zones);

      }

      // Interpret the TIME broadcast

      if (cmd == 165)

      {

        int year3 = getBinaryData(st,9,4);

        int year4 = getBinaryData(st,13,4);

        int month = getBinaryData(st,19,4);

        int day = getBinaryData(st,23,5);

        int hour = getBinaryData(st,28,5);

        int minute = getBinaryData(st,33,6);

        msg += "Date: 20" + String(year3) + String(year4) + " " + String(month) + " " + String(day) + " " + String(hour) + ":" + String(minute);

      }

      // Send findings to USB port

      if (cmd != 0 && st != "00000101010000001000000010000000011000111000000001100011100000000110001111")

      {

        Serial.print(st);

        Serial.print(" ");

        Serial.print(cmd);

        Serial.print(" ");

        Serial.print(msg);

        Serial.println("");

      }

    }

}

int waitCLKchange(int currentState)

{

  int c = 0;

  while (digitalRead(CLK) == currentState)

  {

    delayMicroseconds(10);

    c++;

    if (c > 1000) break;

  }

  return c;

}

int getBinaryData(String st, int offset, int length)

{

  int buf = 0;

  for(int j=0;j<length;j++)

  {

    buf <<= 1;

    if (st[offset+j] == '1') buf |= 1;

  }

  return buf;

}

riviera65

Posted: Nov 01, 2012 - 02:30 AM

Joined: Oct 31, 2012
Posts: 7

I can also confirm that my PC1616 DSC panel sends data on the CLK line going UP (HIGH), and that the keypads respond on the CLK line going down.

Here is a sample of data coming from the panel.

00000101 0 10000000 00000011 00000000 11000111 00000000 11000111 00000000 11000111 1 zone 3
00000101 0 10000001 00000010 00000000 11000111 00000000 11000111 00000000 11000111 1 zone 2
00000101 0 10000000 00000011 00000000 11000111 00000000 11000111 00000000 11000111 1 zone 4
00000101 0 10000001 00000010 00000000 11000111 00000000 11000111 00000000 11000111 1 zone 1
00000101 0 10000001 00000001 00000000 11000111 00000000 11000111 00000000 11000111 1 no zone
00000101 0 10000011 00001000 00000000 11000111 00000000 11000111 00000000 11000111 1 arm delay
00000101 0 10000011 00001000 00000000 11000111 00000000 11000111 00000000 11000111 1 arm delay short beeps
00000101 0 10000010 00000101 00000000 11000111 00000000 11000111 00000000 11000111 1 armed

For the life of me, the "normal no zone trespassed" string I've verified many times, but I can't understand why I don't see zeros for the third group of bits.

If someone smarter than me figures it out, I'll be happy to know where I'm wrong.

Torby

Posted: Nov 01, 2012 - 02:22 PM

Joined: Nov 11, 2003
Posts: 4040
Location: Chicago Illinois USA

Amazing freaks have about everything figured out!

_________________
Discursive design,

Torby

Some days, it's just not worth chewing through the restraints.

riviera65

Posted: Nov 16, 2012 - 02:41 PM

Joined: Oct 31, 2012
Posts: 7

Hi,

Here is the circuit I built to connect the arduino to the DSC Keybus:

Then, here is the Arduino code. Completely rewritten to use interrupt on pin 2 (interrupt 0), because otherwise it seems too slow to be able to receive all messages

Code:

#define CLK 2

#define DTA 4

String st, old;

unsigned long lastData;

void setup()

{

  pinMode(CLK,INPUT);

  pinMode(DTA,INPUT);

  pinMode(13,OUTPUT);

  Serial.begin(57600);

  Serial.println("Start");

  // Interrupt 0 = PIN 2 externe

  attachInterrupt(0,clkCalled,RISING);

}

void loop()

{

  if (millis() - lastData > 500)

    digitalWrite(13,0); 

  else 

    digitalWrite(13,1);

  if (waitCLKchange(1) < 2000) return;

  String stc = st;

  st = "";

  int cmd = getBinaryData(stc,0,8);

  if (cmd == 0x05) lastData = millis(); // Reset led counter

  if (stc == old) return;

  if (cmd == 0) return;

  old = stc;

  String msg;

  // Interpreter les donnees

  if (cmd == 0x05)

  {

    if (getBinaryData(stc,12,1)) msg += "Error";

    if (getBinaryData(stc,13,1)) msg += "Bypass";

    if (getBinaryData(stc,14,1)) msg += "Memory";

    if (getBinaryData(stc,15,1)) msg += "Armed";

    if (getBinaryData(stc,16,1)) msg += "Ready";

  }

  if (cmd == 0xa5)

  {

    int year3 = getBinaryData(stc,9,4);

    int year4 = getBinaryData(stc,13,4);

    int month = getBinaryData(stc,19,4);

    int day = getBinaryData(stc,23,5);

    int hour = getBinaryData(stc,28,5);

    int minute = getBinaryData(stc,33,6);

    msg += "Date: 20" + String(year3) + String(year4) + "-" + String(month) + "-" + String(day) + " " + String(hour) + ":" + String(minute);

  }

  if (cmd == 0x27)

  {

    msg += "Zones: ";

    int zones = getBinaryData(stc,8+1+8+8+8+8,8);

    if (zones & 1) msg += "1";

    if (zones & 2) msg += "2";

    if (zones & 4) msg += "3";

    if (zones & 8) msg += "4";

    if (zones & 16) msg += "5";

    if (zones & 32) msg += "6";

    if (zones & 64) msg += "7";

    if (zones & 128) msg += "8";

  }

  Serial.print(formatDisplay(stc));

  Serial.print("-> ");

  Serial.print(cmd,HEX);

  Serial.print(":");

  Serial.println(msg);

}

void clkCalled()

{

  if (st.length() > 200) return; // Do not overflow the arduino's little ram

  if (digitalRead(DTA)) st += "1"; else st += "0";

}

unsigned long waitCLKchange(int currentState)

{

  unsigned long c = 0;

  while (digitalRead(CLK) == currentState)

  {

    delayMicroseconds(10);

    c += 10;

    if (c > 10000) break;

  }

  return c;

}

String formatDisplay(String st)

{

  String res;

  res = st.substring(0,8) + " " + st.substring(8,9) + " ";

  int grps = (st.length() - 9) / 8;

  for(int i=0;i<grps;i++)

  {

    res += st.substring(9+(i*8),9+((i+1)*8)) + " ";

  }

  res += st.substring((grps*8)+9,st.length());

  return res;

}

unsigned int getBinaryData(String st, int offset, int length)

{

  int buf = 0;

  for(int j=0;j<length;j++)

  {

    buf <<= 1;

    if (st[offset+j] == '1') buf |= 1;

  }

  return buf;

}

This way, I get codes 0x05, 0x27 0xa5 and others. Seems to work well. The code is not complete though, because I still need to make events happen (for example, disconnect the battery) and find out how to identify these events from the data the DSC spits out.

If somebody was to redo this, please share information about what you get out of it, I'd be really interested.

arduino_rich

Posted: Dec 06, 2012 - 05:13 AM

Joined: Dec 06, 2012
Posts: 2

riviera65 wrote:

Then, here is the Arduino code. Completely rewritten to use interrupt on pin 2 (interrupt 0), because otherwise it seems too slow to be able to receive all messages

Thanks for your code, riviera65, I'm using it to decode my own DSC unit, I think I have discovered some new information. I want to know which Access code arms and disarms, and I believe the information is encoded on the 0xA5 time/status line. Following the time are two zero bits, then bits 41-48 seem to indicate whether a system is being armed or disarmed, and by whom. Bits 41&42 are 0x02 for arming, and 0x03 for disarming. Subtracting 0x99 from the arming code and 0xC0 from the disarm code reveal the Access code (01..32, and master code 40 is represented as following duress code 34). Some examples, the first line is the entire string, the following are just the 8 bits pointed at:

Code:

10100101 1 0001 0010 01 1100 00010 00010 010101 00 10011001 11111111 01010101 1

0xA5:Date:2012-12-2 2:21                           ^^^^^^^^

10011001 is arming, user code 01

11000000 is disarming, user code 01

10100000 is arming, user code 01

11000111 is disarming, user code 08

10111011 is arming, master code (i.e. "35")

11100010 is disarming, master code (i.e. "35")

8 bits of ones follow a user code, plus another 8 bits unless it's a master code. Both sequences are then followed by a single bit (usually 1). I haven't been able to decode the last full byte for a user code (preceding the 1 bit).
Can anyone duplicate these findings?

riviera65

Posted: Dec 09, 2012 - 09:08 PM

Joined: Oct 31, 2012
Posts: 7

Hi Arduino_rich,

I reproduced your idea on my system.

Code:

   DDDDDDDD  DDDDDDDDDDDDDDDDDDDDA

a5:00010010011011101101000111101110100110110000000001111111 ARM user 0

a5:00010010011011101101001000011010100110110000000010101100 ARM user 1

a5:00010010011011101101001000001110100110110000000010100000 ARM user 2

a5:00010010011011101101001000100010100110110000000010110100 ARM user 40

a5:00010010011011101101001000001100110000000000000011000011 DISARM user 1

a5:00010010011011101101001000000000110000010000000010111000 DISARM user 2

a5:00010010011011101101001000100000111000100000000011111001 DISARM user 40

In this data, these are the a5 packets I received for different events. The first line identifies with the D which bits are used for Date and time (this I'm sure), The A is probably the Armed status (not completely sure yet). But, for the remaining bits (the last eight), I can't say I'm sure I get the same thing you do, and I'm not able to get the user number from those. Maybe you can? I'm still trying to make sense out of it though. I'll post other details if I finally get the enlightenment... Wink

Edit: Please disregard this example, I think I did not take the right A5 message, since when I arm the system, I get one first A5 message when the code is entered, and then another one when the exit delay has expired and the system is really armed. This is the second A5 that I displayed in the example above, and the first one seems better. Here is the first one:

Code:

   DDDDDDDD  DDDDDDDDDDDDDDDDDDDDA

a5:00010010011011101101000111101100101111110000000010100001 BEFORE ARM user 0

a5:00010010011011101101001000011000100110010000000010101000 BEFORE ARM user 1

a5:00010010011011101101001000001100100110100000000010011101 BEFORE ARM user 2

a5:00010010011011101101001000100000101110110000000011010010 BEFORE ARM user 40

riviera65

Posted: Dec 09, 2012 - 09:52 PM

Joined: Oct 31, 2012
Posts: 7

More info found.

Code:

   DDDDDDDDPPDDDDDDDDDDDDDDDDDDDDA   UUUUUU

a5:00010010011011101101000111101100101111110000000010100001 BEFORE ARM user 0

a5:00010010011011101101000111101110100110110000000001111111 ARM user 0

a5:00010010011011101101001000011000100110010000000010101000 BEFORE ARM user 1

a5:00010010011011101101001000011010100110110000000010101100 ARM user 1

a5:00010010011011101101001000001100100110100000000010011101 BEFORE ARM user 2

a5:00010010011011101101001000001110100110110000000010100000 ARM user 2

a5:00010010011011101101001000100000101110110000000011010010 BEFORE ARM user 40

a5:00010010011011101101001000100010100110110000000010110100 ARM user 40

a5:00010010011011101101001000001100110000000000000011000011 DISARM user 1

a5:00010010011011101101001000000000110000010000000010111000 DISARM user 2

a5:00010010011011101101001000100000111000100000000011111001 DISARM user 40

   DDDDDDDDPPDDDDDDDDDDDDDDDDDDDDA     B

a5:00010010001011101101001010100000111001111111111100111101 Battery disconnect

a5:00010010001011101101001010101100111011111111111101010001 Battery reconnect

In this data, I think I identified by PP the partition number. When this number is partition 1, we get a user (U section) in this weird encoding that I still have to figure out (I know you did, but I'm still stumped)

If we get partition 0, then the information is not a user but an error status (see how the B byte could be battery error, I'll have to get more data)

The hunt continues... Wink

Rogerbarnes

Posted: Dec 10, 2012 - 11:17 AM

Joined: Dec 09, 2012
Posts: 3

mcd1992 wrote:

I am trying to understand this protocol that my DSC 1555 alarm uses between the base and the keypad, but issue is its propriatary of some sorts. There was another thread about it on this forums but it ended prematurely with the guy just checking one bit for stay or away mode.

From what I know about this protcol peimar led lights so far the clock line runs at 1kHz with 50% duty and oddly enough only does so for 41.6ms then it stays high for 5.4ms and starts all over again. The data line seems to transistion on either the falling or rising edge of the clock (or in the middle), which led Kortuk of chiphacker.com to belive that it is NRZ encoding which I'm not sure of yet but here are some OLS dumps of the data and clock lines hopefully with teamwork we can figure this out.

I'm pretty sure the data is the same as whats listed in the PC5401 pdf below just sent via some weird protocol, all I really need help with is figuring out whats a 1 and whats a 0. From there I'm confident I can figure out the rest. Thanks for your time Very Happy

0 is the Data line, 1 is the Clock

DSC OLS Dump
ECP Patent
PC5401 Dev-PDF
Previous AVRFreaks Thread

I have used system many a times but never tried to learn the protocol

Last edited by Rogerbarnes on Dec 11, 2012 - 10:34 AM; edited 1 time in total

arduino_rich

Posted: Dec 10, 2012 - 06:33 PM

Joined: Dec 06, 2012
Posts: 2

Here are some code changes to the Nov 16, 2012 - 03:41 PM post which should help with the user codes,
Add this to the end of the "if (cmd == 0xa5)" section:

Code:

    int arm = getBinaryData(stc,41,2);

    int master = getBinaryData(stc,43,1);

    int user = getBinaryData(stc,43,6); // 0-36

    if (arm == 0x02) {

      msg += " armed";

      user = user - 0x19;

    }

    if (arm == 0x03) {

      msg += " disarmed";

    }

    if (arm > 0) {

      if (master) msg += " master code"; else msg += " user";

      user += 1; // shift to 1-32, 33, 34

      if (user > 34) user += 5; // convert to system code 40, 41, 42

      msg += " " + String(user);

    }

The 0xa5 armed message is received after the exit delay when the system switches off ready to armed. The disarm message is received immediately upon disarming. On my system I receive a date message every four minutes regardless of arming/disarming, so disregard that one for this user information. I think your "A" bit should be two bits long and is two bits later than your code sample. Note that it is followed by 8 zeros and then another 8-bit message which I can't determine. Also make sure your user codes are unique, if you post the same 4 digit pin for two user codes I believe it only finds the first one.

add this to the "if (cmd == 0x05)" section for a possible power fail indicator:

Code:

if (getBinaryData(stc,28,1)) msg += "power fail? ";

jolcese

Posted: Jan 14, 2013 - 05:09 PM

Joined: Jan 14, 2013
Posts: 1

Hi guys,
This is really great information. I've always wanted to interface with the Keybus protocol.
Some questions:
Do you know if the alarm is always the "master" and keypads are slaves?
When do slaves talk in the bus?

Thanks
Jose

jpessini

Posted: Mar 16, 2013 - 06:45 AM

Joined: Mar 16, 2013
Posts: 2

How can I write TO keybus? How to simulate a keypad sending keystrokes to the panel?

fvparg

Posted: Apr 28, 2013 - 02:07 PM

Joined: Apr 28, 2013
Posts: 1

Hi,my name is Federico. i have an Logic Analizer Tektronix TLA704 in order to help in the proyect.
me i captured some frames the CLK and DATA for sharing.
follow in the proyect?

Thanks and I am at your disposal.

jpessini

Posted: May 07, 2013 - 08:51 PM

Joined: Mar 16, 2013
Posts: 2

This guy made a simple solution at http://www.juliano.com.br/dsc

Bingo600

Posted: May 11, 2013 - 08:46 AM

Joined: Apr 25, 2004
Posts: 3817
Location: Denmark

Nice info ..
But there is no source .... Only a hex

Would you by any "chance" be related to "This guy" .....

Your username is jpessini and http://www.juliano.com.br/ refers to a Juliano Zabero Pessini

If you are .. you might ask your "relative" to release the sourcecode Wink

/Bingo

sentinel73

Posted: May 22, 2013 - 09:56 PM

Joined: May 22, 2013
Posts: 3

hello! I am also studying the bus DSC 5010, and I can not understand the purpose of the last bit in the package ..I want to use the keyboard in my project. So far only got to control LED ARM READY

sentinel73

Posted: May 23, 2013 - 03:25 PM

Joined: May 22, 2013
Posts: 3

With the help of a synthesizer package I learned the purpose of each status bit
7- BACKLIGHT
6- FIRE
5- PROGRAM
4- TROUBLE
3- Bypass
2- Memory
1- Armed
0- Ready

sentinel73

Posted: May 24, 2013 - 09:29 AM

Joined: May 22, 2013
Posts: 3

0x27 - Status update zone 1-8
0x2D - Status update zone 9-16
0x5D - alarm memory group1
0x63 - alarm memory group2
0xB1 - zone configuration, next byte allowed zone
0x64 - beep command group1
0x69 - beep command group2

sunpialia

Posted: Jun 14, 2013 - 10:08 AM

Joined: Jun 14, 2013
Posts: 1

Most people would choose the LED lights for cars or also house decoration. So do I. After all, the LED car lights are getting more and more available and affordable in the cars and motors and would make your cars look greater.

Jump to:

All times are GMT + 1 Hour

AVR Freaks Forum Index » General Electronics Technical Forums » General Electronics

AVRFreaks.net

Search