4 Scantronic alarm keyboard interface protocol (SAKIP) description

-- DRAFT ONLY. WORK IN PROGRESS --

I do not know the Scantronic name for this protocol, but I have dubbed it SAKIP (Scantronic alarm keyboard interface protocol).

This description was largely derived by reverse-engineering a sample 9940 connected to a sample 9651 alarm system connected with my own intercept circuit. I used a Tektronic TDS 1001 two-channel digital storage oscilloscope and a generic 8-channel logic anaylzer (four channels used) with SigRok PulseView software running on an Apple iMac.

I am very grateful for the help of GitHub user Remy the Little Chef who provided valuable information on this protocol.

Terminology

• Controller = the Scantronic Alarm system. I tested with a 9651 but guess the protocol may be used by other models.
• Peripheral = the Scantronic 9940 or 9941 Keypad. I guess the protocol might be used for other peripherals although I am not aware of any.

The physical layer

The peripherals are connected in parallel to the controller with four wires, two for power and two for data. Standard alarm cable is recommended, so there are no twisted pairs and no shielding.

Control unit connection bus:

Name	Used For
0V	DC power ground
12V	DC power supply
DATA	Data signal
CLK	Clock signal

The installation manual says up to four keypads may be connected on one bus in parallel or star formation. Maximum distance from the controller is 200m. The distance is achieved by signals of 12-15V amplitude and transmitted at just 2 KHz.

While the DC power supply is labelled "12V", I measured 13V5 on my sample alarm controller using the original power supply and sometimes over 14V with no load. That makes sense because the controller can operate from a 12V backup battery, which could use over 14V to charge. I refer to this voltage as Vcc and allow up to 15V in my circuit calculations. I do not know the lowest allowable voltage but assume it is below 12V.

the devices have 'open collector' connections. The lines are pulled to Vcc by pull-up resistors when idle, and pulled low by any device when transmitting. The pull-up resistors are provided by the controller.

The data link layer

The protocol is similar but not identical to I2C.
A message consists of a variable number of 8-bit frames. The maximum length is not known, but none of the observed messages is very long.

Transmission from controller to peripheral

1. START: The controller initiates a transmission by holding the data line low for 5ms (presumably after checking that the bus is not already in use).
2. CLOCK: The controller then clocks eight 0.5ms pulses (2KHz).
3. DATA: The peripheral transmits an 8-bit frame of data MSB first (assumed, t.b.c.) by setting the data line level low=0 or high=1 (assumed, t.b.c.) for each clock pulse. Unlike I2C, there is no ACK bit
4. NEXT FRAME: After a frame, the clock line is high. To indicate that there is another frame, the initiator takes the data line low after 1ms. After 0.25ms the controller then clocks the next frame as above.
5. STOP: the clock line is high after any frame. If the data line stays high for more than 1ms then the transmission package is complete.

Transmission from peripheral to controller

1. START: The peripheral initiates a transmission in the same way as the controller - by holding the data line low for 5ms.
2. CLOCK: The controller clocks eight 0.5ms pulses (2KHz). The clock is always provided by the controller, never the peripheral.
3. An 8-bit frame of data is transmitted MSB first (assumed, t.b.c.) by setting the data line for each clock high pulse. The bits are low = 0 and high = 1 (assumed, t.b.c.)
4. NEXT FRAME: After any frame, the clock line is high. To indicate that there is another frame, the peripheral takes the data line low after 1ms. After 0.25ms the controller then clocks the next frame as above.
5. END OF MESSAGE: the clock line is high after any frame. If the data line stays high for more than 1ms then the message is complete.
6. ACK: (t.b.c.). When the controller transmits, the peripheral does not respond, but when the peripheral has finished transmission, the controller transmits a single-frame response assume to be some form of acknowledgement - details to follow.
7. STOP: The peripheral has already released the data line during the last frame. When the controller leaves the clock and data lines high for 1m the message exchange is complete.

Message format

1. address byte (assumed)
2. data bytes (assumed)
3. checksum?

Further details to follow

---

If you find any of the ideas in this repository useful, please Buy Me a Coffee