Take the 2-minute tour ×
Electrical Engineering Stack Exchange is a question and answer site for electronics and electrical engineering professionals, students, and enthusiasts. It's 100% free, no registration required.

I'm plan to interface a atmel avr with my alarm system in home but the issue is DSC has a propriatary protocol between the keypad and the base. So has anyone messed with this before or can give me a few beginners tips on how to reverse engineer this protocol?

The wiring is simple: Vcc, GND, Data, Clock

The Vcc is +12 volts and the data/clk lines are between +8-10 but work just fine through a voltage divider to the logic analyzer.

The Clock line is confusing tho, its a 1kHz clock at 50% duty but only runs for 41.600ms then it goes high for 5.400ms and then starts over again.

The Data line appears to change on on either rising or falling edge of the clock

Open Door Data - Picture

(0 is the Data line, 1 is the Clock line)

OpenLogic Sniffer Files

share|improve this question
    
This guy made an easy service. Still on beta, but works... juliano.com.br/dsc –  user23086 Apr 26 '13 at 3:40

4 Answers 4

up vote 1 down vote accepted

There is no simple answer to decoding a protocol, if they have a good encryption scheme setup then you are probably going to be up &$%* creek. With some work and more questions you might successfully figure out the kind of encryption, and then, if it is poorly implemented, decode it.

Chances are that the keypad has a very simple protocol and the controller has some strict constraints on how many button pushes it will accept and such.

On the note of the synchronous protocol, chances are that the protocol is a NRZ protocol. That is my best informed guess based on your explanation. I cannot open the files right now, but I hope this helps.

The fact that it changes on both clock edges is just a sign that both clock edges represent a point that a "bit" of data occurs. With NRZ you are just checking if there was a change or not.

I hope this helped.

share|improve this answer
    
Thanks for that, I don't believe the data to be encrypted as another person on avrfreaks managed to find the bit that is set when the alarm is armed and unset when it isn't (hrm i can't put in newlines in this comment) www.baranharper.com/pdfs/dsc/pc5401-dev_guide.pdf <-- I believe this is the data that is being sent back and forth. So I know what I'm looking for just not exactly how to read it. Thanks for your comment again, hopefully I can spend some time on this project this weekend. –  mcd1992 Mar 4 '11 at 11:46
    
@User3239, I was sidetracked by work, if you save the data you pulled off of the data lines as an image on your computer it can be easily uploaded to the question, then users like myself whom cannot install non-work related software can look at it. –  Kortuk Mar 4 '11 at 23:04
    
ah, sorry bout that. I can't embed a picture (10 rep limit) but i can link to one. –  mcd1992 Mar 5 '11 at 4:15

following my web search on this topic, it seems that this protocol is using the CLK line and then rising edge of CLK is for keypad->panel and falling edge for panel->keypad communication. I plan on testing this tonight with this small arduino sketch:

I'll repost my findings after this...

#define CLK 11
#define DTA 12

String st;

void setup()
{
  pinMode(CLK,INPUT);
  pinMode(DTA,INPUT);
  pinMode(13,OUTPUT);
  Serial.begin(9600);
  Serial.println("Debut");
}

void loop()
{
    if (waitCLKchange(1) > 200)
    {
      // Debut de pattern

      st = "";

      while (1)
      {
        // CLK est bas. On attend qu'il remonte
        if (waitCLKchange(0) > 50) break;

        // CLK est haut, on lit un bit
        if (digitalRead(DTA)) st += "1"; else st += "0";

        // Attendre que CLK redescende
        if (waitCLKchange(1) > 50) break;
      }

      Serial.println(st);
    }

}


int waitCLKchange(int currentState)
{
  int c = 0;
  while (digitalRead(CLK) == currentState)
  {
    delayMicroseconds(10);
    c++;
  }
  return c;
}
share|improve this answer

I went down this path, and found it was far, far easier to just buy one of the supported serial interface cards, such as the DSC 5401 or the newer IT-100.

For more info, see: http://www.payne.org/index.php/Product:DSC_5401

Note: if you had your alarm installed, your installer will have to come over and "register" the interface card on your KEYBUS network. I suspect the protocol may have some security features (I'd hope so), and that will make reverse engineering even harder.

share|improve this answer

It's starting to take shape. Here are a few results. Based on this post: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=942340#942340 I'm looking at status strings, here is what I get:

00000101 0 10000001 00000001 00000000 11000111 00000000 11000111 00000000 11000111 1 no zone
00000101 0 10000001 00000010 00000000 11000111 00000000 11000111 00000000 11000111 1 zone 1
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 3
00000101 0 10000000 00000011 00000000 11000111 00000000 11000111 00000000 11000111 1 zone 4

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

If you can help make sense out of this, I'd be happy!

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.