OOK Wireless Transmit-Receive Pair – Simple Pro

As part of this concept I’m working on to “monitor” several gadgets remotely using the home router and some sort of wireless “gadgets”, I settled for 433MHz devices. I had some OOK receivers and transmitters which I used in the past, so I decided to start with those.

These are basic ones from either Radiotronix (now Linx Technologies), Wenshing (through Sparkfun), or Laipac. For reference, these are the modules I’ve worked with; but pretty much any standard OOK (or ASK) module should work.
• RCR-433-RP (Radiotronix)
72901
• RCT-433-AS (Radiotronix)
72902
• RWS-371 (Wenshing)
72903
• TWS-BS (Wenshing)
72904
• RLP 434A (Laipac)
72905
• TLP 434A (Laipac)
72906

To use them you modulate the data input with a TTL signal and recover the signal on the receiver. Since these devices are very simple, they require care on what type of data is presented to them. The only real consideration for the transmitter is the maximum bandwidth it supports; this limits the bits-per-second (bps) the device can support. For the receiver, however, the bandwidth and data format is equally important. The receiver operates under a very simple principle; I maybe oversimplifying this but what the heck. The receiver is no more than a simple comparator circuit which provides a logic high or low depending on the energy present on the antenna. This energy is somewhat filtered by the analog front-end of the receiver to suppress noise from undesired frequencies. But that is about all the suppression it provides. Because the receiver is always listening to any and all energy on the specified frequency band, it is always triggering the comparator logic (regardless of valid or invalid data). So some means of encoding is desired to be able to suppress some of that “unwanted noise”. There are literally lots of encoding methods; but the key of all the methods is to keep the receiver always receiving valid data. This is accomplished by keeping the amount of logic ones and logic zeroes as close to the same as possible during the message. This is called DC balancing.

So why did I go into all this hoopla; to explain some of the decisions on these examples.

The method I’ve used for working these receiver/transmitter pairs is standard RS232 communications (at TTL levels). But since these type of data is not necessarily “DC-balanced”, a few things must be done to ensure some reasonable transmission purity. First, before the actual message is sent a combination of sequential 1s and 0s is sent. This effectively creates a balancing effect on the receiver (establishes a good midpoint for the “comparator” logic on the receiver). Second, two bytes are sent to “synchronize” the receiver. These are bytes the receiver is waiting for. Only after those specific bytes are received (and in the specific order), the receiving system knows a valid message follows. Third, the number of bytes in the message must be kept to a minimum. This is because by transmitting a straight sequence of bytes without any further consideration, the DC balance will be eventually lost. To avoid that some systems employ encoding techniques (such as Manchester), but we are just keeping this simple and making a choice of avoiding long sequence of bytes. Finally, a CRC (or checksum) is added to validate the message.

For my specific needs I plan to use a protocol similar to the one below:
DC_BAL - DC_BAL - DC_BAL - SYNC1 - SYNC2 - DATA_BYTES(4) - CRC

That should allow for transmission of 4 bytes (8-bit/byte) or 2 words (16-bit/word); enough to relay the information from one or two sensors, plus battery information.

Attached is sample PIC code (for 1 data byte only) created to transmit and receive such messages (using CCS PCM).