See this is were we differ… I don’t know moras code… It wasn’t required for the amature radio license when I took it. I do know sign language.
So that’s why I was suggesting that you can turn it on or off too.
It has 4 user-selectable aux brightness modes / patterns: off, low, high, or blinking. The blinking animation is a simple table in the source code, fairly simple to edit. Any sequence of 0/1/2 works (off/low/high).
Usually the default is low aux in “off” mode and blinking aux in “lockout” mode.
… and on lights with RGB aux, the color can be selected too. There are 7 steady colors and 3 animated (disco, rainbow, voltage). I typically recommend using voltage mode, so it’ll show the battery charge. But I also like combining disco and blinking modes for lockout.
I think you might be looking for the new tactical mode instead… or maybe even lockout (with manual memory set at a useful level).
Momentary (a.k.a. signalling) mode is intentionally “stuck” until battery disconnect, because the point of that mode is that the user can input absolutely any pattern without worrying about whether it will exit and start doing something else. It’s for Morse code and light painting, but also for just messing around. Like, go to lightning mode and then 5C, and it becomes momentary lightning mode.
1 Thank
A while ago I’ve added these two patterns in my more-aux-patterns branch.
1 Thank
Oh awesome I will look them over I was just going to brake up the flash into high and low. But if you have done that already. makes it easier.
Ya, I have set for high cyan for off mode, and low batt check in lock out because I have the auto lock out for 10 mins. BTW does the cycle mods and blink take more juice to run?
And maybe I will change it to 5H instead of 5C… because I seem to be triggering it on accident when going to lockout. Thats why I find it frustrating.
In standby mode, it wakes up 8 times per second. It processes one “sleep tick”, then goes back to sleep. This “tick” of the clock doesn’t do much… it generally just advances to the next frame of animation, which takes barely any time or energy. And this happens in all aux modes, not just the blinking mode. So the animation makes no difference in power use.
The aux brightness matters though…
- aux off: ~0.03 mA
- aux low: ~0.08 mA
- aux high: ~5 mA (really 1 to 15 mA depending on the light and color(s))
- aux blinking: … is more complicated
The animation, specifically, is:
static const uint8_t seq[] = {0, 1, 2, 1, 0, 0, 0, 0,
0, 0, 1, 0, 0, 0, 0, 0};
Doing the math, that’s (5 + (3 * 0.08) + (12 * 0.03)) / 16 mA, or 0.35 mA on average. Or depending on the light, anywhere from 0.1 mA to 1.0 mA average.
So it uses more power than the low aux mode, but only about 1/15th as much as the high aux mode… unless you change the animation, in which case, you’ll have to recalculate the power use.
On top of all that, it checks the battery voltage every 8 seconds. This requires about 0.3 mA to run the ADC, and it runs for roughly 1 tick. Over the entire 8-second cycle, the average is 0.01 mA or less, so add 0.01 to each of the averages above.
In case someone wants to see a visualization of this, I made a measurement with an oscilloscope a while ago:
1 Thank
Interesting. It looks like the ADC stays on for 4 ticks, instead of 1.
I wonder if I can reduce that, or if that’s actually the shortest it can run and still work.
…
Looking through the code and the reference manuals, it looks like it could probably be reduced by temporarily using a different sleep mode during each measurement. I’ll have to try that sometime. I thought the ADC kept running in suspend mode, but it looks like it gets paused, and only runs during the active time for each sleep tick… and since the ADC needs like 1600 clock cycles for a measurement, and the sleep tick only runs for maybe 500 clock cycles, it takes 4 ticks. But I think it could instead use noise reduction mode to do the measurement all at once, which should (I think) reduce the time to just 1 or 2 ms, and reduce the total energy used from ~150 uA-seconds to ~4 uA-seconds.
So, for example, in aux low mode, avg power would drop from ~99 uA to ~81 uA. And it might simultaneously eliminate the spurious readings it occasionally gets. And it could probably measure more often without making a significant impact on total power used. Like, maybe every 2 seconds instead of every 8.
That is, if I understand it correctly, and if I did the math right. 
1 Thank
So it could run 1/5 th longer in sleep mode???
Also Why wouldnt you run run the volt check like every 2 mins or so in sleep mode. Its not likely to change charging or discharging in the sleep mode
Because the colors change with voltage, and right after the light gets shut off, the voltage is probably sagging from the load it had a moment before. So I want the color to “bounce back” to its actual voltage fairly quickly.
It currently waits 8 seconds between measurements, so people have to wait about 8 seconds to find out if their battery is actually low or if it was just sagging. But if it could check every second or two, it would give useful feedback much faster.
It shouldn’t be too often, of course… because the goal is to keep power use very, very low. But that’s a matter of diminishing returns. Like, if the change I have in mind works, it might use 0.5 uA on average, when it checks every 8 seconds… but the chip’s standby mode uses at least 30 uA anyway, so 30.5 uA is virtually indistinguishable. If I raised it to once per second, it would go up to 34 uA… but that’s still pretty negligible.
Or with the aux LEDs on low, it might go from 80 uA to 84 uA… and either one would be an improvement over the ~100 uA it uses now.
TL;DR: I think I might be able to check more often and reduce total power use.
2 Thanks
Well then I am glad I can ask a bunch of dumb questions to help along innovation by facilitating conversation. I still hate mom mode and will be changing it to 5H. so its hard to accidently enter it. also is there a new chart that shows the new tact modes everyone is talking about? I still got a ton of stuff to go over. Like putting together the PCB for the h25lr for starters. I need to get that done by aug.
Nobody’s updated any of the charts yet but it’s fairly simple. 6H to enter/exit, 7H then enter a value for each slot for the 1st/2nd/3rd option, and 1-3H to use each slot.
Omg my wukkos light is so much better than the fw3a I just got btw. So much smoother(if thats what you call it), no weird flashes as its ramping, the button clicks are better( already designed a new PCB with a tact switch.) Like I notice weird flickers in candle mode compared to the wurkoos. Like its just not as smooth. I think with the tack button and the attiny1616 and cmy aux it will become a decent light.
WOO, tact switch. Also I already updated the design. for the vias
I am currently putting together tlv333 board with the at 1616 for the fwXXs . I know its like putting in an LS6 into a 66 fastback. or would it be a 70 bug.
What R and C size do you suggest? Also what pmos do you suggest for the polarity protection?
0603 is a good size, small enough for everything to fit on one side for such driver while still being relatively easy to manipulate.
The miliOhm sense resistor can be 0805 (0603 also works).
The RPP is just for the MCU, so any package will do, I like SOT-723 because it’s small, but a little bigger (SOT-523 ?) might be easier to manipulate.
The attiny1616 can do PWM at any speed from 2 to 65535 steps per cycle, adjustable on the fly. I use this to make the low modes lower and make the ramp generally smoother.
The FW3A used attiny85, which has only 8-bit PWM. So its ramp doesn’t go as low, and it tends to get stair-steppy at the bottom. This could be alleviated by implementing delta-sigma modulation, but that’s tricky to do so I haven’t. It requires very tight timing.
The blink while ramping is just a reference point. It’s mostly relevant on FET+1 lights, to let the user know when they have shifted “gears” from the 7135 chip to the DD FET. But on the FW3A it got carried over even though it’s not as relevant there. OTOH, today’s FW3As seem to be downgraded to FET+1, so… meh.
2 Thanks
Nope… the one I got is full fet + 7 statis. I literally have had it for 4 days. Which I plan to redo that for the 1616 and rgb but proper board. As soon as I build out @thefreeman hdr board for the fwXX. then do one for that h25lr… its current driver is lacking. as its 5 levels only. BTW do you suggest a particular set up. I dont know if a 2 channel 3 melt7135 or what would be best for that type of set up. I am only driving one led for each of the 3 leds.
Also I figured the blinks might be for the ramping… but its like super jank looking. also I do get some weird flicker out of it at higher outputs. I am pretty sure the 1616 will fix the weird flicker. I could have a bad programing too
Thanks working on it now. Hopefully get it done this week.
ALso really dumb question whats the “S” label in your diagram on pad PB4?
Switch.
OMG… slaps forehead. duh. of course. I was thinking like source and drain…
THANKS
1 Thank
For the FW3A a 5060 NFET (Q1) is probably better suited than 3333, better thermal dissipation for the higher power dissipation due to the lower Vf.