Open Source/Freeware Budget USB DAC

[j4cbo]

The word "frame" means a bunch of different things, and it's confusing.

A "frame-based" laser interface, to me, means that the basic interface function has these semantics: "Here is a list of points to be scanned. Run this data repetitively until a new list of points is sent, or until it has been repeated n times; if the count expires, then an underrun has happened, so stop the lasers."

This is a pretty common sort of API, but it's unnecessarily complicated. A laser "frame" is a list of points that traces out a desired image once, like a frame in an animation. The number of points in the frame depends on how complex and how accurately rendered it is. If one repeats a frame continuously, then the frame rate - the frequency at which it repeats - will depend on the rate at which points are scanned and on the number of points in the frame. A complicated frame will thus be "more flickery". But people are used to frame rates being fixed, as they are in film and TV, and animators like to think that way too, which means that having a different number of "points" in each "frame" is totally wrong from an animation point of view. A frame is just an arbitrarily-chosen set of points, and to play those points back at a constant frame rate requires that each frame be the same size.

But a high-quality piece of laser output hardware should be able to produce output continuously, and in that case, there is no need to make the set of points passed at once to the device be the same as the set of points that form one complete picture in an animation. Unless the "repeat this data until I give you more" functionality is used, which it shouldn't be (as I'll get to later), there's no reason why "frames" can't be chopped up and sent in multiple API calls, or combined with multiple frames sent at once.

Now, the alternative to that is to instead have an API that looks like this: "Here is a list of points to be scanned. Add this data to your playback buffer. If the buffer runs out, stop the lasers." This is a lot simpler, it makes better use of buffer capacity, it produces the same output in the no-repeating-frames case, and it does not promulgate the unfortunate myth that the galvos or DAC or any actual hardware knows or cares when one image turns into another.

(And, actually, procedural abstracts as in DigiSynth and LSX look so damn good because there is no point in time where one image turns into the next - the pattern evolves as it is being drawn.)

There's one important difference between a "streaming" protocol and a "frame-based" protocol that's important, and that has to do with what happens if there's a problem - if connectivity to the DAC drops, or the software crashes/glitches, or some such thing goes wrong. A frame-based DAC thinks it knows what one "frame" is, and so it has the option of repeating that frame until the glitch goes away. But this should not be used, because (a) an animation freezing doesn't look any better than the animation vanishing, and (b) it's unsafe.

Whether a DAC interface works in one of those two ways has nothing to do with "framing" in the protocol it uses underneath. My Ether Dream DAC protocol involves sending simple commands over TCP/IP, like "start playback", "stop playback", "here are 50 points to add to the buffer", etc. How those commands are divided up needs not correspond at all with which points are part of which image in an animation, or with which bytes happen to be sent as part of which TCP/IP packet or Ethernet frame.

Sound cards aren't built around the idea that you send them one beat at a time or one measure at a time. Laser DACs shouldn't work in the analogous way either.

[Stoney3K]

Sound cards aren't built around the idea that you send them one beat at a time or one measure at a time. Laser DACs shouldn't work in the analogous way either.

Yet we're using Ethernet (or even worse, TCP and IP!) as the underlying medium to transmit our data. Here's what I see is wrong with that:

Ethernet requires your data to be sent in discrete chunks (in Ethernet terminology, these are also called 'Frames'), which means, there will always be some way you need to chop up your continous stream of (X, Y, R, G, B) data sets and send them in a bunch. After all, if you were to send these small pieces of data by themselves (48 bits, in this case) the network would be instantly flooded by a huge stream of overhead with bits of data stuck in between. Not very efficient.

Now if you use TCP, yes, you can send a continuous stream of data, at the expense of having no guarantee on the data's timing and latency. Which is not a big problem if you were to send one frame (discrete set of points composing an image to be displayed) at a time, but it may be a big problem if you want to send a continous, uninterrupted stream of data which has no concept of 'frames' in the display sense.

Hence my opinion on the fact that Ethernet may even be one of the worst protocols we can choose for transmitting laser images to a stage. If some part of the chain fails and a packet gets lost (or the network inadvertedly gets connected to a bigger LAN, you know how roadies work), there will be a big interruption in your image data, meaning a disrupted show or even unsafe behavior.

There are a few ways to get around it. If you look at digital stage snake systems built by the large audio manufacturers, these use a very high speed Ethernet connection (mostly Gigabit over polymer fibre) which allows them to send all of the audio data redundantly and at such a rate where they have plenty of headroom if something goes wrong. If a packet gets lost and the receving end senses there may be an audio drop-out, there is enough time to request a fresh packet with the same time stamp.

http://en.wikipedia.org/wiki/Audio_over_Ethernet

It may be good idea to borrow some of the ideas (or even implement an AES50-compliant laser transmission/reception system) to have some degree of control over the latency and reliability. However, it's out of the 'hobbyist' domain with through hole components and DIP microcontrollers, and more into the professional DSP domain here.

Alternatively, it may be an option to depart from Ethernet altogether and use a system designed from scratch. The only reason we're using Ethernet is because it allows us to link all of the projectors together with simple, cheap UTP CAT5e cables, however, these cables do not demand you use them for Ethernet. They're simply 4-pair twisted conductor cables with an 8P8C plug on each end, so there is no reason why you couldn't use them for something (maybe even completely) different.

My suggestion would be to use a synchronous system instead which sends a word clock signal together with a sample data stream on one pair, and a stream of control data on another. You'd then have a pair of wires left for safety-related (e.g. emergency stop) features if you don't implement them digitally.

[j4cbo]

Now if you use TCP, yes, you can send a continuous stream of data, at the expense of having no guarantee on the data's timing and latency. Which is not a big problem if you were to send one frame (discrete set of points composing an image to be displayed) at a time, but it may be a big problem if you want to send a continous, uninterrupted stream of data which has no concept of 'frames' in the display sense.

Hence my opinion on the fact that Ethernet may even be one of the worst protocols we can choose for transmitting laser images to a stage. If some part of the chain fails and a packet gets lost (or the network inadvertedly gets connected to a bigger LAN, you know how roadies work), there will be a big interruption in your image data, meaning a disrupted show or even unsafe behavior.

There are a few ways to get around it. If you look at digital stage snake systems built by the large audio manufacturers, these use a very high speed Ethernet connection (mostly Gigabit over polymer fibre) which allows them to send all of the audio data redundantly and at such a rate where they have plenty of headroom if something goes wrong. If a packet gets lost and the receving end senses there may be an audio drop-out, there is enough time to request a fresh packet with the same time stamp.

I disagree with your conclusion here:
1. There's no reason why a dropped packet should lead to "unsafe behavior".
2. TCP retransmission works just fine for this. With very careful design of how the sending application interacts with the TCP stack, it's quite possible to build a system where in the event of a dropped packet, TCP fast retransmit will kick in with plenty of time left to avoid depleting the buffer on the DAC - I'm using 60ms, but lower is possible. This is done with 100 Mbps Ethernet and a 96 MHz ARM; not DIPs and through-hole, but not big DSPs and GigE either. (I soldered the first prototypes by hand, which makes it count as "hobbyist" in my book...)

[Stoney3K]

I disagree with your conclusion here:
1. There's no reason why a dropped packet should lead to "unsafe behavior".
2. TCP retransmission works just fine for this. With very careful design of how the sending application interacts with the TCP stack, it's quite possible to build a system where in the event of a dropped packet, TCP fast retransmit will kick in with plenty of time left to avoid depleting the buffer on the DAC - I'm using 60ms, but lower is possible. This is done with 100 Mbps Ethernet and a 96 MHz ARM; not DIPs and through-hole, but not big DSPs and GigE either. (I soldered the first prototypes by hand, which makes it count as "hobbyist" in my book...)

100MBps Ethernet may be able to cut it. However, the question is whether it's future proof enough, and fool-proof (as I said, if you're not the one doing the wiring, there may be some very nasty stuff down the road.)

With 'unsafe behavior', I mean an unpredictable situation with regards to the operation of your galvos or laser module, and therefore, possibly a beam being projected into the audience which exceeds (10x) MPE. Ethernet, by definition and design, is unpredictable, because it is designed around CSMA/CD media access which specifies a random packet start or end time. In contrast, if you have a fully synchronous data link (for example, 50Mbps with Clock, data, control pairs) you'd be able to determine the behavior of
your data on every possible point along the transmission path.
Doing the math here, if you have an uninterrupted point stream of 48K points per second (I'm using an audio figure here, just for the sake of argument), with 48 bits of data (12 each for X and Y, and 3 each for R, G and B), your raw data rate would be:

48 * 48000 = 2,3 Mbits per second, and the point frames will need to be spaced no further apart than 20 microseconds to keep up.
If you transmit at 100Mbit Ethernet, the data would be there in 0,48 microsecond, giving you enough headroom to tackle protocol overhead and error handling.

Now what I'm wondering about is to what extend this would scale. If you have a multi-projector show with 2 or 3 ILDA streams, it might clog up your Ethernet link pretty fast. Especially if each of the projectors are individually start requesting additional information or exchange control data.

Also, don't forget the latency between your control systems and the (in-projector) DACs because of buffering, and this may even be increased if there are Ethernet switches along the route. If you're running a synchronized show which is slaved to an audio word clock or a video Genlock, it may wreak some serious havoc on the timing.

Lastly, how are we going to tackle the (mandatory) emergency stop? I know there are some tricks out there, but they completely circumvent the Ethernet specification and most of the time are based on a passive wire loop between the projector and the remote switch, which means there are no means to daisy-chain multiple projectors to a single emergency stop switch. Actively driving the emergency stop from your front-of-house and having passive circuitry in each projector would be a lot more sensible.

[JohnYayas]

It's hard to argue that TCP isn't a good idea when there are already TCP based solutions that already exist and work very well.

[j4cbo]

With 'unsafe behavior', I mean an unpredictable situation with regards to the operation of your galvos or laser module, and therefore, possibly a beam being projected into the audience which exceeds (10x) MPE. Ethernet, by definition and design, is unpredictable, because it is designed around CSMA/CD media access which specifies a random packet start or end time. In contrast, if you have a fully synchronous data link (for example, 50Mbps with Clock, data, control pairs) you'd be able to determine the behavior of
your data on every possible point along the transmission path.

CSMA/CD does not apply here, since we're talking about switched Ethernet, not hubs. There's a very small time uncertainty in practice, yes; there's also a time uncertainty in when your computer gets the USB packet from your keyboard saying "go" in the first place...

Now what I'm wondering about is to what extend this would scale. If you have a multi-projector show with 2 or 3 ILDA streams, it might clog up your Ethernet link pretty fast. Especially if each of the projectors are individually start requesting additional information or exchange control data.

I've done it with two and it works. Yes, it doesn't scale infinitely - you can't run a hundred projectors over the same Ethernet link (actually, you *could* if broadcast/multicast were used, but that doesn't work with TCP)...

Also, don't forget the latency between your control systems and the (in-projector) DACs because of buffering, and this may even be increased if there are Ethernet switches along the route. If you're running a synchronized show which is slaved to an audio word clock or a video Genlock, it may wreak some serious havoc on the timing.

Lastly, how are we going to tackle the (mandatory) emergency stop? I know there are some tricks out there, but they completely circumvent the Ethernet specification and most of the time are based on a passive wire loop between the projector and the remote switch, which means there are no means to daisy-chain multiple projectors to a single emergency stop switch. Actively driving the emergency stop from your front-of-house and having passive circuitry in each projector would be a lot more sensible.

I agree that getting an exact time lock would be difficult; then again, there are numerous well-established protocols for time synchronization over unreliable networks (NTP and its successors), so again it's not impossible.

Emergency-stop can't be done in-band, it's true. I haven't fully investigated this, but I suspect basing the emergency stop on the presence of a valid Ethernet link would work, if the other end were suitably controlled.

[heroic]

Industrial ethernet has been running *much* more dangerous equipment over ethernet for a decade or two. Lasers don't scare me half as much as steel rolling mills do.

As for how far it scales- it scales just as far as your host machine's ethernet interface does. If you want to fill your PC with 10gigE cards, and then back it onto a large switch, you can easily run a thousand DACs off it.

[Stoney3K]

Industrial ethernet has been running *much* more dangerous equipment over ethernet for a decade or two. Lasers don't scare me half as much as steel rolling mills do.

But doesn't industrial Ethernet have a certain subset of protocols it should stick to, and also, doesn't all industrial equipment have a (separately wired) emergency stop?

I'd be very anxious to get on a plane which has flight controls that are controlled solely through an Ethernet network or walk into a nuclear power plant that has its safety critical systems wired to Ethernet.

And don't forget that steel rolling mills aren't really designed for interaction with ignorant, innocent people watching them -- there's a reason special effects like pyrotechnics would never be controlled over a network. Neither would I'd like to see someone hack a Tesla coil into network control...

TCP may not be the perfect choice here, but there are a lot of OSI Layer 3/4 protocols you could use in place of a TCP/IP stack which have different (and more useful) features. For example, you'd probably want broadcasting or multicasting to several projectors, instead of having to send identical copies of data destined for multiple projectors more than once as you'd need to do via TCP.

I'm not sure if the FDA/CDRH regulations would allow an emergency stop to be run in-band, or that they demand that is an actual hard (not even digital) wire control.

Basically the goal doesn't change: A single cheap cable coming from your host system (whether or not there's an adaptor in between, I don't care for now), running from the FOH to every projector so it can provide the infrastructure for your entire show.

[j4cbo]

I'd be very anxious to get on a plane which has flight controls that are controlled solely through an Ethernet network

Don't get on an Airbus A380, Boeing 787, or Airbus A350 (when it is finished), then. :P

[heroic]

Don't get on an Airbus A380, Boeing 787, or Airbus A350 (when it is finished), then. :P

Ethernet is only unreliable or unpredictable when it's done wrong. Modern full-duplex ethernet with a switch rather than a hub doesn't even permit collisions; the only possible source of jitter in such a system is congestion, which you can avoid by using a fast enough switch. Ethernet is available up to 10G speeds, which ought to be enough to run any conceivable laser system. And, yes, the per-packet round trip latency on such a system is measured in hundreds of nanoseconds.