Bit overwhelmed- can someone point me to some circuit schematics for Anduril 2 stuffs

In off… lightsabers can depending on the board can last for months to years with out a charge. I believe neos shut down at 2.7v. And I run neos off of the 3.3v with out any issues all the time. It true they play best with 3.5v to 5v but its not necessary. I have a blaster that has about 30 neos in it and that board doesnt use a booster. Sound isnt as loud but neos work the same.

Anyways… as I said I think there is a place for neopixels. especially working in tandem with other accent leds. As I said before its the coding thats a pain.

Question what do you use for temp sensing I noticed that the audriul had the temp sensing?

It’s built in to the attiny chips. The built-in sensor is the primary method it uses to measure temperature.

1 Thank

I tried searching for RGB LED drivers that wouldn’t be integrated into each LEDs, hopefully meaning lower power consumption, found that one : KTD2026 3-Channel RGB LED Driver with I2C Control | Kinetic Technologies
2.7-5.5V, 24 mA 3 channels, I2c,<1uA in shutdown, 200uA with LEDs OFF, 300uA with 3 channels ON, quite better than 1mA per LED. DFN 1.5x1.5mm so it’s small enough to place on an AUX PCB, 125uA per step (192 steps) might be a bit too coarse though. Pretty cheap at 50c/pcs for 10.

The KTD2026/7 are fully programmable, constant current RGB or RGBW LED drivers with a flexible control interface. The devices are ideally powered from one-cell lithiumion/polymer, 3-cell NiCd/NiMH/Alkaline batteries, or systems with 3.3V or 5V supplies. The independent programmable constant current sinks operate without external components.
With an on-chip timing control unit, LED blink rate, fade-in and fade-out are user-adjustable resulting in unique color lighting patterns.
Ten internal registers are programmed via the I2C interface with a built-in decoder allowing individual control of the three/four LED channels’ On/Off state and current level. A total of 192 current levels are available for each channel from 0.125mA to 24mA with a 0.125mA step.

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