Open Source/Freeware Budget USB DAC

[mixedgas]

It comes down to economics.

Because modern chips are surface mount, you need a PCB from a board house. The number of people who can do a singled sided SMD board at home are very small. Double sided is out of the question at home. For example it costs me 150$ for four pieces of a typical dac sized board, unless I am willing to to take shortcuts on how well you can solder the SMD chips, ie no solder masks. To get the cost down, you really need to order 50 boards. Now your probably looking at 10-20 dollars per board and somebody has to do the group order. The number of PL people who would dare to solder a smd board at home is small.

So now your at 30$ for parts and 30$ for board if your wiling to invest your time and you can solder. The chip on the board with the brains most likely will need programed, so now you need a programmer, or someone to set there and program them and do it for no profit.

Plus your looking at software programming time and manuals and support.

200$ is cheap and unbeatable at that point, and supported by a lot of freeware.

The Germans who make Pango like low cost software or freeware are going encrypted in their data stream, to favor board manufacturers that they like, even offering a trade in on old boards if you go encrypted. Therefore your software choices are limited, and its gonna take a couple of hundred man hours to make a useful time line editor.

Therefor it is illogical that you can do this for free, and make it for mor ethen a few people. One person drops out and the project is frozen.

Buy the Riya cards, its easier then reinventing the wheel.

Low cost almost always comes with tradeoffs, I mean who is fork over the cheque to make the board run?

Steve

[cfavreau]

How about 8 bit XYRGB? It works decently and the DACs are cheap enough.

One of the thoughts I had along the lines of Open DACs are using the Arduino platform to make one. We could do an 8bit XYRGB one with the Arduino platform... All it would need is a snap on board with DAC's, power and opamps for outputs. The platform itself is around $35 with USB to serial converter. The top speed would be around 30kpps output ...

How about that?

An Open API would be good. I have been working on one and that is why I had asked. I think even though there are nice proprietary ones out there... have one API that works with the DAC you have (or I have) so we all can use the nice software that we all make. Instead of being locked in to one DAC (don't worry we aren't NAZIs ... you can still code for a specific DAC)... I would really like to use some of Zoof's or Mikes applications with my equiptment. Should we start a new thread for the API?

[mixedgas]

8 bits on x and y is a waste of time. Any rotate you do is going to fall off to 4 or 6 bits, unless you do external analog multiplication a La Pango, and by the time you do that, you can do 12 bits.

Modern standards are higher, 8 bit is so 1990s and the sound card blows that away and is readily available, and show editors are already available.

If you want 8 bits, for 50$ you can get a amiga emulator running LSD1000 freeware and have scripting, editing and hotkeys off a sound card and its the 1995 version of pangolin, with loss free rotations.

Hobbyist graphics generation software is already sopisticated enough that 8 bits is step backwards.

Steve

[heroic]

How about 8 bit XYRGB? It works decently and the DACs are cheap enough.

One of the thoughts I had along the lines of Open DACs are using the Arduino platform to make one. We could do an 8bit XYRGB one with the Arduino platform... All it would need is a snap on board with DAC's, power and opamps for outputs. The platform itself is around $35 with USB to serial converter. The top speed would be around 30kpps output ...

I have a board design for this using the MCP4921 SPI DACs. They're 12 bit.

I think if I were going to design a microcontroller board for doing this kind of thing I'd actually use one of the Atmel SAM9 processors. They have an ARM926EJ in them, which is a better architecture than Propeller, and far faster than either Propeller or AVR.

-J.

[keeperx]

is something like this not fast enough?
http://www.atmel.com/dyn/resources/p...ents/7710S.pdf
are PICs just too slow?

[mixedgas]

More like a ATMEGA168, and its been done before. Already works, is 12 bit and in the public domain.

http://elm-chan.org/works/vlp/ldpctl2.jpeg

Please note your average hobbyist cannot solder to a SOP package like that, he has years of practice.
Parts cost is ~ 40 dollars for a one off, minus board.

I already bought the parts and a mega168 protoboard from olimex, but that got diverted to another project.

http://elm-chan.org/works/vlp/report_e.html

Steve

[cfavreau]

Not to form an arguement... but what would be the goal we are trying to reach. I think there were some valid points brought up.

1) Hobbiests aren't guaranteed to have a really huge skill set. So the construction and programming would need to be simple.

2) There are a few sub $300 boards that do really well that hobbiest would be better of buying if... the open dac was close in features.

3) The tools for the ARM processors are expensive or quite limited. The documentation and support is also difficult to do. The complication of the program would be more.

So what would goal of the DAC be?

A open general experimentation platform?

An open point output device?

An open commercial DAC replacement?

With an AVR and 8 bit parallel DACs all the parts will be close to through hole... with an Arduino ... all the parts can be through hole. The programming environment is free. There is a ton of support for it. There are many Arduino boards to choose from. It is mostly open. There is no special programming equipment required. All we would need is a Laser DAC shield. I think that would certainly fill the shoes of the parallel port DAC in the USB world we now live in.

An SPI DAC could be used with an AVR or PIC however it would be limited to a frame buffer/streaming device like the sound cards and not be capable of much more and the speed of the SPI would be approaching the limits of the processor ... parallel would be much more practical.

And the final point being..

I don't think anyone would say no to a design that materialzied and I think we all would be willing to help on such a project if it was kept open. One us just has to step forward with the design... which I think a few of us have, just not with the whole picture.

[heroic]

is something like this not fast enough?
http://www.atmel.com/dyn/resources/p...ents/7710S.pdf
are PICs just too slow?

Atmel does not make PICs. They make 8051s for legacy apps and AVRs (which include the delightful ATmega chips) for anything halfway new. While these are nice, fast processors, they don't have a lot of RAM, which makes doing much with laser frames a challenge. The limit on my design is a few hundred points per frame, which makes me sad. On the other hand, it has about $40 worth of parts, total...

The SAM9 chips are a little more irritating to program (there are free tools and compilers, but they're not as easy to use or as well integrated as the stuff for AVR) but they are about eighty times faster and have up to 256 kbytes of on-die RAM, which makes this stuff a lot easier to do. The ARM926EJ has a 32-bit ALU with same-cycle shift and arithmetic, which makes scaling and such very very easy and fast. The AVR's 8-bit ALU takes many, many cycles to do a 16x16 multiply...

-J.

[cfavreau]

Why do we need a frame buffer? I think it is practical that if enough buffer space were given we could transfer the frames in smaller chunks like the sound cards do. The frame buffer just adds expense and added complication.

Yes I know Atmel does not make PICs... my comparision was just in capabilties, speed, and programmability.

[keeperx]

thats a good question.

a frame buffer + API = cross platform computability for starters. you can push frames of data to the buffer while ensuring that the data is going to be correct no matter what system your on.

the sound card dac uses WAV files which are already standardized, and streamed, but if your going to push some other kind of data, you want to be sure its correct. you could even check a frame thats in the buffer for proper format before displaying it.

The framebuffer will be a generic interface that will be the same on all systems. you will always be accessing a frame from the buffer so there is never an issue as to where the frame is coming from. the software needs to know nothing about the low level interface, just how to get data to the buffer