Hi Joanne and Tobias, Have a look at Figure 3 here: http://www.sm5bsz.com/linuxdsp/hware/mirisdr/thermal.htm
A huge thermal mass makes it easy to keep temperature changes slow:-) 73 Leif "[email protected]" <[email protected]> wrote: > It should work that way, Tobias. I was simply noting that the WFM broadcasts > may > be considerably far off frequency compared to NFM signals. And as an aside > three digits after the decimal point surely would be nice. The synthesizer, > at > least in the E4000, can handle that level of precision. But, of course, the > dongles can't. But they can hold to one digit after the DP in quiet air over > modest periods of time. The three digits is simply "because it is there." > > (I'm tempted to take a resistor for a heating element, a thermistor, a wad of > hot glue, and a small handful of other components to make a pseudo-oven for a > dongle and see if I really can get it reasonably stable that way without > breaking the USB power budget. I think I have about 125 mA to play with. > Sadly > the crystals typically used seem to be floor sweepings OR crystals calibrated > for serial resonance used in a parallel resonance oscillator circuit.) > > {^_^} Joanne/W6MKU > > (As an aside I designed some of the RF hardware and software used on phase II > GPS birds and their pre-launch testing.) > > On 2014-07-31 03:05, Tobias wrote: > > On 2014-07-31 11:05, [email protected] wrote: > >> Note that at least in the US the frequency accuracy of broadcast FM > >> stations > >> is no better than the transmission mode needs. NFM weather broadcasts are > >> about as good as it gets for most things on VHF. Cellphone signals may well > >> provide the best calibration sources. The towers have ppb oscillators in > >> profusion and one presumes they use them. > > > > OK. Good to know. I tested a few stations here (in Stockholm Sweden) and > > they > > diff by like 2ppm so it's within acceptable range for many applications. As > > compared to GSM cell frequencies, the broadcast frequencies are well known > > which > > the GSM frequencies probably are not for the average user. > > > > I first tried to use the kalibrate-rtl utility that use GSM frequencies but > > the > > DVB-T dongle was so off in frequency so that the scanner found the wrong > > channels and I got completely wrong frequency correction values. One way to > > do > > it is to first do a course calibration using rtl_fm on a broadcast station > > and > > then use kalibrate-rtl with the course frequency correction ("-e" switch). > > > > The calibration should work on NFM as well. It's just that if you have many > > closely spaced transmissions in a band there is no easy way to know which is > > which and you need to use a small bandwidth to filter out one station. If > > the > > frequency error is larger than the bandwidth you're out of luck. By using > > broadcast stations, which are spaced far apart, the frequency error can be > > quite > > large without causing any ambiguity. I guess the same method could be used > > here > > as suggested above: course calibration using broadcast FM and then fine > > tune it > > with a NBFM weather station. Let me know how that work if you try it. > > > > Regards, > > Tobias > > > > > >> > >> {^_^} Joanne/W6MKU > >> > >> On 2014-07-31 01:23, Tobias wrote: > >>> Hi! > >>> > >>> I have just started using rtl-sdr in my application, SvxLink: > >>> http://svxlink.org/. Thanks for your work on the RTL code. It opens up > >>> the world > >>> of wideband receivers to everyone. The SvxLink RTL code is in the > >>> rtl-branch on > >>> GitHub right now if anyone is interested: > >>> > >>> https://github.com/sm0svx/svxlink/tree/rtl > >>> > >>> I was missing some simple utility to calibrate the frequency error for a > >>> dongle. > >>> The simplest way I came up with was to modify the rtl_fm utility since it > >>> is > >>> very easy to find out the frequency error of an FM signal. To get a > >>> measure of > >>> the frequency error, all that have to be done in the FM demodulator is: > >>> > >>> samp_rate * angle / (2*PI) > >>> > >>> The angle is already compensated with PI in the current demodulator so I > >>> only > >>> had to do the rest in my added calibration code. > >>> > >>> I first filed this patch as a pull request on GitHub > >>> (https://github.com/steve-m/librtlsdr/pull/9) but then saw that > >>> contributions > >>> should be mailed to this mailing list. > >>> > >>> The rtl_fm utility may now be used to calibrate the frequency error of a > >>> DVB-T > >>> dongle using the "-c" command line switch: > >>> > >>> | [-c] Do frequency error calibration > >>> Frequency error calibration will only work for FM. > >>> Use a higher sample rate, like -s170k, to handle > >>> large frequency errors. A strong and noise free > >>> signal is needed for good results. For example, use a > >>> broadcast FM station for calibration. Let the > >>> calibration run for some minutes until the values > >>> have stabilized. Rerun with -p option using the > >>> suggested ppm_error. Try this on a couple of stations. > >>> Repeat until the error is stable at about zero. > >>> Example: rtl_fm -f99.3M -s170k -r48k -c - | aplay -r48k -fS16_LE - > >>> | > >>> > >>> Regards, > >>> Tobias > > > > >
