This is an example of a WordPress page, you could edit this to put information about yourself or your site so readers know where you are coming from. You can create as many pages like this one or sub-pages as you like and manage all of your content inside of WordPress.
Hello,
I recently bought a Veritas 8 because it looks reliable and because the electronics behind should be simple at this price range. I want to read what’s happening on the rkp bus to get remotely the alarm status (activated, burglar, fire…) using optocouplers and serial decoder. There is not that much retro engineering on the internet for such an old and common system so I’m very happy to have found your blog. Good luck with the investigations and I’ll keep you up to date if I get something on my side.
Louis
Hello,
I had the same idea as you to emulate Texecom RKPs, and took the approach of capturing the traffic on the RKP bus with a USB oscilloscope.
I’ve only been able to do a limited amount of testing so far, but here is what I’ve managed to work out.
Both the Tx and Rx lines are at about 13V when nothing is being transmitted. They both seem to have exactly the same signals on them at all times, which I’m assuming means that the main panel must echo everything it receives from the RKPs back out on the Tx line, or something similar.
The data is UART, 4800 bps, and seems to be 7 data bits, 1 parity bit (always 1), 1 stop bit.
I’ve started writing a protocol decoder for sigrok, but I don’t really know python, or much about protocol decoders in general. So it’s very rough around the edges. So far, it can identify what keys are being pressed on which RKPs, whether the alarm is in programming mode, when it’s set, walk test active, things like that. The structure of the data seems to suggest that the RKPs just transmit at a predetermined time slot, to avoid collisions – about every 750ms.
As far as I can tell, it should just be a matter of continuing to capture more data to work out how to decode pretty much anything you’d want to know about the state of the alarm in Home Assistant. I was hoping to use an esp8266 to publish the data it receives via MQTT.
The main problem comes with transmitting, because each packet transmitted has what I’m assuming is a 4 bit checksum at the end.
Hopefully the disassembly of the firmware might be able to reveal the algorithm used to calculate this. Otherwise, it might be possible to simply replay button presses as captured from a genuine RKP.
Hi Chris,
This sounds like, between the two of us, we’re almost there. I’ve had to sit the disassembly on the back burner for a while but I do want to pick it up again and continue looking for things. I haven’t posted about it in detail but when I saw those two data lines seeming to follow each other I assumed I had done something wrong with my triggering or probing setup (not that there was a great deal to get wrong with it) as I couldn’t see a time delay but it would follow with what I concluded about everything the RKPs send causing a response of some kind or else they lock up.
I’d agree with your assertion that, for listening to the bus, it’s all about trying to cause every state you’d like to see to occur and then anything else can be ignored.
You’ve seen much more data on the wire than me but my working assumption had been that the RKPs are like serially connected I/O expanders which the main panel queries based on the list of RKPs which are registered and the specification in documentation that no two RKPs can have the same a 3-bit address. This relaxes the need for the RKPs to have any kind of time synchronisation or concept of a system clock / synchronisation pulse which they all ten count from.
It’s would certainly be worth trying a simple replay implementation of controlling a system but I wonder if doing so in the wrong time slot, if the bus really is time division multiplexed, so as not to clash with the real RKP(s) on the bus would cause the main panel to ignore the input or trigger a tamper warning… or since the real RKP isn’t being interacted with could you use the real RKPs time slot and would it sit there doing nothing because it has nothing to transmit or wait for an echo about.
I’ll keep an eye out for a checksum in the firmware. I’ve always assumed there would be one but knowing it’s 4-bits in length (and probably the last 4 bits into the USART TX buffer) should make finding it a bit easier.