I'd be happy to support your DAC. In fact, I will try to support any DAC that anyone has as long as they let me know what it is and can provide me with an API or give enough info for me to figure it out.
Printable View
I'd be happy to support your DAC. In fact, I will try to support any DAC that anyone has as long as they let me know what it is and can provide me with an API or give enough info for me to figure it out.
Based on those information found here I have made the hardware of this USB DAC. It works well with the test application and also controls the analog outputs well.Quote:
Originally Posted by carmangary
I'd like to drive it using a laser-show software but I need a driver for this. Unfortunatelly, I am not familiar with programing PC to make the driver.
Could anyone help me in making the PC driver?
I would be pleased to have driver to the Spaghetti or Mamba programs, for example.
Any question how to make the DAC hardware, I am realy willing to help.
You use the drivers that came with the sound card, Laserboy and Spaghetti outputs 5.1 wavefiles that you play with your soundcard. Spaghetti can output the waves in realtime and I used windows media player to play Lasertboy waves.
I have not tried the latest versions of these programs, some new developments may have been made.
I would be pleased to have driver to the Spaghetti or Mamba programs, for example.
Any question how to make the DAC hardware, I am realy willing to help.[/quote]
Carmongary has been cluebyfoured for his behavior, which means you'll have to find his sphegetti support elsewhere on the net, I've heard rumors of a yahoo group.
Sorry for the bad news.
Steve
You know, this is awfully similar to the thingy I've been doing with Atmel AVRs in their wonderfully hackable guise as Arduino. I'm even using the same DACs! I chose the AVRs because they're just worlds faster than the PICs and the C compilers don't completely suck.Quote:
Originally Posted by Paul_B
My project is actually doing closed-loop light output regulation, but even so there are many similarities. I'd post a picture of my lashup prototype board but it's rather embarrassing (there are lots, and lots, and LOTS of wires involved).
Quote:
Originally Posted by heroic
I've been using them for USB data gathering for a controls project, and just got a high level basic compiler for them for doing lcd interface stuff. Wonderful chip the AVR.
Steve
MY DAC:
Awesome, it makes me want to make one! Too bad we don't have a PCB or a Kit (not my skillset).Quote:
Originally Posted by pepe33
-Adam
I am interested in this project as well. Is there any documentation or description about it to share?Quote:
Originally Posted by heroic
Quote:
Originally Posted by sugeek
If you need a PCB or a Kit contact me privatelly. I can make one for you.
Is there anybody wou can help me to make a driver for Mamba?
I think I can help with a driver.
Quote:
Originally Posted by cfavreau
Quote:
Originally Posted by cfavreau
Chris, This technology has been superceeded. search for soundcard dac
zoofscope, lazymame, laserboy, zooftennis. Off site search for spehgetti laser software.
Download LFIPLAYER from sourceforge
We now do a lot of this stuff on a 6 or 8 channel USB sound card that costs 25-40$ and a level shifter
This model is known to work:
http://cgi.ebay.com/USB-6-Channel-5-...QQcmdZViewItem
You can also PM drlava about his ezauddac driver, since renamed.
Drlava can also tell you about more freeware and commercial software that works with the soundcard dacs.
More data can be found at laserboy forumns on laserboy but that place can be surreal.
Steve
I could help with a driver.. the reason I hadn't spent a lot more time on this DAC project was that I didn't feel that the microchip mcu had much speed headroom to do more interesting things with. Although I have done development with microchip in the past, clock for clock the atmel series just has more power. Anyways if there is still interest in continuing with the microchip based DAC, a MLD or similar driver interface would definitely be doable.
We (Aijii and myself) may be interested in looking into a AVR based solution. The driver would be the catch for us tho, so maybe we could work something here ;)
Two years ago I did the parts selection and schematic design for a USB-powered DAC based on Philips LPC2148:
http://www.photonlexicon.com/forums/...ead.php?t=3210
However, I never completed the software design (the biggest part of the project), it was easier to make a sound card DAC instead:
http://www.photonlexicon.com/forums/...ead.php?t=6595
I chose 32-bit ARM because I planned to include some simple signal processing and pattern generation in the DAC for music-synchronized visuals without a PC. Since the time of that design, Atmel have brought out AT91SAM7 which makes Philips LPC21XX very ugly by comparison. Also, now there 8-bit AVR parts available with on-chip full-speed USB peripheral - for a simple framebuffer DAC, this is probably enough.
I would strongly recommend against writing a Windows driver. Instead, I suggest designing the firmware so that it can be interfaced using libusb. Then it is easy for any application to address it from Windows (http://libusb-win32.sourceforge.net/) or Linux (http://libusb.sourceforge.net/) without having to write or maintain any drivers. I think it is very important to avoid WDM altogether, because it will take more time than the rest of your project combined!
Another alternative is to use some USB chip with manufacturer-provided drivers, e.g. FTDI. However, the hardware is simpler and cheaper and the software interface is cleaner if you choose an MPU with in-built USB peripheral and interface with libusb.
Best regards,
weartronics
Ok here are 3 questions:
1) Is there still a need for an "Open" USB DAC?
2) Is this it? Is this an Open project? Or is there still a need.
3) Is there still a need for an Open API? Some say yes. Some say no. Should I start a thread for that?
A couple of comments. While the LPC chips are nice and fast their development environment and documentation are not great for the hobbiest. They certainly will do the job. I really like the AVR chips however they have the same overhead issue that the PICs have. I have been looking at the Propellor from Parallax. It is 20 MIPs but 8 cpu's in 1 and has a bit of RAM on board. It is also a 32 bit processor(s). And the dev tools are free and there is alot of support for it. Any comments?
If you want AVR... I would suggest one of the FTDI chips (the 245 being the better one for the task) and an AVR or Propellor.
And for the kicker... we could have 2 versions... a PIC version and an AVR version... they are relatively similar in features and should be able to do the job equally well.
Also what is wrong with the Audio DAC stuff?
Chris F.
Also one more comment I have.
Being a Laser Hobbiest with a job, I don't have a great deal of time to work on stuff. I really just want to make shows or play... not make tools.
So I think the question would be what is our time best spent on? I think the parallel port DAC did great things for the community... and it is time to create a replacement. Chances are we already have done something that works well and would be good enough to use for everyone. The problem is... once you venture from soldering up a couple of chips to a port on a computer then you get into a territory not all of us can do.
i believe there is still a need for both an OPEN dac and an OPEN api for that dac.
the sound card is a wonderful thing, but its not perfect.
an open dac with some actual processing power and a frame buffer would be hella cool.
an API that allowed easy incorporation into popular open or free software packages like Spaghetti, LFI player etc etc., or even into commercial players, would also very nice..
I however am not a developer or an electronics guy, but im infamous as a beta tester..
Since RIYA are down to 200$, why reinvent the wheel.
Steve
well thats true.. but its nice to have it out there for someone that wants to build it themselves...
as it stands the API is what would be nice..
I guess you are correct about the riya, but with lasers/projectors becoming more and more common, and nice open source dac and API are inevitable.
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
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?
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
I have a board design for this using the MCP4921 SPI DACs. They're 12 bit.Quote:
Originally Posted by cfavreau
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.
is something like this not fast enough?
http://www.atmel.com/dyn/resources/p...ents/7710S.pdf
are PICs just too slow?
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
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.
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...Quote:
Originally Posted by keeperx
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.
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.
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
Quote:
Originally Posted by cfavreau
even the USB sound card chip has a buffer.
Keep in mind, people who buy low end scanners often need to tune their scanners out of the box, thus, you need to do the ILDA test pattern at 12 bits and a smooth 30K.
Also you have no control over the windows timing, its not 100% synchronous, even though the USb spec says its pretty good.
Steve
thats another great point.. if your frame is not updated in time, and its time to scan another frame, you can just replay the frame thats in the buffer..
I think that would be the only point. The sound card based DACs do have the problem of if things get too busy they repeat their buffer... albeit not a large buffer. A frame buffer less unit could and should do the same.
The USB sound cards don't have a full frame buffer though. Which is my point. In a cheaper DIY situation I think the frame buffer adds expense and complication I think. It can be done to work as well as the sound cards I think. You do have some control over windows timing. It isn't as bad as everyone makes it out to be.
There is no operating except the real time operating systems that you have 100% control over the timing which I guess is the point.
So I guess 12 bits is the minimum for XY and 8 bits for RGB? 8 bits are no good?
I am not sure I get the comment about the 12 bit and smooth 30k ... not everyone has 30kpps scanners... and you can use 8 bits quite effectively to tune your scanners... Are you suggesting a built in test pattern? Anyone can hook it up to a computer to play any test pattern they want... Smooth... yes it needs to be smooth and consistant, whatever speed it is set for.
One more question I guess:
Do people use a constant point output speed or do they vary it from frame to frame? 12kpps or 30kpps fixed output speed is easy to do. Varying the output speed is not as easy to do.
What about 10 bit for XY?
Alot of the frame buffer you can handle in software on the PC.
Given that 30k scanners are so cheap now it seems pretty pointless to cripple the design from the beginning.Quote:
Originally Posted by cfavreau
Here's my SPI DAC board. I used the single-DAC chips so that you could populate as many or as few channels as you need. This will connect to an Arduino or any other microcontroller that has SPI.
The extra space on the board is for the analogue correction amps which I intend to do using one of those digital potentiometer chips.
Chris wrote:
So I guess 12 bits is the minimum for XY and 8 bits for RGB? 8 bits are no good?
12 bits is OK, but 12 bit chips are usually more expensive then 16 bit these days.
Please do not even think of 8 bit XY, it is a waste of time, Norms gets shot down frequently around here for low resolution. At least 8 bits for rgb, NO TTL either.
I am not sure I get the comment about the 12 bit and smooth 30k ... not everyone has 30kpps scanners... and you can use 8 bits quite effectively to tune your scanners... Are you suggesting a built in test pattern?
No, I'm suggesting doing it right.
Look the ILDA test pattern is the standard, it is not scanned exactly right by sound card dacs, its a bit undersampled. There is a purpose for the standard, and many of us are trying to make things better by encouraging the use of the standard.
We have had many people with low end systems who have had to send galvos out for tuning because of poor QC, one axis off, flakey mirror sizes etc. And no way to tune on their own. The ILDA circle in the square does not work properly when truncated to 8. Most scanners today are 30K and getting cheaper., the difference between the so called 20K and basic 30 K is less then 75$, and often less then that. ILDA formats are +32768 to -32769, truncating to 255 x 255 or 1024 by 1024 looses points and is a TOY.
Also many of us are tired of people going cheap, the laser industry is flooded with nonstandard junk, and we get a lot of first time posters saying I bought a CHIN NE MODEL 666, with 8 bit dmx controled graphics, and its pretty useless, how do I upgrade.
We also hear a lot from people who are tired of seeing stuff on youtube that is aweful from the artistic point of view.
So why take a step backwards to crude, when it is no more work to do it right, There is a lot of good artware out there now that demands 24-30K, heck must stuff now flickers unless you run 30K. Images push 700 to 1100 points per frame.
And if a buffer is 10$ worth of parts, its worth it.
Chris, it seems you want to take everyone back to 8 bit 20K open loop. That doesn't cut it these days. You should come to SELEM and see what even a low end system does these days.
Not everybody is a 100% cheapskate, and your not going to get enough user volume if you just target the ultra low end.
And yes, we now push for constant point velocity at 30K for graphics and 22-24 K for beams, to fully take advantage of newer, low cost, scanner technologies and optimization software. We have packages now that render out of 3D studio max, and I'm sure 90% of the stuff on the PL graphics FTP site is 30K PPS, 16 bit oriented material
Steve
Well I am not here to take everyone back to the stone age. I am more of trying to fish out what every one thinks is a good bottom line to take. It is good to know why something is and not just that it is. So please don't take my posts wrong.
If 12 bits for XY plus 8 bits for RGB is what it is ... good. Now that we got that out of the way. 30 kpps flat... so you either go 30 kpps or 15k pps (or some multiple there of) if you really want to. I do not want to stray from a standard... one thing the hobby community can use are standards... so we aren't wasting our energy all over the place.
I have a set of 30 kpps scanners myself and a set of 12 kpps scanners.
I am trying to go with the title of the thread here: "Open Source/Freeware Budget USB DAC".
So with that in mind I think we can keep the cost of parts and labor if someone were to sell a kit or something ... to below $100. Depending on the rest of the parts maybe below $75 or lower. I think that would be good value. Maybe even $60 if you leave off some parts like an external power supply.
How bout any other outputs like a shutter?
A full frame buffer is not absolutely necessary, but it is nice under high system load, the buffer underrun effects would not be as visible.
In my development of ILD SOS optimization software, one thing I have found is that, contrary to what you might expect, having more control points at a rate higher than your scanners improves their maximum performance. So if we are going to try to construct this from the ground up, I suggest a max point rate of at least 60k. Also, as Mixedgas said, 8 bit x and y is wasting your time, we should really shoot for 16 bit. For modulation, 8 bit is O.K.
But, also as has been stated, with RIYA dacs available at an inexpensive rate, and given that the sound card DAC fills the low end, consider carefully your goals and market size before jumping in.
How bout any other outputs like a shutter?[/QUOTE]
BADLY NEEDED, as are 4 to 8 beamtable outputs.
Oh, and these days its RGBV, the 405 diodes have invaded, and we also use dichros to blend in 633 with 650-660 nm diodes.
also galvos ship these days wired for full diff two wire inputs, so add one more dual opamp. Its Ok to leave off the PSUs, or to find a regulator that can take 30V inputs from the galvo power supplies. You've got 5V from the USB, and a AC wallwart and a couple diodes can provide the rest, or use 3 2n2222s as a oscillator/driver and make your v- with a voltage multiplier. Lexel gets -20 and -15 for their laser power supplies that way. Also, the atmels can take some overclocking. GCC is probably the micro language of choice, but assembler is going to give you more speed. Another trick would be to vary Vref on the dac chips, to change image size.
Steve
One more thing. If you get too close to the $200 mark what is the point. I would say the majority of us want to play with our lasers and not have to build everything. Building does give satisfaction but there is a line. Please correct me if I am wrong.
absolutely! it's under $130 or bust :)
Ok so we are up to:
(Updated at full speed)
X - 12 bit
Y - 12 bit
RGB - 8 bit (can change the B to a V in software)
(Updated not as fast as 60 kpps)
1 Shutter Output
7 TTL Outputs for Misc.
60 kpps constant? Can adjust in software by doing multiples of points or add software control point (point pulling algorithms) to reduce the speed seen by the scanners.
No frame buffer.
$100 target cost.
How is that for a spec list?
With a FT232R the limit is 3 Mbps... 60 would not be possible with that. You would need around 4.32 Mbps. 30 kpps is possible for that 2.4 Mbps.
Bit Rate = ((12 * 2) + (8 * 3) + 8) * PPS
If we go with a straight USB micro ... we leave out a lot of hobby folks with the programming and understanding of it. It also makes the boot loader more difficult and such too.
Does anyone have any really big objections to a 30kpps limit?
Dont use maxims unobtainium parts and NO PWM dacing.Quote:
Originally Posted by cfavreau
Steve
Good advice.
The design so far is a spec list. We can add no maxim parts and no PWM for analog out to that list too.
I was not thinking of using either.
Never mind about the 30 kpps limits of the USB chip.
What is everyone's opinion on 30k vs 60k pps. Keep in mind Budget System. Also keep in mind that maybe once it is up and running and we can play with it it maybe able to do 60 kpps if the right parts and pieces are picked.
The point output rate adjustability is dertermined by the architecture of the micro and USB interface.
Fail. We need both a B and a V. Why not just use the same DACs for X, Y, R, G, B and V? That way those suitably inclined can use the spare channel if they have one as a Z or whatever.Quote:
Originally Posted by cfavreau
We should also have an accessible I2C output from the micro that people can hook beam table actuators to. Simple PCF chip or two.
The limits of the USB chip need not be prohibitive if we use a little compression (like, for example, RLL or even a simple Huffman thing) on the link. This need not stop people from programming it themselves if we provide our code as a library (preferably with source, so they can modify and improve it).
If we use something like an ATmega644 that gets us 4 kbytes of RAM, which is plenty to have a small framebuffer.
-J.
Why the Violet channel ... does the standard projector have RGB and V or just RGB or RGV? I only have 3 lasers (PCAOM's excluded of course). I have seen quite a few others that only use 3. Steve is probably right about the Quad DAC being the same price... Just trying to keep it simple though. The more data you have per point, the more memory you need and the more bandwidth you need to transfer it. Just trying to keep that stuff in check too.
An ATMega644 is definitely high on the list for a choice. 20 MHz ~ 20 MIPS. Lots of pins and 4k of RAM. If a FT245R is used instead we have up to 8 Mbps... which should be Ok even for RGBV. Although right now it is best to keep it to a specs list. I bet someone else already has something that will fit the bill designed.
Not sure about the I2C... Anyone else want to chime in? I think good old TTL will work well and fit most people's projector. Good idea though... worth exploring.
An increasing number of people are going RGBV. It gets you a much wider gamut than RGB and far better colours than RGV.Quote:
Originally Posted by cfavreau
There is a difference between data and information; a simple entropy coding scheme will reduce the data while keeping the information.Quote:
The more data you have per point, the more memory you need and the more bandwidth you need to transfer it. Just trying to keep that stuff in check too.
It's called SanguinoQuote:
An ATMega644 is definitely high on the list for a choice. 20 MHz ~ 20 MIPS. Lots of pins and 4k of RAM. If a FT245R is used instead we have up to 8 Mbps... which should be Ok even for RGBV. Although right now it is best to keep it to a specs list. I bet someone else already has something that will fit the bill designed.
I want both :-)Quote:
Not sure about the I2C... Anyone else want to chime in? I think good old TTL will work well and fit most people's projector. Good idea though... worth exploring.
No on the 60 (or max) kpps constant. While it's possible to get close to a target point rate by doing point repeats (such as I do with the audio DAC), why do it if you don't have to? The mcu can clock the points out at almost any arbitrary rate, so let's take advantage of that.
Speaking of clocking out points at a fixed rate, consider that the point output timer interrupt should have highest priority for low jitter but at the same time we don't want its timing requirements to interfere with USB communications. The ftdi chip would probably allow this, but it's not clear to me if internal usb control would.
60 kpps max output rate - variable (from 1kpps to 60kpps)?
So these specs pretty much limit us to the FT245R (the parallel version). Max output rate 60kpps. Internal USB maybe... would have to do experiments to see if it can work.
Does any one have any experience with working with micros (specifically the AT90USB family) to know if we can do USB and have a 60,000 time per second interrupt go off with no interruptions?
We have exactly 16.66666666 microseconds to do the point output and do other stuff too. Obviously other stuff can be split up between points if need be... but we essentially have to transfer and output 8 bytes in 16 us (round down for overhead). At 20 MHz instruction clock rate we have 320 instructions max to do so.
Not to worry about the hardware yet though... have to nail down the specs.
So summary:
USB Interface
60 kpps max output rate (1 to 60 kpps variable)
12 bit X/Y
8 bit RGB(V to be determined)
8 bit TTL (including shutter)
If we don't use the serial port we can throw in DMX too...