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
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
