Jump to content

How to wire a USB to DMX


cubiejeff

Recommended Posts

On the chauvet unit the electronics is built in to the pink 'lump'

 

On 'dicky's' unit it's built in the USB plug. He's just buying USB to Serial converters and chopping the end off.

 

Products in the pics are just direct USB to XLR or it has to connect to "dongle"

 

You CANNOT directly connect USB to DMX. There must be electronics SOMEWHERE.

Link to comment
Share on other sites

It is no mystery on how to make a "USB to roughly DMX-like output" adapter.

 

You take a USB to serial chip that can sustain the baud rate and you add a RS-485 line driver chip. With passives, it should still fit comfortably inside an XLR connector. Yes, there is a 'translator', in fact there are two. First, the device driver provided by the chip manufacturer to get their USB device into the OS's comm stack. Second, some add on software to attempt DMX framing on top of an OS comm stack.

 

The Enttec "Open DMX" initiative is based on this and I believe comes complete with a schematic. You could also 'buy' someone elses repackage of this approach.

 

The downsides of this approach are that packet generation is slow and the output is only marginally compliant with the spec. That is why the refresh rates are dramatically slower than a typical console and channel/fixture capacity is so low.

 

If you want to generate fully compliant DMX output at rates at (or at least near) what the spec allows (because you need to generate multiple universes, need to run fast chases for lasers or pyro, or whatever), it is a little tricker. You need to bypass the generic comm stack and move framing and compliant spacing out to the adapter. That doesn't as easily fit inside an XLR housing. But, of course, it doesn't send out periodic bad packets and output data at a sluggish rate either.

 

Good Luck,

-jjf

 

Edit: I'd encourage hobbiests to take a good look at Ben's initiative.

Link to comment
Share on other sites

  • 3 weeks later...
On 'dicky's' unit it's built in the USB plug. He's just buying USB to Serial converters and chopping the end off.

 

That is not quite how we have designed it. I can assure you that we have never bought a USB to serial converter and chopped the end off.

 

A lot of work has gone into this unit which is why we have delayed the launch several times.

We have our own USB PID code for this device and when pluged into a USB port it is identified as a Afterglow Magic DMX interface.

 

Hours of work have gone into developing the driver which is based on the same architecture as our classic DMX interfaces.

 

We have never detected any packet errors or timing errors from any of our interfaces and all our units are capable of the full 512 channels with ease.

 

Thanks

Dicky

Link to comment
Share on other sites

On 'dicky's' unit it's built in the USB plug. He's just buying USB to Serial converters and chopping the end off.

We have never detected any packet errors or timing errors from any of our interfaces and all our units are capable of the full 512 channels with ease.

 

I can see how many of the errors regularly seen in these type of offerings could be offset with a new kernel level driver that does not rely on the com stack. However, I'm still skeptical that you are getting even cheap console type performance. At the end of the day, you are still sending USB bulk data in the format the chip(set) expects and software timing for framing.

 

In other words, no matter how many improvements you make, I would be very surprised to see good multi universe support, packet refresh rates as fast as the spec allows, or practical data update rates from applications much above about 15-17 Hz (many good consoles use 24-25 Hz, we use 30 Hz for video servers, etc.)

 

-jjf

Link to comment
Share on other sites

On 'dicky's' unit it's built in the USB plug. He's just buying USB to Serial converters and chopping the end off.

We have never detected any packet errors or timing errors from any of our interfaces and all our units are capable of the full 512 channels with ease.

 

I can see how many of the errors regularly seen in these type of offerings could be offset with a new kernel level driver that does not rely on the com stack. However, I'm still skeptical that you are getting even cheap console type performance. At the end of the day, you are still sending USB bulk data in the format the chip(set) expects and software timing for framing.

 

I agree with your points above. We make low cost DMX interfaces and microprocessor based "pro" interfaces.

I would never promote the use of one of our low cost interfaces into a pro application.

 

In other words, no matter how many improvements you make, I would be very surprised to see good multi universe support, packet refresh rates as fast as the spec allows, or practical data update rates from applications much above about 15-17 Hz (many good consoles use 24-25 Hz, we use 30 Hz for video servers, etc.)

 

-jjf

 

There are many applications and markets where a low cost unit is ideal I dont think that anyone would expect "multi universe support, packet refresh rates as fast as the spec allows, or practical data update rates from applications much above about 15-17 Hz" from an interface costing £50 incliuding software. what we do believe is that we have one of the best low cost interfaces on the market, including a 2500v isolated version and soon a wireless version.

 

Dicky

Link to comment
Share on other sites

There are many applications and markets where a low cost unit is ideal I dont think that anyone would expect "multi universe support, packet refresh rates as fast as the spec allows, or practical data update rates from applications much above about 15-17 Hz" from an interface costing £50 incliuding software.

 

But by the time you add a PC, it is no longer a $100 solution. Let's say it is a $400 solution (or more). So it seems reasonable to expect packet rates and timing on par with a $200 DJ board from China.

 

Obviously there are markets for very cheap, not-so-good, DMX adapters for computers. I'm just not convinced there are that many legitimate applications where sluggish and typically non-comliant output is 'ideal'.

 

However, don't get me wrong, if you have replaced the kernel driver and at least moved some of the work to a more suitable place, you are at least executing the approach well. I just question the whole approach. It is like 'dumb laser printers' which have cropped up again and again over the years. The printer is cheaper because more work is offloaded to the PC using it. But users eventually figure out that the results and performance are not as good and, in the great scheme of things, the savings isn't all that much.

 

-jjf

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.