The personal website of Scott W Harden
⚠️ Warning: This article is obsolete.
Opto-Isolated Laser Controller Build
July 28th, 2016

Opto-Isolated Laser Controller Build

I just finished building a device to interface a modern fiber-coupled DPSS laser used for optogenetic experiments with 15 year old scientific hardware. I finished this project in one afternoon, and I'm very happy with how it came out! This project has a blend of analog and digital circuitry, microcontrollers, and lasers (all the fun stuff!) and turned out to be a pretty cool build, so I'm sharing the design and construction with the hope that it will be inspiring to someone else. I don't intend anyone to replicate this project (it's designed to fill a very small niche), but I've learned a lot over the years by reading other peoples' project build web pages and I'm happy every time I get the opportunity to make one of my own.

The hardware I needed to interface is made by Coulbourn Instruments and is essentially just a large multi-channel computer-controlled DAC/ADC and it does its job well (turning lights on and off, recording button presses, etc.), but this new task requires millisecond resolution and modulation patterns which [most likely] lie outside the specs of this system and software. My goal was to utilize a free hardware output line to signal to a device that I build to modulate the laser in a special way. This way there would be no modification to any existing equipment, and no software to install. Further, since this hardware isn't mine, I don't like the idea of permanently modifying it (or even risking breaking it by designing something which could damage it by connecting to it). The specific goal is to allow the existing software to cause the laser to fire 20 ms pulses at 15 Hz for a few dozen cycles of 5s on, 5s off. It's also important to have some flexibility to reprogram this firing protocol in the future if a change is desired. What's more is that experiments are already underway and I needed this device to be complete within a couple of days!_ As much as I'd love to go to the internet and order the perfect, cheap components from China and have a beautiful build completed after the 6-8 weeks of shipping time, I had to build this only using parts I already had at my home.

After a little poking around, I found an auxiliary output which could be controlled by software. This AUX port has a frustratingly rare connector 1mm dual keyhole touchproof connector which I couldn't buy in bulk on eBay or amazon, and couldn't figure out the part numbers of on Mouser or Digikey. Luckily the laboratory had an old (broken) device with that connector on it they said I could cannibalize. (The manual even says "you may find it convenient to fit them with CI-type connectors" which makes me wonder why it wasn't designed this way in the first place) After plugging in the connector, I used a volt meter to measure the output. To my surprise, it wasn't a TTL signal! I expected to see my volt meter read 5V, but it read 28V! After consulting the manual I found mention of this: "Graphic State Notation software is designed for use with our Habitest animal-behavior-analysis environments or any other animal-behavior-testing apparatus that operates on the industry-standard 28-Volt control voltage." I was surprised that 28V signals is a standard for any industry. But wait, there's more! Elsewhere in the manual I found the phrase "The power base is capable of delivering 8 Amps of -28 VDC" which made me question the voltage reading I took earlier. The voltmeter showed 28V, but that's the difference between one keyhole connector output and the other. I became apparent that it really may be 0V and -28mV (an even more curious "industry standard"). I wondered if connecting the negative terminal to ground would destroy the unit (think about how easy this would be to do! If it were a TTL signal, the first thing you would do is connect the negative terminal to ground and start sampling the positive terminal). There was even talk of me interfacing with a different output port (which I hadn't probed, so I didn't know the voltage). Moving forward, I realized I had to tread very carefully. Doing something like connecting two grounds together could permanently damage this system! Not really knowing if I should design to expect a TTL signal, a +28V signal, or a -28V signal, I decided to design a circuit to accomodate all of the above, all the while respecting total electrical discontinuity from the circuit that I develop. I'm going to accomplish this using an opto-isolator on the input. I sketched the schematic on paper while I built the device, and only later came back and formally made it in KiCad. I considered laying out a PCB (I have most of these components in SMT form factors too) but I knew I wouldn't manage a one day turnaround if I went that far so I let that idea go.

Design Goals

  • The input should be able to accomodate any signal (TTL, CMOS, 28V, etc)
  • The input is totally isolated electrically, so this should be very safe on the hardware
  • The microcontroller is a socketed ATTiny85 which I programmed with a Bus Pirate.
  • I decided to rely on a crystal rather than the internal RC clock to improve temporal precision of the output signal. A 11.0592 MHz crystal was chosen because I have a bucket of them (they're perfect for serial communication at all common baud rates). Any crystal could be used, as long as it's frequency is defined in software.
  • Capacitors were added more to ensure oscillation initiates than to bring down the oscillation frequency. (I'm told that omitting them may cause a case where the crystal doesn't resonate as well, but I've never found this in my personal experience.) A good note on microcontroller clocks is in a Microchip PIC application note.
  • I included a "test" button (momentary switch) to simulate having an input signal.
  • Note that R1 must be able to handle the current applied to it. It was mistakenly designed as 1k, and later replaced with 10k. See the bodge note at the bottom of this post for details.

Potential Improvements

  • Forward protection diodes on the input could protect accidental reverse polarity
  • Adding an ICSP header would prevent de-socketing of the MCU if reprogramming is desired
  • The BNC output is directly from a MCU pin. It should be at least transistor-buffered to deliver higher current.

Because there is a possibility that a different output (laser control) pattern may be desired in the future, I considered whether or not I should make the output pattern user-configurable. Adding buttons, a display, and designing a menu system in software would be a lot of work and no one's really strongly asking for it, so I concluded that I'm going to build this device to the specific task at hand. If the end user eventually wants the ability to modulate the pattern on their own, the device they ask for would be a very different one than the one I was tasked to create. Since the current pattern is burned into a microchip, a compromise is that I could have new patterns burned into new microchips, and the end-user could change the chip (as long as it's an infrequent occurrence).

Wait a minute, turning 20 ms pulses at 15 Hz sounds like an easy task for a 555 timer without the need for digital circuitry. Also, it would be easy for the end user to adjust both of these features by turning a knob! Is a microcontroller overkill? I struggled with this question for a while, but concluded that the advantage of the MCU (crystal-disciplined time precision of the output pulses) outweighed the convenience of a purely analog circuit. A 555 timer in astable / multi-vibrator configuration would mostly get the job done, but you would either (1) only allow one output pattern and rely on precision passive components (which I don't have on hand), or (2) allow the end-user to adjust duty/frequency with potentiometers (which would require the output to be quantitatively monitored on an oscilloscope). I considered a blend of analog and digital circuitry by using analog components (with knobs) to adjust the duty/frequency, and microcontroller to measure the pulse width and period and display this on a screen (essentially building the oscilloscope into the device). Again, this is more work, and without being asked by the end-user to have an adjustable product (they just indicated interest when I proposed it), I decided I'd continue with the simplest-case, high-resolution design. Also I'll note that I'm relying on an external crystal (rather than the internal RC clock) to maximize precision from day to day use. Since this device will be used for scientific experimentation, I want to minimize the influence of temperature on the temporal precision of the output signal.

I started by measuring/marking drill points. I used a Dremel drill press to help keep things tidy. I expanded holes with a stepless step bit and smoothed them with a deburring tool. I also drilled holes in the base of the enclosure.

Luckily I had an enclosure ready to go. I always buy enclosures in bulk, and even though nice ones tend to be expensive, having them on hand encourages me to build devices as I think of them, rather than making flaky hardware which I have a history of doing which sometimes borders on ridiculousness. I usually stock unfinished Hammond diecast aluminum enclosures (which I write on with sharpie) for making quick RF projects, and generic fancier boxes with feet and side vents, but for this task I decided to (mostly) seal everything inside a typical (but a little more costly) aluminum enclosure (most likely an eBay special from China, but I can't remember where I got it). I love using low current LEDs, and I started going with frosted instead of clear LEDs because they're easier on the eyes. Also, I switched to mostly 3mm LEDs instead of 5MM because I think they look cooler. I have black bezels but they don't snap in as well as I'd hope, so I find myself having to add a dot of super glue to retain the LED and the bezel in position.

I used nicer perfboard with platted-through holes to build this circuit. Normally I use cheap ubiquitous perfboard with little copper rings glued to one side. It's easy to solder to because the copper is so thin it heats quickly, but it's not always a good long-term solution because the copper pads have a tendency to un-stick. I rarely use this nicer perfboard (it is more expensive, I order from China on ebay), but again I value having things like this stocked at my home ready to go at a moment's notice!

I marked areas of optical isolation with a black marker. This makes it obvious where the potentially dangerous, potentially high-voltage (well, higher than TTL) input comes in. No wires or connections should invade this space on the board. The special connector which will connect this device to the scientific hardware is at the laboratory, and I'll have to solder it at the time of delivery/installation. I left an extra hole in the back which I guesstimated would fit the wire. I didn't have any rubber grommets stocked at my home... I need to get some!

Strong copper wires hold the front panel onto the circuit, but this wasn't actually intentional. I first screwed down the circuit board, soldered everything together, and after I realized a change was needed on the underside of the board an unscrew was required. That's when I realized that I could unscrew the front panel rather than desolder it, and it held its shape great! At first glance this doesn't look like a robust construction technique, but is it really any different than soldering stiff coated wires?

Once it was all together, the device seemed to perform well. The test button on the back made it easy to inspect the output. My RF background made me instinctively terminate the output into a 50 ohm resistor for the measurements, but the square waves looked like super wonky RC curves and I realized 50 ohms is far too low impedance. If it's a TTL signal, let's assume it's virtually infinite impedance, and not worry about it. Note that this is a testament to the relatively low maximum output current of the microcontroller pin, and the potential need for a buffered output if anything more than high impedance TTL is to be driven. I think the datasheets suggests limiting its current to 20 mA per pin (requiring termination of no less than 250 Ohms) A 50 Ohm resistor pulled it out of spec. Oh well, I removed it and it survived fine, so let's make some measurements

An important thing to note is that absolute time precision is preferred over accuracy. Specifically, I want this device to perform identically for years, and highly favor precision over accuracy. With that said, I trust the pulses to be 20ms wide, but not exactly 15 Hz. To do 15 Hz, I'd need 20ms on and 46.666667 ms off. I could probably get pretty close if I wanted to, but I rounded it to 20 ms on and 46 ms off. This gives time for the instruction cycles toggling the output pins to occur (although it's on an order of magnitude faster time scale), which slightly biases the time in the right direction. I considered adding a _delay_us(666) after the _delay_ms(46) but I'm satisfied with it this knowing it's within 1% accuracy of 15 Hz and that precision is locked to that of the crystal (around 10 ppm, or 0.001%).

Admittedly the _delay_ms() method of timekeeping is a little clumsy. I considered a few other methods of time keeping, but decided not to implement them (yet?). The schools of thought were largely on three categories, but all relied on the AVR timers. Here's an awesome guide on the topic, and here's another. Timers would be preferred if I wanted the program code of the microcontroller to be free to do other things like drive menus or multiplex a display. Think of hardware timers on a MCU like multi-threading on a computer - it helps you out by running in the background.

  • Thought 1: timers: Set the timer to overflow every 1 ms. On overflow, a counting variable would be incremented and a function would be called to determine what to do. At pre-programmed time points (with respect to the counting variable), the output pin would be toggled, or the counting variable would be reset.
  • Thought 2: output compare registers: Utilize the built-in OCR (output compare register) to turn the output signal on and off. Set the timer to overflow at 15 Hz, turning the output on. Set the OCR (to the fractional point between 0 and the maximum timer value) such that when it is passed, the output is turned off. This way 15 Hz, 20 ms pulses would be continuously running without any code being executed. Input sensing could simply enable and disable the timer.
  • Thought 3: input interrupts: Why stop at timers? Polling the input pin for a TTL signal puts the chip in an infinite loop. Relying on the AVR's external (pin change) hardware interrupts could eliminate this as well. I always rely heavily on the datasheet when setting these interrupts.

Altogether these improvements could come in handy if a more accurate time source is desired, an advanced display is added, or menus are implemented which would benefit from letting the pulsing output operate in the background. For now, I'm happy with my dirt-simple code, and I'm still far within my one afternoon construction timeline goal!

After I was satisfied with construction, I started labeling the enclosure. I want to tip my hat to Onno Hoekstra on this one, as his webpage demonstrating how good clear labels make custom ham radio equipment look (and a personal email he sent me recently) made me start making clear labels for all of my custom equipment. FYI I'm using a DYMO LetraTag LT-100T Plus label maker and clear tape. It's important to enable the black outline around the text, then cut carefully slightly outside the outline with regular scissors. The results look fantastic!

The morning I delivered my product, I added the final connector which I didn't have at home. It's an inelegant knot-retained configuration, but I think it'll get the job done! Again this is a surprisingly rare fully shielded touchproof connector apparently used only in medical applications. At this point, I'm thinking this figure was chosen to (A) protect the user from accidentally shorting a 28V 8A power source (that's over 200 watts!), (B) to prevent you from damaging the equipment by plugging in something that doesn't belong (could you imagine what would happen if this -28V high current source had a BNC connector and you plugged this into something expecting a 5V TTL input?), and (C) prevent you from plugging in anything that wasn't made by this company. The last option is more likely consumer protection rather than the company trying to maintain a status of sole distributor of accessories, but it does make you wonder. I would have preferred power pole sockets (that's the ham in me), molded connectors like those on motherboards, or even barrel connectors! Surely there's a more standard touchproof connector for moderate voltage/currents (although, to be honest, I'm struggling to think of one at the moment). CL-type connectors seem expensive and bulky.

I plugged the device in to the computer, attached the laser, and it worked immediately! I couldn't say I was surprised that it worked, but it still felt good to watch the blue laser beam trigger like it was supposed to. Another cool one-off project is in the bag, and I got some great pictures for the website. I hope this little box lives many happy years in its laboratory home.

Microcontroller Code

#define    F_CPU (11059200UL)
#include <avr/io.h>
#include <util/delay.h>

int main (void){
    DDRB=(1<<PB0); // TTL output
    PORTB=0; // internal pull-down
        while((PINB&(1<<PB2))==0){} // hang while LOW
        PORTB=(1<<PB0); // TTL ON
        PORTB&=~(1<<PB0); // TTL OFF

Here's the batch script I used to compile and load the code onto the microcontroller. I compiled the code with AVR-GCC and copied it onto the microcontroller with a Bus Pirate. Note also that I'm setting the fuses to respect an external oscillator.

@echo off
del *.elf
del *.hex
avr-gcc -mmcu=attiny85 -Wall -Os -o main.elf main.c
avrdude -c buspirate -p attiny85 -P com3 -e -U flash:w:main.hex
avrdude -c buspirate -p attiny85 -P com3 -U lfuse:w:0xff:m -U hfuse:w:0xdf:m -U efuse:w:0xff:m

Final Design

Update: Improve Current Handling

After a few days I got an email from someone concerned about the current handling capability of the front-end of the circuit. It was noted that a standard 1/4 watt resistor may not be suitable for R1, as a 28V potential would stress it beyond its specs. With 28V applied, R1 (a quarter-watt resistor) would experience P=IE=28mA*28V=784mW of current! It might last (especially if pulsed), but it also might fail with time. The advantage of the R1/D1/R2 system is that the output current will be identical across a wide range of input voltages. The disadvantage is that it's hard to predict how beefy R1 needs to be. I could have placed five 4.7k resistors in parallel to replace R1 (this would let me handle over 1 watt of power), but I instead simply upped it from 1kOhm to 10kOhm. This further reduced the current that the opto-isolator sees (now only about 0.2 mA) but it seems to work still! So I'm satisfied with this bodge, but a little disappointed I didn't catch it sooner. Note that the new input resistor (a 10k R1) should only have to dissipate about 80mW, well within its specs.

Update: H11B1 minimum current and AC noise

After pondering it for a while, I considered that a 10K input resistor on 28V would only allow 2.8 mA to pass through. Considering only 3.3V will persist after the zener (a 11.7% current retaining ratio, if that's valid math), I figured that a best 330uA were passing through the opto-isolator. That seems outside of the specs of the device, because their datasheet graphs always start at 1mA. I decided to run some tests at my home for kicks. I determined that a 10k resistor still works with 5V (500 uA into the device), but checking the output on the oscilloscope I realized that the device operates only partially, and slowly at that low voltage/current. The darlington transistor configuration is very high gain, which is the only reason this works at all, but such low currents are sensitive to parasitic capacitance and infiltrating RF currents. As such, I noticed the chip took a few ms to activate and deactivate. Since this application only uses 5s on and 5s off inputs, it's fine... but I wouldn't expect highspeed pulsing of the input to work well. Furthermore, in my breadboard I realized I was getting funny output currents. They were oscillating around 60Hz, which made me suspicious that the device was picking up AC somehow. I realized it was from pin 6 (the exposed darlington base). Normally the LED is so strong is blasts the device fully on or off, but hovering on the edge like this, that pin is picking up signals. Since it's not connected to anything anyway, I cut the pin off as close to the microchip as I could, and noticed an instant improvement in 60Hz rejection. In conclusion, I wouldn't try to reliably run an optoisolator on less than 1 mW, but it seems to work!

This is the output of the unmodified H11B1:

This is the output of the H11B1 with the base pin removed:

Newer: Live Data in PyQt4 with MatplotlibWidget
Older: Realtime Audio Visualization in Python
All Blog Posts