Custom USB DMX build

[Infidellic]

First of Hello to everyone!

 

Secondly, I am a 1st Year Electronics Undergraduate and this summer will be getting a job. However, I like something deep to get into in my free time and here is where my idea came in. Is it reasonable to have a go at creating my own USB to DMX device from scratch (i.e. make my own circuit diagrams etc, the whole works)?

 

I have seen various ones on the internet however I thought, having used it for years I may as well try to get to grips with the implementation of DMX512 and was basically a little concerned that this might be above my skills at this stage.....what are your opinions?

 

Regards,

 

Richard

[woody74]

Hello and welcome.

 

Have a go with the search function above; USB->DMX has been discussed up, down and sideways here, and I know a few folks here that have gone into great detail of the pros and cons and logic of making your own vs. buying.

 

My opinion is if you can make one cheaper and better than what is commercially available, do it and make some money. Otherwise, unless it's useful from an educational standpoint, why reinvent the wheel?

 

-w

[Modge]

It's not entirely trivial making a USB to DMX - bodge.

If you're thinking of implementing it as an FPGA, then it's really really not a first year level thing (and PIC's are good enough I don't see as you'd want to ether)

If on the other hand your doing it with microprocessor I'd say it was "very stretching" for a first year and that by the time you've finished it you'll be a second year any how, however by the end of your second year you'd be in with a good stab at it. This is based purely on Birmingham uni's elec. eng course. The other half of my business made most of his 4th your elec eng. project talk to other bits of it self via something not unlike DMX.

A few odd pointers, some PIC come with a certain amount of USB handling built in, consider that as a possibility. Another thing (which will become blinding obvious to you with not much research...) is that DMX running over RS485 is a boon in that there are many standard rs485 line driver chips to get from a level your pic will put out to something you can connect to a fixture.

[Infidellic]

Many thanks for you help, I realise this will not be a simple and trivial project and that it would take some time. I might have a go and see how far I get, if I don't get anywhere then it's only my free time wasted and I may have learnt something. I very much doubt I have been taught everything I need to know but I am willing to pick up stuff on the fly so hey!

 

Many thanks once again,

 

Richard

[Jivemaster]

There are so many things already out there on the market, that do all,most or more than your aim. It would be wise to look long and hard at existing products, searching on here and in this forum http://www.mobiledjforums.com/ Member DJ Dicky has already done a lot of the development and is bringing products to market now. (register there to read)

[martinw]

As an educational experiment, its quite useful, as you'll learn lots about USB and DMX. My advice would be that you don't use the USB-serial converter chips that FTDI make, as firstly, you won't learn very much, and secondly, they do a really bad job of generating DMX, and can't really handle the timings required. Find a microcontroller with built-in USB client and UART and write some firmware. You will also need to write or adapt a USB device driver for the host computer, which if you write from scratch (especially for windows), is tough task if you've not been there before (linux is much easier IMHO).

 

Good luck with your project.

 

Martin

[Tomo]

Recently I've been playing with the Cypress USB chips, and some of the Microchip PICs also have built-in USB and UART(s).

 

The easy way to do this is to make the USB enumerate as a serial port (Microchip and Cypress do example code for this), and pass commands down the port - don't try to make the PC do the timings as well, it's not a good option.

 

You can get even cleverer if you feel like writing USB device drivers.

 

Finally:

If you're doing this as an educational and fun project - great!

 

If you are doing this to have a USB>DMX converter - don't bother, as the hard part of such devices is actually the PC software that does the lighting control.

[Infidellic]

....don't try to make the PC do the timings as well, it's not a good option....

 

I was throwing a few ideas around, thanks for the heads up on this one though!

 

Finally:

If you're doing this as an educational and fun project - great!

 

If you are doing this to have a USB>DMX converter - don't bother, as the hard part of such devices is actually the PC software that does the lighting control.

 

It's a little of both. I have no need for a USB>DMX converter however, it would be nice to have one for various events I do. It's primarily just something to do thats a laugh and come out with a useful gadget at the end. Who knows maybe if I do this then I post it somewhere to add to the multitude of tutorials out there already!

[ben.suffolk]

Feel free to check out my design at USBDMX.COM. The circuit is pretty simple really, its all down to writing good firmware.

 

You could always use on of my PCBs and write you own firmware for the PIC, depends which bit of the project you want to spend time on I guess.

 

Regards

 

Ben

[Jivemaster]

What I would really like DMX wise, is a controllable merge. Two controllers into one universe, and itself controllable.

 

This would facilitate having a "rock desk" function with faders and flash buttons, and a movers desk with patterns and programmes. All driving the same lights for the floorshow/conference, then for the disco.

[ben.suffolk]

What I would really like DMX wise, is a controllable merge. Two controllers into one universe, and itself controllable.

 

This would facilitate having a "rock desk" function with faders and flash buttons, and a movers desk with patterns and programmes. All driving the same lights for the floorshow/conference, then for the disco.

 

If I'm understanding you correctly, this would be quite a simple bit of software to write. You would just need two interfaces. Or did you specifically want it to be a standalone device (I'm assuming not as you mention it should be controllable - I'm guessing by software like a standard USB DMX Device?)

 

Ben

[Jivemaster]

While a usb to DMX converter is a laudable project, they do already exist in several forms. The smallest one I have seen and handled was built into the XLR connector body!

 

Once you have a good understanding of the technology look at the market,

 

http://www.artisticlicence.com/

http://www.xtba.co.uk

http://www.nextec.co.uk/

 

are some sites there are hundreds more! Find a niche that is needed and not covered and develop your ideas into that that market.

 

Once you have done that you have something impressive to hawk round the manufacturers when looking for a job.

 

If you have serious interest in theatre technogy and want this project to lead into your placement and permanent employment then it is very worthwhile.

[dirkenstein]

I have built 2 (and, approximately '1/2') PIC DMX devices, as well as Ben Suffolk's usbdmx.com adapter.

 

For my own projects, I used pic18 (16-bit) series devices, rather than pic16 (12-bit) because I prefer to program in C rather than assembler. The extra costs of the parts wasn't critical for series-of-one devices.

 

Because I'm a cheapskate, I use the SDCC C compiler and gputils assembler, and the PICKit2 ICP package.

 

The PIC MPLAB IDE assembler is free but the Microchip C compiler is over £200.

 

I don't have the MPLAB ICD but that's fairly optional. There's a lot of debugging you can do the 'hard way' (nick some ouput pins to light LEDs for exepected/unexpected code states, or use a spare serial out, of which these designs unfortunately have none).

 

SDCC is an adequate compiler for the purpose, but be very careful with bit shift operations, as the results may be counterintuitive or simply wrong in some cases.

 

The first device is a DMX to dataflash 1 protocol converter. This allows the 10 old DF1 strobes our am-dram group bought at auction a few years back to be used with standard DMX. This converter is based on the Microchip PIC18f8720 demo board with two USARTs.

One USART is configured for 250Kbits/s in and the other for 375Kbits/s out. DMX input is interrupt driven into an intermediate buffer just large enough to hold 60 channels (enough for intensity, rate, duration for 20 DF strobes).

The board runs at 24MHz. An earlier version runs adequately at 12MHz, requiring some optimisation of the receive ISR (22573 interrupts/s leaves only 132 instructions per received byte, provided the system is doing nothing else). Output for DF serial USART is polling.

 

I don't believe such a device is commercially available.

 

The second is a DMX to MRL coulourcall converter for some old Strand scrollers, which ouputs the 9600baud colourcall data by bit-banging an ouput line on a pic18f2220 (using a high-priority timer interrupt to generate the bit clock). This was done as no two-USART devices are available in non-TQFP packaging and the pic18f8720 on a demo board costs approximately £30-£40 (less than £4 for the 18F2220).

 

Some company in Germany makes a device like this for EUR900 or so. Rather more than the £40 the set of 4 15" scrollers cost.

 

This device works OK in the lab but may have some 'real world' problems as we could not use it successfully on our last panto with a strand GSX. This appears to be related to glitches in break detection(and possibly some dodgy cabling/connectors or mounting). Unfortunately the current break detection method used by my software is very dumb.

 

The third device is probably going to be a 24-port analogue to DMX converter and patcher for all those old Sirius desks out there for which you can't get DMX boards anymore.

 

The main issues with USB DMX design as far as I can see are:

 

Host computer based timing on a simple (some would indeed argue 'dumb') USB -> 256K 8N2 serial converter, as performed by the Enttec OpenUSB interface, is notoriously difficult to get exactly right. Especially the break duration, MAB interval and minimum/maximum intercharacter/interframe timings are extremely sensitive. The issue is not throughput (23K/s is a doddle for USB, even 1.1) but latency, and the general understanding is that Enttec has had to invest substantially more effort in fixing the host drivers/interface libraries than in originally designing the dongle. Some claim that the OpenDMX USB dongle still occasionally produces not-to-spec or glitchy DMX output, even with these fixes, but I am not in a position to judge this, as I've only used the 'pro' dongle which includes a microcontroller to generate DMX framing on-board.

 

USB itself is not a 'simple' protocol like DMX- it needs a reasonably involved protocol stack to operate.

Writing this functionality from scratch for, say, a PIC18F4550 is not a small project. Probably not at third-year project/dissertation level, but still potentially several months work.

Microchip does provide a library for these functions but I have never used it myself and do not know of the redistribution and royalty conditions attached to it. I also don't know if the overhead is not high enough to make real-time generation of DMX packets problematic. This may mean opting for a two chip solution with one PIC acting as the USB interface and the other as the comms driver.

 

Note that for practical PIC-based USB projects there is no 'shame' in using the FTDI serial or data-bus based interface as a means of simply sending serial data streams to the PIC.

 

If the emphasis on your project is on understanding the USB interface side, then of course this might be seen as taking shortcuts.

 

Kelly Kohls' site has some useful example firmware for PIC16 DMX devices and this site has some outlines on DMX timing parameters.

I believe there is also a booklet available outlining the DMX standard from PLASA which is quite useful.

You can obtain an official copy of the standard for £12, here.

[martinw]

I think the reason the Enttec (FTDI based) device has problems is due to USBs 1mSec time slice, which can in some circumstances result in lengthy (several mSecs) pauses within the DMX packet, between adjacent channels. In theory, this shouldn't cause a problem, since receiving devices should tolerate gaps in the transmission of up to 1 second, however I suspect that many devices will reset their receivers much sooner that this, and ignore the rest of the packet.

 

I've seen some very poor implmentations of DMX receivers (both hardware and software), and I suspect that a lot of developers either don't read the specification at all or don't do enough testing to discover bugs like these.

 

On the subject of microcontroller choices for implementing USB-DMX, I've designed several interfaces using the Cypress EZUSB series, which are easy to use, and do the job very well. At least three different lighting console manufacturers I can think of use these devices to implement USB-DMX either inside consoles, or as external accessories.

 

Martin

[LDODD]

Slightly O/T, but I think I'd look at LED Drivers as a project, rather than USB-DMX - though this may not be your area of interest...?