Just off the CNC - Update: It's Alve!

Wow, you just keep impressing. The lighting is going to be wirelessly controlled? You should definitely hook it up to an alarm, also. Imagine that thing strobing(or fading on and off) when someone is trying to steal your rig? That will definitely get some attention!

Hmmm . . . . I don't know, that olive-drab is looking mighty good . . .

wishywashyFoy

Seriously, an Android app? I didn't think this project could get much cooler.

Hmmm...build in a strobe feature for some crazy night time offroading through the woods? ;)

Awesome, I like awesome ;) Thanks for the compliment.

Never even thought about doing custom flashlights - I have too much on my plate as it is :) Some day, though, who knows.. I love to do this kind of stuff.

PPtk

Yep, that's the plan anyway. We'll see how well the bluetooth signal gets through and how well I can hack together an Android app (I'm assuming its not THAT different from designing for embedded linux).

Never thought of hooking up to the alarm output - good idea! That would definitely be hard to miss.

PPtk

You're telling me. I keep telling myself no, but then I look at the picture, and.. Well.. I like it..

PPtk

Haha.. Yeah, Seriously. As said, We'll see. It's on the "Highly experimental" list.

Built in Strobe is already planned. I can control each group of 3 emitters (8 Groups) separately. Each group is independently variable in brightness from completely off to completely on (3 amps) in 1024 steps, and I can change that value every tenth of a millisecond. At the highest rate, I could strobe from fully off to fully on at 5000 flashes PER SECOND. Now, I would never do it that fast since the human eye can't see anywhere near that fast :) But it's nice to know I could if I wanted to. A more reasonable strobe frequency is probably a couple of hundred flashes per MINUTE. Even more obnoxious would be a pattern that set a random brightness a few times per second.

I could actually program a function into the android app (pretty easily, in fact!) that sent something like morse-code as flashes IN THE BEAM so quickly that a human could not even notice it's there, but a photo-detector could see the flashes and read out the code :)

PPtk

Well, the hardware development bug has bitten me. I'm going to have to re-make the circuit boards. Damn.

The N-Channel MOSFETs that control the buck converters for each group of LEDs are really good parts. They have an incredibly low RDSon resistance of only 11 milliohms (33 millivolts of drop at 3A) which is great. Unfortunately, they have a pretty high gate charge capacitance. I underestimated this value (datasheet was very wishy-washy about it) and my fet drivers don't have enough stones to turn the fets on and off quickly enough.

I'm running the buck-converter at 500 Khz, which helps to keep the inductor physically small. Unfortunately, 500 Khz means that I have to transition from off to on and back to off five-hundred-thousand times every second. A million transitions per second. That leaves me with a full swing time of only 2 micro-seconds.

With the 1A drivers that I currently have on the board, I'm seeing rise and fall times of almost 500 nano-seconds (NOT GOOD). This means that I'm spending about half of the cycle in the linear region of the fet where it burns off power as heat like crazy. It also means that I don't have very good fine-control of current.

I cobbled a 6A driver onto the board using wires and way too much solder. I also increased the gate voltage from 5V to 10V, and my rise/fall times fell to less than 51 nano-seconds. Thats where I want to be. 50 * 2 / 2000 = 5% of the time in the linear region - which is a much much much better number.

I have to re-spin the circuit boards because I can't get any drivers bigger than 2 amps in the same package, so anything bigger won't physically fit. I knew hoping for a fully working design at Rev.A was too optimistic :) Designing with 1 amp drivers was stupid on my part, I'm face-palming myself for this one.

I already re-did the layout and sent the new boards out for fab - have them back in about a week. Getting the (much) larger drivers to fit in the confined space that I have available was not easy. I don't think I could add one single component to the design - it's packed. I was really worried that I wasn't going to be able to route the whole thing in 2 layers which would have forced me to move to a 4 layer board. Luck was with me, though, and I got it all routed without touching my high-current traces.

The good news is that I was able to test everything else, and it all works. The DSP is controlling the LED's beautifully and the whole system is pretty quiet from a noise/EMI perspective. Turning 8 groups of 3 Amp LED's on and off a million times a second is not an easy thing to do without spewing noise all over the place, so I'm thrilled that at least that is stable and quiet. I'm running the DSP in spread-spectrum mode, where the buck-converter frequency actually varies between 495 and 505 Khz, which helps to spread the EMI out a lot. EMI increased a tiny bit with the faster rise and fall times of the bigger driver, but not even close to enough to worry me.

Since I have nothing to do now until the new boards show up, I figure I'll start tinkering with the bluetooth radio. I can solder it down to the current board, put the board in the enclosure, and see if I can get a connection to it through the enclosure. With any luck, by the time the new board shows up, I'll have an answer as to whether bluetooth is going to work or not. Maybe even have a semi-functional Android app written. Downloading the Android SDK now.

PPtk

Ahhhh, Pilot; I'm loving the keep-it-positive attitude and here's hoping ver. 1.2 will be stable. Was the gate charge capacitance a complete unknown or did you expect it to behave differently?

(Foy, talkin' big like he knows what gate charge cappuccino is)

After this, the SDK should be a breeze.

halfcaffrapFoy

Youmademydayfoy

It wasn't a complete unknown, but think of it like an answer from your wife about where she wants to go to dinner. I estimated a little on the low side (which was idiotic of me), but it's much higher than I ever expected it to be. I can see why the manufacturer of the fet didn't want to make it clear in the datasheet. The great RDSon still makes it worth-while to use these fets, though. I just wish International Rectifier would have been more forthcoming in their documentation. It would have saved me a bunch of time and quite a bit of money on a new set of boards. Oh well, designing custom hardware is rarely straightforward.

To give you a very brief overview of gate charge cappuccino, a fet is a type of transistor. It can be turned on and off by applying a voltage to it's "Gate" (The third pin on a typical fet). In my application, the Source of the fet (commonly known as "The Bottom") connects to Ground. The Drain of the fet connects to the end of the chain of 3 LED's (commonly known as "The Top"). When the gate is brought low (to "The Bottom"), no current is allowed to flow, and the switch is off. When the gate is taken to a certain voltage above "The Bottom" - known as the gate threshold voltage, the switch starts to turn on. It's at this point that the fet acts as a variable resistor. AT the threshold voltage, the fet is a high-ohm resistor, and a lot of voltage is burnt off as heat in the fet. As the voltage of the gate continues to rise, the resistance of the fet continues to fall. Eventually, the gate voltage gets high enough that the fet reaches "ON" which is where it has a very low resistance of RDSon (in this case, 11 milliohms) and very little voltage is dropped, resulting in very little loss and very little heat.

The reason that it takes time to go from off to on is that the gate behaves like a capacitor. You have to "Charge" it up - and this takes current. A fet with a low gate-charge-capacitance can be charged very quickly without much current, but to charge the gate of a fet like the one I'm using in a very short period of time, you have to give it a LOT of current. This fet's gate pretends that it's about a 1800 pico farad capacitor - which is pretty huge for a fet, but not completely insane. To reach "ON", I have to charge that 1800pF to about 4.5V. The faster I can do this, the more efficient the whole thing will be, the less heat it will generate, and the more I'll be able to control the brightness to a very fine degree.

Oh, I don't know about that. It's been a while since I wrote software for a linux-like operating system. I'm much more a hardware guy than I am a software one.. we'll see :)

PPtk

PilotPTK you must be some kind of genius because I was able to understand that explanation. I can’t figure out how to scroll to the bottom of the text block when I try to quote your post on my phone but I understood that.

This is very interesting work. Sounds like you have it all sorted out. Bummer about the respin, but if that is the bulk of the issues then you have done quite well!

How are you driving the FETs? With smaller ones, FET array, bjt? I ask because I've recently encountered a problem with slow rise times for a power FET, but the problem was not due to current limitations of the driver circuit. It was due to the high gate capacitance of the driver. Swapped it out and voila.

I'm thrilled you were able to understand :)
While I was typing that explanation, I was thinking to myself - "You sound like a blithering idiot and no-one is going to know what you're talking about" :)

And, I'm no genius - I'd be sitting on a beach somewhere if I were a genius :)

Yeah, the respin in a bit of a drag, but that's the way it goes.. Not really a big deal, and I knew from moment one that having everything work on the first rev was optomistic - to say the least.

I'm using dedicated Low-Side Non-Inverting MOSFET Gate Driver parts.
http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en028725

the MCP1406 is inverting if you need that instead. Exact same part, opposite logic.

They're rated for 55ns in->out times with 40ns of rise/fall into 6800pF - but I'm seeing numbers even better than what they're rated for. 51ns for the entire process. I'm looking at the transition with a 500 MHZ scope, so I'm pretty confident that my numbers are accurate and that the datasheet is just cautious.

PPtk

Thanks for all the explanations here - I know basically zero about electronics.

How consistent are the parts going to be? I'd imagine that the data sheet gives some sort of average with parts +/- however many standard deviations being sold as something else.

Glad you're enjoying my rambling :)

These types of parts are pretty consistent. I tried 12 of them, and all 12 were full transition of 51-55ns in my application That datasheet lists typical delay of 40ns with a MAX of 55ns. Even if I got a part at the max, I believe my full transition times would still be under 75ns - which is still very acceptable.

PPtk

Pilot -

Your ability to explain the complex/unknown (to me, at least) is part of what I find so compelling about this project and why I look forward each day to what new successes and/or hurdles you've encountered. Honestly; I knew you were working from scratch but I guess I didn't realize what starting from zero really means on something like this. In Foy's world, capacitors do or fail to do what they're supposed to and I never considered that somebody has to figure all that out so that my device works.

needstogetoutmoreFoy

Foy -

I'm really happy that I'm able to enhance your understandings of things. It truly does make me as happy to teach as it does to learn -- and I love to learn.

Part of the reason that this build is as complicated as it is lies in the fact that I'm using a very high performance switching regulation scheme. Linear driver designs (even if they have PWM for brightness) are MUCH simpler. I (or anyone with a basic understand of electronics) could design a driver with multiple brightness levels using a linear regulator in about 3 minutes and be 99.9999% confident that it will work perfectly the first time. Problem is, it won't be very efficient at all - and it will generate far more heat. Heat is the reason I did not go with a linear regulator.

Switched Mode supplies, though, are as much art as they are science. Especially in this case, the switch operates at very high speed, and signals stop looking like the nice pretty square waves that you would get in a perfect world. Our world isn't perfect, and all kinds of factors start to come in to play. Things like gate-charge-capacitance, trace length, cross-talk, EMI/noise.. Even the exact layout of the high current portion which includes the load (LED's), output capacitor, diode and switch (fet) - it matters.. The shorter that path can be kept, the better it will work.

It is pretty amazing it all works, actually :) So many factors work against a design being functional - and the only thing working for it is the designer who's trying to take hundreds of different variables into account and make them all dance in harmony. Every single part has it's strengths and weaknesses - overestimate one strength or underestimate one weakness (such as I did with the gate-charge) and you have a door-stop rather than a functional design. Sometimes, it's just the way you ran one trace next to another on the circuit board that renders a design worthless - route a high-impedence analog signal next to a high speed and high current carrying one, and you end up with so much cross talk that the intended signal is completely washed out.

I hope that you, and others following this thread, are learning a lot, and maybe gaining some appreciation (as you said) for just how much goes into making something like this work. It's a fun ride to take - and even when things don't work out (like they didn't in my first try), you get to learn something.

The new circuit boards are going to be a few more days delayed. Since I have much more confidence in Rev B, as I've tested everything and only made one change (which has been partially tested by wire-wrapping it in), I'm pretty sure everything is going to work. Based on that confidence, I've asked the circuit board shop to make the board with pads finished in Gold rather than HASL (Hot-Air Solder Leveling). Gold finish will give me a much flatter surface - not really a big deal on the side where the parts go, but it will allow a much better thermal bond on the back side where the copper mates with the aluminum enclosure. The gold doesn't really add much to the cost (about 10 bucks, in fact), but it does take the circuit board shop an additional two business days to process the boards. The little bit of extra time is worth it to me.

Earlier this evening, I soldered the blue-tooth module down. I'm tired, and I'm not going to do anything more with it tonight, but tomorrow or tuesday, i'll start trying to make a connection to it. We'll see how the signal does through the enclosure.

PPtk

Just wanted to say that it is really appreciated that you not only share your design but also take the time to document and share the progress and setbacks AND explain us folks how come something did or did not do as intended. That is rare man. And appreciated... More than you know.