Keybus communication method...

20 posts / 0 new
Last post
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I'm going to start working on my next project - creating a garage door alert/alarm. It will let me know when I leave my door open for too long and when I arm my alarm system in stay mode at night I want it to disable wireless remotes and alarm if the door is opened.

The one part of this that is a little tougher is monitoring what the alarm system calls "keybus". It is 4 wires (+12v, gnd, data, clock). It has a limit of 1000' and I put my scope on it last night and found it is communicating at 1khz.

It supports multiple devices and the main panel knows if a device is missing or malfunctioning. My question is, with only one data, how might it communicate? Does it make sense that the panel always polls each device (keypad) in order and asks the keypad if a key has been pressed? I am presuming the clock is generated by the main panel. It seems to me that with only one data channel, that something has to be the "master" and constantly ask the slaves if they have anything to report...

Thanks,

Alan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Google "KeyBus" returns a lot of info.

Your description of KeyBus does not match very closely what I just read. It talks about 4800 baud, async serial with a shared data line. Nothing about a clock. Here is one place:

http://www.diysecurityforum.com/index.php?topic=10480.0

Some of what I read says that its proprietary to Ademco Security, so the protocol is not publicly available. However, some can be teased out of patents and manuals, discussed on the board referenced above.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA There are some answers that have no questions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Jim,

I saw that info too about the 4800 baud. I think the keybus in my system may be a little more lower end than the one in that thread.

I did notice that the clock wasn't always running. It looked like it would go high for >4ms or so and then start cycling at 1khz for 40 bits or so. I should have looked at the transitions a little better to see if the data was being changed before it was going high or low.

I just want to read and decode the data, I don't want to interact with it. High=13.5V and Low=GND. Could I use a simple voltage divider to bring the 13.5V down to 5V? I could then feed that into an AVR using an interrupt on the clock to record the bit and try to reassemble them. I then plan to output that on a UART to see if I can make any sense of it. I found a document in that thread that may document what is coming across.

Thanks,

Alan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, a voltage divider should work.

You MAY be able to use the SPI hardware interface on this signal. You will need to figure out which edge is in the middle of the bit; use that edge for latching the data

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA There are some answers that have no questions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I captured this burst of data, does it make any sense:

0101010101110111111101010101010111010101010101011111010111010101111111010101111111

I was hoping to see some ascii characters in this, but my untrained eyes don't see much.

There might be another 1 before and after this stream.

I'm trying to analyze it...

Thanks,

Alan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The first thing I notice is that the sequence is made up of two things: "01" and "11". Never a "00" or "10" in there. This makes me think that, e.g., "01" stands for "0" and "11" stands for "1". Is this possible?

Michael

Edit: For what it's worth, applying the mapping given above, I get:

00000101110000001000000011001000111000111

Edit again: Got the number of bits wrong the first time. That's 41 bits, so I don't see how it would break up into a nice number of bytes.

One more edit: If you assume there's another 1 before and after the sequence, and that "10" means "0" and "11" means "1", then you'd get 42 bits:

000001011100000010000000110010001110001111

42's a bit nicer of a number. 6 x 7 bits gives:

0000010 2
1110000 112
0010000 16
0001100 12
1000111 71
0001111 15

Alternatively, 7 x 6 bits would give:

000001 1
011100 28
000010 2
000000 0
110010 50
001110 14
001111 15

Alright, I'm done messing around for sure this time.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi crwper,

Thanks for taking a stab at it. After looking at the waveform again, I think I was picking up a bit at each clock change (positive and negative) instead of just when it goes positive for example. So I may have twice as many bits with dummy bits between each one.

One thing that surprised me is that the data and clock cross each other at the mid point at practically the same time. I guess I expected the data would be set and once settled, triggered by the clock. Should I consider the middle of the clock cycle the place to sample the data instead of the leading or falling edge?

Thanks,

Alan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

Also note in the top picture, yellow being the clock. If the top of the yellow is where to sample the data, both the data are low. WHY raise the data between cycles if you are sending to low bits?

Thanks,

Alan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi crwper,

I think you were on to something.

I got a new sequence:

00000101010001011000010001001000111000111

If I reverse this and seperate into 7 bits:

1110001 1100010 0100010 0001101 0001010 100000
0x71'q' 0x62'b' 0x22'"' 0xd     0xa     0x01

What caught my attention is the 0xd 0xa cr/lf. I suppose the last 6 bits could be a header/address or something and that is why there isn't seven.

One thing that puzzles me is that the MSB/LSB thing I get, but why transmit the end of the line first? They start with the lf, then cr, then the characters. That is of course if I am on to something.

I grabbed 1M samples with my scope and pressed some buttons on the alarm system while capturing so I have lots of data I can write a program to scan through tomorrow.

Thanks,

Alan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My first thought was something like NRZ or Manchester, but neither of those would be clocked.

Interesting that there is never a high level that is longer than two clock cycles. Makes me think that a "long" high might be one logic level and a "short" one might be the other. An alternative way of looking at it is a long one is one and TWO short ones is the opposite.

Given that it IS a security system, it could very well be that they are trying to make it really obscure!

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA There are some answers that have no questions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The timing of the clock edges definitely seems fishy. Usually this kind of thing would occur when the bit had been set, I believe.

Having recently spent some time playing with the Dallas 1-Wire protocol, it seemed to me that the first rising edge might be for timing, and then the line stays high for a "1", or drops low for a "0"--similar to what Jim suggested. However, such a protocol wouldn't be clocked.

To lay it out a bit more clearly, though, it would work like this: The receiver detects the rising edge of the signal, waits 3/4 of a "cycle", then samples the line. The logic resets, and it's ready for the next bit. This sort of system is quite robust to clock errors, compared to, say, RS-232. The presence of the clock, however, would be puzzling.

Michael

Pages