Difference between revisions of "AVR controlled RF light switches"
From Just in Time
m (→Signals) |
|||
| (5 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| + | {{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. | 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. | ||
| Line 11: | Line 12: | ||
==Signals== | ==Signals== | ||
| − | The image below shows an Audacity screenshot | + | 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. | * 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 ) | * 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 ) | ||
| Line 17: | Line 18: | ||
[[File:onA signal in Audacity.png]] | [[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. | + | 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]] | [[File:on1 signal in Audacity.png]] | ||
| Line 27: | Line 26: | ||
* The pulses are a lot slower, the distance between falling edges is about 2090μs and the pulse trains are some 80ms apart. | * 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. | * 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 μ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. | ||
Latest revision as of 21:27, 3 December 2015
| 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::20151203212755|]] 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 with a pulse train of one RF remote. The pulse train was captured using our 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μ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 goes high, and then the long and short "downward pulses" follow each other, each pulse starting on a regular 2090 μ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.