Missed transmissions

[David Powell]

I'm looking for insight on figuring out why I'm missing some sensor transmissions on my RTL device.

The setup:

At the street end of my driveway (not visible from the house) is a gate with a Mighty Mule gate opener.  A few meters on the inside of the gate is a Mighty Mule FM231 driveway alarm sensor.  I modified the receiver of the FM231 to trigger the gate opener when a vehicle passes the sensor.  This has been almost 100% reliable for several years.

In an outbuilding about, I dunno, 50 meters from the sensor, I installed an RTL device plugged into a dedicated RPi3b+ and and external home-built antenna, running rtl_433*. It receives the signal from the FM231 and sends a message to my MQTT broker when it detects a vehicle coming or going on the driveway.

My Home Assistant server sees the message, takes a snap from a security camera in that area, and sends it to me in an MMS message.  This gives me a good idea and record of who is coming and going on my property and when they are doing so.  I also have a "squawk box" that I built that subscribes to that MQTT topic and verbally announces the arrival and departure of visitors, to eliminate the (sometimes very lengthy) delay in receiving MMS messages over the cellular network.

The only other sensors that the SDR reports on are for temperature and humidity.  There's nothing else running on the RPi.

The problem:

I only get notifications about 70% - 80% of the time a vehicle passes the sensor.  The gate opener always activates, so I know that the transmitter is sending the signal.  The modified FM231 receiver is located at the gate, which is about the same distance from the transmitter as the RTL device in the outbuilding is.  The RTL device reports a signal strength of -10db to -17db most of the time, but occasionally for some reason it will dip down to -21db or go up to -4db. I don't know why the signal varies so much but I am using the -Y autolevel parameter so that shouldn't be an issue I don't think.

Questions:

Is it possible that the RPi can't keep up with the signals?  The FM231 normally sends a dozen or so identical messages on each detection, so surely this is not the problem.

Could the signal strength dips below -20db be the cause? I haven't figured out a way to correlate the dips with the missed transmissions.

What else can I look at to try to increase the reliability of this setup?

Thanks

* version 22.11-5-gd4c0e626 branch master at 202211211916 inputs file rtl_tcp RTL-SDR

[Greg Troxel]

David Powell <da...@depowell.com> writes:

> At the street end of my driveway (not visible from the house) is a
> gate with a Mighty Mule gate opener.  A few meters on the inside of
> the gate is a Mighty Mule FM231 driveway alarm sensor.  I modified the
> receiver of the FM231 to trigger the gate opener when a vehicle passes
> the sensor.  This has been almost 100% reliable for several years.

Interesting. I didn't know about Mighty Mule.

> In an outbuilding about, I dunno, 50 meters from the sensor, I
> installed an RTL device plugged into a dedicated RPi3b+ and and
> external home-built antenna, running rtl_433*. It receives the signal
> from the FM231 and sends a message to my MQTT broker when it detects a
> vehicle coming or going on the driveway.

If you are using a Nooelec SmarTEE or a RTL-SDR Blog dongle, ok, but if
anything less, you should upgrade. I mean that you have something with
a metal case and a 0.5 ppm TCXO. The older/cheaper plastic case dongles
are just not as good. I noticed a 10 dB snr improvement when upgrading,
very roughly from memory, but it was a big deal.

You didn't say how you are doing MQTT, but I would use the relay script
and also log tcpdump of the json output on 1433.

You also didn't say how you are doing mqtt. I'm guessing you have wired
ethernet. I would look at connect/disconnect logs.

> my Home Assistant server sees the message, takes a snap from a

> security camera in that area, and sends it to me in an MMS message. 
> This gives me a good idea and record of who is coming and going on my
> property and when they are doing so.  I also have a "squawk box" that
> I built that subscribes to that MQTT topic and verbally announces the
> arrival and departure of visitors, to eliminate the (sometimes very
> lengthy) delay in receiving MMS messages over the cellular network.

You might try xmpp or the HA app notifications, so it's IP vs MMS.

> The only other sensors that the SDR reports on are for temperature and
> humidity.  There's nothing else running on the RPi.

How reliable are these?

> *The problem:*

>
> I only get notifications about 70% - 80% of the time a vehicle passes
> the sensor.  The gate opener always activates, so I know that the
> transmitter is sending the signal.  The modified FM231 receiver is
> located at the gate, which is about the same distance from the
> transmitter as the RTL device in the outbuilding is.  The RTL device
> reports a signal strength of -10db to -17db most of the time, but
> occasionally for some reason it will dip down to -21db or go up to
> -4db. I don't know why the signal varies so much but I am using the

> /-Y autolevel/ parameter so that shouldn't be an issue I don't think.

There could be crud from other transmitters.

> *Questions:*

>
> Is it possible that the RPi can't keep up with the signals?  The FM231
> normally sends a dozen or so identical messages on each detection, so
> surely this is not the problem.

It is highly unlikely that the cpu isn't keeping up, but look at CPU
time.

How did you adust frequency? When you look at the frequency metadata,
are the values in range, so that you aren't on the edge and have it go
in and out of the configured coverage? And stay away from 0?

> Could the signal strength dips below -20db be the cause? I haven't
> figured out a way to correlate the dips with the missed transmissions.

You aren't really measuring signal strength, but SNR.

Look at and plot the signal strengths noise and snr from the
temp/humidity sensor over time. Especially if same freq (all
433.92?).

My arguments (but I am not trying to receive a Might Mule or anything
like it, just weather-type sensors and TPMS):

# units
UNITS="-C si"

# RF stats
STAT_RF="-M level -M noise -M stats"

# proto stats
STAT_PROTO="-M protocol -M bits"

# low levels
LEVEL="-Y autolevel -Y minlevel=-30 -Y magest"

OPTS="$UNITS $STAT_RF $STAT_PROTO $LEVEL"


You really want the stat option. and to log all that, via tcpdump to
file on the pi and mqtt subscribe on the HA/broker machine.

[David Powell]

On 9/13/23 5:37 PM, Greg Troxel wrote:

David Powell <da...@depowell.com> writes:

At the street end of my driveway (not visible from the house) is a
gate with a Mighty Mule gate opener.  A few meters on the inside of
the gate is a Mighty Mule FM231 driveway alarm sensor.  I modified the
receiver of the FM231 to trigger the gate opener when a vehicle passes
the sensor.  This has been almost 100% reliable for several years.

Interesting.  I didn't know about Mighty Mule.

Good products.  The FM231 is basically a battery-powered metal detector that you bury next to your driveway. Two AAs will last years. I don't see how they do it.

In an outbuilding about, I dunno, 50 meters from the sensor, I
installed an RTL device plugged into a dedicated RPi3b+ and and
external home-built antenna, running rtl_433*. It receives the signal
from the FM231 and sends a message to my MQTT broker when it detects a
vehicle coming or going on the driveway.

If you are using a Nooelec SmarTEE or a RTL-SDR Blog dongle, ok, but if
anything less, you should upgrade.  I mean that you have something with
a metal case and a 0.5 ppm TCXO.  The older/cheaper plastic case dongles
are just not as good.  I noticed a 10 dB snr improvement when upgrading,
very roughly from memory, but it was a big deal.

You didn't say how you are doing MQTT, but I would use the relay script
and also log tcpdump of the json output on 1433.

You also didn't say how you are doing mqtt.  I'm guessing you have wired
ethernet.  I would look at connect/disconnect logs.

I've tried several, both plastic and metal. The current one is the little Nooelect NeSDR Nano 2 Plus, which I really like.  See no difference in the problem no matter which I use.

MQTT is done by rtl_433's  -F mqtt option.  Transport is wifi to a router located about 1 meter away. The router is connected via a media converter to fiber which is connected likewise to my home network at the other end.

my Home Assistant server sees the message, takes a snap from a
security camera in that area, and sends it to me in an MMS message. 
This gives me a good idea and record of who is coming and going on my
property and when they are doing so.  I also have a "squawk box" that
I built that subscribes to that MQTT topic and verbally announces the
arrival and departure of visitors, to eliminate the (sometimes very
lengthy) delay in receiving MMS messages over the cellular network.

You might try xmpp or the HA app notifications, so it's IP vs MMS.

The MMS is just for convenience, so I don't have to install/run/configure external software on all family phones. They already have IM clients that support MMS.  XMPP would be great if the built-in clients would support it.

The only other sensors that the SDR reports on are for temperature and
humidity.  There's nothing else running on the RPi.

How reliable are these?

AFAICT, 100% reliable.  But their reporting is periodic, not sporadic like visitors, and missing an update isn't important.  Come to think of it, I'm not sure how I would even detect a missed update from a temperature sensor.  Of course, the temp/hum sensors are only a meter or so from the RTL device.

*The problem:*

I only get notifications about 70% - 80% of the time a vehicle passes
the sensor.  The gate opener always activates, so I know that the
transmitter is sending the signal.  The modified FM231 receiver is
located at the gate, which is about the same distance from the
transmitter as the RTL device in the outbuilding is.  The RTL device
reports a signal strength of -10db to -17db most of the time, but
occasionally for some reason it will dip down to -21db or go up to
-4db. I don't know why the signal varies so much but I am using the
/-Y autolevel/ parameter so that shouldn't be an issue I don't think.

There could be crud from other transmitters.

I thought of that, but just don't see it.  Plus, wouldn't that also affect the opening of the gate?

*Questions:*

Is it possible that the RPi can't keep up with the signals?  The FM231
normally sends a dozen or so identical messages on each detection, so
surely this is not the problem.

It is highly unlikely that the cpu isn't keeping up, but look at CPU
time.

How did you adust frequency?   When you look at the frequency metadata,
are the values in range, so that you aren't on the edge and have it go
in and out of the configured coverage?  And stay away from 0?

I'm using a sample rate of 1024K.  Here is a sample of the recorded frequencies:

Could the signal strength dips below -20db be the cause? I haven't
figured out a way to correlate the dips with the missed transmissions.

You aren't really measuring signal strength, but SNR.

Look at and plot the signal strengths noise and snr from the
temp/humidity sensor over time.   Especially if same freq (all
433.92?).

My arguments (but I am not trying to receive a Might Mule or anything
like it, just weather-type sensors and TPMS):

# units
UNITS="-C si"

# RF stats
STAT_RF="-M level -M noise -M stats"

# proto stats
STAT_PROTO="-M protocol -M bits"

# low levels
LEVEL="-Y autolevel -Y minlevel=-30 -Y magest"

OPTS="$UNITS $STAT_RF $STAT_PROTO $LEVEL"


You really want the stat option.  and to  log all that, via tcpdump to
file on the pi and mqtt subscribe on the HA/broker machine.

Well, it may be just semantics, but rtl_433 calls it rssi. Here's a plot of the same period.  There does seem to be some rough correlation between rssi and frequency:

Thing is, it will go in spells.  It may catch every vehicle for a week or more, then not catch any for several days.  Other times it's hit-or-miss on each one.

The home-made antenna is really the only constant that hasn't been swapped trying to fix this problem, but at that short distance, line-of-sight, it doggone almost shouldn't even need an antenna.  May just try replacing it anyway for completeness' sake.

I'll try to figure out a way to set up some logging to catch 'misses' somehow.  I'm sure it won't be perfect but maybe that will shed some light.  Thanks!

David

[Benjamin Larsson]

On 2023-09-13 22:31, David Powell wrote:
>
> *The problem:*

>
> I only get notifications about 70% - 80% of the time a vehicle passes
> the sensor.

The most likely problem is other signals that interfere with the main
signal. The rtl-sdr uses the same bandwidth by default as the number of
samples that are set. Try lowering it to 250Ms.

There are other options but to evaluate possible solution we need new
logic and time to test the code, which I currently dont have. So for the
foreseeable future play with the sample rate and frequency. You could
alsp try to set a fixed gain but that will most likely give least results.

MvH
Benjamin Larsson

[Jérémie Abeilhou]

Hello guys,

I read all of your messages carefully  because I am experiencing a similar issue with a pool thermometer (Inkbird ITH20R). The device is normally updating its states every 80 seconds but I spend some times hours without updates. 

I added statistics in my logs as suggested by Greg (thank you very much by the way it's a wonderful feature !). I noticed a lots of "abort_length" and "fail_sanity". Can anyone tell me what those counters are please ? I didn't find so much information about the stats feature in the documentation and I guess this is why I miss updates from the device. 

The counters :

Inkbird ITH-20R temperature humidity sensor                       events    : 192           ok        : 0             messages  : 0             abort_length: 54          fail_sanity: 138

Thanks for your help

--
You received this message because you are subscribed to the Google Groups "rtl_433" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtl_433+u...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rtl_433/baa689dd-1664-6bd7-b90e-28a9766a1fad%40ludd.ltu.se.