AVR controlled RF light switches

Work in Progress This page describes a work in progress. All specifications may change and the final product may significantly deviate from what we describe here. It is very well possible that there will be no final product at all.

[[Revision timestamp::20150722215709|]] Although the Cheapest ever 433 Mhz transceiver for PCs still functions in all its ugliness, there are some things left to be desired in this solution. Particularly, the system needs a PC or Beaglebone/Raspi running for control of the light switches.

I'd like the simpler devices in my home to communicate with each other with only optionally a more initelligent controller in between. I'm working on a "multi-media" bus protocol for my devices (working title: ThingBus) that would work on TCP/IP, UDP, serial ports and through cheap NRF24L01+ transceivers. As a first use case I'm now trying to control the RF switches from an AVR that will listen to NRF24L01+ messages.

It would be silly to have the AVR store the audio samples that were created in the 433Mhz transceiver solution. We need to somehow describe the protocol in a more compact way. This page describes that way.

Signals

The image below shows an Audacity screenshot of an audio card capture of the signal of one RF remote. A few things stand out in this signal:

• It seems to consist of only two types of pulses: wide and narrow. All wide pulses have the same duration and the same is true for the narrow pulses.
• The rising edges of the pulses in this signal are evenly spaced in time (measured in Audacity to be approximately 33 samples or 750μs )
• There are 25 pulses in this signal and (not visible in this image) the same train of pulses repeats after some 6ms.

So far, so good. It seems that we can represent this signal in 25 bits, where we have to choose whether the long pulses map to a 0-bit or a 1-bit. But unfortunately, not all RF transmitters are created equal. Below is an image of the signal another no-brand RF transmitter:

This signal also appears to have only two types of pulse. What's different in this signal:

• It's not the rising edges that are equidistant, it's the falling edges.
• The pulses are a lot slower, the distance between falling edges is about 2090μs and the pulse trains are some 80ms apart.
• There seem to be only 21 pulses in this signal. As we shall see later, there are actually only 20 pulses.

This last signal makes a lot more sense if we interpret it as an inverted signal: just before the train starts the signal level oes high, and then the long and short "downward pulses" follow each other, each pulse starting on a regular 2090 μs beat.

So, at least to describe these two protocols, we need to specify the following about each protocol:

• wether the signal is inverted, and if it is, how long to wait between raising the line and starting the first pulse.
• the shape of a 0-signal and that of a 1-signal. That is: for each of these signals it should describe how long the signal should stay high (low for inverted signals) and how long it should subsequently stay low.
• the number of bits in each train of pulses.
• how long to wait between repetitions of sequences. Experience has taught that most switches need a few repetitions to reliably react on a signal and that the pause between pulse signals is quite critical.