Implementing Dicke switching

I’m starting to think about adding Dicke-switching support into my
gr-radio-astronomy continuum
application.

I (once again) need to understand how to use the auxillary TTL I/O bits
on the DBS_RX daughtercard, for
driving the hardware switching apparatus.

But there’s another issue that I’m struggling with (a little, anyway).
In Dicke switching, the front-end is
switched alternately between the “sky” and a cold load or calibration
source, with the actual detected power
being the difference between the “sky” and calibration source.
Ideally, you do this many times per second.
What this does is to remove gain stability from the equation, since any
system gain change that affects
the “sky” measurements, will also affect the calibration measurements.
When successful, this technique
removes system-induced gain variations by a significant amount–an
order of magnitude is not
uncommon.

In order to do this, I need to know which samples correspond to “sky”
and which samples correspond to
“calibration source” as I’m processing them. One thought I had was to
synthesize a pair of identical channels,
one called “Sky” and the other called “Calibration”, and have the code
that flips the hardware switch set
a multiplier on each of these channels to either 0 or 1. That is:

when the hardware is switched to "Sky":

skychan *= 1.0
calibchan *= 0.0

when the hardware is switched to "Calib":

skychan *= 0.0
calibchan *= 1.0

With the two channels being low-pass filtered separately, then one is
subtracted from the other to produce a
synchronously-detected result.

How can I make sure that the chanels are properly synchronized with the
hardware state of the switch?


Marcus L. Mail: Dept 1A12, M/S: 04352P16
Security Standards Advisor Phone: (ESN) 393-9145 +1 613 763 9145
Strategic Standards
Nortel Networks [email protected]

Marcus L. wrote:

synchronously-detected result.

How can I make sure that the chanels are properly synchronized with
the hardware state of the switch?

Once inband signalling is done, this shouldn’t be hard at all. In the
mean time, here is what I would suggest –

Dicke switches have typically used rates in the low hundreds of Hz, with
a 50% duty cycle. My understanding is that is not necessary, and was
only done to make things easier with the electronics of the time. I
think I would switch at a much lower rate, 1 Hz or less, and probably
use a calibration duty cycle on the order of 10%. This way you can
easily throw out some samples on either side of the switch time without
having to worry too much.

Matt

Marcus L. wrote:

How can I make sure that the chanels are properly synchronized with the
hardware state of the switch?

If you used a double-pole relay (or solid-state equivalent) you could
use the extra pole to signal back to an I/O pin what state the switch
was in. That would allow you to verify the state regardless of switch
delays.

Johh

Matt E. wrote:

Actually, the few-hundred-hz rate was chosen to improve the “fidelity”
of the
calculation–the more-often you look at the calibrator, the more
precisely you
can track gain fluctuations in the system gain. This assumes that the
calibration
source fluctuates to a much smaller degree than the total system gain.

I’m thinking of switching at a lower rate also, mostly because doing so
is
easy with existing infrastructure in the applications–there’s already
a
1Hz timeout used for various housekeeping activities.


Marcus L. Mail: Dept 1A12, M/S: 04352P16
Security Standards Advisor Phone: (ESN) 393-9145 +1 613 763 9145
Strategic Standards
Nortel Networks [email protected]

Matt E. wrote:

Matt

So, there’s the other half of my question, about doing the TTL control
thing on a DBS_RX.
I know you’ve answered this in the past, but I can’t find it in the
archives.


Marcus L. Mail: Dept 1A12, M/S: 04352P16
Security Standards Advisor Phone: (ESN) 393-9145 +1 613 763 9145
Strategic Standards
Nortel Networks [email protected]

So, there’s the other half of my question, about doing the TTL control
thing on a DBS_RX.
I know you’ve answered this in the past, but I can’t find it in the
archives.

The code in gr-usrp/src/db_*.py has examples of how to control the IO
pins.

Matt