Results 1 to 10 of 10

Thread: Would this work for a DAC?

  1. #1
    Join Date
    Feb 2006
    Location
    North West, UK
    Posts
    35

    Default Would this work for a DAC?

    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

  2. #2
    Join Date
    Jun 2005
    Location
    SoCal
    Posts
    506

    Default

    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,
    Code:
    2 analogue outputs: 0 to 5V, output resistance 1K5Ω PWM 0 to 100% open collector outputs max 100mA/40V (on board LED indication)
    However, that looks like FR-4 PCB which cannot handle Ghz due to
    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.
    Code:
    General conversion time: 20ms per command
    This implies that you'll be doing 50 points per second of scanning max...
    Keep in mind that most boards handle 20us (microseconds)
    for conversion time (which is 50,000 points per second)...

  3. #3
    Join Date
    Feb 2006
    Location
    North West, UK
    Posts
    35

    Default Would this work for a DAC?

    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?

  4. #4
    Join Date
    Jun 2005
    Location
    SoCal
    Posts
    506

    Default

    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.

  5. #5
    Join Date
    Feb 2006
    Location
    North West, UK
    Posts
    35

    Default Would this work for a DAC?

    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.

  6. #6
    Join Date
    Jan 2006
    Location
    Charleston, SC
    Posts
    2,147,488,544

    Default

    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

  7. #7
    Join Date
    Jun 2005
    Location
    SoCal
    Posts
    506

    Default

    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!

  8. #8
    Join Date
    Feb 2006
    Location
    North West, UK
    Posts
    35

    Default Would this work for a DAC?

    I think i will try and build the DAC because i want to see how hard it is.

  9. #9
    Join Date
    Jan 2006
    Location
    Charleston, SC
    Posts
    2,147,488,544

    Default

    Yadda;

    Thanks for the great post! Lots of good information there...

    Quote Originally Posted by yaddatrance
    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.
    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?

    [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?)

    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.
    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!)

    If you want a random project I poke at off'n on... it'd be a SPDIF fed DAC!
    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.)

    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?)

  10. #10
    Join Date
    Jun 2005
    Location
    SoCal
    Posts
    506

    Default

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •