SUSI Path Length Compensator

OK, strictly this is not PAVO. But this is needed for SUSI. We need an upgrade because:
  1. There is too much latency in the servo loop. Currently, there is max 150ms for the comms from PAVO to OPCON (just due to being scared about sending too many messages), ~250ms average due to the memory in PAVO (assuming a 0.5s integration time, which is about right at 0.1nm*(t/t0)^(5/6) wanting less than 7 microns or so fringe motion), and typically 80+80+40millisec =200ms for the delay from OPCON to the PLC AV68K. This last delay isn't so great and it would be great to remove it. NB to move less than 100nm in 3.5ms, we could move up to 2.286 microns in 80ms - this speed limit means that there will always be some delay in cart movement.
  2. The tracking speed seriously limits sky coverage. This could be fixed with a servo we had full control over, and if there was a possibility of adding a voice coil.
  3. Tracking glitches, e.g. with new peleas, can completely blur out the fringes.
  4. The slow slew speed is really annoying.

The problems with an upgrade are:
  1. The digital signals from the metrology system originate in the North rack, but the piezos and motors are ~35m of twisted pair and ~35m of ribbon cable away. There are 6 analog signals needed (2 x 2 motor coils plus 2 piezos) and 3 sensors (plus a limit?) and grounds. A big upgrade would be to current drivers and twisted pair - e.g. Digikey Ribbon cable aa20101 (something not in stock that has to be specially ordered). Without this and assuming that only analog signals go to the cart, there is about 0.25 nF capacitance between wires on opposite ends of the ribbon cable. We have an issue of capicative coupling between the piezo and the motor. With a piezo going +/-1V at 250Hz (a very extreme case!) we need less than ~0.1 microns of error from the motor. The motor goes about 2mm of OPD per step... call this a peak rate of 1mm per volt. We'd then want less than 1:10000 coupling between the piezo and the motor wires.... which requires an input impedence of 1.5 kOhms or less. This certainly appears possible... but we'd also have to consider the induced EMF of current loops around the place. As an extreme case, imagine 0.4 Amps at 50Hz going through a wire 5mm away from the ribbon cable loop which has an area of 0.1m^2 (extreme: 3mm loop at 30m). This gives an EMF of 0.5mV only.
  2. The system has to run fast. So it needs real-time linux or the HRT kernel stuff I (Mike) haven't tested yet.
  3. We'd need a full FPGA to replace the electronics that adds up the phase shifts of the return 625kHz signal relative to the reference 625kHz signal. The FPGA could be something like: http://www.opalkelly.com/products/xem3001/. USB latency really is too much, and the trick will be making sure that the data read in is current. The simplest (dodgy) solution would be to set a pin high that says "don't trust this data" just before a write, and setting it low afterwards. A 25ns software delay would be all that is needed to wait for the next good data. Needs thought.