Iām not sure which firmware you used there, but I make a point of including a brief flash on boot on all eswitch-only firmwares I make. It lets me know the power is connected and the chip is booted, and any issues afterward are therefore some other type of problem. I donāt think Iāve seen this behavior on other peopleās firmware though, unless you count Zebralight.
However, e-switch firmwares generally wonāt make light just because they have power. Getting light requires activating the switch, so the switch must be wired up correctly. If it wonāt activate, Iād check for switch issues.
That one click OFF is the most un sung hero of the world. OOOOOOOH how I have dreamed of this. No looooooong press for OFF. NO cycling through stobe, but STILL IN THERE!!!!!!!!!!
Had I written a Christmas list I could not have asked for a thing more!
Coolabs came in today, finished the blfdd light. I noticed something interesting putting firmware in my light. I looped this line in making the beacon off while monitoring button clicks.
PWM_LVL = 0; _delay_ms(50);
I assumed it would keep the FET closed, but it didnāt. When you loop the above it makes very little amount of light on fast pwm You can put your face into it and see the die clearly. Maybe someone is interested in that- thought it was pretty cool. If you want to try it, code is at the bottom. Hold the button for ~3 seconds to get beacon and youāll see in between pulses. Could be an even lower moon
Itās a known ābugā that PWM=0 will still produce a little bit of light when using fast PWM on a high-powered driver (FET, or 32x7135). In phase-correct PWM mode, this doesnāt happen.
Iāve been meaning to tweak my ramping UI firmware to take advantage of this, but have been too busy so far.
Well known to you Itās kind of cool, can get something lower than PWM 1. It does turn all the way off with PWM 0 least on mine. But looping it on 0 causes the lowest moonlight and itās not ghetto looking either, itās a nice light up of the emitter. The only time seen this low was playing around with the buck drivers sense resistors, got a similar output.
Maybe running as default when you turn on the tail switch instead of sleep?
That would let whoever has the light know they left the tail on while still being almost parasitic. Just enough light to keep the ring glowing too maybe.
Or just add some status LEDs and use the Roche F6DD firmware. It keeps one status LED on at all times at about half power as a locator, plus the LEDs give you info about battery voltage under load (green/orange/red).
FWIW, the standby light is barely more than the MCUās parasitic drain. With the light completely off and the MCU in sleep/powerdown mode, the parasitic drain is 0.33mA. With the green LED on but dimmed, the drain is 0.36mA. So, it costs almost nothing extra to leave that slightly on.
Leaving the green LED fully on costs more though; then it runs at 1.23mA. And a lowest-possible moon mode on the main LED is even more ā it depends on the exact hardware used, but 5mA is a common amount for moon on a single emitter on a 8x7135 board.
For a 25R 2500mAh battery, that translates to 10.5 months of standby time with everything āoffā, 9.6 months with the green LED barely glowing, 2.8 months with the green LED fully lit, or about 21 days with the main emitter in moon mode.
Voltage measurements are not performed while the light is in standby. That would drain the battery faster and require removing other functions to make room in the firmware.
Can the lower mod be little lower on that firmware?
I like moon mode to be very low.
Voltage measurements are not performed while the light is in standby but it remains with the color it was while was ON. So if it its red while it is ON, it will glow red on stand by.
FWIW, I finally added a battery check mode to my clicky-switch firmware (based on STAR). Itās what I use on my EDC lights, like a modded Convoy S7 or a CNQG brass beauty.
This firmware has a lot of modesā¦ five solid modes across the full brightness range, three dual-level flashers, a heartbeat beacon, three fixed-speed motion-freezing strobes, two variable-speed strobes, and the battery check. Short-cycle memory to avoid the need to go through all the blinky modes when theyāre not wanted. Itās a lot to fit in just 1024 bytes!
Mostly, Iām just happy that I no longer have to remove the battery from my EDC to find out if itās ready to be recharged.
Yeah, previously the STAR_momentary program shut down the output (went to sleep) when PWM = 0, but RMM had me change it so that 0 is a valid mode so that he can utilize the Fast PWM "bug". Going to sleep is entirely dependent on the MODE_PWM value for that mode instead of the PWM value. That feature is in the latest version of the program from Github.
BTW JonnyC, what is your view on STAR derivatives which no longer follow the main purpose of STAR? Is it obnoxious having that sort of thing here?
Iām wondering, because I love having STAR as a base for other firmwares, but I took out the star solder-based config bits to make room for tacos (er, more modes)ā¦ so it kind of misses the point of being simple, solid, and end-user configurable.
Awesome work Jonny. I still have to check out your changes Toy. But I came to a realization last night sleep lol
You donāt even need boards with the tiny13a. If you can modify the output on a buck driver you just need to glue 2 resistors (4 total) top and bottom of the tiny and wire it up to the existing FET and vcc to the existing mcu. Disconnect the eswitch from the existing mcu and cut the gate, wire your new pwm in. You would then have voltage monitoring (not sure this even works on a buck because itās series cells- probably better to stick protected cells) from the divider and full control of the fet.
Trying to find the cheapest solution to having a ~6a buck with modes on the Y3 Iāll have to try all this new stuff out when the next light gets here- takes awhile to get hereā¦
You could even add in a smaller fet for a second out on a lower amp light but it would add another 2 resistors, and you would have to be careful in programming so one is closed while the other is on. I think can do dual outputs (only one out at a time) like that for next to nothing and still have a 2-3s light. Is there a tinyavr compatible chip that does 4 out? Not sure if fitting 2 tinys in would fit yet for something like that 4 color XML. Or do we have to invest in the PIC equipment Cereal uses.
I think this is a great place to discuss derivatives. I'm assuming there are people out there that downloaded STAR and used it in stock form by configuring the options, even though the majority of the discussion here is about custom, one-off programs. I see this thread as just a continuation of Tido's original thread with a more configurable, perhaps easier to work with codebase to start from.
And yeah, the idea behind "STAR" was just that you could solder different stars for different options (ala NLITE), but the more features are added the less purposeful that feature is since the user will need to enable/disable so many options at compile time that they don't need the solderable ability. But I'll keep the name "STAR" just for consistency.
I could be the only one whoās having trouble with your posts, but Iād really appreciate it if you put some more effort into making your posts easy to read. They seem to be very stream-of-consciousness or something.
Iāll try to reply to what you wrote, but what you wrote may not be what you meant.
Why do you say 4 resistors though? You need 2 for a voltage divider andā¦ what? What are the other two resistors for?
Correct, youāll generally use the VCC intended for the original MCU, regardless of whether youāre using dead-bug wiring or a child-PCB.
You will not cut the āgateā signal. That term has a specific meaning and the gate signal / trace does not need to be modified for any of this. Instead you would modify the trace for the PWM signal.
RE: the italicized stuff about voltage monitoring. Voltage monitoring will work fine as long as you choose appropriate resistor values.
For buck drivers you do not directly control the FET, the buck controller does that. The MCU simply feeds the buck controller a PWM signal. The buck controller establishes a duty cycle where it turns the FET off part of the time - the PWM signal from the MCU tells the buck controller how much additional time it should turn the FET off for.
Adding an additional, separately controlled [smaller] FET does not make sense with a buck controller. IMO it doesnāt make much sense for a DD driver either. Remember, the FET is not there to limit the current - itās there to be controlled by the buck controller. A FET with more on-resistance will simply lower the efficiency of the buck circuit, not lower the output current!
Good news! There is plenty of AVR hardware out there which can do whatever your heart desires. The ATtiny25/45/85 all seem to have 6 PWM channels. Theyāve also got other nice stuff, like additional flash space and a temp sensor IIRC. The ATtiny25 is available in the exact same package / form factor as the ATtiny13A-SSU we currently use. (The 45/85 are both very slightly larger.) We use 150mil or 8S1, the larger chips are 208mil or 8S2. Frankly Iām not entirely sure what the limit on actually using all those PWM channels simultaneously is. There are only 2 timers and our use case may [probably does] prevent them both from being used for PWM. If the Tiny25/45/85 canāt do 4x simultaneously in our application it Iām sure another AVR product can. For anything beyond the ATtiny25 youāll be forced to switch to a QFN style package. EDIT: hmmm.
My advice is to make sure youāve got both feet on the ground with your understanding of a buck driver. Read some stuff on the internet, look for simplified explanations. An animation of the various states used by a buck driver is probably useful. Once you understand how a buck driver operates youāll see the mechanism for limiting current. This will make it clear why adding an additional FET in the way you described is not a good idea.
I know I know Thanks for posting, I was on my way to blowing something up tonightā¦ I just got all my parts in from digikey and dan sent a couple of old dd boards to play with (should thank him publicly for doing thatā¦ you guys are really cool). Let me research a bit more and when the light comes in- Iāll post a build on itā¦ Instead of filling up jonnys thread.
I do have a bad train of thought anymoreā¦ I canāt blame it on anyone, except maybe my wifes trying to poison me! nawā¦ it is what it is unfortunately :disguised_face: