Renard AC Dimming Curves

[P. Short]

Just today I finished writing some code for the PIC16F1825 that implements in-controller dimming curves on a per-channel basis. I haven't started testing it yet, and I need to add functionality to download curve tables over the serial line.

Here are some of it's characteristics:

1) PIC16F1825 code
2) up to 250,000 baud input and output
3) supports AC SSRs (not DC SSRs) in PWM mode
4) 2uS Timing Resolution, 256 brightness levels

Why am I working on this? Mostly the challenge, I think, as the day for AC dimming has mostly passed. Some of the recent posts in other threads has piqued my interest.

What does it do that is different and (hopefully) better than the previous Renard code? The most significant difference is that it allows the various brightness levels to be spaced closer together at the dim end of the brightness scale, and further apart at the bright end. This would allow smoother fading effects, both up and down. Other advantages is that it allows better tailoring for LED strings, which often have a much reduced number of useful brightness levels with the standard Renard firmware. It would also allow for more brightness levels when the maximum brightness is reduced to less than 100% (as an example, curves could be loaded that would allow up to 256 evenly spaced brightness levels between 0% and 35%).

One of the bigger difficulties here, though, is that most of the software sequencing packages have become mostly focused on sequencing pixel displays. I'm able to write plugins for Vixen 2.1 and for the Unix systems that I'm using, but that is the extent of it.

Anyway, I'll see where this goes, if anywhere beyond my house.

[ctmal]

Wow, this sounds awesome...I'm interested.
I have to say though...yes, things these days are mostly pixels...but I do think there is a really big crowd of us AC only folks. For me, I don't participate in the forum as much these days strictly because most of the talk is about pixels. I think some of that is due to the fact that most AC related stuff is pretty much rock solid at this point.
And, I'm still a Vixen 2.1 user so that works for me.(in fact, I'm in the process or trying to write a new UI for it to get a few more features....hopefully some news on that in the future).

[jchuchla]

I think there's still an appreciable AC audience. But I do think that we're at the point now where the discovery about our hobby happens elsewhere, and as such Renard doesn't get much attention. That, coupled with the fact that Renard isn't a product you buy from an online store, slows adoption quite a bit. The hype of the co-op days has long since passed. I'd be surprised if new folks these days even know where to get a renard board.

Anyhow, I use a fair amount of AC Renard channels. And i use dimming curves on all of them. Because it doesn't exist in the Renard firmware though, I implement it in software from Vixen. I could see it being handy to enable it and tweak it in hardware. But that would require a user interface. Ideally local to the controller, not a control computer somewhere across the yard.

[MikeKrebs]

Sounds fast...Would it be able to read serial data and interpret it 120 times per second? So, for example you could have a very smooth ramp using a timing curve and 120 different values over 1 second?

[todd1814]

I want to chime in as another AC user. I run 96 channels along with pixels. When it starts to get dark, most of my incandescent lights come on as a warm up to the sequenced show. The majority are white. My wife likes the incandescent look and I have to admit it offers a more traditional holiday feeling. Some of those AC lights are used in the show. I have a bunch of 120v LED lights I've never used but would like to try out. It would also be nice if I could find some warm white LED's instead of replacing hundreds of incandescent bulbs every year. A couple of years ago, my wife bought a 9ft pre-lit x-mas tree. This year we lost all bulbs on a few of the strings. I suggested replacing all 1200 lights with warm white LED's but was shot down because likes incandescent bulbs. I don't know what I'm going to do with it next year. Maybe I'll buy some commercial grade incandescent.

Anyway, I'll probably always have AC lights as an option.

[P. Short]

Anyhow, I use a fair amount of AC Renard channels. And i use dimming curves on all of them. Because it doesn't exist in the Renard firmware though, I implement it in software from Vixen. I could see it being handy to enable it and tweak it in hardware. But that would require a user interface. Ideally local to the controller, not a control computer somewhere across the yard.

How do you feel about the visual appearance of the host-based dimming curves? Are the fades smooth enough to suit you (if you're using fades)? And did you give up much (if at all) in the lower and upper levels of brightness?

Regarding 'ideally local to the controller, not...' I'm not sure what you're advocating for. I see two aspects to the 'control' interface, that of loading data into the controllers and that of creating a library of dimmer curve files for individual types and models of lights.

There would be an interface for downloading dimming curve data through the serial interface to the controllers. This would be done remotely over the same data lines for controlling the lights. There would not be any need touch the Renard controller after the initial re-programming of the PICs. Each channel on each controller would have unique dimming curve data. This data would be stored in non-volatile memory on the controller so that it doesn't need to be downloaded each time the controller is powered up. For Vixen I would imagine that this is done through a new plugin or add-on.

The dimmer curve data would be stored in a library of dimming curve files, such as what is currently available for the Lynx controllers. For my own controllers and strings I would first use an oscilloscope to see how much current is going through the strings at particular portions of the AC half-wave cycle. There would a somewhat tedious task of recording that information, and calculating the power output of the lamps over the course of the curve. The response curve of the human eyes would then be factored in to determine how to divide up the half-wave cycle into 256 variable-width timeslots weighed for uniform visual appearance using some computer software or other. That's my story, and I'm sticking to it (at least until reality intervenes). Other methods of creating dimmer curve data, who creates it, and where the repositories would exist are topics for discussion.

[P. Short]

Just to make things clear, the work is only for the 14-pin PIC controllers, and would require the replacement of PIC16F688 processors with PIC16F1825 parts. Also, it would not apply to the Renard-Plus and related controllers; it would take some difficult refactoring to support more the higher channel-count processors.

[P. Short]

Mike -

That will take some thought. The issue is that much (or all) PC-based playback software (such as Vixen) are unaware of AC power-line transitions. Also, the relationship between serial line data rate and the number of channels per serial line must be considered so that all updates occur within one AC half-cycle.

[jchuchla]

How do you feel about the visual appearance of the host-based dimming curves? Are the fades smooth enough to suit you (if you're using fades)? And did you give up much (if at all) in the lower and upper levels of brightness?

Regarding 'ideally local to the controller, not...' I'm not sure what you're advocating for. I see two aspects to the 'control' interface, that of loading data into the controllers and that of creating a library of dimmer curve files for individual types and models of lights.

There would be an interface for downloading dimming curve data through the serial interface to the controllers. This would be done remotely over the same data lines for controlling the lights. There would not be any need touch the Renard controller after the initial re-programming of the PICs. Each channel on each controller would have unique dimming curve data. This data would be stored in non-volatile memory on the controller so that it doesn't need to be downloaded each time the controller is powered up. For Vixen I would imagine that this is done through a new plugin or add-on.

The dimmer curve data would be stored in a library of dimming curve files, such as what is currently available for the Lynx controllers. For my own controllers and strings I would first use an oscilloscope to see how much current is going through the strings at particular portions of the AC half-wave cycle. There would a somewhat tedious task of recording that information, and calculating the power output of the lamps over the course of the curve. The response curve of the human eyes would then be factored in to determine how to divide up the half-wave cycle into 256 variable-width timeslots weighed for uniform visual appearance using some computer software or other. That's my story, and I'm sticking to it (at least until reality intervenes). Other methods of creating dimmer curve data, who creates it, and where the repositories would exist are topics for discussion.

Most of my renards are renard-plus models (for the external SSRs) so this won't end up being all that useful to me. I suppose I do have some of the fourstick devices that use the smaller pic chips. But just because I don't have a need for it, doesn't mean i won't contribute my ideas.

I really only use commercial led strings, so they are really good for consistency from string to string of the same type. But each color has it's own curve, and each string length has it's own curve. But all 100ct Blue strings for example, use the same curve. So every channel usually needs it's own curve.

I find that these commercial strings don't require a lot of a curved path to make it look good. But to be fair, i'm balancing them against pixels, not against incans. What I do need to do with almost all of these strings is raise the lower limit. Somewhere between 7 and 20% is typical. Filament LEDs tend to be in the 24-28 range. I do not change the upper limit. I leave that at 100%

Where I was going with the local only control is that if you need a computer and software to do it, you might as well just do the dimming curves in the sequencer. In that case, there's not much point to the hardware doing the work. But if it could be configured from the board itself, that would be very useful because you can be right in front of the lights you're adjusting, and tweak it right there in the field. This would obviously need some sort of board upgrade that included some physical interface. I suppose it could be a hardware programming tool that plugs into the data input port and allowed you to adjust the parameters and store it to the board.

I assume you're probably going to use look up tables for speed during execution. But you might consider building the LUTs dynamically at boot or at time of reconfig. That way you can reduce the required config to 3 parameters Lower Limit, Upper Limit and Gamma. The formula would be ValueOut = ((ValueIn/100) ^ Gamma) * UpperLimit + LowerLimit

[Spankyty]

I am an AC user! Let's all keep the tradition!!