[Gb-ccb] Caltech Backend Telecon Monday 07 July 4pm EDT

[Richard Lacasse]

Brian et al.,

A few comments:


> =======================================================
> 
> 
> Some Specific Questions Caltech has Raised-- to be discussed in
> upcoming (Monday 07jul 4pm) videocon.

> 
>   -The choice of signal cabling between the receiver and backend boxes.
>    Some options include:
> 
>       Multi-pair twisted-pair or parallel-pair cables with both
>       individual and overall shielding. For example, Amphenol
>       "Skewclear" parallel-pair cable boasts -70db near-end-crosstalk
>       between neighboring pairs.
> 
>       Multiple separate coaxial cables with SMA connectors at each
>       end.
> 
>       Multiple separate twinaxial differential cables.
> 
>   -Assuming that twisted-pair or parallel-pair cables are chosen, would
>    it be best to use a single 16-pair cable for all of the signals
>    coming from the receiver, or assign separate 4-pair cables to each
>    of the bands?
> 
>   -Alternatively, if separate coaxial or twinaxial cables are chosen,
>    how can they be bundled in such a way that their proximity doesn't
>    compromise the crosstalk isolation?
> 
>   -Should the shields of the signal cables be connected to the cases of
>    both the backend and receiver boxes, or just to the case of the
>    receiver box?  Coaxial cable shields almost certainly shouldn't be
>    connected at both ends, but those of twisted pair cables potentially
>    could be.
> 
>   -If the shields aren't to be connected to the backend case, what would
>    be the best method of insulating the connectors from the case
>    without compromising the RFI shielding of the case?

I have not see the suggestion I made last week considered.  Maybe it was 
unclear.  I suggested using a few cables (2 or 4) that had
    - twisted pairs,
    - beldfoil shields over each twisted pair
    - an overall braided shield.
    - the use of spectrum control or similar filtered connectors and
      die cast metal backshells (AMP 745171 or similar).
For RFI shielding, the braided shield is connected to the connector backshell at 
both ends.  The drain wires from the twisted pairs shields can be connected at 
one end or both, depending upon what works best.  If they are not connected, 
heat shrinkable tubing should be used to prevent the individual shields from 
contacting each other.  We know this works well from an RFI point of view, but 
at least I have not tried it for analog data acquisition such as this.

> 
>   -Similarly, should the shields of the digital control cables be
>    connected to both cases, or just to the case of the backend? Since
>    these will be twisted pair cables carrying differential digital
>    signals, the question here isn't whether ground loops might affect
>    the control signals themselves, but rather whether digital transients
>    in the backend might get coupled into the backend case, and from 
>    there into the receiver case via the cable shields.

Seems like a lot of this worry could be alleviated by using opto-isolators. 
That way there is no ground return that has to flow through the system to get 
back to the driver - all the current just flows in and out of an LED. (Except 
for a small amount that might couple into the shield.  This can be minimized by 
filtering the signal going into the twisted pair if necessary.)


>   -Are there any concerns regarding my new scheme of using a low-pass
>    filter and a 10MHz ADC, instead of an analog integrator and a 40KHz
>    ADC?

Sounds perfectly reasonable, not to mention cheaper and simpler.  The concern 
mentioned about the time domain response of the filter may be addressed in a few 
ways.

   - measure a similar filter.  We've got boxes full of old filters here and 
there may be quite a few laying around CIT.

   - Simulate.  Simulation programs are getting very good - especially for 
passive linear devices like filters.

   - Breadboard the system.  I think it's important to prototype the system (or 
at least the more challenging parts of it) for many reasons, not only the filter 
time response.  There's always a surprise!

Also, with respect to the problem that the detector output is always positive, 
and thus requires extra range of the A/D, it is certainly possible to offet the 
output so that the mean is near-zero.

A question:
Noise is a large concern in this design.  Is it not true though that the real, 
main concern is only about noise that will not integrate out?  It seems as if a 
little random noise might even be a good thing.  What if the detector output 
were nearly constant, to less than an LSB of the ADC?  Without random noise the 
averaged detected output would be less accurate than the ADC output * 2**n. 
With the random noise, fluctuation in the signal smaller than the LSB would be 
detectable.

Rich