21 Oct
2012
21 Oct
'12
7:25 p.m.
Hello everyone, I hope this is an appropriate forum for a beginner
question about using an E4000 dongle.
I'm an amateur astronomer, and lately I've been wanting to get into
amateur radio astronomy. The rtlsdr seems like a really cheap way to
get involved. It can tune many interesting frequencies, in particular
channel 37 around 608-614 Mhz.
I am a Python programmer by trade so I am using roger-'s amazing
pyrtlsdr library which is great, I can read samples from the device
and they get returned as numpy arrays. The scipy.signal package
allows me to correctly decimate the signal and I am working on a
simple graphing program to graph signal levels in realtime, by hour,
by day, and by week. I hope to basically reproduce the Jansky
experiment that started the entire science of radio astronomy:
http://en.wikipedia.org/wiki/Karl_Guthe_Jansky
I have a question though about how to use the dongle that I can't
quite figure out. roger-'s demo_waterfall program, for example, sets
the default sample_rate to 1.4e6, but then on each scan only calls
read_samples(2**16). The demo displays the entire megahertz of
bandwidth, so I'm a bit confused as to how the 64K samples map onto
the 1M samples of the device. It doesn't seem to make sense taht the
device only returns the first 64K samples. Can anyone clue in a total
beginner on the sample rate and reading samples from the device
correlate?
Thank you!
-Michel
21 Oct
21 Oct
10:12 p.m.
To get from the time domain (the raw samples) to the frequency domain
(waterfall display, etc.), you need an FFT. The FFT operates on some
given buffer size, and outputs a buffer of the same size filled with
complex frequency levels (where the magnitude squared is the signal
energy).
The FFT width determines your frequency resolution, not the bandwidth.
The bandwidth is determined by the sample rate--in your case, 1.4 MHz.
So you choose your FFT based on your resolution and performance
requirements. In your case, the FFT will return frequencies from -0.7
to 0.7 MHz around the center frequency--no matter what the FFT width.
The FFT results store the positive frequencies from 1..(N/2-1) and the
negative ones from (N/2+1)..(N-1). Sample 0 is 0 Hz and N/2 is 0.7 MHz
(you can't really use this last one since it aliases). The other
frequencies scale linearly between these points (sample N/4 is 0.35 MHz,
etc.). For a waterfall display, this generally means you want to swap
the left and right halves of a buffer.
You can read as many samples as you want from the device. Conceptually,
it's similar to an audio device--if you need more samples, you just wait
longer. You could collect 64M samples if you wanted, and get some nice
sub-Hz resolution, but it would take 45 s to record at your settings.
There is of course a tradeoff between time and frequency resolution. I
don't know much about radio astronomy, but you'll probably want to
figure out what the shortest timescale events you'd like to track are,
and choose the FFT width based on that.
Incidentally, none of this is peculiar to rtl-sdr--even the fanciest and
most expensive units operate the same way, though they have higher
sample rates and such. In fact, the stuff I said is fundamental to all
signal processing--if you're willing to get your hands dirty with math,
you might want to read the wiki articles on Fourier Transforms and other
signal processing subjects.
-Scott
On 10/21/2012 10:25 AM, Michel Pelletier wrote:
Hello everyone, I hope this is an appropriate forum
for a beginner
question about using an E4000 dongle.
I'm an amateur astronomer, and lately I've been wanting to get into
amateur radio astronomy. The rtlsdr seems like a really cheap way to
get involved. It can tune many interesting frequencies, in particular
channel 37 around 608-614 Mhz.
I am a Python programmer by trade so I am using roger-'s amazing
pyrtlsdr library which is great, I can read samples from the device
and they get returned as numpy arrays. The scipy.signal package
allows me to correctly decimate the signal and I am working on a
simple graphing program to graph signal levels in realtime, by hour,
by day, and by week. I hope to basically reproduce the Jansky
experiment that started the entire science of radio astronomy:
http://en.wikipedia.org/wiki/Karl_Guthe_Jansky
I have a question though about how to use the dongle that I can't
quite figure out. roger-'s demo_waterfall program, for example, sets
the default sample_rate to 1.4e6, but then on each scan only calls
read_samples(2**16). The demo displays the entire megahertz of
bandwidth, so I'm a bit confused as to how the 64K samples map onto
the 1M samples of the device. It doesn't seem to make sense taht the
device only returns the first 64K samples. Can anyone clue in a total
beginner on the sample rate and reading samples from the device
correlate?
Thank you!
-Michel
10:22 p.m.
Scott Cutler wrote:
To get from the time domain (the raw samples) to the
frequency domain
(waterfall display, etc.), you need an FFT.
..
In fact, the stuff I said is fundamental to all signal
processing
And as it happens, the GNU Radio package allows to snap many powerful
signal processing blocks together using python.
Don't reinvent a square wheel. Learn to use GNU Radio.
//Peter
22 Oct
22 Oct
12:29 a.m.
And as it happens, the GNU Radio package allows to snap many powerful
signal processing blocks together using python.
Thanks Peter, I have installed gnu-radio and played around with it and
rtlsdr, it was great for getting immediate results and picking around
through the spectrum to see what's around. If it provides
functionality for radio astronomy, of course i would love to use it,
but my very initial investigation didn't reveal much for me.
Don't reinvent a square wheel. Learn to use GNU
Radio.
No square wheels here, pyrtlsdr, numpy, scipy, and matplotlib, are the
precisely machined wheels I'm using so far to just dump and examine
data. Any attempt on my part to implement any form of advanced signal
processing would be totally foolish.
-Michel
12:45 a.m.
Michel Pelletier wrote:
I think it may provide the primitive blocks that you need, even
if they weren't specifically created for radio astronomy.
And as it
happens, the GNU Radio package allows to snap many powerful
signal processing blocks together using python.
Thanks Peter, I have installed gnu-radio and played around with it and
rtlsdr, it was great for getting immediate results and picking around
through the spectrum to see what's around. If it provides
functionality for radio astronomy, of course i would love to use it,
but my very initial investigation didn't reveal much for me. No square wheels here, pyrtlsdr, numpy, scipy, and
matplotlib, are
the precisely machined wheels I'm using so far to just dump and
examine data.
One cool thing about GNU Radio is that while you use python to snap
blocks together the data path is compiled code, so it will beat the
performance of pure-python implementations. I don't know if numpy,
scipy, and matplotlib are, but worth keeping in mind.
Anyway, it's another option - if you need one specific simple signal
process then GNU Radio may be overkill, and if it's simple enough
with no bad performance tradeoff then reinventing that wheel can be
fun and educational.
//Peter
1:12 a.m.
On Sun, Oct 21, 2012 at 3:45 PM, Peter Stuge <peter(a)stuge.se> wrote:
One cool thing about GNU Radio is that while you use
python to snap
blocks together the data path is compiled code, so it will beat the
performance of pure-python implementations. I don't know if numpy,
scipy, and matplotlib are, but worth keeping in mind.
Thanks a lot, in this case I'm passing pointer data from one C
function to another, the python interpreter loop adds very little
overhead, at least for the data collection step. For any kind of
visual or interactive setup I'll no doubt be looking at GR.
Anyway, it's another option - if you need one
specific simple signal
process then GNU Radio may be overkill, and if it's simple enough
with no bad performance tradeoff then reinventing that wheel can be
fun and educational.
I love options! And I do confess to enjoy inventing a wheel or two.
No one in their right mind would write another Forth compiler... oh
wait.
-Michel
12:24 a.m.
Scott,
Thanks so much for your detailed reply. As an optical amateur I am
really excited to be immersed in a new world of very interesting
concepts related to radio astronomy. Thanks for patiently explaining
to me how I was getting it wrong. I've read the wikipedia pages on
FFT and some of the history and I think I get, at least abstractly,
the distinction now.
On Sun, Oct 21, 2012 at 1:12 PM, Scott Cutler <scott(a)scottcutler.net> wrote:
To get from the time domain (the raw samples) to the
frequency domain
(waterfall display, etc.), you need an FFT. The FFT operates on some given
buffer size, and outputs a buffer of the same size filled with complex
frequency levels (where the magnitude squared is the signal energy).
I don't think I want a waterfall "frequency domain" display however (I
didn't know that, until I read the references you pointed me toward),
I suspect that what I want is the time domain. From a very simple
perspective, and initially to recreate the Jansky experiment, I just
want the signal strength over a wide bandwidth plotted over time.
Jansky used a simple pen plotter of signal strength (again, according
to wikipedia) to chart the passage of a strong radio signal across his
local zenith. After discovering the period was a sidereal day he
consulted a sky chart and realized it was Sagittarius.
The FFT width determines your frequency resolution,
not the bandwidth. The
bandwidth is determined by the sample rate--in your case, 1.4 MHz.
So you choose your FFT based on your resolution and performance
requirements. In your case, the FFT will return frequencies from -0.7 to
0.7 MHz around the center frequency--no matter what the FFT width. The FFT
results store the positive frequencies from 1..(N/2-1) and the negative ones
from (N/2+1)..(N-1). Sample 0 is 0 Hz and N/2 is 0.7 MHz (you can't really
use this last one since it aliases). The other frequencies scale linearly
between these points (sample N/4 is 0.35 MHz, etc.). For a waterfall
display, this generally means you want to swap the left and right halves of
a buffer.
You can read as many samples as you want from the device. Conceptually, it's
similar to an audio device--if you need more samples, you just wait longer.
You could collect 64M samples if you wanted, and get some nice sub-Hz
resolution, but it would take 45 s to record at your settings.
Ok, I think I'm getting the picture of this, and it's very
enlightening. I think that I just want the signal strength of the
entire bandwidth over time. Which I believe I can get by simply
summing the magnitude squared of all my samples taken, and plot that
over time. Does that sound right to you?
I eventually plan to try and do some basic interferometry, where
multiple observations are taken and combined to synthesize an aperture
capable of resolving point sources. But I'm way far away from doing
that or even really understanding it other than from a high level.
There is an excellent python package called aipy that is developed by
a group of radio astronomers that is used for a large scale 64 antenna
array in southern Australia that I would eventually like to use to
combine multiple sources. The whole sky images they have developed so
far from cheap (compared to multi-meter dishes) crossed dipole arrays
are very impressive. This may be utterly foolish thinking, but I
really hope something like rtlsdr, or something like it terms of
price, can bring large scale interferometry to the masses.
Incidentally, none of this is peculiar to
rtl-sdr--even the fanciest and
most expensive units operate the same way, though they have higher sample
rates and such. In fact, the stuff I said is fundamental to all signal
processing--if you're willing to get your hands dirty with math, you might
want to read the wiki articles on Fourier Transforms and other signal
processing subjects.
Thanks Scott, I'm digging deep and consuming as much information on
the subject as I can. Can you recommend any standard works on signal
processing I should dig into?
-Michel
1:04 a.m.
Happy to help. I had to guess a bit on your level of background
knowledge, but it sounds like I didn't go too over or under your head.
If you just want the energy over the entire sampled bandwidth, you are
correct that you can just average the samples squared. I believe this
is equivalent to a "1 sample FFT", which as it happens is just the
original value. So averaging the squares over time will give you a nice
smoothed energy value. Note that by changing the sample rate, you can
change the window size--the rtl-sdr chip supports from 250 kHz to 3.2
MHz. So that at least gives you coarse-grained control over your window.
That said, you will almost certainly want to use a frequency view once
you start really digging into this. So keep that in mind, even if in
the short term you play with something simpler.
Your goals with interferometry are ambitious, but not absurdly so! The
rtl-sdr units have problems with frequency stability, and will be hard
to synchronize--but these aren't necessarily insurmountable problems.
It would be awesome to see progress here.
Unfortunately, I don't have any good references for texts. I honestly
use Wikipedia for most of my information. Maybe some others here have
recommendations.
-Scott
On 10/21/2012 3:24 PM, Michel Pelletier wrote:
Scott,
Thanks so much for your detailed reply. As an optical amateur I am
really excited to be immersed in a new world of very interesting
concepts related to radio astronomy. Thanks for patiently explaining
to me how I was getting it wrong. I've read the wikipedia pages on
FFT and some of the history and I think I get, at least abstractly,
the distinction now.
On Sun, Oct 21, 2012 at 1:12 PM, Scott Cutler <scott(a)scottcutler.net> wrote:
To get from the time domain (the raw samples) to
the frequency domain
(waterfall display, etc.), you need an FFT. The FFT operates on some given
buffer size, and outputs a buffer of the same size filled with complex
frequency levels (where the magnitude squared is the signal energy).
I don't
think I want a waterfall "frequency domain" display however (I
didn't know that, until I read the references you pointed me toward),
I suspect that what I want is the time domain. From a very simple
perspective, and initially to recreate the Jansky experiment, I just
want the signal strength over a wide bandwidth plotted over time.
Jansky used a simple pen plotter of signal strength (again, according
to wikipedia) to chart the passage of a strong radio signal across his
local zenith. After discovering the period was a sidereal day he
consulted a sky chart and realized it was Sagittarius.
The FFT width determines your frequency
resolution, not the bandwidth. The
bandwidth is determined by the sample rate--in your case, 1.4 MHz.
So you choose your FFT based on your resolution and performance
requirements. In your case, the FFT will return frequencies from -0.7 to
0.7 MHz around the center frequency--no matter what the FFT width. The FFT
results store the positive frequencies from 1..(N/2-1) and the negative ones
from (N/2+1)..(N-1). Sample 0 is 0 Hz and N/2 is 0.7 MHz (you can't really
use this last one since it aliases). The other frequencies scale linearly
between these points (sample N/4 is 0.35 MHz, etc.). For a waterfall
display, this generally means you want to swap the left and right halves of
a buffer.
You can read as many samples as you want from the device. Conceptually, it's
similar to an audio device--if you need more samples, you just wait longer.
You could collect 64M samples if you wanted, and get some nice sub-Hz
resolution, but it would take 45 s to record at your settings.
Ok, I think I'm
getting the picture of this, and it's very
enlightening. I think that I just want the signal strength of the
entire bandwidth over time. Which I believe I can get by simply
summing the magnitude squared of all my samples taken, and plot that
over time. Does that sound right to you?
I eventually plan to try and do some basic interferometry, where
multiple observations are taken and combined to synthesize an aperture
capable of resolving point sources. But I'm way far away from doing
that or even really understanding it other than from a high level.
There is an excellent python package called aipy that is developed by
a group of radio astronomers that is used for a large scale 64 antenna
array in southern Australia that I would eventually like to use to
combine multiple sources. The whole sky images they have developed so
far from cheap (compared to multi-meter dishes) crossed dipole arrays
are very impressive. This may be utterly foolish thinking, but I
really hope something like rtlsdr, or something like it terms of
price, can bring large scale interferometry to the masses.
Incidentally, none of this is peculiar to
rtl-sdr--even the fanciest and
most expensive units operate the same way, though they have higher sample
rates and such. In fact, the stuff I said is fundamental to all signal
processing--if you're willing to get your hands dirty with math, you might
want to read the wiki articles on Fourier Transforms and other signal
processing subjects.
Thanks Scott, I'm digging deep and consuming as much
information on
the subject as I can. Can you recommend any standard works on signal
processing I should dig into?
-Michel 
2:50 a.m.
Hello
May I suggested a few things not related to the "Programming" issues but
related to the Radio Astronomy subject? Just like retail, about "Location,
Location, Location," Radio Astronomy's is about the "Antenna, Antenna,
Antenna." One thing the TV Dongle offers for Radio Astronomers is the ease
of placing the receiver (Dongle) on the Antenna. The USB must be extended
from the Computer to the Antenna, instead of bringing the Signal from the
Antenna to the Dongle. The advantage is lower noise and higher gain (without
noise). There are many references on the Internet for extending USB, some
for purchase, some DIY.
Extending the USB is not limited to Radio Astronomy...
-----Original Message-----
From: osmocom-sdr-bounces(a)lists.osmocom.org
[mailto:osmocom-sdr-bounces@lists.osmocom.org] On Behalf Of Michel Pelletier
Sent: Sunday, October 21, 2012 12:25 PM
To: osmocom-sdr(a)lists.osmocom.org
Subject: Beginner question about rtlsdr
Hello everyone, I hope this is an appropriate forum for a beginner question
about using an E4000 dongle.
I'm an amateur astronomer, and lately I've been wanting to get into amateur
radio astronomy. The rtlsdr seems like a really cheap way to get involved.
It can tune many interesting frequencies, in particular channel 37 around
608-614 Mhz.
I am a Python programmer by trade so I am using roger-'s amazing pyrtlsdr
library which is great, I can read samples from the device and they get
returned as numpy arrays. The scipy.signal package allows me to correctly
decimate the signal and I am working on a simple graphing program to graph
signal levels in realtime, by hour, by day, and by week. I hope to
basically reproduce the Jansky experiment that started the entire science of
radio astronomy:
http://en.wikipedia.org/wiki/Karl_Guthe_Jansky
I have a question though about how to use the dongle that I can't quite
figure out. roger-'s demo_waterfall program, for example, sets the default
sample_rate to 1.4e6, but then on each scan only calls read_samples(2**16).
The demo displays the entire megahertz of bandwidth, so I'm a bit confused
as to how the 64K samples map onto the 1M samples of the device. It doesn't
seem to make sense taht the device only returns the first 64K samples. Can
anyone clue in a total beginner on the sample rate and reading samples from
the device correlate?
Thank you!
-Michel
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2741 / Virus Database: 2614/5846 - Release Date: 10/21/12
3:22 a.m.
On Sun, Oct 21, 2012 at 5:50 PM, Jay Salsburg <jsalsburg(a)bellsouth.net> wrote:
Hello
May I suggested a few things not related to the "Programming" issues but
related to the Radio Astronomy subject? Just like retail, about "Location,
Location, Location," Radio Astronomy's is about the "Antenna, Antenna,
Antenna." One thing the TV Dongle offers for Radio Astronomers is the ease
of placing the receiver (Dongle) on the Antenna. The USB must be extended
from the Computer to the Antenna, instead of bringing the Signal from the
Antenna to the Dongle. The advantage is lower noise and higher gain (without
noise). There are many references on the Internet for extending USB, some
for purchase, some DIY.
Thanks Jay, I'm personally fascinated by the scientific aspects of the
subject so I do appreciate your comment. I'm not sure if you're
referring to the link I posted in this thread to a picture of my
telescope, but I did as you suggested an embedded the dongle directly
in the cantenna. My extension is a simple usb cable as my computer is
just across the wall, although for my next antenna on the other side
of my property, I intend to use a small dlink access point device
flashed with openwrt and using usb over IP and power over ethernet to
extend the other data source to my computer. This will give me a
single interferometric baseline to begin using packages like aipy. I
have the parts, I'm still piecing together the receiver. I live in
Western Oregon so weatherproofing is key. :)
FWIW the EOR array uses simple, omnidirectional crossed dipoles and Python:
http://eor.berkeley.edu/
That's a pretty gorgeous picture of Centaurus A for some simple
dipoles! Here is an excellent presentation on the python technology
behind it:
http://setiathome.berkeley.edu/~aparsons/papers/2008-08-10_LFSW_AIPY_Presen…
there are some pretty pictures at the end. All of the software parts
of the interferometry are basically done, what is needed is to vet the
possibility that something like an rtlsdr dongle and a simple antenna,
arrayed across an area, can produce data of sufficient quality to feed
into a package like aipy. As roger-'s ecellent pyrtlsdr can already
capture dongle complex data directly into numpy arrays, it seems like
all the pieces are laying around, simply needing to be put together,
and I intend to try it.
As an update, thanks to Scott's great help I am currently dumping data
at 1420 Mhz center frequency into numpy arrays and averaging their
squares. Here's the simple "core" of my loop:
while True:
yield numpy.average(numpy.absolute(radio.read_samples(2**20)))
I'm accumulating one average per secondish and dumping them into a
data file that I am plotting on a simple graph. Cassiopeia reaches
maximum at my local position around midnight, and the graph is
currently trending upward. I'm really hoping that by morning I'll
have a nice curve that peaks at midnight and hopefully not a bunch of
random squiggles. :)
-Michel
4 a.m.
Hello Michel
OK, I see you are way ahead of me. However, I have some experience using
these TV Dongles, they have pitfalls. Number one is its frequency Accuracy,
out-of-the-box; needs calibration. Another is that its frequency accuracy
drifts over time and from the Ambient temperature necessitating periodic
offset calibration. While it is possible to create a compensation cure for
frequency drift vs. temperature, it may be far more prudent to place the
Dongle in a temperature controlled enclosure (50C Heater) keeping it above
the ambient to help prevent drift, in your case, the all too important
Temperature related Phase Shift. I have thought of disconnecting the
Dongle's Crystal and placing it in a Crystal Oven, but I have not tried
that. The Entire Dongle is small enough to place it in a temperature
controlled enclosure which also keeps it dry.
-----Original Message-----
From: osmocom-sdr-bounces(a)lists.osmocom.org
[mailto:osmocom-sdr-bounces@lists.osmocom.org] On Behalf Of Michel Pelletier
Sent: Sunday, October 21, 2012 8:22 PM
To: Jay Salsburg
Cc: osmocom-sdr(a)lists.osmocom.org
Subject: Re: Beginner question about rtlsdr
On Sun, Oct 21, 2012 at 5:50 PM, Jay Salsburg <jsalsburg(a)bellsouth.net>
wrote:
Hello
May I suggested a few things not related to the "Programming" issues
but related to the Radio Astronomy subject? Just like retail, about
"Location, Location, Location," Radio Astronomy's is about the
"Antenna, Antenna, Antenna." One thing the TV Dongle offers for Radio
Astronomers is the ease of placing the receiver (Dongle) on the
Antenna. The USB must be extended from the Computer to the Antenna,
instead of bringing the Signal from the Antenna to the Dongle. The
advantage is lower noise and higher gain (without noise). There are
many references on the Internet for extending USB, some for purchase, some
DIY.
Thanks Jay, I'm personally fascinated by the scientific aspects of the
subject so I do appreciate your comment. I'm not sure if you're referring
to the link I posted in this thread to a picture of my telescope, but I did
as you suggested an embedded the dongle directly in the cantenna. My
extension is a simple usb cable as my computer is just across the wall,
although for my next antenna on the other side of my property, I intend to
use a small dlink access point device flashed with openwrt and using usb
over IP and power over ethernet to extend the other data source to my
computer. This will give me a single interferometric baseline to begin
using packages like aipy. I have the parts, I'm still piecing together the
receiver. I live in Western Oregon so weatherproofing is key. :)
FWIW the EOR array uses simple, omnidirectional crossed dipoles and Python:
http://eor.berkeley.edu/
That's a pretty gorgeous picture of Centaurus A for some simple dipoles!
Here is an excellent presentation on the python technology behind it:
http://setiathome.berkeley.edu/~aparsons/papers/2008-08-10_LFSW_AIPY_Present
ation.pdf
there are some pretty pictures at the end. All of the software parts of the
interferometry are basically done, what is needed is to vet the possibility
that something like an rtlsdr dongle and a simple antenna, arrayed across an
area, can produce data of sufficient quality to feed into a package like
aipy. As roger-'s ecellent pyrtlsdr can already capture dongle complex data
directly into numpy arrays, it seems like all the pieces are laying around,
simply needing to be put together, and I intend to try it.
As an update, thanks to Scott's great help I am currently dumping data at
1420 Mhz center frequency into numpy arrays and averaging their squares.
Here's the simple "core" of my loop:
while True:
yield numpy.average(numpy.absolute(radio.read_samples(2**20)))
I'm accumulating one average per secondish and dumping them into a data file
that I am plotting on a simple graph. Cassiopeia reaches maximum at my
local position around midnight, and the graph is currently trending upward.
I'm really hoping that by morning I'll have a nice curve that peaks at
midnight and hopefully not a bunch of random squiggles. :)
-Michel
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2741 / Virus Database: 2614/5846 - Release Date: 10/21/12
4:13 a.m.
On Sun, Oct 21, 2012 at 7:00 PM, Jay Salsburg <jsalsburg(a)bellsouth.net> wrote:
Hello Michel
OK, I see you are way ahead of me. However, I have some experience using
these TV Dongles, they have pitfalls. Number one is its frequency Accuracy,
out-of-the-box; needs calibration. Another is that its frequency accuracy
drifts over time and from the Ambient temperature necessitating periodic
offset calibration. While it is possible to create a compensation cure for
frequency drift vs. temperature, it may be far more prudent to place the
Dongle in a temperature controlled enclosure (50C Heater) keeping it above
the ambient to help prevent drift, in your case, the all too important
Temperature related Phase Shift. I have thought of disconnecting the
Dongle's Crystal and placing it in a Crystal Oven, but I have not tried
that. The Entire Dongle is small enough to place it in a temperature
controlled enclosure which also keeps it dry.
Interesting! I was actually considering going the other way, and
putting the radio in a Peltier cooled enclosure, but that was based
only on my experience with cooling digital cameras for
astrophotography purposes to lower noise. I just instinctively
figured that lower temperatures would equate to lower noise in a radio
receiver as well, but I have no experience with the kind of accuracy
drift or phase shift you're talking about. Well, this is definitely
something I will keep in mind when I try to capture my first baseline.
:)
-Michel
5:53 a.m.
Hello Michel
The fact about Cooling Electronics comes down to how much benefit is
obtained by lowering the chip temperature. While lowering the temperature of
CCDs contributes to lowering the Chip's Dark Current and single pixel
artifacts, the benefits to reducing noise of Low Noise Radio Frequency
Amplifiers is not very effective, at least from what a Peltier cooler would
provide. Reducing noise in RF Amps will only be useful if you can reduce the
"System Noise Temperature" (in Kelvin) by a factor of 4, resulting in
doubling the effective communication range (number of Light Years).
Examples of Cooling a GaAs PHEMT preamp with a noise temp of 50K at Room
Ambient, with Dry Ice might at the most, reduce its noise by 35%; only a
small improvement. However, the Antenna noise, plus Sky noise, plus Earth
noise is the source of much of the unwanted noise, not the Amplifier hence
the advantage of Space-based Receivers. So cooling an LNA with Dry Ice plus
the unavoidable environmental noise provides only an 8% improvement. Cooling
with a Peltier device or Dry Ice, while providing some benefit, is not worth
the trouble. Cryogenic cooling provides a more desired effect. Placing a
Cryogenic LNA (Liquid Helium) in front of the Tuner will definitely increase
your Light Years, however, this technique is logistically complex and
expensive, but possible.
The obvious direction is toward an Array. This provides a solution to reduce
noise through Signal Processing, with the down side of needing many more
receivers and physical space for the Array.
-----Original Message-----
From: osmocom-sdr-bounces(a)lists.osmocom.org
[mailto:osmocom-sdr-bounces@lists.osmocom.org] On Behalf Of Michel Pelletier
Sent: Sunday, October 21, 2012 9:13 PM
To: Jay Salsburg
Cc: osmocom-sdr(a)lists.osmocom.org
Subject: Re: Beginner question about rtlsdr
On Sun, Oct 21, 2012 at 7:00 PM, Jay Salsburg <jsalsburg(a)bellsouth.net>
wrote:
Hello Michel
OK, I see you are way ahead of me. However, I have some experience
using these TV Dongles, they have pitfalls. Number one is its
frequency Accuracy, out-of-the-box; needs calibration. Another is that
its frequency accuracy drifts over time and from the Ambient
temperature necessitating periodic offset calibration. While it is
possible to create a compensation cure for frequency drift vs.
temperature, it may be far more prudent to place the Dongle in a
temperature controlled enclosure (50C Heater) keeping it above the
ambient to help prevent drift, in your case, the all too important
Temperature related Phase Shift. I have thought of disconnecting the
Dongle's Crystal and placing it in a Crystal Oven, but I have not
tried that. The Entire Dongle is small enough to place it in a temperature
controlled enclosure which also keeps it dry.
Interesting! I was actually considering going the other way, and putting
the radio in a Peltier cooled enclosure, but that was based only on my
experience with cooling digital cameras for astrophotography purposes to
lower noise. I just instinctively figured that lower temperatures would
equate to lower noise in a radio receiver as well, but I have no experience
with the kind of accuracy drift or phase shift you're talking about. Well,
this is definitely something I will keep in mind when I try to capture my
first baseline.
:)
-Michel
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2741 / Virus Database: 2614/5846 - Release Date: 10/21/12
4209
days inactive
4210
days old
12 comments
4 participants
participants (4)
-
Jay Salsburg -
Michel Pelletier -
Peter Stuge -
Scott Cutler