DMX4 SSR Project

[RPM]

Hello all,

I have a few projects going on right now and one I'd like to share with you is one that I call "DMX4 SSR".

What is it? Like the name says, it's a 4 channel DMX controlled SSR and it is designed to fit in the Keptel TA-200 enclosure.

This is a DMX input only design and it is designed around the Atmel Attiny2313 processor.

I plan to use several of these in my show this year and if there is any interest, I can do a co-op of the design.

I have attached the Firmware and Eagle schematics and source code.

Note that the crystal frequency has been changed from 8mhz to 20mhz in the updated schematics and project files.

Robert

[budude]

Whew - don't think you could pack much more on that board - nice layout!

[n1ist]

Would it make sense to add a 6-pin ISP header to the board to ease programming the chip? Also, do you get enough accuracy out of the internal oscillator for reliable DMX reception?
/mike

[Henne]

Hi,

the internal oscillator isn't that precise... Your proto might work well and the next 10 modules, too.

Some months later you buy another bin of Tinies - and you will get in trouble with the DMX reception.

-> Please use a crystal.

Optaining the zc-signal on the secondary side of the transformer, you will get a load dependend phase shift. So if you want to use an optocoupler, getting the zc-signal directly from the mains is better. (But you have to filter the incoming signal from the noise in hw or fw...)

Can you mount the triacs on heat sinks to drive bigger currents? Furthermore don't forget the chokes if you want to implement forward phase control. (iron powder, toroidal type, 1-2mH)

If you don't like big inductors: What about phase reverse dimming of RC loads?


nice board!
Hendrik

[RPM]

Would it make sense to add a 6-pin ISP header to the board to ease programming the chip? Also, do you get enough accuracy out of the internal oscillator for reliable DMX reception?
/mike


The board is pretty packed, so I had to eliminate the ISP header to make everything fit and still keep everything as DIP packages.

For the purpose of DMX reception and light dimming the internal oscillator works fine. I've been testing this firmware (and variants of it) for about 6 months now and haven't had any issues with using the internal oscillator. I will add the external oscillator anyways just to make sure... that's why it's a preliminary design ;)

Robert

[LabRat]

I've been thinking about a similar device, though I was leaning towards a different approach. Why not take the JEC Pixel as a starting point? Rather than driving RGBAW + 3 servos, convert it to drive two 4 channel SSR's. (An external module to drive the existing SSR's)

The source is already there for the 16F688 PIC's, including the ability to program the address from the DMX signal.

The major difference is how the board is powered. Using the JEC method, the board is powered via +12 on the CAT5 (via a power injection board), versus putting a transformer on every board you build.

There are pro's and con's to each, but I thought I would throw this out there for consideration. (I've even considered buying some of JEC through hole boards in order to experiment (but as I don't have DMX source yet... that wouldn't make much sense)).

[RPM]

Hi,

the internal oscillator isn't that precise... Your proto might work well and the next 10 modules, too.

Some months later you buy another bin of Tinies - and you will get in trouble with the DMX reception.

-> Please use a crystal.

Optaining the zc-signal on the secondary side of the transformer, you will get a load dependend phase shift. So if you want to use an optocoupler, getting the zc-signal directly from the mains is better. (But you have to filter the incoming signal from the noise in hw or fw...)

Can you mount the triacs on heat sinks to drive bigger currents? Furthermore don't forget the chokes if you want to implement forward phase control. (iron powder, toroidal type, 1-2mH)

If you don't like big inductors: What about phase reverse dimming of RC loads?


nice board!
Hendrik

Thanks for the advice, I'll probably include a crystal just to make sure.

The reason I use the secondary side for the ZC is to make it easier to adapt to 230vac by just changing the transformer and the gate resistors on the triacs.

It's a reverse phase dimming design. The triacs can be mounted on a heatsink, but the design is mostly for small resistive loads of 1 amp or so, commonly used for the DIY christmas lighting.

Robert

[RPM]

OK, I've just added a crystal and reversed the orientation of the triacs to make it easier to mount a heatsink.

Robert

[Henne]

To JECs pixel / remote adressing:

I have written a complete RDM responder stack for AVRs (which will be improved todeay to become compatible with ENTTECs RDM devices) :D

But I'm not sure if all that fits in the Tiny2313. I use mega8 for RDM devices, cause they have 8kB flash, ADCs and are 0,25 EUR more expensive.


to phase reverse dimming:
you need MOSFETs in the dc paths of rectifiers or anti-serial connected IGBTs for that. Triacs are just for forward phase control ;)


Please don't blow yourself up...

Hendrik

[RPM]

To JECs pixel / remote adressing:

to phase reverse dimming:
you need MOSFETs in the dc paths of rectifiers or anti-serial connected IGBTs for that. Triacs are just for forward phase control ;)


Please don't blow yourself up...

Hendrik

I meant to say forward dimming. My bad :oops:

Robert

[P. Short]

As I see it, if the part has a decent uart implementation you should be all right without a crystal so long as the frequency is within roughly 2% of nominal over all environmental factors (voltage, temperature, noise and lot). This assumes that the transmit frequency may be off by as much as 2%, and that the UART sample clock is at least 16X the baud rate, and that the nominal UART baud rate is spot on.

The UART should be able to time things from the beginning of the start bit to determine the center of each bit cell (give or take 6% of a bit period), and then count clocks from there to sample each consecutive cell. If you assume that the transmitter frequency is off by 2% in one direction and the receiver is off by 2% in the other direction, then after 10 bit times the input data would be sampled at +/-40% of a bit cell from nominal. This should still be within the correct bit cell, so the uart should sample the correct value for each bit. This allows some margin for jitter and for error in determining the center of the start bit. If the transmit frequency is crystal controlled, then things should be so much the better, although I would try to make sure that the Rx frequency error is still less than 4% or so.

[RPM]

As I see it, if the part has a decent uart implementation you should be all right without a crystal so long as the frequency is within roughly 2% of nominal over all environmental factors (voltage, temperature, noise and lot). This assumes that the transmit frequency may be off by as much as 2%, and that the UART sample clock is at least 16X the baud rate, and that the nominal UART baud rate is spot on.

The UART should be able to time things from the beginning of the start bit to determine the center of each bit cell (give or take 6% of a bit period), and then count clocks from there to sample each consecutive cell. If you assume that the transmitter frequency is off by 2% in one direction and the receiver is off by 2% in the other direction, then after 10 bit times the input data would be sampled at +/-40% of a bit cell from nominal. This should still be within the correct bit cell, so the uart should sample the correct value for each bit. This allows some margin for jitter and for error in determining the center of the start bit. If the transmit frequency is crystal controlled, then things should be so much the better, although I would try to make sure that the Rx frequency error is still less than 4% or so.

I figure there are too many variables involved and it's easy to add an oscillator, so I've just included it to the design.

It only adds about 30 cents to the cost and since these are designed to run out in the yard under the extremes of weather I thought it was best to add it instead of relying on the temperature sensitive internal R/C oscillator.

Robert

[LabRat]

I've been thinking about a similar device, though I was leaning towards a different approach. Why not take the JEC Pixel as a starting point? Rather than driving RGBAW + 3 servos, convert it to drive two 4 channel SSR's. (An external module to drive the existing SSR's)

The source is already there for the 16F688 PIC's, including the ability to program the address from the DMX signal.

The major difference is how the board is powered. Using the JEC method, the board is powered via +12 on the CAT5 (via a power injection board), versus putting a transformer on every board you build.

There are pro's and con's to each, but I thought I would throw this out there for consideration. (I've even considered buying some of JEC through hole boards in order to experiment (but as I don't have DMX source yet... that wouldn't make much sense)).

Zero Crossing!! (d'oh)... Ignore this idea, unless you want to run LED's on those SSRs. (sounded good when I started)

[Matt_Edwards]

Robert,

I am building a prototype of this controller this weekend.
Have you tested this code at 8 channels?


Cheers
Matt

[RPM]

Robert,

I am building a prototype of this controller this weekend.
Have you tested this code at 8 channels?


Cheers
Matt

Matt,

Yes, actually the code was written as 8 channels and modified for 4.

All that needs to be done is change the references in a couple of places in the first few lines of code from 4 to 8.

I'll attach the 8 channel files here. Source and hex files included.

Robert

[Matt_Edwards]

Cool.
when I looked at the ASM, I noticed:

.equ DMX_CHANNELS =4 ; Number of DMX channels
and the similarities with Henns original code.


Thought it would hurt to ask.

Thanx
Matt

[Henne]

I should have written my code in c from the beginning... :D

The firmware looks nice (the macros are a good idea).
What about firing curves for brightness linearisation?
Beware of nested interrupts: nested PinChange-IRQ with bouncing inputs causes problems with the stack.

If the frequency detection works well and reliable, I will include it in my own packs...

best regards,
hendrik

[RPM]

I should have written my code in c from the beginning... :D

The firmware looks nice (the macros are a good idea).
I added the macros since there were a couple of repetitive routines and it seemed to make sense to do it with macros.


What about firing curves for brightness linearisation?
I wanted to make the code simple, so I didn't add any linearization at this time. I will probably add it in the future.


Beware of nested interrupts: nested PinChange-IRQ with
bouncing inputs causes problems with the stack.

I had this problem early on, so I moved things around in the code and the problem went away.


If the frequency detection works well and reliable, I will include it in my own packs...

best regards,
hendrik

It was something I came up with that seems to be working well enough. The code defaults to 50Hz and then switches to 60hz if the frequency count is above 55.
I know it detects 60hz, but I need someone run it through some testing at 50hz. All of my 50hz tests were with a signal generator across the ZC circuit.

Thanks for your input, hendrik

Robert

[Henne]

Hhm - I have only 50Hz and so I'm simulating the 60Hz...

If you port your firmware to the transceiver HW I can verify it for Europe.
(I don't have the time to etch your pcb.)

best regards,
hendrik

[RPM]

I've built one of your transceivers, so I can port it over for you to test.

Robert

[RPM]

I have ordered some prototype boards of this design and once they arrive I will build a couple of them to test.

If there's any interest in this design, I'll do a co-op at that point.

Robert

[RPM]

The boards finally arrived today.

So far they look good... now to build and test one.

[dmcole]

The boards finally arrived today.

So far they look good... now to build and test one.

We await your results with anticipation.

\dmc

[budude]

Hi Robert -

Have you determined the max number of these you can daisy-chain from the same dongle and still get synced results? I'm guessing 128 would be a few too many...?

[dmcole]

Have you determined the max number of these you can daisy-chain from the same dongle and still get synced results? I'm guessing 128 would be a few too many...?

Jumping in for Robert here, as with all DMX/RS-485 environments, there is a limit of 32 devices per chain. That's what the DMX splitter is for -- you can create more chains that themselves can then have 32 devices each. I believe Robert's splitter gives you the ability to distribute five circuits (or chains), which would mean 160 devices. But, since a DMX universe is only 512 channels, you'd only need 128 of Robert's DMX4 SSR devices to reach universe saturation.

\dmc

[budude]

ah right - forgot about the 32 device limit - thanks for that!

[RPM]

Jumping in for Robert here, as with all DMX/RS-485 environments, there is a limit of 32 devices per chain. That's what the DMX splitter is for -- you can create more chains that themselves can then have 32 devices each. I believe Robert's splitter gives you the ability to distribute five circuits (or chains), which would mean 160 devices. But, since a DMX universe is only 512 channels, you'd only need 128 of Robert's DMX4 SSR devices to reach universe saturation.

\dmc

Yes, for the most part 32 is the limit, however the Maxim MAX487 IC has a maximum of 128 devices, and I believe the ST Micro ST485B will go up to 64 devices in one chain.

I use the SN75176 IC which will allow up to 32 devices on one chain, but there's nothing that says someone can't use the Maxim or ST Micro IC's in theirs if needed. I only use the SN75176 for design cost reduction and the others are fully compatible and can be used if needed.

Robert

[RPM]

We await your results with anticipation.

\dmc

I've just got the cord ends on one now and I'll run it through some testing.

Robert

[fkostyun]

Very cool - whats the approx cost per unit on these?

[RPM]

They are about 20 in parts + PCB + Enclosure.

[RPM]

If anyone is interested in building this design, I have about 10 spare PC boards and programmed processors.

Here's the Mouser web BOM http://www.mouser.com/ProjectManager/ProjectDetail.aspx?AccessID=49ada8c3cb

They show several parts out of stock, but I have them and can supply them with the boards if needed.

PM me if interested.

Robert

[lightman]

RPM,

How did the tests go? I never saw anything on your results. Just may be that I missed them.

Regards,
Lightman

[RandyA]

RPM,

Would like 2 boards & 2 processors. Shipping to 14094


Thanks,
Randy

[NogginBoink]

Do you have a board layout for the 8-channel version? Is it designed for a particular enclosure? I was going to build a few more SSR's for my Grinch this year, but what the heck... I might as well put myself under a severe time crunch and the pressure of building a DMX system this year.

I have some elements of the display that would be ideal for 4 channel SSR's and some areas where an 8 channel would make more sense.

[fkostyun]

RPM - definatly hoping on a CoOp on these for next year! - I am looking for a potential for a (budget allowing) of 53

[NogginBoink]

RPM, how are you programming your AVR's for this board? Do you have a separate board with a ZIF socket or something?

[RPM]

Do you have a board layout for the 8-channel version? Is it designed for a particular enclosure? I was going to build a few more SSR's for my Grinch this year, but what the heck... I might as well put myself under a severe time crunch and the pressure of building a DMX system this year.

I have some elements of the display that would be ideal for 4 channel SSR's and some areas where an 8 channel would make more sense.

I did do an 8 channel version, but I had trouble finding an enclosure that the board would fit into.
The firmware for the 4 channel version is the same (with the exception of changing 1 line in the source) as the 8 channel version, so it's just a matter of adding the additional components for 4 more channels.

Robert

[RPM]

RPM - definatly hoping on a CoOp on these for next year! - I am looking for a potential for a (budget allowing) of 53

I'm running behind on my show for this year, so I won't be doing anymore co-op's, but I plan on doing some for several of my designs early next year.

[RPM]

RPM, how are you programming your AVR's for this board? Do you have a separate board with a ZIF socket or something?

I have an Atmel AVR Dragon with a ZIF installed that I do programming with, as well as an STK500 with an add-on ZIF board to program other chip types with.
I chose not to include the ICSP port on this board because I was trying to keep the board as small as possible.
I don't plan on changing the board except for rotating the triacs 180 degrees to make it easier to mount a heatsink to them. The way they are right now makes it a little tight to add one.

Robert

[mmulvenna]

I'm running behind on my show for this year, so I won't be doing anymore co-op's, but I plan on doing some for several of my designs early next year.

Any word on the coop for the dmx4 this year. Like Frank I would like to use a number of these, although it would not be 53 of them.:smile: I might do 10 of them.