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

This is a breakout of a topic started in the Texas Avenger driver thread. Toykeeper is looking to make a driver for a light saber with 4 channels to run RGBA LED’s.

Since it is technically using LED’s and not plasma, I figured it qualifies as an “other LED flashlight”. It could quite easily be used to light up your walk to the bathroom at night, in epic fashion no less….lol

Opps, I see what I did wrong, the cylinder is what holds the optic to the LED, I thought the emitter screwed on the other way around.

25mm I could do for sure.
25.4mm max diameter.
4x channels of 3x 7135s each.
Attiny25 pads? Or 85?
C1, C2, R5, D1
Pads for each channel ground out
Pads for OTC or E-switch
Pads for power and ground input

In that sized board that should actually not be too hard.

Thanks for making a thread for this! :slight_smile:

I’m hoping to fit a tiny85, but could probably get by with a 25 if necessary. It’ll just reduce the number or complexity of the modes, or maybe prevent onboard config menus. The code isn’t really formed yet.

Also, still debating about an e-switch or clicky switch, primarily because the e-switch would mean depending on a cheap charge port for the current path and I’ve had some issues with that on other sabers. Er, unless the driver was able to handle (block?) charge current without issues. The plan was to break current via clicky switch before connecting a charger, so the driver wouldn’t be at risk during charging. Alternately, the charge port can cut current, which works well… but when it’s connected it’s a really weak connection. So I can bypass it to avoid the weak point. But then I either need a clicky switch or a driver which doesn’t mind being connected while charging.

I’ve never attempted to charge a battery with the driver in the circuit, so I have no idea what to expect. Is that difficult? An e-switch would otherwise be easier and offers a richer UI, but I don’t want to fry the driver or rely on a weak connection.

Perhaps I should just use all three charge port pins as they’re intended, and not worry about the current going through a weak spring. I can replace it if it fails. Or I could maybe even just cram a clicky switch into the pommel instead of the chunk of lead I was planning to put there. Weight can be added by wrapping the battery in lead foil, perhaps.

… done thinking out loud now. :stuck_out_tongue_winking_eye:

Ok, if I have 25mm to work with I should have room to spare, so if there is anything else you need let me know. Tiny85 should be easy.

Thinking I will put the 7135’s on the top of the driver facing the LED’s and the MCU on the bottom facing the battery. Lots of extra space for pads and components this way but I will have to see how it all fits in the real world.

As far as charging it with the driver in the circuit. It appears the driver is on one “side” of the charge port and the battery is at the other “side”. So thus the current would not have to flow through the driver correct? It would simply seem the charging voltage.

So in this case the driver should be fine as long as the charger doesn’t output more then 6v (well it should never go over 4.2V for the batteries sake anyways).

In other words it should be fine to have the driver in the circuit during charging unless I am missing something. Now not sure it would work as expected while it was charging but I doubt you will be using it with a cord connected.

Ok, I think this is what you are looking for. Let me kow if you see any changes that need to be made.

It has the voltage divider, OCT / e-switch on the same pin since there was room for it, it is 1206 footprint for the OTC.

Obiously 4x channels of 3x 7135’s

Oh yeah,

jump = 0 ohm resistor to jump a trace
BR = bleeder resistor in case you want to do any kind of lighted tailcap, figured I would toss that on there since some form of glowing LED somewhere on the saber while off could look cool, and there was room.

Top of the driver (facing saber)

Bottom of driver (facing pamel)

Sweet! I’m looking forward to seeing what TK comes up with now for firmware!

I just realized the tiny25/45/85 might not be able to do full 4-channel PWM. Wikipedia’s summary lists it as “2 x 2 (sharing 3 pins)” with a note attached: “4 pins are usable, but only 3 unique generators can be attached. The 4th pin would be the inverse of OC1B on the 3rd pin.”

So, if I understand correctly, it can independently operate channels 1+2+3 or 1+2+4, but not anything involving 3+4 unless I don’t mind them being inverted from each other. When one is on, the other is off. I think.

With a RGBA emitter, maybe I could set it up so that opposite colors (blue+amber) are on channels 3 and 4, since they should theoretically never be on at the same time. And then flip a MCU flag somewhere to tell it which one is active at any given time, on the assumption that I never want both active simultaneously.

Or perhaps only use 3 channels; a pretty full rainbow can still be made from just R+G+B.

Or maybe do RGBW in a way where it is either in a color mode or white, but not both.

Or maybe RGBA with red+amber on the shared pins, and a restriction that they must always have inverse power levels.

Or maybe try to use a tiny84, which has more channels (and more pins in general).

Or maybe do soft PWM on channels 3+4 (or just 4?), but that’s going to look a bit weird (especially on an e-switch driver) because the pulse lengths won’t be as fast or as consistent. Probably would work best on RGBW with soft PWM on white, which would make irregularities merely look like a shimmer.

I think I’ll probably have to test some ideas before I figure out what works. The simplest is to do only RGB.

Not capable of four independent PWM channels?

Oh… :weary:

Well, I’m sure you’ll figure something out. I’d be for using the blue and amber on 3 and 4 and never having them activated together. But, of course, it’s your light saber! :smiley:

Wait… Dr Jones driver definitely uses pwm on all four colors. I can infinitely adjust each color separately including white and yet blend them all to be on at the same time. So there must be a way, no?

Yeah, he uses a different MCU.

He uses the atiny85.

Sorry, I got my RGBW’s crossed… I was thinking of tterev3 for some reason, even though you said DR Jones. :person_facepalming:

Edit: The Dr Jones RGBW driver uses software PWM.

Ok. I wasn’t aware of the difference. Is software pwm an option for us?

Yes, if somebody writes the code. That would be TK in this case. :wink:

Ahh… So, TK…? :wink:

Or, maybe you could talk DR Jones into tweaking his firmware for this new board. He may do that for a decent price. But, an open source solution would allow us to carry it forward and make changes and tweaks to our liking and to fit future boards, etc.

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.