View source for AVR controlled RF light switches

{{WIP}}
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.

{{#ev:youtube|WXGQK0TiHtY|480|}}

[[Category:AVR]]
[[Category:433Mhz]]

==Signals==
The image below shows an Audacity screenshot with a pulse train of one RF remote. The pulse train was captured using our [[Cheapest_ever_433_Mhz_transceiver_for_PCs|Frankensteinian device]]. 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&mu;s )
* There are 25 pulses in this signal and (not visible in this image) the same train of pulses repeats after some 6ms.
[[File:onA signal in Audacity.png]]

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:

[[File:on1 signal in Audacity.png]]

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&mu;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 goes high, and then the long and short "downward pulses" follow each other, each pulse starting on a regular 2090 &mu;s beat with a falling edge. That also means that there is one less pulse in the signal than it seemed at first sight: there is one extra edge at the start of the signal and one at the end, when the signal falls back to low.

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.