Can anyone identify this 433Mhz OOK protocol?

Question

I am working with some wireless devices that use 433MHz OOK transmitters and receivers. They use a simple protocol for the data sent between the nodes. I feel it is reminiscent of common IR remote control protocols - the long high pre-amble, the pulse coded data, the length of pulses.

Examples:

• RC-5 has 1778\$\mu\$s long pulses and 14 bits.
• NEC has a long start bit as do others

It is different to any of the weather station or remote sockets protocols I have seen.

Some of the devices in the system are large ASIC DIPs, others are much more modern SMT microprocessors. I suspect this protocol has been used for a while and may have a name.

I have tried searching for the pulse lengths as ranges on Google to no avail.

Does anyone recognize this protocol? I would concentrate on the 14 bits of data, the length of pulses rather than the checksum and multiple bytes - this may be a higher level of protocol.

Here is a link to the full size image.

The salient details are:

• Pre-amble - 5410\$\mu\$s high
• 0 and 1s are both 1850\$\mu\$s long
• 0 is 385\$\mu\$s low, 1465\$\mu\$s high (79% duty cycle)
• 1 is 980\$\mu\$s low, 870\$\mu\$s high (47% duty cycle)

In case the data content of the packets are important, they follow this general form:

• 3 bytes of address information
• 1 byte of status information
• Checksum

or

• 3 bytes of address information
• 1 byte of status information
• 2 bytes (4 nibbles) representing data 0-9 x 4
• Checksum

As per the image the checksum is the sum of the lowest 10 bits of the sent data segments, take the two's complement, and add one i.e. -SUM(data) + 1

Answer 1

"I suspect this protocol has been used for a while and may have a name." (highlighting by me)

Possibly, but I doubt it. There's a huge chance that this is a proprietary protocol which is only internally documented. Main reasons for a proprietary protocol:

• Design freedom. The designer checked a number of existing protocols and dismissed all of them because of some technical reason or other. It may have too little throughput, or be too complex to code in a 2kB microcontroller.
• Commercial protection. Use a proprietary protocol and competitors can't make products which can be used with yours, so the customer has to come back to you. Simple protocols can be reverse engineered, though, so they may want IP protection (to the extent possible, I'm not a lawyer.)

There is a zillion of those proprietary protocols around, often by small businesses who are doing their own thing and don't have to comply with anything as far as standard protocols are concerned.

You may have a chance with reverse engineering. You don't say what kind of data the transceivers take, but maybe you could find a pattern in how a given input is coded.