Some noodling

I want to write a dicke-switched type system for my existing
un-calibrated radiometry application (usrp_ra_receiver.py).

Controlling the switching function is no problem. But processing the
samples as they come in has me a bit stumped,
unless I write a custom-processing block.

So, the input switches at some rate (a few Hz), which means that the
samples sometimes represent the “sky”, and
sometimes represent the calibrator. I can tag the samples so that
samples that come in during the time when
the input is “sky” will be positive, and those that come in during
“calibration” will be negative. But after that, I’m
not sure what to do. But perhaps something clever will occur to me
or someone on the list.

Also, I need a way of triggering switching at rates faster than 1Hz.
One I idea I had was to create a side-chain
off of the USRP which uses keep_one_in_n() to reduce the sample rate,
and have this terminate in a Python
function (is that possible yet, and if so, how?) that ignores the
data, but simply uses that as a timing mechanism
to drive the switching function.

Cheers
Marcus

On Tue, Aug 19, 2008 at 2:00 PM, Marcus L. [email protected] wrote:

Controlling the switching function is no problem. But processing the
samples as they come in has me a bit stumped,
unless I write a custom-processing block.

This is your best bet.

So, the input switches at some rate (a few Hz), which means that the samples
sometimes represent the “sky”, and
sometimes represent the calibrator. I can tag the samples so that samples
that come in during the time when
the input is “sky” will be positive, and those that come in during
“calibration” will be negative.

It’s pretty straightforward to write a new block that only passes
positive samples (or negative, depending on a constructor parameter.)
Then you’d attach two of these to the output of your usrp block and
you’ll have the two streams you need.


Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com/

Turns out I didn’t need to write a new block, but rather through clever
abuse of
keep_one_in_n(), I was able to implement a cheap “mute and pause”.
Which means that
I can control the two different streams, and control what gets to the
final integrator.

While we’re in “switched” mode, I simply pause the main chain, and only
the side-chain
gets data, and visa versa. The side-chain data are used to drive a
short-term estimate
of the reference signal power, which gets subtracted on the main
chain.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs