Lighting control circuit, this time for sure
February 22, 2009
(2011-01-20) I’ve continued to work on this, if you are seriously interested, see also:
Adjustments to this circuit (resistors were wrong)
Light fabrication (older)
More light fabrication
More compact PCB, circular
Standlight switch PCB
Standlight and its (now obsolete) software
Packaging the PCBs appropriately
I’ve been tweaking the resistor values, and software, haven’t gotten around to publishing any of it yet.
Every system is a second system, or so it seems.
Update: it really, really helps to use the right chip. After being incredibly careful about every orientation of every weird transistor, I designed the board around a “LM387N”, which is not the chip I intended or the one that I had ordered — LM258 (usually referred to as LM358, but the 258 works in the cold). I was testing the board before putting on the big components, and it was just not working, and in the end, it seemed like the op-amp was on drugs. In the end, I got out a magnifying glass to check the label. DOH!
All is not lost, but the board needs to be rerouted. I’ll sort out the pins and test again.
Up-update: After installing a pin-scrambler, it works roughly as predicted. The most important part of the circuit, the high-end shunt control, delivers 3.85 volts to the base of the shunt transistor at 31.1 volts. This is a perhaps a half-volt earlier than planned, but it’s a half-volt to the safe side. In the high 20s, the shunt is not activated, as planned.
(1) the LED control sends a little more power to the lights than I had planned. Not lots, and it’s mostly a low-end effect. At 31.1, the control voltage is 1.7, which is exactly on target. At 22.5 it is 2.6 (plan, 3.1) and at 12.9 it is 3.24 (plan, 3.6) and at 9.6 it is 3.4 (plan, 3.8).
(2) the off-level shunt base voltage is 0.6, where the plan was 0.2. This should not be an issue with the particular Darlington shunt transistor; it claims to have a Vbe of 2.8 volts.
I’ve decided to take the plunge and learn how to get PCBs made.
The new hub (Shimano 3D71) produces too much power, at too high a voltage if your LED circuit does not use it all. The new plan uses a piecewise linear function of the input voltage to drive the voltage control circuit on a BuckPuck, plus a shunt to guard against overvoltage. The idea is that at lower power, enough light is produced, but at high power, the excess is dumped into the lights, with the intent that somewhere between 30 and 31 volts, the LEDs are receiving near-maximum power (9-10 watts), and the shunt is activated to drain up to an amp (30 watts) to keep the voltage from going any higher. The shunt circuit allows an external device (as many as 7 LEDs!) to dissipate the power instead of the transistor. My plan is to use an Endor Star (3 surface mount Luxeon Rebels on a single puck) that I bought but could not find a use for (could not heat sink effectively enough) to dissipate up to 10 watts externally. The goal is to ensure that the supply voltage is limited to 32 volts, no matter what, because the op-amp and the BuckPuck are rated for 32, the capacitors are rated for 35, and the diodes are rated for 40.
The combined circuit is just complex enough that it should be on a PCB, which should also make the result more durable. Vibration on a bicycle is a serious problem.
I buy parts here. I can make sense of their search, they generally have links to the documents that are inevitably necessary to figure things out.
More parts, more discussion of parts, more tutorials. A good place to find answers to Eagle questions.
This is where I learned how to make autorouting parameters more fumble-fingers-friendly.
Qucs is a circuit simulator, a little quirky, but it gets the job done, and gives me some confidence that my Great Designs will (or won’t, as the case may be) work.
CadSoft sells Eagle, software for designing printed circuit boards. The full version does way more than I need; the free version is enough for me, at least so far. The autorouter is mostly my friend, especially once I got used to its quirky habits.
- Consider device specs
Quite a few zener diodes don’t reach their rated voltage until they have quite a few milliamps flowing through them. If those milliamps are also flowing into the base of a transistor then the shunt will have a long, wasteful “on ramp”.
- Consider temperatures
Diodes, including LEDs, have a forward voltage that increases significantly when the temperature falls from 35 degrees to -5 degrees.
- Consider device precision
If you want a ramp that comes on at 30.5 plus-or-minus .3 volts, that is a 1% device. That suggests that the resistors had better be at least that good.
- Tinker and fiddle
Just because it looks like it works, how will it behave in the real world with slightly different parts? Tinker with element values, tinker with resistor gain, try monkeying with the forward voltage on transistors. Push things around till the simulation goes wonky, so that you can know how large your sensible-operation margins are.
- Instructables design rule changes
- Pouring polygons, joining nets
- Removing thermals
In the board editor, click rats-nest to get the polygons poured, then click info on a polygon. One of the info options is a “Thermals” checkbox. You might want thermals; they are intended to make it easier to solder onto a ground plane, which can sink a lot of heat from a soldering iron tip.
- Using restricted areas to make the autorouter behave
I had a heck of a time get the autorouter to behave, and not rip up polygons. One way to help it is to remove choices; by putting a long skinny polygon of tRestrict or bRestrict, I force it to not cut across some polygons (polygons are optional, tRestrict and bRestrict are not).
- Must have a 3-button mouse
Working on a Mac laptop, pretty quickly you hit one of those “hit control-right-button for next choice” items in the Eagle UI. Unfortunately, by default you hit control with the trackpad to get it to do “right button”, so you this doesn’t work. A 3-button mouse is a big help. (I went rummaging in System Preferences, and just now discovered the two-fingered “secondary click”, not sure that works with control also).
- Checking design rules
- Important layers
- Checking signals
Oh yeah, about the copyright. I’d like to open source it, but cannot figure out how to put the whole GPL on one PCB. I’m a bit ticked off at all the bicycle lighting companies; everything costs too much, way too much. Bought retail, the cost of the components on this board is in the 15-20 dollar range, plus the buckpuck, which is another $15. LEDs+lenses cost about $10 apiece, you need at least 3 for a bike (4 is better), unless you want to also use an LED to help burn off excess voltage. The board itself, quantity 1, costs $45, with shipping and handling. SO, all the parts, except for the hub, cost under $100, and direct 200+ lumens out the front of the bike, and boatloads to the back. Dinotte is probably the best deal out there, and their 200 lumen headlight is $160 all by itself. Add a taillight, another $160. Add a fog/running light, another $160 — here, a fog light costs you an SPDT plus two more LEDs (i.e., $25 more).
This graph shows the intended operation of the varying power control.
At low speeds, the buckpuck is not really on, but if the drive current is low it will start to come on at around 10 volts. 350 mA is the goal; that corresponds to 16 volts, which the hub seems to cheerfully generate if not all its current is sunk. Beyond that, nothing exceeds like excess, we’ve got to do something with the power, might as well turn it into light.
The “efficiency” line is an approximation of the Buckpuck’s predicted efficiency, to allow a rough extrapolation of current draw from the hub/rectifier. The design goal was 200 mA, which correponds to greatest efficiency, according to the data at pilom.com. Higher voltages and lower currents are good; they correspond to lower drag on the bike, and less heat in the hub itself.
The clamp was much harder to get right. “Zener” diodes are not as stable as you might like, and plain old diodes can vary from about 0.6 to 0.8 volts in their forward bias, depending on temperature. It was very helpful to learn that Qucs includes temperature data for many of their devices, so that the shunt could be simulated at various inhumane temperatures. I see this temperature dependence already in the shunt that I use; it comes on more easily when it is cold. So, don’t use Zeners, do use voltage reference devices.
Note: Pr2.I is the current through the shunt. VREFmilliAmps is the current through the voltage reference that controls the shunt. Pr1.V is the drive voltage from the op-amp to the base of the shunt transistor (which is a Darlington, beta of about 20000).
I had to add three devices (two voltage references, and a buckpuck) to the Eagle library. Here they are. The Buckpuck includes a hole drilled underneath its trim pot, if you care to use it. I hope it’s in the right place.
I modeled the two circuits separately in Qucs.
It definitely occurred to me that I could probably program this up with a PIC microcontroller instead (if I could program a PIC microcontroller), and use that to get special modes, allow secondary operation from or charging of batteries, etc. I would not trust the PIC to run the shunt, though.
The general plan would be to feed AC1 and AC2 to a comparator to keep track of wheel rotation, monitor V+ with an A/D to determine the BuckPuck control voltage, and include a current sense resistor on the battery stack to keep track of the cumulative (dis)charge. Outputs would be a relay or MOSFET control voltage on the battery, plus several bits (4?) fed to a D/A (resistors plus an op-amp) to derive a control voltage. So it could definitely be done — but not today.
Turns out I could not help myself; after looking at microprocessor choices, the Atmel chips look like the best bet, mostly because of a better set of tools and community. I planned something that is Arduino-like; it has the same connector, and mostly the same electronics, but some of the pins are different,
and the clock is internal, both for reduced footprint and reduced power consumption. It’s probably best to start with the analog version of this controller first, but this would be a fun project.
I’m still tinkering (I really need to stop), with the current plan being to line up all three headers on the same 1/10 inch grid, so that a daughter board (carrying switching and sensors for battery charging, etc) could be added. One reason for a 3-header daughter board is to make it completely impossible to plug it in wrong, because one of the pins is now the unregulated up-to-32V DC high-power supply. That could cook some parts.
I looked further into battery charging; “optimal” charging is hard, and I think the best bet would be to aim for casual battery management. Since a stack of 20 AA batteries (20-24 volts) could run the lights for perhaps 10 hours at full charge, it is not necessary to aim for 100% charge, and stopping short would be safer. Maybe later.