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

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.

incredibly impressive. First I thought you were going to be using triples on MPCBs with an off-the-shelf CC driver, then I saw that you were designing your own board and driver PLUS soldering it all together. I've soldered a couple of bare LEDs to pads which was absolutely no fun at all. Sorry to hear about the respin, but even the pros make mistakes, so I wouldn't be too hard on yourself. I've followed George from Taskled's posts on designing and building drivers and it's quite an eye opener, even if I don't always understand what the hell he's on about.

A few questions:

1) are you going to be running all the same optics for each triple or mix'n'matching? I would have thought that using a couple of ellipticals and a mix of mediums and spots for the rest would give you the best of both worlds for an automotive application. I'm a little surprised not to see an aspheric or two thrown in as well, although I guess that they're too focused for a fixed position light.

2) how are the LED strings wired? Each triple in parallel then a series string of triples?

3) have you modeled the LED temperature at all? Efficiency drops off from 25C with heat, to ~85% when 100C at the emitter (not the housing where your thermocouple would be). I'm not sure what the temperature differential between the housing and the LED will be (5C? Perhaps 10C, although that's more common with MPCBs) but you could be looking at 80% efficiency at your 100C trip point, at which point you could be running them at 2.2-2.5A for the same output but less heat and load on your alternator. The LEDs should last longer too, although I've no source for LED temperature vs. longevity.

Sorry everyone that I haven't responded or provided updates - I got incredibly busy with work again, and I've had very little time to keep up my with this project. Finally got a big project finished up yesterday, so I'll have a little more time to put into it. The new circuit boards shipped yesterday, meaning I will have them on Monday.

It's my pleasure! I'm thrilled that some people are following my development of this project - I think I said it back in the beginning of the thread, but it's so much fun to develop in a public forum where others can share and comment on the progress. Most of what I do is very structured and the vast majority will never be shared with but a few people.

I see a lot of build threads around here, so I'm not so sure it's rare, but I'm happy that it's appreciated anyway. Please don't hesitate to ask questions either! There's a reason I'm posting the entire design and build experience.

PPtk

Yeah, I decided from the beginning that if I was going to design something, it was going to be ground-up. The only off the shelf parts are the components on the circuit boards and the optics - and even then, I'm not using a traditional Switch-Mode controller. I instead opted for a single DSP that will control the switch gates of all 8 supplies. In an LED light-bar like this, I'm breaking new ground, for sure. In fact, there are very few products in the world right now that use a DSP to control the SMPS of even a single LED - let alone 24 high power ones.

The comment about the pros making mistakes.. Trust me, I'm fully aware.. And disappointingly, I am one of the 'pros'.. I'm not really that upset about it - it happens. I'm helping another engineer right now with a product (commercial nature) that is still not working at Rev Q (Yep, ABCDEFGHIJKLMNOPQ) - and he's a very good engineer!

I'm going to be using three different optics. They're all the CUTE-3 optics from LEDiL, but I'll be using four of the narrow optics, two of the medium optics and two of the wide. This should give me a powerful throw and a ton of wide angle spill and cover everything in between. I'm expecting a long-reaching WALL of light. In the unit, the optics will be positioned, W-M-N-N-N-N-M-W.

Each triple is a series of the three emitters (roughly 9.9V Vf). The triples are individually driven using their own SMPS controlled by the DSP, so they're independent from each other. I could run every triple at a different current, if I wanted.

I have modeled it using the very thin FR-4 circuit board with tons of vias (which performs BETTER than an MCPCB), and I modeled the emitter itself using CREE's published thermal resistance through the package. At 3A per emitter (10W, roughly), I'm looking at a DeltaT of about 31C from the emitter to the enclosure (25C through the emitter package and 6C through the PCB). at my 100C trip-point, the emitters themselves will be running at about 131C. 100C is the trip-point, though, not the expected run-temperature. My study suggests that even on a very hot 90F day, the enclosure temp should not exceed about 78C - and this is worst case scenario with almost no air-movement. Just a little air-movement from wind or from driving would reduce that temperature drastically (10s of C). Real-world, normal use temperature of the enclosure is probably about 60-65C, meaning the emitters would be running 91-96C.

When talking about the enclosure to LED temp, you mentioned 5 or 10C. An MCPCB 'might' be able to maintain 5 or 10C from enclosure to LED Package, but remember the temp that matters isn't package - it's the actual diode junction. The XM-L has a 2.5C/W thermal resistance from Packge to Junction, so a MCPCB that could maintain 10C from Enclosure to Package would be able to maintain a 35C Delta from Enclosure to Junction when the emitter is running at 10 Watts. To get an XM-L to output 100% of it's rated Lumens, one would have to mount it on an MCPCB and then keep the MCPCB at minus 5 or 10C.

CREE rates the XM-L to operate at up to 150C Junction temperature, so with 31C Delta between enclosure and junction, I'm perfectly safe cutting off at 100C enclosure temp.

PPtk

The bluetooth works! I mounted the bluetooth module on the Rev.A circuit board and put the pcb in the enclsoure. I was able to make a connection to the module using my Netbook, send data to the DSP and get data back! Range is pretty good, as well - about 30 yards (meters) if I am somewhere in front of the enclosure and 18-20 yards (meters) if I'm behind it. Much better than I expected, actually - since the bluetooth module is wrapped in a 4 pound aluminum shell. I'm just using the bluetooth module as a dumb bluetooth->serial converter since I can handle the data-packet in the DSP.

I started cobbling together a bit of android code, but god, I'm definitely no Android developer. If anyone here is good at writing Android code, I'll trade you some hardware engineering/design for some Code :)

PPtk