This is a proposed project to create a system based on KFLARE which would provide single-channel Laser/TEC driver boards controlled by a single central controller.

Discussions Nov 2019

• TEC Driver currently 3A would like 4A
• Laser driver 2.5-3A now (thermally limited) would like 4A (see DRV595)
  • Need to discuss power supply issues
  • Need dual polarity
• New photodiode readout requirement
• Flexible polarity / grounding

Sylvain suggests that a 2-channel board would be OK but need to discuss changes above and mechanics / cooling.

A big issue with the old design was cooling of the driver circuit. A couple of thoughts come to mind. One is to optimize the power supply voltage for each laser (programmable switching regulator?) Another is to us a larger transistor package with a bigger heatsink.

Existing System

• Existing design uses an Atmel ATMega164A uC per laser in a 44-VQFN package. This device is efficiently used, with only about 4 spare I/O pins.
• Communication is over a Modbus-like RS-485 serial shared bus. This works well since RS-485 has very good power supply rejection. See ​communications protocol spec document.

In the current system an additional ATMega64A uC was used as the system controller, which would manage up to 20 Laser/TEC modules and handle the interface with the host computer. The system controller also managed the power supply, fans and an additional white light source.

System Controller functions:

• UART (RS-485) bus to Laser/TEC modules
• UART or other interface to host computer
• Fan control PWM output
• Fan sense input
• Interlock control logic inputs: TEMP_ALARM, AC_FAIL, FAN_FAIL, INTERLOCK_STATUS
• Interlock control logic outputs: LASER_SHUTDOWN, LASER STATUS (per laser)
• ~4 temperature sensors
• I2C DAC for laser current setting (or maybe Laser/TEC control?)
• White light source control (opt-isolated)
• Laser enable outputs
• LED indicators

Controller ideas

• Zynq, e.g. Enclustra Mars ZX2 DIMM
  • Pros: Linux on-board, familiar, lots of GPIOs, complete control of peripherals
  • Cons: Analog inputs may be hard to use
• Beaglebone:
  • Pros: Linux on-board, UARTs and analog inputs built-in, enough GPIOs
  • Cons: Unfamiliar, sounds like analog inputs are a real headache
• Raspberry pi:
  • Pros: Linux on-board, widely used
  • Cons: Unfamiliar, share UART with serial console (?), analog inputs maybe a pain
• FPGA Eval board:
  • Pros: Relatively easy to use (IPBus interface?)
  • Cons: Need to come up with an ADC solution

There exist some useful PMODs, such as ​Isolated RS-485 and ​4 ch 12 bit ADC