>>
> 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
Matt Ettus wrote:
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 pro
Matt Ettus wrote:
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 prob
Marcus Leech 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
Marcus Leech wrote:
>
> 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"
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 str
