>
>Here are our comments on the "Multiplexing system revision 2
>(8/14/2003 - Simon Dicker) " document:
>
.....
>
>Another major point: (Page 6) starting the clock card and having to
>look at an LED to detect if it started ok will be a serious
>operational problem for us. Can we replace that LED with some sort of
>voltage readout that we send back and can at least monitor in the
>control room? We should aggressively try to identify any other such
>items.

version 3 of the firmware (which will be completed by about the end of
Feb) will have a diagnostic timetream mode with an "aliveness block"
of data that is a superset of the information conveyed by the blinking
yellow light.

>
>Some more detailed questions:
>
>Page 4: Dac cards are 16 bit but only 14 bits are sent to the address
>card?

the DAC in each DFB is 14 bits; the DAC in the *tower* (which is to set the
detector and preamp voltages) is 16 bits.

>
>Do we know the
>number the clock divider should be set at?

greater than or equal to 32

>
>What is the protocol for the serial ports? Are they all the same?
>

Rs-422 

>Is the feed through card programmable?

No.

>
>What is the data rate of the fiber card?

<=1.5 MHz/channel

>
>The signalling mechanism for the PCI data stream should be discussed
>in the hardware/software interface document, not just the Python
>script documentation.
>
>Concerning the data on the PCI bus, does the data with the Frame bit
>set contain the data for pixel 1 (row 1, col 1)? Does the next packet
>contain row 1, col 2? etc. Am I understanding the context for this PCI
>"Frame" bit? Is the Frame bit on the interface card the same Frame bit
>in the PCI data stream data? If not what is it? (see previous
>question) 

I think: frame bit corresponds to row 1 of any column; next 32-bit word
is row 2 (frame bit is zero) ... all the way up to NSTEP rows.

>
>How do you differentiate data from the interface card and the fiber
>cards on the PCI bus - i.e. they both come through the PCI data stream
>card to the PCI bus?

currently you just have to know the order of the channels (DFB N vs DFB Q vs
interface card), and count the frame bits.

>
>What do we do with the data coming from the interface card?  

several possibilities, to be elaborated later. to zeroth order,
average, or just write to disk, though there are fancier things you
might do.

>
>We'd like to find out what the required magic numbers
>(like"0x20000000" in the setup scripts) mean.
>

We don't know.