X10 EagleEye RMS18 - Multiple frequencies

[H S]

I am trying to use six X10 EagleEye RMS18 motion sensors with RTL433

They are supported via Protocol 22;

I have checked the individual devices for actual frequency via SDRSharp.

Thought they would all be the same but the central frequencies are:

310.1

310.275

310.3125

310.625

310.7375

310.9625

From what I see in SDRsharp and average stats from RXUI, the output seems to be OK (or is it?):

RSSI between -0.1 and -0.2

SNR between 5 an 10

NOISE between -5 and -10

If I tune about 100k under the actual frequency of a single device, it gets decoded correctly as I consistently get all 5 repeated signals which is typical for these units.

Since the original receiver (CM15) was working with all of them,

I tought I could decode them all with a single average frequency.

however, after trying a number of frequencies, samples rates, gain etc. I can't figure out a way to get decent decoding for all devices at once.

Is this possible at all based on the above data ?

am I missing some basic concept ? 

Anything I should test/fine tune ?

Let me know if you can assist, I can also provide further data if required. 

 

Thank you!

[H S]

Ok I had not gone beyond 1024k for sample rate, now using 2048k seems promising;

-d 1 -R 22 -f 310.558M -s 2048k -F http -F mqtt://192.168.0.etc....

still open to suggestions for further fine tuning though. 

and learn from more experienced people here.

Thx,

[Christian Z.]

At 2048k you might need to think about cooling the receiver.

The band is of "sample rate"-width, so 1000k should cover it. Add some drift and you might miss a sensor though :/

The noise shown seems really high, SNR above 9 dB should be fine, but we expect noise below -15 dB, around -20 dB in usual setups. Is there interference on the band?

[H S]

I have two receivers, one running 433Mhz, default sample rate; the other one at 310Mhz, 2048k ( dedicated to this project so only protocol 22 is running)

They both run at what seems to be a normal 33C temperature. so no issue there I guess.

They are connected to ground plane antennas with correct frequency.

Stock X10 receiver what working well with this setup.

Logically, with frequency set at 310.558M ( which I found in the protocol notes : https://github.com/merbanan/rtl_433/blob/master/src/devices/x10_sec.c)

and sensor frequencies within the 310 range, I should see no reception/decoding difference between 1024k and 2048k, right?

I am not new to this but not an expert either; 

I think I understand how drift could affect a single sensor/receiver and the fine tuning associated

But how would this affect my use case with multiple sensors/frequencies?

Does it mean that all sensors frequencies must be in some sort of "phase" with the tuned frequency, rendering this difficult (or impossible) to accomplish ?

Just don't want to spend time trying to fix something with a flawed plan.

As for the noise, I have SDRsharp visual data but don't have enough experience to assess the noise/interference level (see below)

The bottom signal comes from one of the sensors and has some type of "echo" on each side (normal? good? bad?)

What are the best practices to diagnose/fix noise (or other potential) reception issues?

Could other settings (-g -Y , etc.)  play a role in the solution or should I keep it default/auto ?

open to any suggestions / further testing.

Thank you

[Christian Z.]

I should see no reception/decoding difference between 1024k and 2048k, right?

Ideal case, yes. But there are some filters and processing steps, so higher sample rates tend to work better for "faster" protocols (e.g. 50 µs FSK). And "slow" protocols like this (562 µs OOK) will work better with low sample rates.

Also higher sample rate means wider band and that picks up more potential noise.

But you are interested in the width of the band here: highest sensors frequency minus lowest sensors frequency gives the desired sample rate (band width). So 1024k can cover 310.0M to 311.0M.

Noise looks ok, really quiet in SDR# (-36) and also ok in rtl_433 (-14). The harmonics are normal.

 

[H S]

Thank you, seems to be working *OK* now; a certain percentage of signals are not detected but it is acceptable.

 not as efficient as modern 433Mhz sensors which won't miss a beat, but hey these are from the 80's and I believe the 310Mhz band FCC regulations call for a lower signal strenght.

Still want to use them because they have great battery life, especially outdoors in cold weather.

 also found further notes in the protocol code which confirm my previous tests:

"Seems to work best with 2 MHz sample rate: rtl_433 -f 310M -R 22 -s 2M"

Finally, just to improve my skills would you mind answering the following:

- When assigning a frequency, I've read that you have to try to move away from the center frequency, around 100k under.

Is this just guess work / hit and miss or is there a logic way to calculate the optimal SDR frequency or use SDRsharp to find it?

- Other than covering the spectrum of target frequencies, is there any "fine tuning" involved with the Sample rate

Ex: could changing the sample rate from 2048k to 2071k or 2012k make some sort of significant difference ?

- What is the minimum/maximum gain that can be used with -g and, if it's worth it for my current use case, what would be the best practice to test it?

- For general usage on known/existing protocols, when should we move away from the default/auto values for gain  (-g) and pule detection (-Y) ? 

- Am using Windows 10, any other tools worth having in my toolbox other than the triq.org suite and SDRsharp ?

Thanks for your help,

[Christian Z.]

working *OK* now; a certain percentage of signals are not detected but it is acceptable.

Great to hear!

 

"Seems to work best with 2 MHz sample rate: rtl_433 -f 310M -R 22 -s 2M"

Strange. Might be some quirks with filters. Our two examples work fine at 250k.

 

- When assigning a frequency, I've read that you have to try to move away from the center frequency, around 100k under.

Is this just guess work / hit and miss or is there a logic way to calculate the optimal SDR frequency or use SDRsharp to find it?

There can be a DC spike at the center frequency, either from the receiver or processing steps. (Basically there is fake tone at 0 Hz).

That will interfere with reception and also a signal at around 0 Hz has no (practical) sine shape anymore. Not ideal for processing. A few kHz away should be fine, in practice 10-50k -- you want each pulse to be multiple oscillations, for faster signals you need to tune away further.

 

- Other than covering the spectrum of target frequencies, is there any "fine tuning" involved with the Sample rate

Ex: could changing the sample rate from 2048k to 2071k or 2012k make some sort of significant difference ?

Not all rates are supported by SDRs. Unless you specifically want to match a (fast) data rate it doesn't matter really.

 

- What is the minimum/maximum gain that can be used with -g and, if it's worth it for my current use case, what would be the best practice to test it?

Very much dependant on the SDR and chip used and which gain stage are used. 0-49 for the R820T RTL-SDR.

 

- For general usage on known/existing protocols, when should we move away from the default/auto values for gain  (-g) and pule detection (-Y) ? 

Only if you need a fixed level to compare (absolute) signal strength. Otherwise the AGC is very useful.

The -Y autolevel will help to read even faint signals. But that feature is new and not tested well.

 

- Am using Windows 10, any other tools worth having in my toolbox other than the triq.org suite and SDRsharp ?

PulseView from SigRok maybe, gory details about the actual I/Q signal and demod state. We have an output mode for that "-w myfile.sr".

Have fun!

[H S]

Thanks for your help, much appreciated.

One last thing, I know it can vary from case to case is there some type of general reference/charts/guides you could recommend to interpret/compare the different signal parameters:

-RSSI

-SNR

-NOISE

(something equivalent to the Wifi RSSI table below)

-RSSI

-SNR

-NOISE

[H S]

You also mentioned harmonics which I would add to the parameters above.

Thx

[Christian Z.]

The "minus dB" values are just a relative strengh, or rather attenuation, not an absolute measurement like dBm.

Maxed out dynamic range is -0dBm and we are showning the "dampening".

RSSI is the "dampening" of the signal, noise is the value before and after the signal. SNR is just the difference.

Harmonics here are an artifact of "sharp edges" in a loud signal, should be integer multiples of something like the data rate, I guess. It's sign of a crude signal or too much gain, I'd say.

[H S]

Thx

So to summarize:

In SDRsharp 

Noise:  smaller number is better, < -30 is good (-35 for instance)

In RXUI

-RSSI : closer to 0 is better ("dampening" of the signal vs Maxed out dynamic range ie:-0dBm )

-SNR : higher number is better , > 15db is good

-NOISE : smaller number is better < -15 is good

Where do you look for to assess harmonics ?

Is my graphic below somewhat accurate ?

[H S]

I think I've actually reversed Noise and SNR on my graphic,

[Christian Z.]

Yes, looks great. rtl_433 currently needs at least 9 dB SNR to pick up a signal. Without "-Y autolevel" at least -15 dB RSSI is needed to read a signal, usually I see -0 to -8, with autolevel e.g. -28dB is also fine.

Noise at -35 dB is really quiet (if the receiver is a RTL-SDR), up to e.g. -18 dB is "normal".

[Christian Z.]

Ah, harmonics, that's just extra "lines", equally to "left and right" in the waterfall or spectrogram ("up and down") around the actual signal. You had them in the SDR# picture.