discuss-gnuradio
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] comparing SDR upconverters, thermal stability

From: Marcus Müller
Subject: Re: [Discuss-gnuradio] comparing SDR upconverters, thermal stability
Date: Wed, 30 Mar 2016 20:04:18 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
Hi Daniel,

shortly answering your questions:
On 30.03.2016 17:50, Daniel Pocock wrote:
OK, so keeping the mixer cooled will help reduce loss but has nothing to do with frequency stability?
yes; well, the point is that the mixer is really just a multiplier, built from a nonlinear device, and we use the fact that this nonlinearity introduces a term that contains the product of the two input signals, and usually filter out the unwanted original signals, and wrong intermodulations afterward.

Temperature might change the coefficients of whatever model you use to describe the nonlinear element;
for example, the current I(U) through a Diode is well-modeled with an exponential function

$I(U) = I_0 e^{\alpha U}$,

and you can represent $e^x$ as power series

$e^x=\sum_{n = 0}^{\infty} \frac{x^n}{n!} = 1 + x + \frac{x^2}{2!} + \dots$ ,

and abort that series after the second part. You'll notice the quadratic component in there; and if $U = \frac x\alpha$ happens to be the sum of two cosines, so

$x=\frac{\cos(f_1 t)+ \cos(f_2 t)}{\alpha}$ (imagine $f_1$ is the frequency of your soon to be mixed up signal, and $f_2$ your oscillator's frequency)

by the binomials, you'd have $x^2=\frac{\cos(f_1 t)^2 + 2\cos(f_1 t)\cos(f_2 t)+\cos(f_2 t)^2}{\alpha^2}$ with the cosine product in the middle; now $\frac{2\cos(f_1 t)\cos(f_2 t)}{\alpha^2}=\frac{2}{\alpha^2}\cos(f_1 t)\cos(f_2 t)$ is only sensitive to temperature in $\alpha$, not in either $f_i$, so temperature will change the amplitude of your modulated output, but not the frequency (lest temperature changes $\alpha$ so fast that you'd notice the amplitude change as some frequency component; but we can safely assume it won't).

For completeness: If you use Euler's formula to break down cosine, you'll find that

$\cos(f_1t)\cdot\cos(f_2t)=\frac14\left[\cos\left((f_1t)-(f_2t)\right)+\cos\left((f_1t)+(f_2t)\right)\right]= \frac14\left[\cos\left((f_1-f_2)t\right)+\cos\left((f_1+f_2)t\right)\right]$

which contains the sum of the two frequencies, $f_1+f_2$, which is what we wanted for upconversion!


Now, the oscillator, on the other hand, does change its frequency
That is definitely quite a relevant point, where I live at present the indoor temperature can often be a lot lower than indoor
Hm, the point of cozyness was more to avoid temperature changes; basically, that's why OCXOs are used: you can relatively well control the temperature of an oscillator inside a small oven; first of all, building a control loop to keep that temperature constant is relatively easy, because a big-enough oven won't cool down or heat up too quick, and secondly, physics is cooperating here by the laws of thermodynamics. 


That brings one down to the question whether you have the chance to use
the same oscillator for both your SDR device and the upconversion; ...
For people using low-cost RTL-SDR dongles that might be more than they
can expect
Well, there are people who use one RTL-SDR's clock for multiple RTL-SDRs, to keep them frequency aligned, so that's probably possible if you can solder some kind of amplifier (a FET will possibly do, but watch out for intermodulation products ;) ) to original oscillator.

For the proper SDR boards (e.g. USRP, BladeRF, HackRF) is this feasible?
USRPs: well, given you have either a USRP that integrates its RF frontend (B2xx, E3xx), or a daughterboard that can transmit: you could directly generate a tone for mixing with at arbitrary frequencies within the frontend's frequency range, and that tone would be derived from the same frequency reference as the oscillator frequency to convert down in the receiver.
Some USRPs (mainly, the X3x0) also export their 10MHz reference (but on those, you could also just use a BasicRX daughterboard that doesn't have any mixer and just receive from e.g. 50MHz in baseband).

BladeRF: same thing; if you can transmit, you can probably also generate a tone. I haven't worked with that; if it's not full-duplex capable, you might have to make some firmware/software modifications to be able to continously have such a TX tone.

HackRF: definitely not Full-Duplex.

Cheers,
Marcus
reply via email to
[Prev in Thread] Current Thread [Next in Thread]