Electronic – Can anyone identify this 433Mhz OOK protocol

433mhzprotocol

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

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

Image of data

Best Answer

"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.

Related Solutions

Electronic – How to software-decode this 260KHz serial stream

You say that the overhead of interrupt handling would be too high, but I don't think that's necessarily true. A cheap microcontroller may not be able to do much useful processing of the data stream, but it should be powerful enough to serve as an ad-hoc converter.

Let's take an AVR chip as an example: the ATmega328P that serves as the core of the Arduino dev board. At the maximum clock rate of 20MHz, you get 77 clock cycles per bit. According to the datasheet (page 15) it takes about 7 clock cycles to enter an ISR and 4 cycles to exit.

Assuming you spend half of each data bit in a spin-loop waiting for the right time to sample the input, you're left with about 27 cycles per bit outside of the interrupt handler. Most AVR instructions are single-cycle, so that should be plenty of time to frame the bits into bytes and shove them onto an SPI link to your host processor.

(I've glossed over the problem of detecting start bits. One option is to reset one of the built-in timers at the beginning of every bit, and use the output compare to determine whether the interval between two rising edges exceeds a threshold.)

Electronic – Understanding IR Protocol Checksum generation

Here's my analysis, based on your small sample of data:

If you ignore the "Never changes" data, and also remove the zeroes before the checksum, your data looks like this:

00100100 11000000 00000000 01000000 01111110
00100100 11000000 00000000 01100000 01000001
00100100 11000000 00000000 00100000 00000001

00100100 11000000 10010000 00100000 10010001
00100100 11000000 10010000 00110000 10001001

00100100 11000000 11010000 01100000 10110001
00100100 11000000 11010000 01000000 10010001

So that's four bytes of data and one byte of checksum (or whatever).

Now, reverse the order of the bits within those four data bytes (checksum omitted), so I mean bit 0 becomes bit 7, bit 1 becomes bit 6, etc.:

00100100 00000011 00000000 00000010
00100100 00000011 00000000 00000110
00100100 00000011 00000000 00000100

00100100 00000011 00001001 00000100
00100100 00000011 00001001 00001100

00100100 00000011 00001011 00000110
00100100 00000011 00001011 00000010

Now sum each row, modulo 255, reverse the order of the bits again, and compare the result with your checksum:

It works for me, but maybe there's more of that data (like the zero padding) that's taken into account, but we'd need more samples to figure it out. For now, you can create the checksum byte by simply reversing the order of the bits of each data byte (i.e. ignore the "never changes") and taking the sum, modulo 255, then reverse the order of the bits of that sum.

All of this necessity for bit reversal suggests that the data is being sent the opposite way to how you're interpreting it. For example, it's being sent MSB first and you assume LSB first or vice versa. Other than that, the checksum is just a cumulative sum of the data, ignoring overflow.

Best Answer

Related Solutions

Electronic – How to software-decode this 260KHz serial stream

Electronic – Understanding IR Protocol Checksum generation

Related Topic