How to wire a USB to DMX

[Meduza]

I saw on this DMX creator basic or chauvet.. they have that

 

http://www.dmx512.ch/creator512basic.htm

 

And they are taking EUR 750.00 + VAT for it!

[DJ Dicky]

I saw on this DMX creator basic or chauvet.. they have that

 

http://www.dmx512.ch/creator512basic.htm

 

And they are taking EUR 750.00 + VAT for it!

 

A bit higher that the EUR 75.00 inclusive for ours. I wonder if they sell any?

[tuxlux]

packet refresh rates as fast as the spec allows, or practical data update rates from applications much above about 15-17 Hz"

surely its shouldn't be beyond any USB design to get a datarate of at least 250kbps with a maximum of 12/400+Mbps there's still plenty of room for overhead? As long a the program keeps the output buffer full, then sending data out to a device much faster than that isn't difficult. It then becomes can people write good control software?....which I'm sure someone else mentioned, but from a userbilty point! :D

[Tomo]

I saw on this DMX creator basic or chauvet.. they have that

 

http://www.dmx512.ch/creator512basic.htm

And they are taking EUR 750.00 + VAT for it!

Bleedin' heck! A HogPC dongle is only slightly more than that, and I know for certain which I'd buy...

 

Come here little flying piggy...

 

packet refresh rates as fast as the spec allows, or practical data update rates from applications much above about 15-17 Hz"

surely its shouldn't be beyond any USB design to get a datarate of at least 250kbps with a maximum of 12/400+Mbps there's still plenty of room for overhead?

Not the issue.

The issue is that USB is not a real-time communication protocol (neither is Firewire, although it's better due to packet timestamping), so if you want to do perfect framing and packetry then you have to generate the timings in the dongle itself, as ben.suffolk's unit does.

 

This makes the drivers and software much, much easier to write as well as all you have to do is send "channel x is now at y" type commands to the dongle, and let it deal with framing etc.

Update latency is still an issue, and it always is, even inside 'proper' consoles - the WholeHog 2 had known issues with update rate if there were too many effects running together - but framing can now be guaranteed.

 

This makes the dongle hardware more expensive though, as you need enough RAM to store the whole universe (or many universes...)

 

I suspect that Dj Dicky's unit is based on an FTDI USB->serial chip, although it's apparently not as simple as the OpenUSB interface.

(And getting an FTDI IC to respond with a custom device ID is extremely simple, btw)

[bruce]

Well, there was another post recently that said it was based on FDDI. But I guess that was a typo :D

 

Bruce (who discovered a pile of FDDI boards today, and spent a short time reminiscing about MIC connectors (A,B,M and S) before chucking the lot in the skip....)

[jfitzpat]

packet refresh rates as fast as the spec allows, or practical data update rates from applications much above about 15-17 Hz"

surely its shouldn't be beyond any USB design to get a datarate of at least 250kbps with a maximum of 12/400+Mbps there's still plenty of room for overhead? As long a the program keeps the output buffer full, then sending data out to a device much faster than that isn't difficult. It then becomes can people write good control software?....which I'm sure someone else mentioned, but from a userbilty point! :D

 

No, the issue is two fold. First, what work is done where. Example: if you are trying to enforce the narrow MAB portion of the packet in your foreground application, output is going to be slow and CPU overhead relatively high. Second, how is the USB transfer itself handled?

 

Using Bulk transfer USB 1.1 is, in practical terms, an 8 Mbit link. But many, many peripherals and drivers do not get close to this (it is a small block ack/nack type protocol so either side can easily constrain bandwidth). Also, latency can be amazingly high without some effort on both sides (driver and peripheral). Remember, deep buffers are great for keeping a pipe working at max efficiency, but also immediately become end-to-end latency.

 

Is the pipe big enough? Certainly, we comfortably do 16 universes, updating at a rate at or above top end consoles. But no matter how much effort DJ, Enttec, or anyone else puts into it, the problem with this approach is that low level protocol management is not where it needs to be for best possible performance. It is seperated from the output by a typically async com link (USB) and inheriting the latencies and burst behaviors of a non RTOS.

 

-jjf

[tuxlux]

surely its shouldn't be beyond any USB design to get a datarate of at least 250kbps with a maximum of 12/400+Mbps there's still plenty of room for overhead?

Not the issue.

The issue is that USB is not a real-time communication protocol (neither is Firewire, although it's better due to packet timestamping), so if you want to do perfect framing and packetry then you have to generate the timings in the dongle itself, as ben.suffolk's unit does.

Ah, sorry, misunderstanding I wasn't realising it was using the PC to generate the DMX packets....seems a less than ideal way to me. I'm not sure I can think of why anyone would do it that way.

 

I was suggesting that as long as an entire universe could get transfered to the dongle in about 250ms (which should be possible with USB), then it would be no worst than DMX at worst case for timing constraints/meeting deadlines. I'd expect the 'cheap control software' people use with the cheap hardware wouldn't be highly responsive either, and have various delays in it too!

 

To me there is no excuse for sending bad DMX. Slightly slow transfers for the time it takes to kick a completely new universe, excusable for "it's cheap", but not failing to meet the spec.

[jfitzpat]

I was suggesting that as long as an entire universe could get transfered to the dongle in about 250ms (which should be possible with USB), then it would be no worst than DMX at worst case for timing constraints/meeting deadlines. I'd expect the 'cheap control software' people use with the cheap hardware wouldn't be highly responsive either, and have various delays in it too!

 

250 mS (4 Hz) would be much to slow to do even basic dimmer fading. The human eye readily sees 10-12 Hz or less as 'jerky'. The 'cheap' stuff updates about 12-17 times per second. A good desk updates 24 times per second. We update 30 times per second because it gives us smoother movement generation and fades on video servers.

 

USB bandwidth is not the problem. Good drivers and peripherals can move up to a meg a second. A universe is 512 bytes. 16 universes is 8K bytes, and 30 Hz brings things up to 240K, or about 1/4 the bandwidth available.

 

Cheap consoles are generally pretty responsive and often send packets dramatically faster than the 'Open DMX' (and like) interfaces can. For example, I've got a Chinese 24x2 board here (< $200) that spits out DMX packets hundreds of times faster than a serial interface chip based USB dongle. Like us, they send packets as fast as the standard allows for the channels in use (this is good because of the lack of error checking, but I've discussed that in the past). The data update rate (how fast the faders are scanned) appears to be about 18 Hz, only a little faster than most the freeware, but there aren't any bad packets from time to time either.

 

-jjf

[tuxlux]

250 mS (4 Hz) would be much to slow to do even basic dimmer fading.

cough, 25ms even (ie more like 44Hz). 250ms is far too slow! :) insert brain. But I think we're actually saying the same thing. And how many people with cheap interfaces will need a full universe ?

[jfitzpat]

250 mS (4 Hz) would be much to slow to do even basic dimmer fading.

cough, 25ms even (ie more like 44Hz). 250ms is far too slow! :) insert brain. But I think we're actually saying the same thing. And how many people with cheap interfaces will need a full universe ?

 

But as the channel count goes down, the packet rate goes up. If you use just 32 channels on a universe, we'll send the DMX packets as fast as the standard allows (several hundred Hz), but we'll still only put new data in the packets 30 timers per second. This gives best responsiveness and the shortest 'hold time' for transmission (line) bit errors. We've got some laser and pyro users who specifically use a small number of channels at the beginning of a universe to achieve this.

 

About 40 Hz is as fast as the serial chip based solutions can generate packets of any length. So they might as well send all 512 channels, since they are only a little slower than the spec at that point, but much slower than the spec with smaller channel counts. Rather or not the apps using the cheap dongles can generate data to fill 512 channels at a reasonable rate is another story.

 

-jjf

[dbuckley]

The interface I use and its software are parallel port linked, and it does 40Hz irrespective of number of channels.

 

JJF: If you update the date at 40Hz why do you send it out the interface any faster? I know its legal, but the world is full of broken DMX receivers that seem to have problems if the gap between breaks is significantly shorter than "normal", normal being the 44Hz rate...? Where does the benefit accrue?