Finally giving in to LED's

ctmal said:
I did read that the Lynx controllers supported this at one point but I don't know anyone who has any of those to test out.
Click to expand...
I have several lynx controllers that I could test this with.

Sent from my SM-G930R4 using Tapatalk
 
P. Short said:
I've got a project going for a minimalist 4-channel AC dimming controller, I'll try to incorporate at least 10-bit dimming (and maybe up to 12-bits) into it. It could be fitted back into the Renard controllers at some point, especially the PIC16F1825 code. There would still be 256 levels of dimming, but much more evenly spread out in terms of brightness. I would likely try to make the dimming curve data to be downloadable and stored in the controller, with the potential to have a separate table for each channel (useful because I suspect that different color LED strings would have different behavior).

This would be for after this display season, and is not likely to be widely disseminated, as I don't know of more than one person who is expanding an AC string-based display.
Click to expand...
Phil,
I continue to use AC lights so I would be interested in this.

Sent from my SM-G930R4 using Tapatalk
 
Phil,
We are actually returning to using a lot more AC lights, so I too would be interested in the development of this.
 
I'm still playing around with this, although not at the point of testing on hardware.

There are some issues. First, I'm not planning on porting this to the PIC16F688. The principle reason for this that the dimming curve tables would reside in program memory, and the '688 doesn't provide a method for writing to the program memory other than in a programmer. The other difficulty is that the highest clock rate without using an external oscillator is 8Mhz, which is really too slow.

The most likely target for porting this to Renard hardware is the PIC16F1825, which already has code to allow it to replace the '688. It's still not the fastest part, which might limit the curves that it can provide. It still remains to be seen if I get around to coming up with a finer-grained dimmer code like I've been discussing above.

Right now the object of my development project is the PIC24F04KL100, which is a much faster part than the PIC16 parts due to it's higher instruction rate and better instruction set. It's neither pin-compatible nor program compatible with the PIC16 parts. The project is currently targeting the use of a nRF24L10 radio transceiver for getting data into the controller, so that would have to replaced for any re-targeting to the Renard platform.

Hopefully I'll have some results in a few weeks when boards arrive.
 
I put a dimming curve into the PIC16F1825s on my REN64 6 years ago. Worked great with my AC lights. I even made the curve uploadable.
 
Interesting.

How did that work? Did you just translate each byte into another byte without changing the fundamental dimming code, in other words retaining the constant 30 uS interval between when the AC outputs could change? Or did you do something to make the timing less coarse?
 
Update - I'm now playing around with a more or less standalone 4-channel controller on a 1"x2" board (well, actually 2.5cm x 5.0cm), intended to fit in a 1" pvc pipe. The microcontroller for this design is a PIC12F1572. This board is going to need a new layout because a few of the components close to the edge of the board stick up too high (especially the SPT1 cable for the AC outputs).

At the moment I'm playing around with different dimmer curves to come up with a fairly uniform brightness appearance as the level varies between 0 and 100%. With the el-cheapo going-out-of-business K-Mart LED strings it appears that my eyes are only sensitive to the peak brightness, not to average brightness levels (i.e. it's only timing of the start of on-time that matters, not the percentage of on-time per AC cycle). These LEDs do not appear to have built-in capacitors to reduce flicker, which may matter). This does seem to need more investigation and testing.
 
Here's our lasted update: All of our LED lights came in after the huge delay...we changed all of our lights to LEDs. I did all of the suggested things for LED's, like adding resistors to the outputs, etc.(thanks for all the tips throughout the forum for that).

We finally finished setup tonight and turned everything on. Let me tell you....these things are BRIGHT! Haha...all the greens are green, all the reds are red, everything looks GREAT! I'm soooooo happy with it right now.
 
Great to hear. Thanks for the follow up. Where's the pictures?

And those colors will stay that way year after year. No chipping or fading paint on the bulbs.
 
jchuchla said:
Great to hear. Thanks for the follow up. Where's the pictures?

And those colors will stay that way year after year. No chipping or fading paint on the bulbs.
Click to expand...

No pictures yet...I'll have to talk my brother into pulling out the drone again. And yes! I'm so happy there's not chipping of the paint.
 
P. Short said:
Interesting.

How did that work? Did you just translate each byte into another byte without changing the fundamental dimming code, in other words retaining the constant 30 uS interval between when the AC outputs could change? Or did you do something to make the timing less coarse?
Click to expand...
Sorry. Just saw this. Yeas I left the basic intensity generation alone (256 steps) and mapped the dimming curve to the steps in a way that gave smoother dimming. More steps would allow me to make it even smoother but that would probably use up too much CPU time.
 
You must log in or register to reply here.
Back
Top