Found this on Maplin and was wondering if it could be used as a Galvo DAC? Can anyone tell me?
http://www.maplin.co.uk/Module.aspx?...d&doy=7m3#spec
Found this on Maplin and was wondering if it could be used as a Galvo DAC? Can anyone tell me?
http://www.maplin.co.uk/Module.aspx?...d&doy=7m3#spec
Yes, but not in the high-speed conventional sense... The driver
use PWM the generate the analog outputs, which would be slow
unless you used some creepy high speed logic,
However, that looks like FR-4 PCB which cannot handle Ghz due toCode:2 analogue outputs: 0 to 5V, output resistance 1K5Ω PWM 0 to 100% open collector outputs max 100mA/40V (on board LED indication)
intraboard capacitance which rules out high speed creepiness.
The output voltage range is 0 to 5V which means you'll have to implement
a multiply and shift opamp circuit offboard, which isn't too bad... You
could get by with a single TL074 if you didn't want differential outputs...
But the main problem is the actual speed.
This implies that you'll be doing 50 points per second of scanning max...Code:General conversion time: 20ms per command
Keep in mind that most boards handle 20us (microseconds)
for conversion time (which is 50,000 points per second)...
Oh i see i am new to all of this, so how hard is it to build a DAC? Surely it cant be that hard?
The actual DAC circuitry is trivial, all of the problems are on the computer side.
The main problem is that none of the standard consumer grade operating
systems (windows/linux/osx) are built to handle "real-time"... Simple actions
such as inserting a CD can cause the entire system to pause for hundreds
of milliseconds, which is a problem for laser display which requires
microsecond level updates and accuracy.
Quality solutions work around that problem by providing either a sufficient
FIFO buffer or a frame buffer... The systems which do not compensate for
the problem can have significant visible jitter which will show up as
hot spots and timing errors on a projected laser image... Unfortunately,
cost of the product isn't necessarily a good indicator of the quality, there
are plenty of commerical mid-tier products which are worse than a lot of
homebrew systems...
The second consideration is the resolution of the DACs... Honestly,
this is less important than you'd think. The minimum acceptable resolution
is 8-bits if you have external scaling, 10-bits if you don't... You just have
to make sure the DACs are fast enough, which for laser control is a 10-20us
slew rate...
bilda is a cleanly engineered project with open schematics, if you're looking
for commercial solutions, Pangolin has an excellent CF-card driven
12-bit system...
In terms of your end goal, I'd look at the software offerings which provides
the features you want, and then look at what hardware solutions, homebrew
or not that work with the package you choose.
What about easylase usb is that a good working DAC? Are DACs built with specific software for them? Or can you use any type of laser scanning software? Because all i am looking for is a parrell printer port DAC board with software like Mamba etc.
Yadda;
I'm glad you responded to this thread; your post above (and others in the thread about your new board) got me thinking about the shortcomings of laser show hardware.
As you pointed out, if the operating system stops to perform a housekeeping task, the data flow to the DAC halts. Now, why wouldn't any smart designer recognise this as a problem and design a buffer into the controller card itself. A few megs worth of local storage would go a long way towards preventing these types of glitches. Given that RAM is so cheap, do you have a theory as to why it isn't more common to have on-board buffering on controllers?
On a related note, I'm curious if there are interrupt-driven solutions (I'm thinking sound-card DAC's here, or something similar) that could perform an end-run around this problem. After all, even when the OS gets tied up with disk insertions, disk formatting, or even printing operations, the sound output remains constant and uninterrupted. (No doubt due to a combination of DMA access and on-board buffering.) I've seen several homebrew projects that use this approach, but no commercial ones.
So is there a specific reason why using a sound card or other DMA-capable off-the-shelf board is less preferable to a custom DAC fed from some other port? (Parallel, USB, etc..) And what about firewire interfaces? (Well, apart from the licencing fees...)
I'm not trying to crack on any one specific product, and I'm not looking to build the one killer solution either. (That would be your job! )
I'm just curious as to the WHYS behind some of these developer decisions that, to me, seem rather short-sighted. It just doesn't seem like it would be all that hard to build a solution that would be so much better than what we have now. But if it really were that easy, we'd have the solution already. Since we don't, I'm trying to learn why. (And you are without a doubt the most qualified person I know that could answer!)
Adam
tomc: I like mamba, though I wouldn't necessarily compare it to pangolin.
For the most part software isn't interchangable, phoenix or whatever they
call it now is a nice package btw. If you are satisfied with parallel ports and
have the slightest inclination toward electronics (or have a buddy that does),
I strongly recommend building your own DAC. The commercial parallel
port solutions are not any better than the homebrew ones except in
end user support. Groover's last design was pretty nice and simple.
Whatever you choose, post it here so we can help you make it work right.
A lot of the online circuits make assumptions about the knowledge of
the assembler so some difficult steps may be omitted as "obvious".
buffo: For commercial solutions, it's all a matter of what people want
to spend, and for most folks, it's not very much. So the commercial
designer is limited by the budget and knowledge of his target audience.
The second part is actually more important, since the laser field, at
times, is like a bunch of secretive sorcerors muttering about etalons
and aligning crystals and squirrelling away "sekrit" information... What
this results in, is that lasers are less science and more voodoo cult.
And in the end, users don't know what specs matter and don't have
a definitive source to go to... I've never even heard of a side-by-side
shootout of laser systems...
To answer the questions directly.
In terms of designing buffers:
The specific buffer chips which would have been perfect for buffering parallel
port boards have been discontinued for decades. (They were used as print
buffers for old dot matrix printers)... The modern equivalents are basically code
blocks in a FPGA.
CF cards and similar technologies are slow at non bulk transfers and
read-write cycles mean that you'd wear out the actual card in hours
if you tried using it as a buffer.
SRAM is expensive monetarily (this is the route I took because SRAM is
also fast) and more importantly, SRAM and other RAM technologies are very
expensive in terms of IO lines required off CPUs and micros...
DRAM, SDRAM and other volatile ram technologies require several offboard
chips to handle refreshes which increases the real-estate required on the
PCB... The design is also more critical and should be professionally fabbed.
(this is the route pangolin took)
Sound cards are avoided for the most part because most soundcard dacs,
even precision 24-bit dacs have linearity issues which are noticable as
distinct stairstepping on a scope. Not an issue if you are looking for cheap,
but since you'll have to do mods and attach some offboard circuitry, IMHO
it's just as easy to build one from scratch.
Which leads us to built from scratch DMA based boards which is a fine idea,
and what we were thinking of originally, except you can't use it on laptops...
(With the exception of some creepy PCI adapters) I believe there are a few
commercial units which use DMA... but they used 12-bit dacs so never
got the full consideration that they deserved.
Basically your bus transport is irrelevant if your bandwidth is sufficient
and your buffers are sized accordingly. People don't do it because they
either don't know better, don't care, or are cost conscious.
If you want a random project I poke at off'n on... it'd be a SPDIF fed DAC!
Take a standard CDROM drive with one of those play buttons, grab the
digital out of SPDIF, then feed it to a one chip digital sound processor
(to translate into a format DACs can understand) and then feed it
directly to a pair of DACs... manually setting the LSB will allow you to
feed "blanking" data withouth affecting signal clarity (15-bit accuracy)
at 44.1kHz.... For laser speed control, you merely upsample the desired
output of an ILDA show using some simple fouriers... There's even
a reference for a similar thing for audiophiles on headwise... I would
change the DAC and the offboard opamps would be designed for
lasers not headphons, but the principle is identical...It would make
for an incredibly cheap and very nice playback system!
I think i will try and build the DAC because i want to see how hard it is.
Yadda;
Thanks for the great post! Lots of good information there...
I'm confused. Are you saying that the fuction of the custom print buffer chips can be recreated using FPGA's? Because I was under the impression that FPGA's were reasonably inexpensive. (That's why they're used for prototyping?) So why not use an FPGA-based buffer?Originally Posted by yaddatrance
[quote]CF cards and similar technologies are slow at non bulk transfers and
read-write cycles mean that you'd wear out the actual card in hours
if you tried using it as a buffer.[/qhote]
Yeah, this makes sense. I can see CF working as a mass storage replacement to hold all the show data for a stand-alone playback device, but not as a buffer for individual points/frames.
You mentioned that DRAM solutions need to be professionally fabbed... Is this because the timing is so crucial? (esp. with regard to refresh?)
Huh... That's a surprise! So high-end audio really isn't, eh? (Or rather, that the human ear can't detect the non-linearity, but a set of galvos will bring it to the forefront, right?) I admit that I've never hooked my scope to the outputs of a decent sound card to see how clean the output is... (I've played with a few different ones from Turtle Beach, and my favorite was always the old AWE 64 gold, but I just assumed they were good because they sounded good!)Sound cards are avoided for the most part because most soundcard dacs, even precision 24-bit dacs have linearity issues which are noticable as
distinct stairstepping on a scope.
Now that's a neat idea... Come to think of it, didn't some early laser projectors use DAT units to playback the pre-recorded show? (Of course, they were recorded from an analog source, so that's not really the same thing you're proposing.)If you want a random project I poke at off'n on... it'd be a SPDIF fed DAC!
But yeah, you'd have a CD rom hooked up to your projector (or built-in to it!) and you could play the whole show from a CD... The only problem is that you'd be stuck with monochrome, and 15-bit resolution at that. (Though as you said, 15 bit is more than enough - heck 8 bits looks pretty good to me!)
Truthfully, if it were me, I think I'd drop down to maybe 12 bit resolution or so and use the rest for color control. You're still not going to get full analog (8 bit per channel) color, but you can at least get TTL on 4 lines, which wold be enough for a 4 channel PCAOM on a mixed gas rig. (Ok, 8 channels would be better, but if you can grab 647, 512, 488, and 457, that would make for a good mix, no?)
tomc: great! Let us know which design you pick! I'm always really interested
in what goes into people's decisions!
buffo: FPGAs are relatively cheap but they also suck a great deal for use
on a low volume or one-off project. To just dedicate an FPGA, you may as
well just throw a micro at it since you'll definitely want to clock the output
and check states on the input. It would make more sense if there were
a lot of offboard logic that you could also implement on the chip. FPGA is
inexpensive compared to custom silicon, not compared to say a general
purpose micro with gobs of RAM built-in (economies of scale and all that)...
In terms of sound cards, I always did like the AWE series myself... If you
want to scope the output of the sound card, keep in mind that most cards
have capacitors which filter out a lot of the usable DC (makes the waves
smoother, but a lot less accurate)... You'll definitely want to take the output
straight from the DAC before the built in "slush" circuitry... People may
appreciate "warmth" from speakers, but they certainly wouldn't appreciate it
seeing it out of a set of galvos
With 12 bits of XY, you'd get 8 usable bits of data (4 per channel), which
you could use to make either a EEPROM lookup table for color, or whatnot.
but the simplicity kind of goes out the window since you're looking at
stuff like octal dacs with its accompanying timing considerations.
Plus if you dumped the cash for a whitelight and a PCAOM, I'd imagine
that you'd probably swing for a higher end circuit However, the circuit
will scale linearly, so the more dacs you throw in, the more channels you
can get out... You can also make really creepy optimizations like
"every other frame" algorithms and stuff, but at that point its no longer just
a decoder + DAC, you'd want CPU involved in there somewhere.
Incidentally, the way a lot of laserists do colors on an 8-channel PCAOM is to
slave certain lines together... especially since the modern ILDA connector only
give you 6 modulatable color channels. For example, it's very common to see
the two Kr reds tied to a common signal.
Me personally... I'd just take the two bits you'd get from making the dac 15 bit
and do TTL modulation on two colors, probably red'n yellow since this would
be a "budget" project.