Skip to main content
Topic: PIC16-based 9-channel DMX512 dimmer (Read 7614 times) previous topic - next topic

PIC16-based 9-channel DMX512 dimmer

Thanks for the invitation, Ian.  I have an old project that I started in 2008, and I hope to eventually have enough free time to finish it.  In the mean time, I might as well document what I have so far.

I had previously designed a PIC18-based USB-MIDI control surface.  In that design, I reserved the second UART for DMX512 expansion I/O, but never quite convinced the client to fund full development of the idea.  Since I hoped to eventually get a PIC communicating over DMX512, I realized that I would need some sort of DMX512 dimmer as a test so I could connect my control surface to something.

I selected the cheapest and smallest PIC that seemed capable of handling the job.  This turned out to be the PIC16F87.  It's an 18-pin PIC with almost 16 pins of I/O!  I went to MAXIM for the RS-485 receiver, since most other chip makers include multiple channels of input and output, yet I only needed one channel of input and desired a small board for mounting inside random lighting enclosures; the other RS-485 chips are much larger due to increased pin counts.  DMX512 runs on 12V, so I have an LM2931A that can provide up to 100 mA to the PIC.

After reviewing how many of the I/O pins would actually be available after allowing for crystal, UART input, and ICSP programming/debugging, I settled on 9 channels of LED outputs.  Each individual LED channel has a MMBF170 FET capable of 500 mA.  If fewer channels are needed, then individual FET parts can be left out during SMD assembly.  I also placed a small 8-resistor pack on the LED outputs to avoid potentially running an LED without any current limiting, although the resistance is small enough that it won't interfere with running a long string of LEDs on a single channel.  There's room for a 9th SMD resistor for those cases where all 9 channels are needed.

Nine channels is far more than my minimum, but is nice because it would allow 3 full RGB LEDs to be attached to a single dimmer.  Some of the lighting experts that I talked to suggested RGBA, with A for Amber or some off-white color, because many RGB lights cannot produce a pleasing color tone on human skin - the amber makes a good color all on its own, and I could even have 2 full RGBA sets.  Another issue is that most LED dimmers are 8-bit linear brightness, but our perception of intensity is such that we see big steps at the dark end of the fader while the brightest levels have barely perceptible changes.  One goal was to either use the full 16-bit mode of DMX512, or perhaps even just have a gamma curve for the 8-bit mode such that there would not be giant steps between darkness (0) and the first level (1).  This should all be automatic so that a standard DMX512 fader board would not produce huge jumps without special curves.  The lighting people I talked to all hate the way that LED lights offer such coarse adjustment in the dark levels, where an incandescent light has no similar problem.

I expect to provide the 12V from an external supply.  LEDs can operate from either 12V or 5V, although the 5V supply is limited to 100 mA or less.  Each FET grounds the LED under PIC control, and so it doesn't really matter what the high-side voltage might be.  External resistors are needed to calibrate the desired current based upon how many LEDs are in each string.


Things I Learned
The Maxim part proved impossible to purchase.  I would have needed to order 1,000 of them minimum.  Nobody carries this, and I only found one mysterious reseller who offered to sell 100 instead, but I wasn't really sure I could trust that source (they were no Mouser, by any stretch).  I ended up requesting 9 samples from Maxim, which they happily provided for free, and I did not lie about the number of 'units' I expect to manufacture.  I thought surely they would turn down my request, since I might never build this thing, but I think that they might have considered how many of their other chips I have used in commercial designs.  Since this particular 9-channel DMX512 dimmer was for my own surround sound installation, where I want 9 lights spread around a 9.2 surround setup, I decided to build 9 prototypes.

Eagle tends to place vias too close to SMD pins.  Or, rather, the autorouter places traces too close to SMD pins.  I had a problem when hand-soldering because a via near one of the PIC pins had a solder bridge.  Unfortunately, the via is underneath the PIC, so it's impossible to fix without removing the PIC.  I now have soldering tweezers, so it should be easier to do by hand.  I realize that I could bump up the spacing rules in Eagle to force more separation, but I think that there is something about Eagle's treatment of 45-degree trances that places them too close to SMD pads, despite the usual spacing rules.  It's usually a matter of examining the board after autoroute and hand-moving the 45-degree traces a few units away from the corners of SMD pads.

Researching the gamma brightness curve issues, I realized that the maximum clock speed of the PIC16F87 could not actually handle PCM values for multiple channels with 16-bit resolution without flickering.

After obtaining an assortment of seven or eight LED colors (red, orange, yellow, green, blue, violet, pink, white), including IR, I realized a couple of things would affect the electronics.  First, the voltage drop is different, of course, and basically means that there are two groups of colors - each needs a different current-limiting resistor.  Second, the brightness of each color is different, so if I want an even mix of RGB colors, I might need to put more of one LED color to match the brightness of another, more efficient color.  Since the design allows for strings of LEDs as well as individual LEDs, and since I have 12V available, this allows a closer balance of brightness for each color.  However, some care has to be taken for efficient colors with low voltage drops, because the current-limiting resistor will drop more voltage and thus waste power.  For this reason, my LED connector offers both 12V and 5V supplies - the 5V allows less power dissipation, provided that the LED string does not need more than 5V.  Finally, my research stopped before I could learn about human perception of brightness based on color.  Although the LED specifications give precise brightness values in lumens, I'm not sure what this means about the perceived intensity of those LED colors.  I would want to provide a balanced mix of colors without having one or more seem too much brighter than the other color(s).

I went to Sunstone Circuits for the 9 PCBs.  They're in Oregon, and I believe that it's important not to waste fossil fuel shipping things half way around the globe just to save $1; besides I paid under $90 for 9 boards.  If you're considering Sunstone, contact me via private messaging, because I think I can get you a discount on your first order if I 'recommend' you - and I get a kickback, too.  Mouser provided all parts except the PCB and MAXIM chips.  Printed Circuits Assembly, Corp. is within walking distance of my office, and quoted around $30 each to assemble the boards.  I decided to make one by hand before dropping $300.
You'll note in the photo that I have not soldered all of the parts yet, because I want to at least prove that I can get the firmware working.  Once I have the firmware working, I'll just have PCA Corp. handle everything.

Microchip does not offer a C compiler for the PIC16, and I could not find a free one when I looked.  Thankfully, this seems like a simple enough project for assembly.  Before I heard about some of these advanced multi-channel PCM techniques, I decided that it would be most efficient to update all channels on a given port with one write.  So, I decided that it would be best to have different firmware depending upon how many channels are active.  Very few installations will use all 9 channels, and thus most can just hang all LEDs off a single port.

By the way, one common trick for multi-channel PCM generation is to use bit-weighting so that fewer updates are needed per cycle.  Thus, with an 8-bit PCM level, the loop would only update the port bits 8 times, but the timing of each update period would be half the neighbor's.  This also works with 16-bit PCM or any other bit depth.  However, it only represents a savings when there are more channels than bits.  Some designs that I read about were generating 48 PCM channels of output, and thus there was a vast savings because fewer than 48 port writes are needed per cycle.  However, in my case I have only 9 output channels, and I want way more than 9-bit PCM resolution.  In fact, I'd like as much as 16-bit resolution as possible, but 16 updates per cycle is certainly more than 9!  I have devised some special techniques to hack around the PCM limitation using custom cycle-counted assembly, and thus I do not have more port writes than active channels.

P.S.  You'll note that the schematic and firmware sources are not included above.  That's because this isn't an open design.  It's also not complete - especially the firmware.  But I do want to share some of the things that I learned and help others who might be working with the same chips, standards, or just similar ideas.

Re: PIC16-based 9-channel DMX512 dimmer

Reply #1
Looks like you really did some research on this project, and learned a thing or two.
I have been wanting to give Eagle a try, and now I know of a few things to be aware of when using it.

I look forward to a demo video at some point in the future. I've made a few small scale Arduino based LED dimmers, but only to test the concept.

Nice project post! :)


Re: PIC16-based 9-channel DMX512 dimmer

Reply #2
[quote author="Makerdino"]I have been wanting to give Eagle a try, and now I know of a few things to be aware of when using it.[/quote]Note that I was using the autorouter, even though it seems that every layout person I've ever interviewed refuses to use any autorouter.  It really makes me wonder why the industry keeps producing autorouters if absolutely nobody uses them.  I have a hunch that it's only because of the engineers I know that I've not found anyone (besides me) who will use one.

That said, my problem may not have been Eagle's fault.  For one thing, I set the Design Rules to the absolute minimum sizing/spacing that I could get from my PCB fab house without paying a premium.  Therefore, I'd say that it's probably a bad idea to set the design rules so small unless you really need it.  After seeing the problems, I usually now just set my Net definitions to have larger sizing/spacing rules to avoid the really tiny features.

Even still, my problems may have been due to hand soldering.  This particular board has not been assembled by a professional with a stencil made from Eagle, and using a pick-and-place.  It could be entirely possible that the via is not too close at all when the robots are in control.

Yet another issue is that there are no guarantees in this industry.  You'd think that chip makers would provide stencil information and layout guidelines and placement restrictions.  Well, they do provide such information, but it is never definitive.  Every stencil making process, every solder type, every pick-and-place machine, and every process is a little different.  Thus, it's actually impossible to have a generic set of design rules that will work everywhere.  You really do need to learn your PCB fab house and your assembly folks.  You then tweak the Eagle settings, save them in an organized fashion so you know whose equipment it works with, and learn as you go.

Eagle is free, so there's not much reason to avoid it.  However, they do charge for the full professional version, and as a licensee I can say that it's worth the money.  We probably should have a couple of threads on this site - one for Eagle and another for the whole general category of design rules.

P.S.  Thanks for the reply about my project.