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
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
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
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
Michel Pelletier wrote:
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.
I think it may provide the primitive blocks that you need, even if they weren't specifically created for radio astronomy.
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
On Sun, Oct 21, 2012 at 3:45 PM, Peter Stuge peter@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
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@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
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@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
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@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@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
On Sun, Oct 21, 2012 at 5:50 PM, Jay Salsburg jsalsburg@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:
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...
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
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@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@lists.osmocom.org Subject: Re: Beginner question about rtlsdr
On Sun, Oct 21, 2012 at 5:50 PM, Jay Salsburg jsalsburg@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:
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
On Sun, Oct 21, 2012 at 7:00 PM, Jay Salsburg jsalsburg@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
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@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@lists.osmocom.org Subject: Re: Beginner question about rtlsdr
On Sun, Oct 21, 2012 at 7:00 PM, Jay Salsburg jsalsburg@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
-
Jay Salsburg -
Michel Pelletier -
Peter Stuge -
Scott Cutler