Can you share the original firmware dump that you hopefully made before messing with the driver? We need the build ID to know what was used. Have you checked the version information before updating it?
It’s possible it’s using the sp36 firmware. Are fuse values still a thing on the attiny1616? Maybe something like CKDIV8 is making the ramp slow. I’ve had that issue with Lume1 drivers in the past. Any tips on changing fuse values using pymcuprog?
Thank you. -This is already Anduril 2 as far as I can see from disassembling and analyzing the file. But it’s a very early build. I guess it’s a development build from gchart with a SP36-like configuration as the tinyavr port was merged much later.
Very interesting. It acts so much like Anduril 1. No simple mode and 4C from on goes into ramp config. Is this consistent with early builds of Anduril 2?
This entire time I’ve been trying anduril.2021-12-13.sofirn-sp36-t1616.hex and getting the slow ramping, but I just tried anduril.2021-08-31.sofirn-sp36-t1616.hex and it works!!
Also, I recall the mid-ramp flash was intentionally programmed in. It is intended to alert the user when switching channels.
If you are comfortable with coding and compiling, you can probably edit the flash or flashes in the ramp out of any version of Anduril 1 or 2.
Personally, I agree that a smooth ramp without any flashes is best. The only point of knowing when you’re switching channels would be to get an idea of when efficiency drops as you go to FET. With that knowledge you could fine-tune your output to stop just before you hit that point. However, in practice this does not work as the default ramp speed of 2 seconds is far too fast to provide any meaningful fine-tuning around channel switches.