You’re welcome. I’m going through all my cfg’s that I need and while those numbers are different per light, its at least in the file, so you can find it. I have some flashing to do.
1 Thank
I fixed the weirdness with thermal regulation. There was an unsigned int where a signed int should be, so negative calibration numbers made it think it was always overheating.
Also a few other fixes today, including the aux pre-flash. New builds are up in the usual spot.
It allows the user to blink numbers using the aux LEDs instead of main LEDs, but I haven’t figured out yet whether that should be default or not. Any thoughts?
On some lights it makes more sense than others, so it’ll probably be decided on a per-light basis… but there’s also the option of going the safe route and always defaulting to main LEDs.
To change it, go into batt check mode, and click 3C.
4 Thanks
As for the Aux blinking out the battery voltage and temp… I like that quite a lot. Being able to switch to different Aux colors or the main emitters via 3C is also a really cool trick. Feels like that’s peak performance to me.
Of course, as you said, some lights won’t have that option… Would something like the D1V2 or D1K be able to switch between the main emitter and the Aux lights under the button?
1 Thank
I didn’t realize it was togglable, missed that in the manual.
If it’s an option, it might be good to make RGB the default to spread the awareness of that setting. That way users know it’s there and can easily change it back to the main emitters if desired with 3C.
1 Thank
I think it makes the most sense to use aux for lights where the aux is located with the main emitters, but not for ones where the aux is e.g. a switch LED only.
Yes. If you have the RGB switch, each aux colour can be defined as a channel so you can choose which aux colour it uses as well, or for single colour switches it’s still usable that way too.
Really liking the new version check format, definitely makes it easier for me to read.
3 Thanks
This is slick… Can’t wait to get the rest of my A2 lights updated and play around.
Thanks!
EDIT - my D1V2 runs A2 for model 0125 - the “D1V2 nofet”… Looks like it’s not been updated yet.
changed version check from YYYYMMDDXXXX to XXXX.YYYY-MM-DD,
where the punctuation makes a “buzz” instead of number blinks
OOOhhh. I need to update a few lights now.
1 Thank
Here’s a set of builds for every currently-working target as of today (revision 721): 490.6 KB folder on MEGA
2 Thanks
Updated my Docker builder fork to include GNU grep, required to support the args passed in the latest change to build.sh. If you’re using it from Docker Hub, docker pull siterelenby/anduril-builder:latest.
1 Thank
Ah, sorry, I’ve been really dragging my feet about updating the rest of the builds. I’m still debating whether to change the internal implementation details, and it’s easier to change that now than it’ll be to change it after everything is updated. But I should be able to update that one…
(as for what might change, it’d be nice to organize all the channel stuff into a single struct per channel mode, like a C++ “object”, to make the API simpler and easier and less prone to errors… but OTOH, RAM is incredibly limited on attiny, and the current method allows keeping some parts in RAM and others only in ROM, to reduce RAM usage… and I’ll need a lot of RAM for upcoming RGB features… so I’m debating what implementation I should use)
The channel mode stuff is pretty experimental and I don’t have a clean, obvious design in mind like I did when writing FSM and Anduril. So it’s a lot of trial and error and a lot of awkwardness along the way. I’m not super happy with it, but I also don’t know how to make it significantly better. Some lights need a bunch of different channel modes to support all the hardware types and usage styles, but it kinda sucks flipping through a dozen different channel modes with a 1-button interface which was already very dense before this new feature category.
I have a similar issue with an upcoming RGB mode I want to add. It needs like a dozen slots for presets, to allow the user to explore the options and save their favorites, but I don’t know of an easy way to navigate a dozen different presets. The current version uses a double-click to rotate through them, much like how strobe modes use 2C to rotate. But that interface is pretty inconvenient if you use more than one or two of the modes in that group.
We’re really pushing the limits of what can feasibly be accessed with just 1 button. The more stuff gets added, the harder it is to reach the features.
Many people won’t change it, or won’t even know they can change it. They might just get confused when they try to check the battery and the light doesn’t make enough light to see anything unless they turn it around to look at the front end.
There’s also another matter to consider, which is that a lot of builds seem to get used on several different hardware models… and not all models have the same physical features. Like, a build might support button LEDs but get used also on models which don’t have that. Then if it defaults to aux, it might just appear to do nothing at all, on some models.
So I’m unsure if aux would be a good default. But OTOH, if the default stays the same as it has always been, there’s the issue that people who want the new feature won’t know it exists.
Anyway, things are growing, and new hardware and new features are being added… but it’s all a bit wonky so far. Making it clean and intuitive is increasingly difficult with more features and complexity.
2 Thanks
Oh dang, it didn’t have grep? Sorry about that, I’ve generally been able to assume that certain core utilities are available, like grep.
The build.sh changes aren’t even very important. It could probably check for existence of those utilities and only execute some parts when they’re available. It just dumps a debugging file on each build, to make it easier to see the effect of preprocessor clauses, and to make it easier to directly compare different builds. It’s not something I expect anyone other than me to use… and I don’t even need it very often.
I added it while trying to find the difference between D4v2 and KR4 which would cause one to think it’s overheating while the other was fine… but it turns out there was no relevant code difference between the two. It’s just that, by random chance, my KR4 and D4v2 had different temperature biases in hardware, so a factory reset gave one a positive correction factor and the other one a negative factor. And my config refactor patch earlier accidentally converted an int8_t to a uint8_t, which made negative numbers stop working.
Fixing it was as simple as deleting one letter… just a single byte. But it took a while to figure that out, because I was looking in the wrong places.
Anyway, I’ll try to keep in mind that this sort of change isn’t free any more, since Docker doesn’t run a full userspace environment.
1 Thank
So just what I suggested a while ago. 
Indeed, RAM might be a problem. Can’t you just offload some of the channel configuration to a struct of function pointers in ROM using __flash? One struct for the pointers, one for the state that is passed during function calls.
I’m probably worrying too much. Anduril has never been close to the RAM limit, and it will probably still be okay even after adding a relatively large data structure for user-defined RGB modes. I just went to check the specs again, and there’s more RAM than I thought.
The RGB stuff will definitely take a big chunk of eeprom though. It’s like ten bytes per preset or “patch”, and probably a dozen presets. That’s nearly half the total eeprom.
The number of “patch” slots is debatable though. With RGB, it needs 6 slots just to cover the basic primary and secondary colors, and I’d like to also have enough slots to include more interesting patterns. Originally I made it for RYGB, with 8 slots for primary+secondary and 4 for extras… but with just 3 colors of LED, maybe it would need fewer slots.
No worries at all! Given what little of all of this I’m able to do myself I can’t imagine there’s much, if any, dragging of feet on your end - innovation and exploration becomes increasingly difficult with a continuously growing repository. In whatever time it happens, it happens - not like I don’t have a few dozen other lights to play with!
Thanks!
1 Thank
It has grep, just it’s based on alpine so by default it’s BusyBox grep (which doesn’t support long args, also seems to have no equivalent to --text), unless you install GNU grep. Firmware still builds without it, just the .cpp generation fails. I wrote my own preprocessor script a while back to debug some stuff and it didn’t result in as clean output, so it’s a good feature to have.
As it is, when busybox grep it outputs a usage summary into the build output, one way around that would just be to redirect grep’s stderr to /dev/null, since it’s something most people will never use, you’re right there (and I’ve actually broken builds of stuff my making similar assumptions about tool availability and version before 
).
Starting to feel like it’s pushing the capabilities of a single switch interface a bit. I added 4C for previous channel, which works in ramp mode, which helps a bit, but would need a different number of clicks to work in other modes like strobes, but RGB modes are definitely going to be harder. I guess dual switch support was potentially going to happen anyway at some point though. Might be worth looking into a bigger MCU for RGB support, possibly the 2-series.
[/quote]
Something like a hold to go through them? On my dual channel lights I already have 12+ modes if I enable all the aux modes in addition to the standard channel modes (plus plan to add some custom channel modes), so when the user holds the switch down, it cycles through all the channels, previewing each one similar to the 9H menu. Might need to go kind of slowly for some, but if the user has memorised the order, easy to have a setting to speed it up. I’ve been considering getting an RGB critter for a while just out of curiosity, but it might be interesting to see how they implement their interface (obviously, 3 switches, it’s going to be more complicated) to see if there are any ideas that could be adapted.
It’s no problem, it’s easy to keep up to date and IMO things like coreutils are fine to expect to be installed and present (although there is in some cases portability issues with MacOS with its mostly-but-not-entirely-BSD userland too, which is kind of part of the entire reason Docker is a good solution in the first place…), I just don’t like bloating Docker images with unnecessary tools when if there is ever a time to do some debugging on one, it’s trivial to install what you need at that time.
External memory? Not sure how many pins you’d need to reasonably access it, but it’d be useful for a feature that’s only on some lights without having to add and maintain support for more MCUs, potentially more different than the current range.
Juuuuuust a bit.
With the multi-channel branch, I’m somewhat torn. On the one hand, it’s massively better than what I had before, and it enables a ton of new features which just weren’t possible. On the other hand, it doesn’t feel like it’s quite the right solution. Something feels off.
Funny you mention it. I was just in the middle of writing to Hank about maybe switching to attiny3216. There’s also attiny3226 (2-series model), but in some ways it looks like it’s less capable than the older 1-series model. Specifically…
- 1-series: 7 PWM outputs + 1 analog output
- 2-series: 5 PWM outputs, and slightly lower power use
So I think 1-series can handle more complicated lights than a 2-series MCU.
Oh, it’s not full enough to need anything like that yet. But on RGB lights, it might use like 70% of the eeprom, instead of 15% like it does now for a single-color light.
As for the RGB modes themselves… I’m not really talking about channel modes. It’s more like the strobe group, except that every mode would be user-defined. Pick two spots in the hue+brightness color space, pick an oscillation pattern, pick and overlay pattern, turn some metaphoric knobs to adjust speed and intensity and stuff, and you have a custom color mode. Then repeat until all the patch slots are full.
It’ll come with some interesting defaults, of course.
For example, it could use a medium red and brighter yellow with a candle type oscillator between, plus another slow smooth oscillator on top for brightness, to simulate a candle. Or make a mode with a rainbow oscillator plus a variable shimmer on top, for an extra fancy mode. Or a reddish to purplish mode with a broken-wiring oscillator (similar to lightning), plus another lightning-style brightness oscillator on top, for a borderline sith type pattern. Or give it zero-brightness red and blue with a slow-ish square wave, plus a fast square wave on top for brightness, and it’s a police flasher. Etc, etc.
The user can make their own patterns to suit their needs and preferences, and the method used is based on how people design sounds on a synthesizer.
This is all completely independent of the channel modes. It’s just a special mode group for fancy color effects. It’ll probably be useful for light painting and lightsabering.
3 Thanks
That’s something I know almost nothing about, but it definitely sounds interesting and I’m looking forward to playing with it
I flashed my KR1 XHP70.3 (boost) with the anduril.2023-05-17.noctigon-dm11-boost build since it seemed to match the model number from the firmware it shipped with (0273), but battery check and firmware check don’t work now (maybe related to the change to use aux now for those which it doesn’t have?). Is there a better build to use? None of the others in the toykeeper build list match the noctigon-dm11-boost from the models.txt for 0273.
Hi
I used Wolfgirls latest builds, the DM11 Boost for the KR1 70.3, and temp, voltage and firmware checks work for me.
Yea, that worked, after I changed the output mode with 3c; it defaulted to aux. I had tried that on the 2023-05-17 build too but it didn’t seem to work. Thanks!
1 Thank