Well the whole point of the neo is to be integrated. and if you control power with a mosfet so the drain is totally minimized. So if they flash just write the mosfet pin high then off again when its done. when in use they dont use much more than the rgbs do… would use this on flash light that I charge the battery regularly. like slapping them into a bike light. Another point is that if you arent using all of the rgb its more drain than the 1 to 2 of the neos. Was that something that was considered? anywayss… I got my question anyways I got my understand why you use RGB over neos.
Are you sure that was 100 mA and not 100 uA?
The aux LEDs are powered directly by MCU pins, and the MCU has a maximum power output of 40 mA. I measured a board with its resistors shorted out, and with all channels running at full power, it measured 42 mA. The Atmel reference manuals recommend against doing that though, because running that hot can cause damage long-term. But that was only a test; lights aren’t shipped that way. Usually it’s much lower – around 5 mA on high aux mode or 0.05 to 0.20 mA on low aux mode. People typically use low mode because high mode uses too much power.
If the goal was to provide active RGB functions while the light is “on”, like while a user is actively using it, I think a NeoPixel setup might be a good way to do it.
The aux LEDs are generally not used while the light is “on” though… instead, they emit a dim glow while the light is “off”. It’s like adding tritium vials to make the light easy to find in the dark, except they’re slightly brighter, don’t have a radioactive half-life, and can blink or change color.
Typically, the MCU measures voltage every 8 seconds, changes the aux LED color, and goes back to sleep to save power. It cannot do any I/O or PWM while it’s asleep… it just passively allows a trickle of power to flow.
Technically, it could PWM the RGB pins to adjust brightness or generate in-between colors, just like the NeoPixel does… but keeping the MCU awake enough to generate a PWM signal uses way more power than just leaving the LEDs on in sleep mode. So it would be self-defeating.
OTOH, there are some flashlights which are designed to use colored LEDs for primary output modes. I’m planning to work on some in the next couple weeks, even… and doing some big code changes to improve support for that. But for those, a NeoPixel isn’t bright enough. These colorful flashlights are measured in A, not mA. And the NeoPixel’s 8-bit resolution might not be enough; I frequently use 10 bits or even dynamic bit depth to make the low end of the ramp lower and more smooth.
The models I’m using for development are warm/cool/red and flood/throw/red, but they could also be white/red/blue or red/green/blue or white/infrared/ultraviolet or whatever. In addition to that, they have a lighted button and sometimes RGB aux LEDs. Would be funny to have RGB on both primary and auxiliary LEDs… but it’s an option, so I plan to support it. I’m adapting some of my lightsaber code for that purpose.
1 Thank
Someone should design a light that uses light-rods embedded in the host coupled with NEO emitters for during-use RGB. A large multi-cell light would suffer less in the battery life department while also offering more space to get creative with the mood lighting.
I am totally advocating for active use neopixal case. But I cannot think of many use cases bee on bat check and maybe mood lights. Like a fire or candle or rain or other types of active mood type light effects. I am also saying that you could have a statis effects. And it would be helpful for menu status.
Lol I just had a crazy idea. I was just looking at a video of the w2 leds with the red green and blue leds. Add in a white and you got a mega version of a neopixal. That would be an interesting idea for a flashlight. I am sure someone has thought of it before. But interesting idea
What do you think about using the T1616’s TCD with ULP ? Adventures in TinyAVR 1-Series - #29 by gchart
Gchart measured 500uA at 5V, probably would be <400uA at li-ion voltages, which is more reasonable than than the 1~2mA at normal system clock, it’s stilla bit high but would be ok for an optional richer high aux mode.
Unless the t1616 works differently than the last time I tried ULP, there’s one main reason why I haven’t used it. Every time I’ve tried underclocking that far, it effectively bricked the MCU because it was running too slow to talk to a flashing adapter. So when I underclock, I’ve made sure to keep it fast enough for reflashing purposes.
If you have a solution for that, it would probably be a good option for increasing runtime of low modes, and potentially also making aux LEDs dimmable.
Also, er, I don’t have any lights with t1616 and RGB aux… and my t1634 lights don’t have RGB on PWM-capable pins. So I’m lacking the hardware I’d need for development.
I will have to did into the data sheets for that one. So my question is the Caps… Do you have any suggestions for the caps? like would a 1uf or would a 0.1uf be enough for the IC to kill noise. what about around the LD on pins 4 and 5? and the vreg.
So what is the better IC for this. the att1616 or the att1634? @ToyKeeper Would it be better to stick with the 34? for the ULP?
BTW I found this for unbricking the att1616
I may not totally understand this stuff. but my google foo game is strong. I hope it helps.
Attiny1616 is almost certainly better in most cases. It’s newer, more powerful, and only needs 3 pins to reflash instead of 6. However, the toolchain setup takes a couple extra steps, and the reflashing adapters aren’t as easy to obtain.
Of course, it doesn’t have to be the 16 KiB version. 32 KiB should work fine too, if you want lots of extra room. The builds lately are around 8 to 10 KiB.
1 Thank
Something like this.
4.7R+ 1uF is a LPF for smoothing the input voltage when the turbo FET is switching, could be 10uF as well, without turbo FET it’s not needed.
The 0805 cap not sure it’s really nedeed.
2.2uF is the LDO output cap, doubles as VCC decoupling (there are very close to each other), techincally the LDO (MIC5205) requires a tantalum output cap, the driver uses a MLCC, so I wouldn’t use that LDO, there are plenty of all ceramic LDOs to choose from.
100k/3.3k/1uF is a voltage divider+LPF, 1uF is the value used (measured it some time ago), the higher the value the less ripple, but the longer the rise time (mostly an issue for strobe modes)
100nF is Op-Amp decoupling cap
220-1000pF/10k/510R are Op-Amp compensation, I usually put 1nF here.
T1616 should be used going forward, it has a factory calibrated temp sensor (the other ones require user calibration), 1wire+GND+power flashing, smaller size, has a DAC that can be used instead of PWM (no LDO required, no LPF/ripple).
I must have a T1616 linear driver schematic that use DAC, with high dynamic range (dual sense resistor) somewhere.
4 Thanks
That’s fewer components.
2 Thanks
I don’t know myself because I don’t code, but I think you have mentionned this one time and @Mike_C replied that he didn’t encounter this problem with ULP with the T1616, I’ll have to go find this conversation to be sure.
Edit : Adventures in TinyAVR 1-Series - #274 by Mike_C
But that wasn’t you asking, maybe that was another time or I misremembered.
Anyway it’s probably better to discuss this with him or @gchart .
Yeah that’s problematic, personally I use an Xplained nano board on which I replaced the 416 with a 1616 because the former doesn’t have enough space for full Anduril 2, it’s on a breadboard with a bunch of 5mm LEDs for testing different stuff.
That said I thought about making a dev board for Anduril development, with a linear/buck driver, dual/triple sense resistor (high dynamic range), a bunch of indicator leds…etc.
Also having a board plugged all the time to the PC is much more convenient than having to remove the cell of a flashlight, use the programming key and hope it will work the first time, then put the cell back for testing every little changes.
I should probably start a new topic about this.
3 Thanks
What do you mean by tool chain setup?
Looking around, it looks like some Wurkkos lights have this. And I need to merge Wurkkos builds upstream anyway, so I coincidentally contacted Wurkkos Terry about that just a few hours ago.
But just now I realize it fills another gap in my test hardware, so I have another reason to get one aside from just adding some missing build targets.
I wonder if I could get Hank to use your HDR circuit design. Is that something you’re okay with?
He has a lot invested in t1634, but long-term I wonder if he might be open to using t1616 or t3216 instead, and perhaps selling gchart’s flashing adapter too. It would basically be gen3 for his Emisar and Noctigon lights.
2 Thanks
The compiler and flashing program. Attiny 1-series aren’t supported in Debian yet, because the packages have been abandoned. So it needs an add-on. Details are in the repository’s README file.
1 Thank
So why not the ARDUINO IDE on windows? is there a particular reason you dont use it?
Its mostly all I have used. Like I have said I am more basic end user. I have done a fair number of projects on it. I am very much a KISS person. KEEP IT SIMPLE SILLY
Sorry If I am asking a ton of basic questions. I dont have a super in depth knowlage for this stuff. I learn enough to get the job done. lol. Very much a jill of all trades. Master of xray and coffee.
Because it’s not a bloated Arduino sketch, but a native avr-libc project. The Arduino IDE is a lot of things, but not KISS.
Easiest way might be to use my anduril dev environment docker image:
You can download the release image instead of building it yourself.
A few reasons:
- I don’t use Windows.
- Space is tight.
- The Arduino bootloader takes a minimum of 512 bytes, which is half the total ROM on attiny13 where a lot of flashlight projects run. This is also big enough to break nearly all the attiny85 versions of Anduril.
- The Arduino runtime environment uses additional space on top of what the bootloader occupies.
- Arduino provides its own kernel-like layer, which interferes with the FSM mini-kernel. FSM is basically a domain-specific alternative to the Arduino environment.
So to get more space and more direct access to the hardware, I basically started from scratch and made a custom mini-kernel with exactly the features needed.
At some point, I might try to add a bootloader for hardware with 16+ KiB of ROM, and try to get manufacturers to add a USB port for direct reflashing without an adapter. But that hasn’t happened yet… and is completely independent of Arduino.
1 Thank
Ok that makes a ton of sense… Time to dig out my old pi zero w… All my good pis are running my print farm.