Troubleshooting wireless sensors

Over the years we have acquired a number of wireless sensors -- remote temperature sensors and motion detectors.  All of the ones that have failed spent time outside, something they (according to the manufacturers) should be able to handle.  While most seem to have failed due to moisture related problems, one of the motion sensors was colonized by ants.  It started sending out signals almost continuously because the ants were crawling across the surface of the sensor.  After cleaning out the ants and their nesting crud, the sensor stopped working -- sort of.

All these sensors SHOULD have been working, because the red or blue LED "transmit" lights would flash -- but their receivers weren't picking anything up.  One of the sensors appeared to have a greatly-reduced transmit range.  So what was going on?

Awhile back I bought a cheap SDR -- a software defined radio -- to play with.  It is an RTL-SDR, basically a USB dongle with an antenna and can receive RF from 500KHz to 1.7GHz.  I got it to use as an ultra-cheap spectrum analyzer, but it's very slow when used for that purpose.  This is mainly due to the design's relatively narrow RX bandwith (about 1MHz).  However, there's a simple application for it that can be used to troubleshoot wireless sensors.  It's called "rtl_433", and was written to listen to and decode wireless sensors.   Another handy utility is "gqrx", which has a RF spectrum display and a waterfall display.  A waterfall display shows the intensity of received signals over time -- the horizontal axis is frequency, and the vertical axis is the intensity over time (about 30 seconds are shown).  This is handy for pinpointing periodically-sent signals, like the type generated by wireless sensors.

The above shows the output of gqrx.  The small vertical red stripe in the waterfall portion is a burst of RF data sent by a wireless sensor.  In this case it's an Acurite temperature sensor.

The waterfall display shows this wireless sensor is transmitting close to the specification, which is 433.920MHz.  But the bad wireless sensors were all transmitting at significantly different frequencies:

-In this case, about 432.58MHz.

This is where the other utility, "rtl_433" comes in handy.  You can specify the frequency it listens to by calling it this way:  "rtl_433 -f 432580000" (the frequency parameter is passed in Hz).  I was able to get data from some sensors, but not all of them, by doing this.  BTW, rtl_433 should be called from the command line so it is NOT a graphically-oriented application.  I'm using Linux at home so I'm accustomed to using command line programs in a terminal window.

The sensors that were sending data (just at the wrong frequency) mostly likely had a frequency shift due to "crud" buildup under or around the transmitter components.  To test this, I soaked one in very hot water after opening the case up (and removing the batteries).  To help the circuit board dry faster I rinsed the board with isopropyl alcohol, then left the board to dry in the sun for a few hours.  I reassembled everything and checked the transmit frequency -- right back to where it should be.  After resetting the receiver unit, it started picking up the sensor.  Success!

Now I need to figure out why the other units aren't sending data, despite having a functioning transmitter.  That may be a more serious problem, but one clue is that the amplitude of the transmitted signal is quite a bit lower compared to a good unit.  I suspect the RF is not being modulated, perhaps due to more-robust "crud" on the circuit board.  Time to look at the board more carefully.....