Mod - GarryBunk's SecurityIng HD-016 (It's Finally Done!) - Pic Heavy

Ok, With the info we have collected, I propose the following approach regarding the MCU's. Please chime in with an concerns, thoughts, better ideas, etc.

  • Cut Pins 7 ,8, 13 (See Post 51) and reinstall the stock MCU. The stock MCU will only control the indicator LED's.
    • I think the mode cycle for the stock MCU is Wide Beam On, Wide Beam Strobe, Throw Beam On, Throw Beam Strobe, Both Beams On, Both1 Beams Strobe, Off. So most of the time the indicator lights will be on as 6 of the above modes are "On". Every time Garry hits switch 7 times, the stock MCU will turn off. He will need to cycle 4 clicks to return to a the same mode on the Attiny13a and also have the stock MCU on (that's if he even wants the indicator light on at that moment). If he changes modes often, there is really no concern because the next mode change will turn on the stock MCU.
  • Attiny will control drivers and have external temperature and voltage divider monitoring and safeguards.
  • Piggy back the Attiny connecting Vcc to stock Pin Pad 1, and Ground to Pin Pad 14. Pin Pads 7 and 8 (Head light PWM), 03 (Momentary Switch), 12 (Temp sensing), 13 (Voltage Divider) will connect to Attiny as determined by the FW.

The above is dependent on Toykeeper's and Garry's approval. They will need to nail down what they want to do regarding:

  • External temperature monitoring. Will the FW have it?
    • If yes, is Turbo Timeout still needed?

In the mean time, I will get some temp/voltage readings and finish the work on the thermal path (AR coated lenses have arrived). Do I nee to change resistor in the thermal circuit to increase voltage? Right now it looks like the .2x volts will be the target voltage at which the FW would step down a mode? I'm guessing not because it is a fraction of 1.1 (e.g. .28 volts would be about a value of 65 in the FW).

EDIT: Plan outlined above is not viable due to how stock MCU is turned Off (Long press).

Well stock modes were: wide led on, narrow led on, both LEDs on, both LEDs strobe, then off (I think). Nope, back to wide led on. It's a press-n-hold from any mode to turn it off. So is that close enough to the Attiny's FW to stay "aligned"?

-Garry

Stock modes are as follows: wide beam on, throw beam on, both beams on, strobe with both leds on, ... repating ... Long press in any mode turns light off. There is no off mode in the cycle.

Wait- if the Attiny were put into it's strobe mode that would throw off the "alignment", right?

-Garry

OK, good info Garry and ledoman. I think my idea needs to be scrapped. I got nothing at the moment. Anyone have any good ideas?

EDIT: What if we toss the stock MCU and just use one pin on the Attiny for the indicator LED's? It could blink one or all of them when voltage gets down to a certain level. Maybe faster as voltage gets lower.

For anyone interested in some of the circuits outside of the drivers, here is a very high tech diagram.

The dots are thru-holes. They are just from memory so there may be some I forgot. Pin 3 connects to the Momentary Switch.

I think that we can control the stock MCU with a different, relatively simple, circuit. Whether you’ll want to build one is up to you. I’ll hammer something out and post it in a minute.

I think that a “monostable multivibrator” is the tool for the job if we want to turn on the stock MCU when power is applied. - Multivibrator - Wikipedia

You could certainly build one, and it wouldn’t take many components or much money… but you can also buy one in an IC for <$1. I specifically glanced over the datasheet of the SO-16 packaged 74AHCT123AD,118 ($0.40) and it seemed suitable. I think that at least 2-3 external components (at least one cap and one resistor) will be required. At a glance the SSOP-8 packaged TC7WH123FUTE12LF also looks suitable and is smaller.

  • What a circuit like this should allow us to do is trigger an output pulse on a ‘rising edge’ (power being applied).
  • I think that we can setup the pulse length using a resistor/capacitor/both.
  • If it fails to trigger due to the chip being powered on at the same time as the trigger input is produced (eg we are applying power)… I think that we can put a capacitor between the “positive edge triggered input pin” and GND, then put a resistor between that and Vcc. That should slow down how quickly it triggers, I think.

I'm totally fine with this. I don't need all three lit, just some indication that the battery pack is getting low. Would be nice if indication was in two steps: 1) 10% battery (or whatever is most appropriate) and 2) flashing indicator LEDs and either dropping output to low or shutting off. I would plan to change battery at the first indication so the light cutting off during a ride probably wouldn't happen.

-Garry

^ Thank you for the idea wight. I'll have to think on that.

I trust you on the theory (goes over my head), but I'm initially concerned about more components/complexity. It increases the risk for problems and future failures. Do you have any rough guess how much power this circuit would consume?

Fair enough. It’s not like I’ve built and tested one. There’s a lot of “I think” and “should” in my suggestion. :wink:

As far as how much power would be consumed… I think sub 1mA, maybe waaaay below 1mA, but I don’t know and I’m not super confident. (I think that the IC cannot supply more than 75mA, so it should be safe to say that it would consume less than 100mA or something no matter how wrong I was about the rest.) In any case it should not be enough to affect battery life and in the most likely case the big drain will be keeping a 10-20mA LED lit.

Would it be easier to convert the power bank to parallel, bypass the stock MCU entirely (don’t even power it up, or the other stock components), and use only two of the three power indicators? That way, there’s no need to buck the voltage, no need to sync anything with the original MCU, and most common firmwares should “just work”.

At that point your longest regulated runtime likely comes from switching to a linear driver as well (eg Nanjg-105c).

EDIT: switching the battery config doesn’t free up any MCU pins anyway.

I need/want to keep this light working with a standard 2S2P battery pack.

-Garry

Switching the battery config doesn’t free up any pins, but it does make most of the complexities disappear. I’m not a fan of complexity. However, I’m not doing the hardware so it’s not my call. :slight_smile:

The same battery capacity and runtime should still be available; it would just be four cells in parallel instead of 2S2P.

I'm with ToyKeeper regarding complexity. I think we are on the verge of making a really nice light, but there is something much bigger than that I think we are creating. So far, we don't have a viable DIY driver/FW solution that provides true thermal and series cell voltage protection. It seems this build will provide a blue print for our board designers to add these much sought after protections with buck. Modern emitters are more voltage hungry and series seems needed for the foreseeable future. The thermal and voltage divider circuits on this driver are simple and elegant and can be used for DD too. We, however, can not pull this off without assistance from ToyKeeper. I'm more than happy to do all the measuring and tuning to make the hardware and software merry.

So my preference is to ditch the stock MCU and pursue using only the Attiny and ToyKeeper's FW. If she is able to a squeeze in using the indicator LED's in some fashion, we should consider that icing on the cake.

From a firmware point of view, voltage monitoring is easy. The hard part is dividing it to a usable range and then calibrating the actual values needed on the internal 8-bit or 10-bit scale. Er, and the other hard part is fitting more than one battery into a flashlight. It’s all about the physical build and circuitry.

Thermal step-down shouldn’t be too difficult (again, after build concerns and calibration), but we start to run into limitations on the attiny13 in terms of ROM space and switching the ADC channel. Especially on e-switch lights, since handling that takes a lot of room. As is, only 174 bytes are left.

JonnyC has been trying to put together a solid firmware with both voltage and temperature monitoring, and last I heard he is seriously considering requiring an attiny25 instead so there will be enough ROM to hold the code. Everything is do-able, just very hard to fit into 1024 bytes.

It’s also a bit difficult for me to ensure anything works without having the relevant hardware. You may have to do a lot of tweaking and calibration.

I'll do the best I can if you are game. I certainly don't want your time to be wasted and you seem to appreciate the same for me. We just need Garry's agreement to proceed.

Garry,

I'd like to say that pulling off thermal protection (not faux turbo timeout) and voltage monitoring with series cells is not a small feat. Adding another MCU to the mix creates more potential problems and potential failure points. I recommend making the indicator lights optional (hopefully, they can be worked in some hobbled form) and ditching the stock MCU.

To me, FW is the critical factor as there is very limited space in the Attiny13a. So I will do my best to work with whatever you and ToyKeeper want to do.

I'm fine with ditching the stock MCU. I'm also okay if you can't get the thermal protection to work and just keep the turbo timeout. I'm also okay if the voltage monitoring is hobbled down to just one of those LEDs flashing or something like that. I'm at your and TK's mercy as to what you all can pull off.

-Garry

Sounds good. Thanks Garry.

TK,

Sure you know, but just in case. The Thermistor circuit drops voltage to the MCU as it warms up. So I'm getting assuming it decreases resistance with heat as it is between ground and the "R1" of the voltage divider. It makes sense that is should work about like voltage monitoring from a FW point of view. Not sure if you can use the existing voltage monitoring and use an "Or" type clause. I think step down reading will likely be in the 60's.

No sure if turbo timeout takes up much space. If it does, real thermal protection seems like a better safety measure. Ideally, I'm guessing Garry would like to have both in place.

Finally, if you are able to include code for a voltage indicator output pin, the indicator LED's are hardwired to 5.19volts positive. The MCU appears to provide ground via a 470 ohm resistor. I could rewire them if you need them set up the other way around.

For some reason, I can't get the indicator emitters to light up when I take them to ground directly. They test fine with a DMM. I don't know what to make of that.