Sunday, April 6, 2014

rtl_power (more modifications)

I've been working on improving the 'quality' of the rendered 3D data from my version of rtl_power.  This morning I reduced the MAXIMUM_RATE by 800k samples per second.

#define MAXIMUM_RATE  2000000 /* trh changed from 2800000 */

After a quick recompile, and restart of the running rtl_power instances I had running here are some results to compare with.

2.8msps

2.0msps

Notice the MUCH better rendered resolution, and the much smaller gap between frequencies!

Also notice that in the 2.0msps you can EASILY see an intermittent carrier at around 42 Mhz that you can't see in the 2.8msps version.  These are two diff dongles using the same upconverter, LNA, and antenna, running simultaneously.   There is NOTHING wrong with the 2.8msps RTL Dongle being used in this comparison.

Lets look at a much smaller spectrum in the same data 40-44Mhz between the 2.8msps and the 2.0msps now.

2.8msps

2.0msps

It appears that this change is a massive improvement!  Note that there is a difference in the time span being used between these to graphs however this should not be enough to cause this much of a vast difference. (I mistakenly deleted the raw data from the first graph too soon, to be able replot it to match the time in the second graph), this however is not the sort of issue that would cause the 'washed out' appearance of the 2.8msps graph.

Since for this frequency span we're we only scanning a total of 55Mhz (5-60Mhz) the additional retunes required for this change do nothing to impact overall performance negatively.

I may attempt later today to further reduce to doing 1msps MAX.  The goal is to reduce the dark fringes you see in the graph immediately above this text as much as possible.



1 comment:

  1. Hi Tim.
    About the change to the max sample rate and its effects: I find it a massive improvement like you say.
    At the same time there's something i don't completely understand yet.

    Lowering the sample rate i would expect loosing information and consequently seeing less detail.
    The charts actually show an increase of detail.

    Probably I've missed something while reading. I will read again the whole post... :-)

    Anyway, I think that, for Jupiter at least, there are different storm cases to detect for which different resolutions are needed.

    Rapid fire storms with reduced bandwidth would probably benefit higher detail - higher sample rate scans.
    Higher bandwidth storms, with rapidly decreasing frequency should be better covered by lower res - lower sampling rate scans.

    I will take some time to think at this and then email you :-)

    ReplyDelete