Since I mentioned this in the other thread...

I've long used my scanner's "close call" feature to notify me of when there were nearby transmitters --
usually it's the local sheriff deputies coordinating lunch, but sometimes it's real police traffic, or the
local fire department, and I'd get daily pings on the APRS frequency of hams driving by.

I have a couple issues with close call on a scanner, though. I really don't need alerts when there's a
nearby APRS transmitter, and the way close call works, you need a very strong signal -- it's working off
of near-field RF -- to trigger it. Which is great, but given that I'm in a rural area, getting an alert at a 1/4 mile
is pretty much next door -- literally just a few houses away from me. I really wanted a "sort of" close call,
that wouldn't necessarily be dependent on near-field RF, but also wouldn't go off on every single transmission
that could be heard -- so basically, something that would be like a squelch with a very narrow range.
Now, in theory you could do that with a scanner if you set the squelch high, but unlike close call, you'd
need to program frequencies, unless you used the "search" mode -- which is so slow it'd miss short
transmissions. What if it's a frequency you don't know about? So I wanted something that would
do all this better than my scanner could.

Ideally, a spectrum analyzer could do this, if you could set it to trigger on peaks across the spectrum,
and watch for them 24/7.

One of the great things (or terrible things if you like fancy graphic interfaces) about linux and other unix
operating systems the the so-called "unix philospophy" of simple command-line tools that you can use to
automate things, and the ability to combine a bunch of simple programs to do something more complex.
As it turns out, a fellow radio geek applied this philosophy to software-defined radio using the popular
RTL-SDR dongles. He created a fantastic tool, rtl_power which takes a few command
line settings and happily spits out power levels for the entire spectrum you want to monitor as a simple
comma-separated value (CSV) text file.

So a simple command line:
rtl_power -d 0 -p 52 -c 50% -f 137M:174M:10000 -i 4 -g 18 -P -e 8h  >> vhf.csv

Will tune a RTL-SDR dongle from 137MHz to 174MHz in 10KHz steps, logging the peak power level seen
for each bin every 4 seconds. You can do some cool things with this. Another tool, heatmap, for example
will convert that file into an image of all activity in the range specified over time:

56K alert! (Heck, probably DSL alert too!)
This is a 5MB image of the VHF hi band traffic in my area for the past 2 hours.
(I had to edit it from 8 hours because the file is too big to share!)
Here's the spectrum image.

So that's cool -- you can see, for example, the periodic APRS packets at 144.39 MHz, or that fact that
I have pretty awesome reception of the local NOAA weatherradio station at 162.55 MHz. You can also
easily see some frequencies that have repeaters, since two of them light up at once and one of the
lines will be consistently bright, while the other (input frequency) is variable. The great thing is all of
this works regardless of the signal type and modulation -- even FHSS or DSSS would show up as random
spikes on the heatmap or an obvious increase in noise floor.

What about the closs call feature?

Well, there's a utility in most unix systems called "tail", that shows the last few lines (the tail end, get it)
of a file. And there's another option to tail, "-f" which means follow. So basically, "tail -f filename" will
keep watching a file, and everytime something is added to it, it will spit out the new stuff. So, to get
the "close call" feature, I just run tail -f on the vhf.csv file that first rtl_power program is generating.
The output gets piped into a short python program (at the end of this post) that will set off an alarm
and report strong signals when it sees then, and also can filter out persistently strong signals that
might otherwise trigger the alarm. All this program does is look at the reported signal strength
and spit out the time and frequency if it's above a certain level. All the if-then statments are just
silencing some strong transmitters I don't care about.

I happen to use a couple other command line tools, cwpcm (which generates a .wav file of morse code)
and aplay (alsaplayer, which plays wav files through your audio card) to generate the alarm, but
you could run any program you want, really.

Here's the hacked python program, apologies for the double-spacing, it's the formatting that's doing it.:

#!/usr/bin/python

# rf-alert

# warn on high RF sensed



import sys

import os

import time

import subprocess



def main():



    max = -50.0



    for csv in sys.stdin:

        #csv = sys.stdin.readline()

    

        data = csv[:-1].split(",")



        for i in range(7, len(data)):

            if (float(data[i]) > max):

                max = float(data[i])

                print max



            if (float(data[i]) > 5.0):

                freq = int(data[2]) + int(data[4])*(i-6)

                show = True

                if (freq > 162500000) and ( freq < 162600000):

                    show = False

                if (freq > 154200000) and ( freq < 154300000):

                    show = False

                if (freq > 152200000) and ( freq < 152300000):

                    show = False

                if (freq > 154450000) and ( freq < 154470000):

                    show = False

                if show:

                    print data[0].strip()+chr(9)+data[1].strip()+chr(9)+str(freq)+chr(9)+data[i].strip()

                    if (float(data[i]) > 10.0):

                        os.popen("echo 'rf rf' | cwpcm -w 20 -F 20 -v 20 -f 400 -lowrez | aplay -q ")



main()

Read once, will read several more times before it sinks in.

OST

same here.  You have my attention however.

Updated with the image. No service would take the 20MB file so it's trimmed to only 4MB (about two hours of traffic.)
Each pixel in the image is 10KHz wide and 4 seconds long.

Ok, thats cool.

I dont really have a use for it, but a buddy of mine is one of the radio reference guys and he is always looking for previously unknown stuff. This is  right up his alley.

I have been using rtl_power for a little over 6 months. It is an awesome tool and has come in handy a few times. I made a post about it here back when I was first wow'd by it.

I have a raspberry pi doing nothing right now




super tag until I can digest this

As if I need another iron in the fire... I do want.

OST

I'm with you... But this is a pretty cool idea.

this thread is fapworthy.  tagging for later further cogitation.

Mad skillz, seek2 has them.

Still reading. Making more sense.

Which base linux distro are you running this under?

seek, which dongle are you using? Going over to re-read GCWs thread for the same info.

Distro is slackware arm (probably not the best choice) but any distro that python and rtl_power/rtl-sdr runs on should work fine,
there's no whacky dependencies.

The RTL-SDR dongle I'm using currently is the Nooelec Mini 2, though
virtually any of them should work. You might have a few issues with birdies, but the if-then statements can filter most of those
out if they're so strong as to be over the detection threshold.

That's the one I was looking at, but reading /r/RTLSDR sub on reddit they seem to say it's not worth double the price. I'll probably still get it because I can't seem to find the "White one" or the "cozycave" one they refer to.

Yeah, 2X the price and its $23. The dudes complaining about $12 are whining a wee bit too much.

Almost every one of them has something a little off -- might only tune to 50 MHz, might have
too many birdies, might not be stable until warm up, etc etc. This one probably has the fewest
issues -- I've got four different brands/versions including the white one.

I wouldn't sweat spending the extra money.

Too late. I already ordered it.

That's good -- I'm not sure if you got what I meant -- getting the "expensive" one is the right move, so not too late.

Honestly all the cheaper ones were coming from China and were going to take 2-3 weeks. I went with the one that could easily be here in a day or two. That alone is worth the extra $10.

The original PI has enough horsepower, or should we look at the B rev, or the version 2?

If you have one, it should be fine. rtl_power's load on a Pi 2 is about 20% or so, so I'm sure a Pi can
hack it. It barely uses any memory.

If you're going to get one, I'd get a Pi 2, the extra memory and horsepower for a few more dollars is
a bargain.

There are lots of reasons to buy an A or B+. Your first Pi isn't one of them.

It's when the projects start multiplying and you see the benefits of one of the smaller ones that you appreciate they still exist. For example: the radio in my car has a video input....I use one of the ones with the yellow TV output and have a pi in my car.


(Now to come up with a reason to do that....)

See what I mean?