433 Mhz signal with Audacity


I try to vizualise the 433Mhz signal of my remote control of my stove, but I have a strange signal comming out of my 433 Mhz receiver.
Even without signat send by my remote controller, this is wat i constantely see in audacity: (see attachment).

What is going wrong here.
I’m using the following receiver:

There is nothing wrong.
Those small 433 Mhz receivers have no squelch, so in the absence of any input signal,
they produce bandwidth limited noise on the data output pin.
Thats what you are seeing.

i also read that when they have no signal they turn up the gain, resulting in more noise but when a clearer signal is present the turn it down appropriately

and for others who come here for the title check this post: http://arduino.cc/forum/index.php/topic,22105.msg165865.html#msg165865

For people who may not understand how these cheap 433 radios work , hers a very basic explanation. The radios use amplitude modulated keying , which simply means a logic 1 turns the transmitter on , and a 0 turns it off. All the Transmitters and Receivers are on the same frequency, normally 433.92 Mhz. The Receivers have a bandwidth of around 4 Mhz , which means they will receive anything that falls between 431.92 to 435.92. The receivers will receive anything in this range , including transmissions from other peoples transmitters and in the case of when nothing is being transmitted the receiver just produces digital garbage , which is essentially the digital equivalent of thermal noise. The receivers know nothing about data rates , baud rates , whether data is serial or not , or anything else, but simply respond to amplitude transitions at their input. To use them properly, you need to provide some kind of flag sequence at the start. A flag sequence is a series of 1 0 1 0 1 0 transitions that needs to last a couple of milliseconds. The purpose of the flag sequence is to allow the receivers AGC (automatic gain control) to adjust itself to the input level of the incoming signal and to allow the receivers data slicer (the part of the receiver that decides whether the data is a 1 or 0 ) to adjust itself to the 1/2 way point of the amplitude variation. The data slicer needs transitions to work, ie needs data that continuously changing, so sending a constant series of 1 s or 0 s in a row , will result in the receiver not decoding properly. Most applications that use these radios use some form of data coding like Manchester or similar coding schemes to ensure that there are always data transitions , even when continuous data sequences of 1s and 0s are being sent. The receivers AGC has a fast attack and slow decay characteristic which means that if the receiver receives nothing for more than approx 10 ms , the AGC winds up and the receiver starts producing garbage again. There is a maximum rate at which you can send data with these radios , usually around 4800 transitions per second , some will do 9600, but not reliably. There is also a minimum rate of around 100 transitions per second , as less than this and the receiver thinks there is no signal at all in the off periods and winds its AGC up. Trying to reverse engineer appliances which use these radios is a time consuming tedious task, and ideally you need a digital CRO that can store long periods of data which you can then analyze.

A common method of sending data is to send a flag sequence , ie lots of 1 0 1 0 transitions and then a sync , which is a short sequence differant from the flags but easily identified, then whatever data you want to send. This can help when trying to reverse engineer data streans , as the flags are always at the start and dont change , the sync doesnt change , but the data does, so it helps you to know where in the sequence the data is likley to be.