Tuesday, January 09, 2018

Monitoring the Monitors: Setting up a Raspberry Pi, and Tripping over rtl_power data (Part 2)

Last week I had success monitoring my alarm system's motion detectors and door sensors. This week I'd hoped to take the ad hoc detection capability and make it something more formal.

First off, I needed to improve the platform I was using. Detecting signals using my cell phone is fun, but not practical. I really wanted a small, always on device, that could sniff the data out. My raspberry pi seemed like the ideal candidate to fill this role.

I found this transcript which walks through the complete process of setting up RTL command line tools on a pi. To my great delight, every command in the transcript worked. The result was SDR enabled Raspberry Pi.

I figured the best chance I'd have at scripting behavior based on FM signals was to leverage rtl_power. I went ahead and kicked off the following command on the pi:

$ rtl_power -f 344M:346M:200K -e 30 -i 1 > motion.1.csv

If my understanding of the command line options are correct, I'm asking rtl_power to scan 344Mhz to 346Mhz and put the collected data in 200Khz buckets. I know I'm looking or burp of activity in that range. I'm running this process for 30 seconds and have the integration time set to 1 second.

Everything went smoothly, until I looked at the data itself. Consider one run where my front hall's motion detector was dormant, and one where it was active:

As you can see, there's a large number of nan values. Which means...uh, I have no idea what this means. Obviously, I need to figure out what's going on with those nans, and figure out if there's a way to avoid them. Perhaps I'm using the wrong tool altogether? At least I have an SDR capability Raspberry Pi setup, I can imagine using that in all sorts of ways going forward.

If you see where my logic went off the rails, or have a suggestion for how I can get this working, I'm all ears! Please share in the comments.

No comments:

Post a Comment