Rtl_fm already supports a lot of features,
but there is still lots to do.

No one in my area uses trunking.
I may need interested people to provide recordings.

Demodulate any number of channels, anywhere in the spectrum.
Basic antenna diversity could come out of this too.

Demodulate any number of channels that are within 2.4MHz.

Demod two channels simultaneously.
One goes to the left stereo channel, the other to the right.

Also known as named pipes.

Lots of room for improvement here, probably the #1 area of complaint.

Only one type of squelch is supported,
other types exist and should be options.

A time maximum that a carrier can hold the squelch open.

This might require using a channel configuration file.

Allow rtl_fm to support all rtl_tcp features.

https://github.com/sysrun/rtl-sdr

Allow DSP to be chained together in an arbitrary fashion.

Oversample mode requires extra lowpasing in order to be effective.

First, I would need access to the hardware in question.
Second, this could easily get very complicated very fast.

Signals with a well-defined carrier can be automatically tuned.
This could correct for thermal drift, doppler shift, or small typos.

Load and process pre-recorded raw iq streams.

Some way of identifying which station is received.

WBFM support is currently the lowest quality to confirm a dongle is working.

The present resampler is a pretty terrible boxcar filter.
Replace it with (at least) a CIC filter.

http://lists.osmocom.org/pipermail/osmocom-sdr/2013-September/000818.html

Various levels of freq, timestamp, power, squelch.

Create files such as 'freq_date_time.wav/raw'
(Only works with squelch.)

Information like last time seen, power level, per-channel squelch.

Produces a ticking sound in the audio at the buffer boundary.

There are some gaps in the SDR tool chain.

Audio stream in, raw bits out.

This is probably my weakest area and the most difficult section of code.
But I've written a bunch of usablity improvements and there are plenty more to do.
I can also do the boiler plate coding to transform your proof-of-concept patch into something likely to be merged.

Sometimes the USB will flake out.
Wouldn't it be nice if the library could power-cycle the USB port, restore the dongle's state and continue where it left off?
(Detected and handled automatically of course.)

There is no standard way to select automatic gain from the command line.
By using '-g auto', automatic gain can be forced.

When most of rtl_foo was written, 2.8MS/s was the safe upper limit.
Now it has been found to actually be 2.4MS/s and everything requires small tweaks.

http://lists.osmocom.org/pipermail/osmocom-sdr/2014-August/001347.html

The new range tests generate hundreds of harmless errors.

The PLL has a resolution of 439.45Hz when not dithering.

During verbose operation, the library should produce a warning when sampling is dangerously high.

I enjoy writing groff by hand and think everything should have a manpage.
This might be split into two subgoals, for the rtl_foo commands and rtl-sdr.h

This was originally a little demo thrown together in three days.
It has the potential to be the fastest, lightest and easiest to build waterfall ever.
screenshot 1 screenshot 2

One of the simplest ways of ID-ing a modulation.
Plots the IQ pairs on an XY plane.

Turn rtl-sdl into a real waterfall.
Mouse/keyboard controls to select a channel's freq and width.

SDL provides a nice cross-platorm audio library.
Basically would merge rtl_fm into the waterfall.

Turn rtl-sdl into a real waterfall.
Mouse/keyboard controls to select a channel's freq and width.

Yes, the useless one.
(Feature may be linux-only, we'll see how WinLIRC goes.)

Calculates the self-symmetry of a signal.
Very handy for deciding if a signal carries useful information.

Save your channels and quickly restore them.

Originally it was designed for a touch screen.
There are some non-sensical keybinds that map to the touch screen's hardware buttons.

There is no way to change the on-screen bandwidth.
Should also report the displayed bandwidth as well.

The screen size is fixed to the original demo hardware.
It does not yet detect full-screen or window resizing.

A waterfall power logger, without the burden of a GUI.

Heatmap was originally supposed to be a proof of concept.
It needs some work to become a serious plotting tool.

Convert rtl_power output directly to a heatmap
without saving the CSV to disk.

Every Y pixels, automatically save the image and start fresh.

Given a frequency or time range, draw only that section of the data.
Should be capable of relative time, such as "last hour".

Places marks around where and when a satellite should be detectable.

Produce files that can be read directly by gnuplot.

There are three cases to consider here:
1. Dongles == bands. Monitor all bands without hopping.
2. Dongles < bands. Hop in rotation.
3. Dongles > bands. Continuously monitor with most, hop with the remainder.
(It might be worthwhile to specify which dongles do which bands, for better antenna use.)

Right now rtl_power drops data while the FFT is being processed.

HDF5 is a popular binary format for scientific data.
Most likely this would be a stand-alone filter and not integrated into rtl_power.c

A lot of astronomy is measuring signal power, but rtl_power is not really suited for RA yet.

Wouldn't it be nice if a program could read the CSV directly,
without a length and memory-intensive conversion process?
Most importantly, it would give the exact time and frequency of a signal under your cursor.

Convert an rtl_power CSV file into a time/freq/duration activity log.
Possible sub-task for making it operate real-time?

There are several sample rates to meet a given FFT.
Default is fastest, make option for slowest.

An external script that converts the csv to active timestamped frequencies.

A very small ADS-B demodulator.
Normally the output is piped to a plotting program.

Doubling the sample rate would improve the SNR by half a bit and pick up weaker, more distant signals.
It will also increase the CPU use 3x or 4x so this will be optional.

Right now it can only produce the raw ADS-B hex.
Instead, fully decode the message.

At present it does no CRC checks.
If there are very few errors, it is possible to fix them and recover the message.

Provide an option to send output directly to an ip/port.

Rtl_tcp lets remote control dongles and stream across networks.

Typically compresses by 7x.

Provide a mechanism for 3rd party programs to follow dongle state.
For example, to automatically switch antennas based on tuning range.