4 channel Light saber driver design, may the light be with you.

I’ve been trying to get ahold of him but he hasn’t been around the forum for a while and I don’t have any other contact info for him. I would be willing to pay for a completed rgbw firmware that I could use on self built drivers. Idk if he would’ve good with that though?

His driver firmwares are proprietary code. But, he used to sell pre-flashed MCUs. I would think he’d be willing to make a tweaked version for a new board if there was enough demand. How different is your board from his self-designed RGBW driver? If it’s basically the same, or not much different, his code may already work for you. It would be nice if you could get in touch with him. But, like I said above, it would be even better if someone came up with an open source RGBW firmware that was as nice as DR Jones or tterev3 code.

Here’s the DR Jones firmware website.

Ya. For me, his existing firmware is great! If I had the choice I would change the mode to clicks configuration, but if I could get an MCU from him as, I would be thrilled. I have one of his drivers left and I plan on removing the programmed MCU to place on my own driver layout. I’m working on a multilayered driver to power 4 XML rgbw led’s as well as one xpg3 high cri led. It will control three banks of 7135s and one fet channel for the white. I’m going to parallel the xpg3 along with the four white dies. When testing, I can get 4amps to the xpg3 and 1amp to each white die when in parallel.

At first, I was planning on using an escutcheon modified BLF d80, but room was very very tight. I found a way to pack it in with a custom driver design, but I finally surrendered to the pk26 as a host. After receiving the pk26, I’m still not certain it will work out. Even if it never works out, it’s been fun thinking about a 40w rgbw pocketable flashlight. (40w for about 40sec that is :slight_smile: )

TK, if you want his driver board minus the MCU for testing, let me know.
(Edit: that is, dr jones driver board I am referring to.)

I found this instructable for software PWM. I’m not near versed enough to know what this entails, but the instructable gives a little hope for another good four individually addressable PWM controlled driver.

Wow! Thanks LightRider!

I would love to see some action here. TK? …Have you got anything to report? …TK? …Anybody?

I got kind of ninja’d by other parts of life for a few months.

Also, um, I don’t actually have any driver boards to print and build. Texas_Ace, do you have these up on oshpark? I didn’t see the saber driver listed there.

I never heard back from you on weather it was ok and what you wanted so I didn’t bother uploading it in case it needed changes. lol

If you think it will work for you I can upload it.

I think it’ll probably work. If you’re willing though, it’d also be nice to have one with a pin and pad for an e-switch instead of the voltage divider. I think I can probably use the inverted VCC method for measuring voltage, and an e-switch likely makes the interface easier to navigate.

Or I could maybe use the 4th PWM pin for an e-switch, and use only three colors. I’m not sure how much value there is in adding a 4th color channel, and it should be fairly easy to stick the switch wire into one of the vias on pin 2 or 3.

Is there no use for adding a little bit of white to the mix? You can get some bright tinted colors this way. But I must say, I have no idea how a saber is yo be used:)

The idea was that you could use the R1/R2 pads to setup the e-switch if you didn’t need the voltage divider. I went ahead and added a dedicated set of pads for the switch though.

Here is the oshpark link: OSH Park ~

Software PWM can work very well as long as you have a timer available (that is not used for anything else) and don't frequently need to suspend interrupts (such as to write to NVM) which will glitch the PWM output. It's fairly easy to implement - here's pseudocode that you would put in an 8-bit timer's overflow interrupt routine. The only overhead you'll need is a variable for the output (duty cycle) you want and a flag bit that toggles to keep track of the phase of the output.

if timer overflowed to zero (interrupt):

toggle the flag

if the flag is set:

turn on the output pin

load the timer with a value of (255 - duty cycle)

else if the flag is clear:

turn off the output pin

load the timer with the value of duty cycle

The way this works is by scheduling the following interrupt to occur in a variable amount of time. By loading the timer with a low value, it will take longer before overflowing past 255 again and the subsequent interrupt will scheduled further out, and vice versa for a high value. So as an example, say the timer runs at 1MHz and the duty cycle is set to 200 (of 255). The interrupt will fire and turn on the output, then load 55 into the timer. The timer then has to count up 200 cycles before firing the interrupt again, when the output is turned off. Then 200 is loaded into the timer, so it only has to count up 55 cycles before firing again and starting the process over. This gives a high output for 200us and a low output for 55us, so we get a ~4kHz PWM signal at ~78% duty.

This can be extended slightly to give better performance at the extremes (0 and 100%) by adding a test for 0 and 100% duty before setting the output:

if timer overflowed to zero (interrupt):

toggle the flag

if the flag is set:

if duty cycle is not zero, turn on the output pin

load the timer with a value of (255 - duty cycle)

else if the flag is clear:

if duty cycle is not 255, turn off the output pin

load the timer with the value of duty cycle

My AVR skills are rusty but I think a simple implementation would look like this, assuming you set up timer0 as an 8-bit timer with an overflow interrupt:

bool flag;

uint duty;

ISR(TIM0_OVF_vect)

{

flag=~flag;

if(flag){

output_pin=1;

TCNT0=(255-duty);

}

else{

output_pin=0;

TCNT0=duty;

}

}

Thanks tterev3! :+1:

TA, is this board optimized to (also) work with the new 4-channel firmware from Flintrock? I know you made this for TK, but we might like to use it in a regular flashlight too. :innocent:

I’d love to see some of our firmware people comment a bit about what tterev3 said, too (ToyKeeper, Tom, Flintrock).

It should work fine with the right firmware although it is not really setup for a flashlight and is pretty large.

All 4 of the output pins can be PWM so it is just a matter of getting firmware that takes advantage of it.

I missed David EF's post. never mind. Anyway, yeah, the code should work. It's not exactly like ttrev3 said, but similar. The PWM match is already built into the chip, so it uses a match itnerrupt and an overflow int (and I doubt you'll find smaller ones anywhere). Just the 4th waveform generator that was missing. Anyway, yeah, it should be ready to go if you're happy with preset mode ramps, and it can get the eswitch and Vcc read too. I hadn't known about this thread. I'm not that interested in sabres but it seems like a fun test case.

Well, it’s less than 26mm, so it’s large but not huge. There are some lights, especially 26650 lights, that can use that large of a driver. I did notice that it doesn’t have a ground ring. That in itself will make it a challenge to use in most lights. But, the parts selection and layout are what I was referring to when asking about the compatibility. If the circuit schematic is basically compatible, then a flashlight-friendly board can be made easily. That’s what I’m hoping for. :wink:

TA I think you'll find it pretty easy to customize the simplified attiny.h to whatever layout you've got. If really needed it is even possible to move the 4th pwm from the traditional cap pin to the traditional voltage pin, but I did not include that as a "user-visible" option.

.. or just get me some details and I'll set it up.

With the almost staggering number of mode choices available in a single firmware now (by using mode groups and config options), I think preset mixes would be a fine place to start. The modes would just need to be RGBW-level modes, versus the white-lighting-level modes we use normally.

In the future, it would be great to have a dual-switch control where one switch moves you through channels and the other operates smooth ramping (and/or typical “modes”) . Then it will just be “click A-switch” to choose which channel to change, then “click-hold B-switch” to ramp brightness of that channel (or “click B-switch” to use preset “modes”), then back to “click A-switch” to select the next channel and continue. I don’t know how hard this will be to write and I don’t want to make demands on anyone’s time. It’s just a dream of mine for now. :innocent: