I'm finally done with the logic checks for my homebuilt laser controller.
So I'm giving a sneak preview (like a photonlexicon exclusive or something).
I'm what you could call a professional hobbyist. 15 years ago, I had some
dreams of making money by doing shows, I got some equipment and learned
how hard and annoying being a laserist is first hand. So... I've long since
relegated this to being a pure hobby. Here in Southern California, we've been
gathering like-minded laser hobbyist and we spend most of our free time
tinkering with this gear. I do have a day job as an engineer (with a really
long scary title as corporations are sometimes wont to do), but luckily it
isn't soul sucking and leaves enough creativity to do fun projects for myself
while I'm at home.
I call this whole project "Ghettolaze" since, love it or hate it, ghetto really
seems to permeate the whole industry. It's a scarily common occurance to see
$4000 optics attached with hot glue and heatguns instead of bragg mounts.
The new prototype I layed out. I used DIPs wherever possible since I'll have to hand solder all the components. It's going to be fabbed on a 4-layer board.
This is a system designed with a "cost (and especially time) is no object" mentality.
Every single chip has absolutely insane specs, the opamps alone
cost $50 a piece. As I already own a nice Pangolin Pro, I thought
it would be fun and interesting to design something completely different given the same
budget as buying another pangolin board. It's not designed to compete with
Pangolin as I have no interest in implementing features like synchronizing
with SMPTE timebase codes or anything like that... Most of the features
of Pangolin would be useful if you did professional shows synchronized to
lighting and video systems... Rather it was designed to give me extreme
flexibility in some specific areas that I really wanted.
This is my last quick sanity check of the traces I laid out for this controller before fabbing!
High resolution version: (http://photonlexicon.com/gallery/alb...MG_1202?full=1)
The board has 2 x 16-bit DACs for X & Y, 8 x 8-bit DACS for color, 16 TTL channels.
It has two onboard microprocessors, an 8051 and an SX52 clocked at 100Mhz.
The 8051 is dedicated to the USB 2.0 High speed protocol (480Mbps) and has
three endpoints defined. The SX52 is used with 4Mb offboard 12ns SRAM to
provide the frame storage and timing... The micro code for both processors was
coded in pure assembly with speed and accuracy as the primary goals.
(That part really sucked btw, the SX52's datasheet is tome length! It
had so much data it made my eyes cross and it was dull enough that it
could put computers to sleep.)
The basic architectures is "framebuffer", its easier to think of it as a
vector based video card. It supports variable scanrates in a single
frame and can adjust all of its parameters realtime on the fly...
It starts to differentiate itself from other systems by maintaining
ludicrous levels of precision at high speeds. The system is designed
to stay within microvolt range accuracy even at 150Kpps scanning,
not a trivial task, in fact a somewhat stupid idea since you'd be
stretching the limits of resolution on even modern 'scopes! Every stage
was bench tested and a test rig was build for every single component.
I started with opamps designed to operate with high slew rates off of
20-bit DACS in scientific instruments with less than 1 LSB error.
I selected 16-bit DACs which can maintain less than 1/2LSB error while
driven into the Mhz range. I would have selected a higher resolution DACs
but I discovered that even when you say cost is no object, there is a
tradeoff between maximum accuracy vs accuracy at high speeds. Meaning
that a more accurate DAC will likely be less accurate when driven at higher
speeds than a less accurate DAC! I originally optimistically looked at 24-bit
audio DACs, but the output looked more like stair steps and exhibited
terrible linearity. Totally out!
I did build several test rigs which could maintain true 20-bit accuracy
but they ended up settling slower (and hence being less accurate) than the
original 16-bit DACs I selected at the scanrates I was demanding.
Now back in reality land, past 14 or so bits of accuracy you would
be incredibly hardpressed to visually tell the difference. The difference
in accuracy between 14-bits and 16-bits is about 0.00005 volts.
Am I nuts for designing this for true 16-bit accuracy? (don't answer that)
Well, I certainly thought so, but as luck would have it, there was a
perceptable quality difference! Though unfortunately it wasn't due to
the accuracy on my part. As it turns out, reality is truly ugly
and even the 16-bit laser systems I tested didn't exhibit anywhere near
14-bit accuracy. Or more accurately, the noise floor drowns out any
precision on the existing systems. So... you win some and lose some.
I'm currently resisting the urge to "upgrade" the pangolin I have with
some of the new chips I've been playing with since for all practical purposes,
it's more than good enough, borders on great and is just shy of perfect.
So lessons learned? Past 14-bit's it's completely unnoticable unless
you're scanning something over the horizon or something at equally silly
distances.
So, back on track, I also selected dedicated balanced driver chips so
it can maintain this accuracy while pushing high impedence loads. As it
turns out, this is really important since the Cambridge amp is a terrible
terrible noise source... I really really wish I hadn't scoped the collectors
on the scanamp... The pure cruft and AC drivel made me eyeball their circuit
and it's using CHEAP audio class opamps. Since I'm a bit *ahem* retentive,
I plan on building my own scanamp drivers as soon as I'm finished with
this first project. I was thinking of using a fast DSP instead of the classic
analog feedback design that's been around for decades.
So... uhm...
My primary goal in this exercise was "real-time" control as I had been
somewhat unsatisfied with the real-time performance of existing systems.
This new board has millisecond level frame latency and each point is
displayed with crystal locked accuracy inside the frames. You can choose
and adjust the scan rate up to 150Kpps rates in 1 pps increments.
The uplink is USB 2.0 High speed (480Mbps) and there's enough spare
bandwith to support 4 boards on one USB 2.0 bus with no glitching.
(Note, Well technically you could have many many devices and it won't
glitch being a framebuffer'n all, but I'm talking no glitching in terms of
full speed framerates) (Note 2. Our earlier prototypes were made with
Firewire, but aborted in favor of USB2)
I've written native drivers for Windows, OSX 10.4 and Linux, and
I'm working with several other talented people on software and toys.
We've got a working cute realtime beamshow driver...
It's a harmonic waveform synthesizer, We call it mona... It can also
be fed audio and generates attractive harmonics in realtime with
DFT and FFT algorithms. The latest version is slightly more attractive,
but I'm waiting to finish some more features before showing it off...
We also have a quick program we use to draw frames for shows... This
was never meant to be pretty, just useful to me... All the options
and things you'd normally point and grunt at are still mnemonic keybindings.
I plan on fixing that soon
This is an example of something drawn using framelab...
Here's a ghetto hoopty designed in Framelab, and exported as GIF...
Took about a minute to make
I also implemented a somewhat usable autotracer... It needs a lot more
work, you can see the operation in this 8MB movie clip.
Movie Link: http://scc.sc.wfinet.com/howdy/MVI_1198.AVI
Phew!