An experimental torch/flashlight intended to be safer for eyes, completely inspired by and built upon the TritiLED project

Similar projects worth following
Having followed Ted Yapo's TritiLED project, I'm using it as inspiration for a small torch for my children. Ted has been fantastic at coaching me in an area of electronics new to me, so he gets the project named after him.

Caveats about making this project or a derivative for children - be sensible. Nothing diminishes your responsibility to check this project or a derivative is safe for your applications and situations.

Primary aims:
1) A torch for the user to find their way around a dark room or for limited reading under a duvet.
2) Safer for the eyes than white or blue LEDs (if directly looking at the LEDs).
3) Turns itself off after a while to conserve battery, unless user resets the "on" period.
4) An "always on" glow/pulse/blink to allow the user to find it in the dark (without keeping everyone awake).

Secondary aims:
5) Long life between charges.
6) Easy and safe charging.
7) Learn about efficiently driving LED light sources.


I wanted to make this because my son is probably going to shine whatever torch he can find in his eyes and my understanding is that shorter wavelengths in the blue and UV region can damage your eyes if too much enters your eye. As I understand it, most white LEDs rely on a blue LED stimulating phospor which adds in the red/green or yellow frequencies to make us think the light is white. Secondly, blue light isn't going to help him get to sleep if he uses his torch under the duvet to read - not enough melatonin. Added to this is a desire to keep the occasional flash in my eyes at night from ruining any night vision I may have, so I've decided to explore longer wavelengths. In the UK, most streetlights have been sodium lamps (until white LEDs started to replace them) so orange-yellow is a familiar tone and we'll start with that. We can move on to green and perhaps the cyan LEDs used in TritiLED but I think yellow would be a nicer colour if we can only have one wavelength. The thought of combined wavelengths sounds attractive but I'm not keen on the complexity that various LED forward voltages and optimum efficiency currents would introduce.


So, I want to drive an LED or two from a battery and have a timer to turn it off after a certain period. This will hopefully prevent battery drain if my son forgets to turn the thing to SLEEP mode (as there's not going to be a planned "off" mode). I'm aware that different modes could be achieved with a discreet component circuit but for me, a bare microcontroller with decent low power sleep and watchdog modes is what I'm after. Depending on the eventual feature set, I think an ATtiny85 should suffice and is available in a hand-solderable SMD package.


Driving LEDs is something I've tried before but not seriously moved beyond resistors to control the current. I've been amazed at how small a current can generate a visible light output but when I discovered @Ted Yapo's #TritiLED project, the care that has gone into eeking out the best photon per coulomb ratio is admirable. If I get stuck using the simple driver design from the V2 TritiLED, I'll go back to current-limiting resistors.


LED driving efficiency isn't really essential here - I do plan to use a decent 18650 with perhaps 3400mAh and compared to the ON mode, the energy lost in the resistors while minimal (microAmps) current is flowing is negligible. Most of the energy conservation will come from the auto-SLEEP feature that I currently envisage will start a timer when the torch is switched to ON and will modulate the light output after, say, 10 minutes. This alerts the user who then has two minutes to press the control button and reset the ON timer.


Using lithium rechargeable batteries in a "home-made" children's project presents some health risk. I'm going to have to work this one out and if I have to resort to alkaline or NiMH AA batteries in series, then that's an acceptable fall-back. I'd like to crack the (admittedly self-defined) problem of using a TP4056 but requiring a method of assurance that the charger and battery are connected to each other. I.e. I want to make sure someone hasn't placed a short circuit across the charging terminals before applying power. I think this is most likely to be implemented on the 5V side of the TP4056 because the device can work between 4-8V, although I can't tell what the dropout voltage is and therefore the minimum input which would still allow a 4.25V max cell charge. This could use a voltage divider or a serial connection over one or two wires, which would be helped by the TP4056's common ground pins for battery and supply sides.


Using the ADC to determine rough state of charge in the battery. It could use this to alert the user to charge it as well as perhaps adjusting the driver circuit pulses to maintain brightness.

  • 1 × ATtiny85 (eventual main microcontroller) Microprocessors, Microcontrollers, DSPs / ARM, RISC-Based Microcontrollers
  • 1 × Inductor (LED driver circuit component) Playing with various values - 1mH, 3.3mH, 6.8mH, 10mH. Low ESR is desireable.
  • 1 × Optional - digital multimeter Limited utility in measuring the actual voltages and currents used
  • 1 × Optional - oscilloscope For useful analysis of the LED driver circuit - mine is a cheap DSO 138 kit and does the trick
  • 1 × Arduino Nano clone For convenient USB-enabled design work where I want to test code (e.g. edit the pulse lengths and frequency) conveniently

View all 13 components

  • We have a leak.

    Simon Merrett09/06/2019 at 10:16 0 comments

    You may have noticed a frothy amount of progress with the next version of #Yapolamp in June and July this year, and then a big pause. Summer holidays? No. Leaky circuit. When I tested the "full on" run duration of the test setup, which uses a 3F capacitor pair (in series to achieve 5V handling), I also tested the "always on" mode, where we put the microcontroller to sleep between very short, spaced out pulses that allow you to find the torch in the dark without depleting the capacitors significantly. 

    The problem was that I couldn't get 24h from this, even though in theory it was using waaaay less power, so I dug in a little deeper. It appears that my carefully thought-out constant current charging circuit, with anti-backfeed diode (to avoid zapped tongues if the charging connector ends up in someone's mouth...) was discharging my supercaps at a noticeable rate. In the following diagram from the schematic, you'll have to forgive the error in placing the caps in a 1S2P arrangement - we needed at least 2S for these supercaps to take 5V. Also, J4 and J11 would be closed/connected and J7 would be open/disconnected. They are test points.

    So where's the leak? I had my suspicions but it took a little while to be sure. It's the Schottky.

    Everyone will tell you about Schottky reverse leakage current but I didn't hear them or blithely ignored any mention of it. In the case of the diodes I was using, the ON Semi MBRA210LT3G, this is what is claimed: 

    We should be seeing between 30-70uA reverse current. My multimeter had it at 110uA, so that's disappointing. I started looking around for a better option. I thought there would be three obvious ones:
    • A better Schottky - how hard could it be to find one?
    • A normal diode
    • Some other anti-backfeed device, akin to the MOSFET-in-reverse protection against reverse polarity

    So, I couldn't find anything simple as an ideal diode that wasn't a bit expensive for this application (rail to rail opamp and a PMOS perhaps). A normal diode would be fine except that it means I can't charge the capacitors to as close to the 5V supply. This is annoying because I heard the higher voltage you go on a capacitor the more energy you store... But seriously, we can keep this as a backup version. I tried a normal diode and it did a grand job at preventing reverse current leakage. So, back to Schottky's. 

    One of the sad things about the parametric searches is that there is rarely a checkbox for "reverse current leakage at 1.8-4.8V between 10C and 25C". I noticed that you can have decently low forward voltage (tick!) but poor leakage (untick!). Or you can have "low leakage" diodes that have nA Ir (tick!) with Vf in the 1V range (untick!). Not to mention needing current carrying capacity. I could put a couple in parallel for my attempted 500mA charging current but I'm loathed to buy three or more for every torch, so that rules out another subset of parts.

    I think I now have a decent contender: the ON Semi MBR0520LT. Here are the claims:

    0.25-0.35Vf (tick!)

    5-8uA reverse leakage current (tick!)

    And 0.5A max current, so we may use a pair in parallel for our charging at half that max rate. Or perhaps charge more slowly.

    Anyway, I'm off to update the board and maybe one day soon we'll have a supercapacitor version of Yapolamp on the go!

  • Pulses, not pauses

    Simon Merrett07/19/2019 at 13:40 11 comments

    This could almost be a log for #The Rise and Fall of Pulses but we're operating in the microsecond range, which is a relatively geological timescale compared to those pulses!

    There's a certain amount of curiosity that drives this project along. The pulse generation is a point in case. As you may have noticed, I've recently been playing with the new-ish ATtiny402, a part that shares many of its peripheral and register settings with two families of parts the ATtiny 0 series and ATtiny 1 series. In theory, there's a huge amount of flexibility for an engineer to switch quickly between parts because the code will be so portable. In reality, the datasheets have suffered from what appears to be a relatively high degree of copy and paste, or at least the assumption of commonality hasn't been tested. This can mean that discovering how a peripheral needs to be set up for parts like this that don't have many readily published examples, can be a "voyage of discovery" to put it mildly.

    #Yapolamp needs pulses (although as I have pondered @Sander van de Bor's  #ATtiny Super Capacitor Spider which drives its LEDs purely with PWM to produce a fade effect, I wonder if protection against MOSFET failing ON could allow this to be a contender for the #Yapolamp . Anyway, I'm deep into the inductor driver rabbit hole at the moment and the delights of the ATtiny402 (not its datasheet, but the IC itself!) are more than adequately holding my attention. 

    You may recall that I used TCB0 on the ATtiny402 to generate a nice, duration controllable pulse on the Waveform Output (WO) pin, PA6. This was lovely because using another neat trick of the ATtiny402, I can measure the continually decreasing supply voltage from the supercapacitor to the circuit and automatically adjust the pulse to assure we were achieving the same sawtooth current profile throughout the full voltage operating range, which is over 3V. By controlling the current, I am happy that this is a proxy for brightness, so I don't need to "test" that we are maintaining the same light level across the range of supply voltage. I also chose this current profile because it represents the most efficient conversion of electrons to photons, according to my shonky tests.

    But all of this was using delay() and as I'm playing with the 402, why don't we see if we can generate the pause, after the pulse, during which we wait for the inductor to discharge through the LEDs, in a more convoluted way? Great, glad you're onboard with that. Options to do this with the older ATtinies would have included timers. Here's the timer option set for the 402:

    We have already committed TCB0 to doing duty on the single shot pulse generator, so that's off limits. We do have TCA0 on the ATtiny402, although this is reserved in the megaTinyCore for all the Arduino timing stuff, exactly like millis(), delay(), micros() and microSeconds(). So best not to mess with that for now (although you can mess with what you like if you can live with the consequences). The last one, the RTC, is a nice little thing not really with an equivalent in the older ATtinies. It runs from the 32kHz oscillator though, so the fastest period it has is 1/32000 or ~ 30us. My sawtooth discharge at 12-14mA takes around 10us, so we'd be extending total duty from between 30-60% (for 1.8v - 4.8V respectively) down to 25-50%. Maybe not drastic but I think we can do better, and there's no guarantee that we can actually do anything within a single RTC clock cycle. In fact, as far as I can tell from the dubious datasheet, the shortest Periodic Interrupt Timer is 4 cycles, plus whatever time it takes you to service that ISR, and the fastest you could do an event driven approach is 64 cycles. Not worth investing in for this use but definitely worth returning to, perhaps as part of #ATtiny 0 Series programming on the cheap

    Events, dear boy

    The new kid on the 0 and 1 series block is the core-independent peripherals. Core independent...

    Read more »

  • I love tiny-land and I never want to leave.

    Simon Merrett07/17/2019 at 15:11 0 comments

    After ensuring that one uses the unit of Arbs at every available opportunity, I'm well aware that the second rule of "science" is to change several variables at once, so you can be sure you will never really understand what happened but that if it's a good outcome you can carry on, smugly praising yourself for saving at least one iteration of work. If it doesn't work you can always go back to the way-of-the-sucker and change variables one at a time.

    Wrong MOSFET

    You know I told you all about that naughty OnSemi FDT439N that was operating far worse than its datasheet claimed, perhaps causing us to lose 20% of the usable voltage range of the supercapacitors? Erm, I may have used a different part. On closer examination, it appears I took some shortcuts with populating my Yapolamp 1.1 development board and an itinerant STN4NF03L may have sneaked its way onto the PCB both PCBs...

    So what? I took the opportunity to lash up the 1S 6P and change the MOSFET for a pukka FDT439N.

    Back to the bench

    I didn't change the timings on the pulses, and it's probably a good thing too. One thing I didn't notice in SPICE for the 6S 1P arrangement is the discharge duration is muuuuch longer (double, because half the Vf for 1 LED vs 2 LEDs in series). There's a roughly 20uS discharge period for this arrangement, as opposed to the other arrangement. We are getting into audible range of oscillation for the full pulse-discharge cycle but I didn't detect any noise (especially above the oscilloscope fan!). Here's the setup:

    Scores On the Doors

    I couldn't quite believe this but my little 3F supercapacitor bank (2 in series because I got 2.7V versions) ran down to 1.8V at some time after the 5 minute point. The reason I'm not sure of the time is that it kept running, that little ATtiny, lower and lower. Eventually, the LED brightness dropped a bit, but certainly not to an unusable level. The ATtiny402 kept going and going and going, until at 6 minutes and 42 seconds, the lights went out. What amazed me about this was not how the MOSFET mix up (and maybe the LED 1S 6P arrangement) had made such a difference, but that the voltage across the supercapacitors when the lights went out was


    I love it here in tiny-land and I never want to leave.

  • Slowly moving to tiny-land

    Simon Merrett07/17/2019 at 11:46 0 comments

    This log is about transferring from pulsing the classic inductor driver with an ESP8266 that is powered separately (and therefore Vpulse = 3.3V, even when Vcapacitors = 1.8V) to an ATtiny402. It's no secret that I'm a fan of this chip but this phase took me to places in the datasheet I have never been before...

    The big news is that the megaTinyCore for the new 0 and 1 series ATtiny chips for Arduino is available. More details coming soon on my #ATtiny 0 Series programming on the cheap project but somehow having the ATtiny402 in the Arduino IDE just helped me speed things up with development. At the moment, while the core is new, I do still check if something that breaks on the Arduino IDE side works on Atmel Studio before admitting it's my fault!


    The 2S 3P arrangement doesn't take kindly to Vpulse < 2.4V. This means we're losing 0.6V/(4.8V - 1.8V) = 20% of our anticipated operating voltage range. This won't necessarily translate into 20% of our run-time but it is significant.

    But First

    Before we get into the goodness of the microcontroller, there are issues to report... Since last time, I have implemented a quadratic calculation for the number of microseconds the pulse should last for any given voltage. It works well (until brightness drastically drops off at 2.4V. I have tried altering the equation to significantly increase the pulse duration approaching 1.8V (from 17uS to 40uS) to no avail.

    What could the cause be? Well, my first instinct was the MOSFET, although this part (OnSemi FDT439N) is rated for a VgsThreshold of 0.67V typical and 1V max. I could understand it complaining about 1.8V perhaps but I would expect 2.3V to be fine... This seems a likely contender because immediately that I swap the pulse back to 3.3V, the LEDs do brighten, although not as good as they should be.

    I realise that we're getting to some very low voltages for discrete silicon parts that I can buy and solder together, but I was somewhat disappointed to find that 30% of my voltage range has gone missing! 

    My next contender for disappointing component is the inductor. It has resistance, so reduced voltages are going to struggle more. Not sure. What I do know is that I saw the inductor voltage trace on my oscilloscope struggle and then fail to reach the required voltage to discharge through two LEDs in series, as Vcapacitor passed below 2.4V. Which gave me an idea to revert to the no-no of driving LEDs - 1S manyP.  Hold that thought.

    The Burden of Control

    In the last log, when I reported a 4mins 30second run-time, I was careful to caveat that this was not paying for the energy used by the pulsing microcontroller; it was just the LEDs drawing from the supercapacitors. This time, I whipped out my trusty (totally untested) ATtiny402 and tried to get some pulsing going. I set the clock to 5MHz, which is deemed safe down to 1.8V, turned brown-out detection etc off and got it blinking. I managed to get it down to running at 1.5V in this mode and 1.7V at 10MHz but YMMV and there was hysteresis, ie you needed a couple of hundred mV above those to restart, once it crashed. Not for the faint-hearted. I do wonder what you could get down to while running the internal 32kHz oscillator and consuming less than 10uA. maybe a shiny new single AAA cell would even be able to get one going at 1.5V... Ah, distractions...

    Anyway, after impressing me with the operating voltage, I re-tuned to  5MHz and gave it some pulsing on the LED driver MOSFET gate. Success. That last couple of sentences makes it sound way easier than I found it but that's my fault for insisting upon learning how to do single shot pulses using TCB0 on the ATtiny. There's a thread on AVRfreaks alluding to my woes and recording the code which works for me. I hope to recount my tales of TBC0 and Event System glory on the #ATtiny 0 Series programming on the cheap project one day. I had forgotten that although the peak sawtooth current is 14mA per LED, that equates...

    Read more »

  • Auto-pulse, auto-brightness

    Simon Merrett07/15/2019 at 12:52 0 comments

    Last time we noted that the 2.2mH inductor was going to need long pulse-discharge periods to drive the planned 6x LEDs for the next version of #Yapolamp . I thought I would go for a 1mH inductor but plumped for a 680uH one instead. I ordered it a while ago and can't remember why I picked it - probably price!

    Dynamic Pulse Calculation & Generation

    Now the pulse durations required for the 680uH inductor driving 6x LEDs at the most efficient sawtooth profile (see previous log) vary almost inverse proportionally to the voltage of the supercapacitors that are powering this version. I took the pulse durations calculated by spice at 1.8V, 3.3V and 4.8V, which represent the lower, nominal and upper operating voltages that I expect. I then measured the ADC counts for the 3.3V (actually 3.29V) and 5V (actually 4.82V) rails on the Wemos D1 mini R2 when put through my 2.2K/2.2K Ohm voltage divider. I put them into Excel and used a linear trendline (to start with - we can always improve this) to work out how to calculate a pulse duration for every voltage between 1.8V and 4.8V.

    So using this, we can make our pulse calculation code as follows:

    pulseOn = 25 - ((analogRead(A0) + 21) / 42);

     The  /  42 is the equivalent to * 0.024. I add 21 to the ADC read because 21/42 = 0.5 and because integer maths rounds to a floor, rather than normal rounding, adding 0.5 has the effect of implementing normal rounding (both up and down, rather than solely down).


    This works! From a fully charged pair of 3F supercapacitors in series at 4.85V, the discharge brightness is pretty even over the full range of voltages down to 1.8V. Here's one of the moments that the pulse duration is increased to maintain the peak sawtooth current (as indicated by the increased duration of the discharge of the inductor in the trace):

    I set the ADC-based recalculation of the pulse length at 10Hz and this seems fine for adjusting the pulse (brightness) not only during the discharge but also the MUCH faster charge phase - that's right, this torch can be fully-on with constant brightness during charging of the supercapacitors from the USB battery bank!

    This test also now allows us to better estimate the run-time for a given capacitor charge. Bear in mind that we will have to add in the microcontroller current burden to the calculation but from this experiment, our 3F capacitors give us a 4 mins 36 seconds run time from full to 1.8V (and the LEDs are still bright at this point - just can't be sure the microcontroller will keep going below this voltage). 

    Auto-pulse points to address in future:

    • There's a slightly detectable increase in brightness at each increase in pulse duration. Ideally, find a better way than delayMicroseconds() to time the pulse lengths. This will rather depend on the final microcontroller and its configuration (clock etc). 
    • The discharge duration sits nicely in the 10-12 uS range for voltages above 2.1V but below this, it drops a little low. This could be improved by adopting a non-linear function to calculate pulse durations from ADC counts. Again, because of ADC non-linearity etc, there's little point in optimising this with the ESP8266 (which was never a contender for the final uC but has 3.3V GPIOs for test pulse generation) and I'll wait for the final microcontroller before improving this.
    • You will see in the GIF of the oscilloscope trace above, that the point when the next pulse opens the MOSFET is not well-matched to the inductor voltage's lowest point, wasting some energy. This could be improved as an optimisation but I don't think it would make a significant difference to run-time and efficiency. Please disagree with me in the comments and perhaps it will motivate me to compare!

    Next steps

    So now I have proved we can achieve a constant-ish brightness from a wide range of supply voltages, I'm confident we can now start to design a more compact PCB for a V1.1 beta (oh dear - will we ever leave beta-land?!). However, before that,...

    Read more »

  • Scaling Up

    Simon Merrett05/14/2019 at 08:27 0 comments

    In the last log, we created the pulses to generate the most efficient peak sawtooth pulse currents to drive the LEDs and compared the brightness of the most efficient LEDs to the existing Beta model of the #Yapolamp  which is driven by an anomaly (go see what I mean) and it's LEDs get hot and are a different colour tone to the efficiently driven ones...

    In concluding that we needed to go brighter with the efficiently driven LEDs, we created higher peak sawtooth currents by pulsing the same 2.2mH inductor for longer (pulsing means opening the MOSFET and letting current begin to build between VCC and GND, which builds the magnetic field in the inductor). Checking back to the efficiency curves, we seem to be losing 9% of our Lux/mA (or Arbs) if we drive at 20mA peak sawtooth current. There was a noticeable increase in brightness but they still weren't as bright as the Beta.

    Which brings us to the latest test: will efficiently driven LEDs produce sufficient light in a bank of 6 to meet the aim:

    1) A torch for the user to find their way around a dark room or for limited reading under a duvet. 


    So with an array of 6 LEDs in a 2 Series, 3 Parallel (2S 3P) arrangement, we need to go back to Spice. The 2S 1P circuit we used previously is on the top and the 2S 3P is below:

    Here, we can see the effect of the same pulse applied to both circuits: 

    Note that the current going through the 2S 3P is approximately 1/3 of the 14 mA peak in the 2S 1P (as expected with Kirchoff's law). Both discharges start and end roughly the same time. To get the 2S 3P arrangement operating at 14mA peak sawtooth current, we need to pulse the MOSFET much longer, about 3x longer (everything's looking nicely linear at this point). In this plot, we're pulsing the 2S 3P circuit for 25.5us and I have delayed the start of the 2S 1P pulse so that the discharge curves are superimposed:

    See how the 2S 3P (turquoise) discharge period is about 3x longer than the 2S 1P (red), making our whole cycle duration about 57us. This means that the fastest pulse-discharge frequency is 1/0.000057 = 17.5kHz. This is in the upper range of audible sounds, so we could have a problem with the device whining in use. If we shrink the inductance, we can reduce the pulse length required to generate our peak currents and also commensurately this will reduce the discharge time across the LEDs for a cycle. For example comparing two 2S 3P LED circuits below, one with the original 2.2mH inductor and one with a 1mH inductor, we can see they can both be pulsed and achieve 14mA peak sawtooth discharge:

    This time the turquoise trace is the LED attached to the 1mH inductor and the green trace is attached to the 2.2mH inductor. We can read from the traces that a total pulse-discharge cycle for a 1mH inductor takes about 27us, which isn't an exact division by a factor of 2.2 but is close enough. The resulting frequency for a 27us cycle is 1/0.000027 = 37kHz, which is sufficiently above audible spectrum that I'd be happy with this.

    For now, until I buy a 1mH inductor (good, there are plenty to choose from in this size) I can use the 2.2mH to test brightness of the 2S 3P arrangement

  • Matching Theory and Practice

    Simon Merrett05/13/2019 at 10:21 0 comments

    So last log we looked at the pulse durations required to generate 14mA peak sawtooth current with the two "working" extremes of supply voltage - 1.8V at the lower end and 4.7V at the top end. I say "working" because eventually we may look at working with voltages outside this range, particularly at the lower end. However, for now, they will do as a good envelope to design within. For a quick test of whether 14mA peak current (which we calculated would be the most efficient conversion of electrical to optical energy using the inductor boost driver) looks bright enough, I wanted to run it on the V1.1 prototyping board at 3.3V (because that's easy to generate and have matched voltage between Vsupply and Vpulse). Here are the three circuits we're now looking at, which differ in their voltages and pulse timings.

    As before, when I compared the 1.8V and 4.7V supplies, I have adjusted the pulse start times and durations so that all the voltages have their discharge current curve superimposed:

    This gives us a theoretical pulse time of ~9us will give us our 14mA peak sawtooth discharge current and a 10us delay before pulsing again will start the new pulse as the inductor voltage swing is on the down slope after the LEDs switch off. To generate this with the ESP8266 and accounting for the added delay of digitalWrite() and loop(), I used these timings to achieve this:

    void loop() {
      digitalWrite(D4, HIGH);   // pulse ON
      delayMicroseconds(7);   // generate a 9us delay
      digitalWrite(D4, LOW);    // pulse OFF
      delayMicroseconds(3);   // generate a 10us delay

    Which can be verified by connecting the oscilloscope to the pulse pin on the ESP8266 with nothing else connected:

    Note that the oscilloscope does the measurement hard-work for you when you press the +Width and -Width buttons on the left side of the screen, displaying times helpfully along the bottom of the screen. 

    Then connecting the ESP8266 3.3V, GND and pulse pin to the V1.1 prototyping board, we get the following trace:

    And now for the all-important brightness comparison. It's hard to convey the difference using a mobile phone camera and words but I'll give it a go:

    Yapolamp Beta (Left) with all LEDs and Yapolamp V1.1 protoboard (right) with 2S 1P configuration.

    You can see what I perceive in this photo, that the Beta is slightly brighter than the V1.1 protoboard. However, I thought it would be fairer to compare 2 LEDs to 2 LEDs, so masked three of the Beta with electrical PVC tape:

    Although the focus is frustrating, their brightness is closer than I initially thought. I went back to the efficiency calcs to see what driving at 20mA peak sawtooth current would do to the efficiency - it would be about 0.91 at 317 Lux/mA relative to the peak efficiency of 348 Lux/mA. Worth considering. Lets see if we can tel the difference in a comparison. According to Spice, we'd need a 12-13us pulse and we would catch the downward voltage slope of the inductor about 14us later. Now to generate that profile on the ESP8266, we need:
    void loop() {
      digitalWrite(D4, HIGH);   // pulse ON
      delayMicroseconds(11);   // generate a 12.5us delay
      digitalWrite(D4, LOW);    // pulse OFF
      delayMicroseconds(7);   // generate a 14us delay

     This timing needed tweaking so that the next pulse catches the downslope from the inductor in reality. This is the beauty of having an oscilloscope to verify what the simulation says. We now need a 13us wait before sending the next pulse. To compare the 14mA and 20mA versions, we will cycle between them, one cycle per second, so each mode will be on for 500ms. Because of the delay introduced by checking the time for pulse length cycling, this is what the code results in for now. You wouldn't go to production with it, but it suits our prototyping needs:

    byte pulseOn = 6;
    byte pulseOff = 0;
    unsigned long present = 0;
    void setup() {
      pinMode(D4, OUTPUT); // initialize digital pin as an output.
    void loop()...
    Read more »

  • Back to the Spicing Board

    Simon Merrett05/11/2019 at 22:49 0 comments

    Having played around looking for the optimal sawtooth current pulse, my last log concluded we were aiming for 12-14mA peak, at the start of the pulse. I took this to LT Spice to see what pulse times would work with what inductor values and voltages to achieve this. Remember that in the next version (V1.1) of #Yapolamp we're planning to use supercapacitors to run the thing, so we are likely to see a large range of supply voltages. For now, I will say our planning range is 4.7V, the top charge I expect to get the capacitors to, to 1.8V, where the ATtiny will stop being reliable.

    The first Beta Yapolamp uses 5 of the Chanzon 5730 LEDs in parallel (with that crazy "it shouldn't work" inductorless driver circuit). For some reason I think we'll be looking at 6 LEDs in total this time (more layout options) and I think we should try driving a 2 Series 3 Parallel arrangement. I'm not aware that there are any huge disadvantages of driving 2S 3P over 6P - your inductor needs to generate a larger pulse voltage to overcome 2x the forward voltage of your LED but the current is kept lower. Indeed, driving LEDs without individual current limiting on each circuit line is frowned upon, so moving to more LEDs in series is returning towards "good" practice, at least nominally.

    So to start off this round of simulation, I will only use a pair of LEDs in 2S 1P configuration, with a 2.2mH inductor.

    I want to see what the voltage range does to the peak sawtooth current. I found with a 4.7V supply (Vpulse is the same as the supply) and 6us pulse pulling the inductor to ground (pink trace), we get our 14mA (red trace) peak current. However, that same pulse length (green trace) at 1.8V supply only manages a measly 4mA (turquoise trace) peak current:

    If I want to match them up, I need to give the 1.8V system a 17us pulse. Here's what that looks like against the 4.7V 6us pulse (delayed the 4.7V system pulse so the sawtooth discharge currents align):

    Let's leave Spice there for now and just update on some of the playing I have done with the prototyping/test board. I have connected  both the classic driver and the MT9284 sides as well as populating the supercapacitor chargin circuit. Here you can see the supercapacitors powering two LEDs through the classic driver with a 2.2mH inductor and a 3V pulse from an ESP8266. 

    I'll do a more detailed log on the MT9284 another day but for now it gives me too many concerns to use with supercapacitors, due to it's ultrabright startup and then noticeable drop in brightness, audible whining and then very quick burn through the supercapacitor charge. I don't think I want to pair that IC with supercapacitors for now, although for more stable power sources it's definitely something I'd consider. It also cuts out at 2.2V and although that's not far from the cutoff voltage of 1.8V for the ATtiny that is likely to be driving pulses in the V1.1 Yapolamp, the classic driver has been putting light out down to below 0.5V on the capacitors! I admit I haven't completely ruled out the pulse input being significant in this observed performance (although there's a low value resistor in there). If it was a driver circuit that could light LEDs down to 1V, I don't know how I'm going to take advantage of that yet. It would be amazing to go into a distinct version of the always-on mode which told you that you need to charge the Yapolamp before you can use it in full mode. Could the microcontroller do high level management of it's a joule thief or charge pump for self operation down to those low voltages, say by kicking it in at 1.8V?

    My first design flaw was to make this board for a single supercapacitor in series and several in parallel. That was silly because most of the supercapacitors I'll want to use will only be ~2.7V rated, so will need to be paired in series. For now I have twisted the legs of two capacitors together in the middle and taped them out of the way with kapton tape, before soldering the pair into the holes for one...

    Read more »

  • Back on Track?

    Simon Merrett05/10/2019 at 23:44 0 comments

    So after the debacle in the last log where I discovered I have completely connected up the MOSFET wrong in the very first #Yapolamp and by some freak phenomenon it not only works but it works without an inductor, we return to normal viewing.

    A couple of logs ago, I showed my first current/illumance graph for the Chanzon yellow LEDs (which produce orange light, if you ask me). I blatantly copied this from #TritiLED 's search for the most efficient way to drive an LED for your coulomb. We opted for the far less rigorous unit of Arbs in #Yapolamp . Today, I went to the next step that #TritiLED did which is, once you know how many Lux you get for each mA, to try and work out the optimum saw tooth peak (initial) current to drive the LED with. This is different to the peak efficiency current because as current decays to zero (imagine the inductor disharging into the LEDs in our driver circuit), it passes through the efficiencies of all the lower currents.

    When @Ted Yapo did this properly for #TritiLED , he used octave plots and normalised everything because he knows how to do that and it's good practice - normalised values let you do comparisons etc. As you may have picked up on by now, #Yapolamp differs from it's namesake by being somewhat less rigorous and skilled. I just used Excel. I assumed the same as Ted that my current would step up instantly to peak value and then decay linearly to zero. I used 10 time steps as a proxy for proper integration, worked out the time-step current based on an initial peak value and calculated the Lux/mA at each step. I then took the mean Lux/mA across all time steps for a given peak current and plotted them over my graph from last time.

    Note that I had trouble finding a good polynomial trend line to my data - those measurements were all over the place, so no wonder Excel had trouble. The ^3 trend line (red dots) looks nice in most places but overshoots a bit around 7mA and at lower values. The ^6 curve (green dots) is better in most places except it goes a bit wrong above 13mA. I decided to plot the optimum sawtooth current curves for both to see how they differ.

    The main takeaway is not the comparison between the polynomial trend lines but how the optimum peak currents (pink = ^3 trend line and blue = ^6 trend line) are higher than the most efficient static currents. This was expected, thanks to Ted's work, but it's nice to see the curves superimposed for contrast.

    My conclusion is that for our 60mA-rated LEDs we're looking at a peak sawtooth current of around 12-14mA. I seem to recall Ted forming a rule of thumb from his observations that about 20-25% of rated current was where we'd expect to find peak efficiency. I just can't remember whether that was static current or sawtooth peak current!

    Now I have a design current to take into SPICE and this time, who knows, maybe we'll design something with the parts connected the right way around.

  • How is this working without an inductor?

    Simon Merrett05/10/2019 at 15:49 2 comments

    I'm mystified. I now have the prototyping board to try out supercapacitor power and compare the MT9284 driver scheme with the original inductor boost circuit. I decided to tear down the original Yapolamp Beta (I know changing from Beta to V1.X isn't helpful). As you may remember, the whole impetus for a V1.1 was that the original had stopped working. Here's what I found:

    That cheeky little inductor I was so keen on for its low profile has completely come away. I think I'll share the blame for poor soldering with the fact that the bonding pads on the inductor were probably not designed to be dropped as much as the Yapolamp has been. It was nestled in behind some PVC insulation tape I had lined the enclosure with, thankfully not causing any short circuits with my lithium battery.

    Now for the weird stuff.

    So then I  happened to touch the two pads where the inductor should have been with a finger and the Yapolamp glowed into life!


    It didn't just glow, it had full function. Button presses cycled between the always-on and full-brightness modes. I left the full-brightness mode on and sure enough, after several minutes it started to blink to signal to the user that it would be turning itself back to always-on mode if you didn't press the button again...


    I can understand the ATtiny85 running properly but how can the reverse-connected LEDs be driven if they're not connected at one end and the other is only connected to Vbat? Inductor PCB pad acting as a capacitor? Ideas gratefully received in the comments... 

    <EDIT> Hopefully you can see the pictures now @Ted Yapo  - I think I used a link from Google photos. They're now uploads.

    Now I'm even more confused. Here's the schematic from last December:

    Ignoring that white LED (which I never felt the need to fit) and the fact that I shorted across the fuse terminals, can you spot the error? Yep, that N channel MOSFET appears to have a pulse driving the Drain, with the Gate pulled to Vdrain by a 10k resistor and the Source at the same voltage as the LED anode... how is ANYTHING working here!?!


View all 26 project logs

Enjoy this project?



Ted Yapo wrote 07/12/2017 at 13:35 point

Hi Simon, I just wanted you to be aware that there's a serious failure mode associated with the basic design of the MOSFET/inductor boost circuit.  If the MOSFET is held on, the inductor is basically shorted across the battery.  This could cause very serious damage to the circuit and surroundings, especially with a high-power battery such as you are using.  The MOSFET could get stuck in a conducting state through a number of failure modes, including software errors, software corruption (cosmic rays happen), or if the gate is left floating due to tri-stated uC outputs (even during reset).  I discuss one solution to this in a TritiLED log:

but this may not work if you also want a high-power mode.  Just a heads-up, because I didn't see this at first, and it definitely should be addressed.

  Are you sure? yes | no

Simon Merrett wrote 07/12/2017 at 13:43 point

@Ted Yapo, thank you for making sure I'm aware of that risk. I have read your post and I am using a 10k pull down resistor on the MOSFET gate in the current Yapolamp design. Do you think a resistor in series with the inductor and led is also required/sensible or will controlling the gate with a pull down be sufficient? 

  Are you sure? yes | no

Simon Merrett wrote 07/12/2017 at 13:51 point

I see now, after reading again, that the series resistor is really worth having in case the uC pin fails high. If cost is lower priority than safety, I wonder if having an npn transistor between the gate and ground, with the base tied to the uC pin via capacitor, with a pull down resistor, would work. If the pulse is short then the capacitor doesn't charge enough to open the transistor and pull the gate low, but if the uC pin stays high, the capacitor charges, the transistor starts to conduct and the gate is driven low.... 

  Are you sure? yes | no

Ted Yapo wrote 07/12/2017 at 19:31 point

Yes, I think the uC pin sticking high is the real risk.  It could be as simple as the oscillator stopping (for whatever reason) mid-pulse.  It's probably a rare occurrence, but the consequences could be very bad.

I see where you are going with the transistor gate shunt idea - to limit the pulse width, essentially.  I think some kind of current-limiting element in series is probably the safest approach.  It might be as simple as a picofuse - they make them down to 62 mA rated current:

The currents go up from there - I'm sure you could find one that would protect all the elements in your device while still allowing the power you require.  This will work better than a simple resistor for the higher-powered lamp you are developing.  At the power levels I care about, the efficiency loss with a resistor is tiny.

  Are you sure? yes | no

Simon Merrett wrote 07/12/2017 at 20:48 point

A fuse popped in to my head about 5 mins after my last reply - great minds... 

  Are you sure? yes | no

Simon Merrett wrote 05/30/2017 at 18:58 point

Thank you to everyone who likes/follows #Yapolamp. In a bid to save everyone's feeds getting clogged, I'll do it once, here.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates