Frequency details

[Benjamin Larsson]

The frequency range that most of the signals rtl_433 can handle is on
the 433MHz ISM band. The center frequency of the band is 433.920 MHz and
this is what most of the devices write that they use. This doesn't mean
that the device actually use this frequency. In the device a crystal is
used to generate a clock source for the transmitter. Imperfections in
the crystal or temperature changes will change the actual frequency that
the signal is transmitted on. Design choices in the hardware could also
move signal in the available range (433.050-434.790). By default rtl_433
uses a 433.920 MHz center frequency with a 250kHz sample rate. This
means that it is able to pick up signals that are in a range of
433.92MHz. What the exact range is unknown as the crystal imperfections
are also valid for the rtl receiver. But as the sample rate is 250kHz we
still get a decent range.
But the further away we get from the tuned frequency the lower the
signal strength will be. The choice of 250kHz as sampling rate is to
reduce the amount of samples to process.

Another factor that is a little bit unknown but should be valid is that
the tuner in the stick (e4000, r820t, etc) sends a 8MHz wide signal to
the rtl demod. The rtl demod has a filter that band limit the signal to
around 2MHz. As we are sampling at 250kHz we should get aliasing of the
signals that are outside our sampling range but still inside the 2MHz
range. In most cases getting these aliasing signal components will
destroy the received signal. For OOK signals this is not the case so we
get more range "for free".

MvH
Benjamin Larsson

[Robert Terzi]

Benjamin:

Thanks for this write up. I learned some of this on my own. There is
still a lot I don't understand yet. I have been using SDR# on Windows,
via rtl_tcp to the Linux box where rtl_433 runs so I could see some of
what rtl_433 sees. I wasn't quite using Audacity right and understanding
the different file formats that were being output. Now I realize I could
have answered some of my questions with the recorded files.

With regard to the signal processing this brings me to some wishlist items.

1 - I'd like to have rtl_433 be able to give an idea of where the noise
floor is as well as to see how it changes over time. There are some
times of the day when receiving my outside sensors becomes difficult.

2 - It would be nice to have more dynamic level detection. This would
be harder to implement and requires a bit more DSP background than I have.

It would also be nice if these could be in some sort of units that
have meaning or relation elsewhere. I think the units shown by SDR#
are dbFS (ratio to Full Scale). Sure that's not a calibrated value
but has a little meaning.

Just wanted to add these thoughts to the discussion

Thanks for your work on rtl_433, even in it's current form it is very
useful and educational.

--Rob

[Benjamin Larsson]

On 01/25/2015 08:19 PM, Robert Terzi wrote:
> Benjamin:
>
> Thanks for this write up. I learned some of this on my own. There is
> still a lot I don't understand yet. I have been using SDR# on Windows,
> via rtl_tcp to the Linux box where rtl_433 runs so I could see some of
> what rtl_433 sees. I wasn't quite using Audacity right and understanding
> the different file formats that were being output. Now I realize I could
> have answered some of my questions with the recorded files.
>
> With regard to the signal processing this brings me to some wishlist items.
>
> 1 - I'd like to have rtl_433 be able to give an idea of where the noise
> floor is as well as to see how it changes over time. There are some
> times of the day when receiving my outside sensors becomes difficult.
>
> 2 - It would be nice to have more dynamic level detection. This would
> be harder to implement and requires a bit more DSP background than I have.
>
> It would also be nice if these could be in some sort of units that
> have meaning or relation elsewhere. I think the units shown by SDR#
> are dbFS (ratio to Full Scale). Sure that's not a calibrated value
> but has a little meaning.
>
> Just wanted to add these thoughts to the discussion
>
> Thanks for your work on rtl_433, even in it's current form it is very
> useful and educational.
>
> --Rob

Right now the gain is set to auto for the rtl stick, so we would need to
query the stick for the scale and use that for the actual db report. I
have thought about it but I don't know enough on how to calculate it.
And then the limit value is hard to translate to a db scale as the limit
value is used in demodulator in a step that is operating on a known
scale. It should be possible to get a good metric when the change to
pulse list generation is done. Then we can calculate the total energy in
the signal for it's duration. That should be relatively easy to implement.

MvH
Benjamin Larson

[Benjamin Larsson]

On 01/25/2015 08:19 PM, Robert Terzi wrote:
> Benjamin:
>

[...]

> 2 - It would be nice to have more dynamic level detection. This would
> be harder to implement and requires a bit more DSP background than I have.
>
> It would also be nice if these could be in some sort of units that
> have meaning or relation elsewhere. I think the units shown by SDR#
> are dbFS (ratio to Full Scale). Sure that's not a calibrated value
> but has a little meaning.

If you read through the OOK signal demodulation mail we get to the
result R(t)=A^2. If you take the square root of that you get back the
amplitude from s(t) = A*sin(2*pi*f*t). That A can then be used to
calculate a proper dB value.

If you look at this picture:

https://lh3.googleusercontent.com/5tDjtyZpo-VmLXYaSmBy7gGeeG9R29lKiJxwcVntDkBrB_V7jPOq5qebi4J3iUnvsXStwQ=w1218-h751

You could take the first pulse and average all the samples. That should
give you the S^2_avg. Then take the signal between pulse 1 and 2 and
average that to N^2. If you now ask the rtl_sdr device what gain it is
using you now have everything you need to calculate signal strength and
the signal to noise ratio.

MvH
Benjamin Larsson

[Batilan]

Thanks for this excellent disquisition, unfortunately it seems I have no access to the picture (403 - forbidden).

Op zondag 1 februari 2015 15:42:42 UTC+1 schreef Benjamin Larsson:

[Benjamin Larsson]

On 02/08/2015 02:30 PM, Batilan wrote:
> Thanks for this excellent disquisition, unfortunately it seems I have no
> access to the picture (403 - forbidden).

https://drive.google.com/file/d/0B7StsLVdpBgfOHFTOWZXOUwzY00/view

/Benjamin