Open Source/Freeware Budget USB DAC

[mixedgas]

I think we've lost Chris... 22 posts ago.

Steve

[heroic]

but with the DACs on the atmel the total is 6 or 8 12 bit analog outputs. The single, quad external DAC chip is not expensive enough to warrant socketing four single DIP DACs, IMO. Plus the single quad will take up less board real-estate.

*shrug* Okay. As long as I get twelve bits I'm happy.

[mixedgas]

*shrug* Okay. As long as I get twelve bits I'm happy.

OK to summerize, we use the ATXMEGA64A1-AU-ND, a FTDI chip, and a 12 bit quad dac? We have 8 bits of TTL output plus one shutter that can be TTL or OC.

All parts appear to be stocked some place in more then Q5. 0-60Kpps since there appear to be 50 Kpps galvos at a low cost now.

I'm seeing $7.65 for the MEGA, and $4.75 to $7.50 for the DAC. 1 quad and 1 dual opamp for the buffers, so 2$ there. 2 more quads for the ilda outputs, so 2$ there, 69 cents for a crystal, and 2 dollars or so for caps, + 2.75 for the USB connector + 1$ for a decent db25 for the ilda port, that puts us at 25$ for parts less board, give or take. Plus say 7$ each for a blank board? 32$ about right?

Other then how to sync the show to the audio, are We good?

Steve

[heroic]

OK to summerize, we use the ATXMEGA64A1-AU-ND, a FTDI chip, and a 12 bit quad dac? We have 8 bits of TTL output plus one shutter that can be TTL or OC.

All parts appear to be stocked some place in more then Q5. 0-60Kpps since there appear to be 50 Kpps galvos at a low cost now.

I'm seeing $7.65 for the MEGA, and $4.75 to $7.50 for the DAC. 1 quad and 1 dual opamp for the buffers, so 2$ there. 2 more quads for the ilda outputs, so 2$ there, 69 cents for a crystal, and 2 dollars or so for caps, + 2.75 for the USB connector + 1$ for a decent db25 for the ilda port, that puts us at 25$ for parts less board, give or take. Plus say 7$ each for a blank board? 32$ about right?

Other then how to sync the show to the audio, are We good?

Steve

Well:

- use a spare op amp into one of the analogue inputs for audio input
- put down pads for at least one of the spare serial ports to be exposed on a header (tx, rx, gnd) = 3 pins
- ditto i2c (SDA, SCK, gnd) and one of the spare SPIs (MOSI, MISO, gnd and a slave select)= three pins and four pins
- I want the ADCs exposed on a header for loop-closing and scan fail interlock fun = nine pins

so I'd like another four headers please :-) that's gotta be a whole twenty cents.


With that lot we can do scan failure detection, DMX512 and linearization. Later. :-)

[cfavreau]

Chris isn't lost. Chris is watching. I am mostly a software engineer so specs are the utmost importance. I hate picking out parts... but it is still fun to get in on the discussion.

The on board DACs might work on the XMega's however ... they don't update at the exact same time. 1 MHz is the tops you can update both I believe. The XMega is also another part that is not out the in the wild very long so I would question the actual availability but I suppose you guys have checked already. If I was you... I would use a ATMega644... unless you can definitely get the XMega (this might be a moot point) cause 32 MIPS never hurts.

One comment about the FTDI chip. If you use the USB to Serial ... IE the 232R you will run into a bandwidth barrier without some sort of compression which I would like to remind people that compression is not a fixed percentage all the time unless you use LOSSY compression. Huffman encoding/decoding is easy because it just uses a table to encode/decode bits. However I do not think it would work well in our situation. I think the link dictates the point output rate. This is largely due to no or a partial frame buffer. If you cannot transmit 60 kpps unencoded to the microcontroller you cannot do 60 kpps. You can do 60 kpps in whatever bursts you can buffer. But eventually you will run out of points to display and you will have repeat points or stop displaying.

If you use a 245R then you will have plenty of bandwidth. It interfaces readily with an ATMega and is interrupt compatible if you want to use them.

Originally I was thinking to use an Arduino based platform as the development environment and programming of the thing couldn't be much easier... and you can use C and assembler if you don't want to use the Arduino stuff. I would still recommend using it if you can... It also brings one more large advantage to the table. No surface mount components to solder. While I am comforable working with the little FTDI chip packages other people may or may not be. With an Arduino you can simply make a piggy back "shield" board to place on top... it can be all through hole or large surface mount components like SOIC packages.

*** If I really had my choice of platforms I wouldn't mess around with microcontrollers at all. I would use an FPGA with a soft core processor. The NIOS II from Altera is great. There is an ethernet adapter for it among other things, boatloads of flash and RAM, but ... it is costly and not hobbiest friendly for the most part. Cheap ones are $150 for a module you don't have to solder but the IP cost for the processor is $1500 (for 1 product) and there are other costs if you don't make your own peripherals. Totally worth it and IMHO capable of competing with Pangolin type systems. I think you would be looking at around $400 to $500 for a hobby kit DAC (if you want to call it that).***

[heroic]

The on board DACs might work on the XMega's however ... they don't update at the exact same time. 1 MHz is the tops you can update both I believe.

We're talking about driving galvos that might have 4 kHz bandwidth if we're lucky so it's not a big deal.

The XMega is also another part that is not out the in the wild very long so I would question the actual availability but I suppose you guys have checked already.

Digikey has them in stock.

One comment about the FTDI chip. If you use the USB to Serial ... IE the 232R you will run into a bandwidth barrier without some sort of compression which I would like to remind people that compression is not a fixed percentage all the time unless you use LOSSY compression.

Have you tried compressing ILDA data lately? There's a LOT of air in those files.

Huffman encoding/decoding is easy because it just uses a table to encode/decode bits. However I do not think it would work well in our situation. I think the link dictates the point output rate. This is largely due to no or a partial frame buffer.

The XMEGA parts have plenty of RAM for a frame buffer.

If you use a 245R then you will have plenty of bandwidth. It interfaces readily with an ATMega and is interrupt compatible if you want to use them.

I thought that was what we were doing.

Originally I was thinking to use an Arduino based platform as the development environment and programming of the thing couldn't be much easier... and you can use C and assembler if you don't want to use the Arduino stuff. I would still recommend using it if you can... It also brings one more large advantage to the table. No surface mount components to solder. While I am comforable working with the little FTDI chip packages other people may or may not be. With an Arduino you can simply make a piggy back "shield" board to place on top... it can be all through hole or large surface mount components like SOIC packages.

Arduino doesn't have the performance we need to run this.

*** If I really had my choice of platforms I wouldn't mess around with microcontrollers at all. I would use an FPGA with a soft core processor.

I work with these things a lot and they're not all that great. Plus they're expensive.

-J.

[dave]

May I point out the Lumax DAC

http://www.lumax.de/

The Lumax DAC runs a Mega8515 and is capable of 70Kpps with RGB, or 45Kpps with 2 extra color channels.

So this sort of thing can be done with a lot less hardware than you guys are planning on using

[mixedgas]

[QUOTE=dave;96702]May I point out the Lumax DAC

Dave, Thank You!

The site says, when google translated:
"Unfortunately, I can request for reproduction or for firmware no longer". So are we back to rolling our own, or can we buy that?

Steve

[heroic]

May I point out the Lumax DAC

http://www.lumax.de/

The Lumax DAC runs a Mega8515 and is capable of 70Kpps with RGB, or 45Kpps with 2 extra color channels.

So this sort of thing can be done with a lot less hardware than you guys are planning on using

Right but we want to have some headroom to do stuff like closed loop power control, exclusion zones, scaling and geometric correction. The Lumax clearly can't do that sort of thing since it has to drop its point rate to support those extra colour channels.

Meanwhile the successful commercial DACs are based on somewhat more powerful chips- the Pangolin stuff being based on the ColdFire things, for example- and this is what gives them the ability to run sophisticated software.

Design for tomorrow, build for today, remember what happened yesterday :-)

[cfavreau]

And... might I mention that the Lumax uses a frame buffer I am pretty sure. It also as mentioned above has to drop something in order to speed up or add more channels.

Ok. So a 245R ... no need for compression.

Some experiments should be made to test Huffman encoding on small chunks of frames. That would be interesting. Right now totally not necessary and just complicates the system. I wasn't sure about the USB interface because it was kind of pushed to the side and don't worry about it was said.

Ardunio Mega does have the power and the pins... but no big deal.

So who is raising their hand to make the board?

I will sit back and watch some more.