Anduril ... 2?

Garik_F · October 30, 2023, 5:51pm

Yes, but these are only transition between levels 150 → 149, it’s two lines of code, what can be possible be broken with those?

SammysHP · October 30, 2023, 6:01pm

There were massive changes in Anduril over the last few years. It is very unlikely that a configuration from a few years ago or even a few weeks or months ago would still work. It needs a new hwdef and an updated cfg file as well.

Quadrupel · October 30, 2023, 6:42pm

dynamic pwm

wolfgirl42 · October 30, 2023, 6:48pm

…you prefer higher lows and a bumpier ramp?

Quadrupel · October 30, 2023, 6:50pm

Nope, i have other reasons, can not implement it to my UI. Years ago managed to get super low moon with fet+1 driver…

wolfgirl42 · October 30, 2023, 6:53pm

I’m listening…

There really isn’t any difference visible to the end user other than the lower low and improved consistency across the lower to mid ramp. Unless a specific level causes PWM noise on a certain light?

A bit too busy right now but I’ll try and look later. There are a few things in that hwdef that seem wrong (unless you made other code changes elsewhere) though.

Garik_F · October 30, 2023, 7:24pm

I think it’s another change in fsm-adc.c (EXTERN_TEMP_REVERSE_FORMULA in hwdef) - just found this right now:

    #else
    // external sensor, need to use a reverse formula otherwise the ceiling temperature will be calculated incorrectly
    // convert (therm_ceil in Celsius - therm_cal_offset - THERM_CAL_OFFSET) to ADC value 
    uint16_t ceil = ((uint16_t)EXTERN_TEMP_REVERSE_FORMULA(therm_ceil- therm_cal_offset - THERM_CAL_OFFSET) ) << 1;
    #endif

I’ll try build with this change and let everybody know

Garik_F · October 30, 2023, 8:43pm

Yes, it worked. Now I got normally operating flashlights from FF on Anduril 2 rev.657.

Thus, in order to update any Lume1-Fireflies Driver For Hardware Revision B (orange one)
for Anduril 2 rev. 657 of you need to make the following changes:

cfg-fireflies-lume1.h

#define MAX_1x7135 149 // was #define MAX_1x7135 69 - this is misuse of option because here we got also MIN_THERM_STEPDOWN 
...
// #define USE_TENCLICK_THERMAL_CONFIG - obsolete
...
// #define USE_VOLTAGE_LOWPASS - obsolete

ramp-mode.c - line 310 and below

#ifdef USE_THERMAL_REGULATION
...
           #ifdef USE_SET_LEVEL_GRADUALLY
            //set_level_gradually(stepdown); - comment out
        >>> if (actual_level == 150) {set_level(149);} // added
        >>> else {set_level_gradually(stepdown);} // added
            #else
            set_level(stepdown);
            #endif

fsm-adc.c

#ifdef USE_THERMAL_REGULATION
…
#define TURBO_TEMP_EXTRA 7
…
// old code block
    #ifndef USE_EXTERNAL_TEMP_SENSOR
    // onboard sensor for attiny25/45/85/1634
    temperature = (measurement>>1) + THERM_CAL_OFFSET + (int16_t)therm_cal_offset - 275;
    #else
    // external sensor
    temperature = EXTERN_TEMP_FORMULA(measurement>>1) + THERM_CAL_OFFSET + (int16_t)therm_cal_offset;
    #endif

    // how much has the temperature changed between now and a few seconds ago?
    int16_t diff;
    diff = measurement - temperature_history[history_step];

    // update / rotate the temperature history
    temperature_history[history_step] = measurement;
    history_step = (history_step + 1) & (NUM_TEMP_HISTORY_STEPS-1);

    // PI[D]: guess what the temperature will be in a few seconds
    uint16_t pt;  // predicted temperature
    pt = measurement + (diff * THERM_LOOKAHEAD);

    // convert temperature limit from C to raw 16-bit ADC units
    // C = (ADC>>6) - 275 + THERM_CAL_OFFSET + therm_cal_offset;
    // ... so ...
    // (C + 275 - THERM_CAL_OFFSET - therm_cal_offset) << 6 = ADC;
    uint16_t ceil = (therm_ceil + 275 - therm_cal_offset - THERM_CAL_OFFSET) << 1;
    int16_t offset = pt - ceil;

// replace with this
    #ifndef USE_EXTERNAL_TEMP_SENSOR
    // onboard sensor for attiny25/45/85/1634
    temperature = (measurement>>1) + THERM_CAL_OFFSET + (int16_t)therm_cal_offset - 275;
    #else
    // external sensor
    temperature = EXTERN_TEMP_FORMULA(measurement>>1) + THERM_CAL_OFFSET + (int16_t)therm_cal_offset;
    #endif

    // how much has the temperature changed between now and a few seconds ago?
    int16_t diff;
    diff = measurement - temperature_history[history_step];

    // update / rotate the temperature history
    temperature_history[history_step] = measurement;
    history_step = (history_step + 1) & (NUM_TEMP_HISTORY_STEPS-1);

    // PI[D]: guess what the temperature will be in a few seconds
    uint16_t pt;  // predicted temperature
    pt = measurement + (diff * THERM_LOOKAHEAD);

    // convert temperature limit from C to raw 16-bit ADC units
    #ifndef USE_EXTERNAL_TEMP_SENSOR
    // C = (ADC>>6) - 275 + THERM_CAL_OFFSET + therm_cal_offset;
    // ... so ...
    // (C + 275 - THERM_CAL_OFFSET - therm_cal_offset) << 6 = ADC;
    // Note, defined in fsm-adc.h: uint8_t therm_ceil = DEFAULT_THERM_CEIL; in Celsius
    uint16_t ceil = (therm_ceil + 275 - therm_cal_offset - THERM_CAL_OFFSET) << 1;
    #else
    // external sensor, need to use a reverse formula otherwise the ceiling temperature will be calculated incorrectly
    // convert (therm_ceil in Celsius - therm_cal_offset - THERM_CAL_OFFSET) to ADC value 
    uint16_t ceil = ((uint16_t)EXTERN_TEMP_REVERSE_FORMULA(therm_ceil- therm_cal_offset - THERM_CAL_OFFSET) ) << 1;
    #endif

If someone has enough skills to redefine those pieces of code at the build target level, you are very welcome - my skill is not enough for this task.

wolfgirl42 · October 30, 2023, 9:30pm

I can do it, but I’m probably going to work on porting it to the latest multichannel branch instead, as the version you did is still about 200 revisions old.

eckyeckypikang · October 30, 2023, 9:34pm

Lots of fun stuff in the most-recent builds! I look forward to seeing it whenever it comes out - hoping to modernize my T1R if I can!

Garik_F · October 30, 2023, 9:39pm

It will be super cool, I’m simply don’t have any multichannel lights (yet?) so why multichannel

wolfgirl42 · October 30, 2023, 10:15pm

It’s the current development branch, which has various other new fixes and features. Plus, aux is a channel - e.g. you can have things like battery check mode use aux instead of main LEDs.

dmenezes · October 31, 2023, 10:21am

Thanks for that piece of info. I was judging USBASP to be at least minimally decent in that regard, but it seems I underestimated its suckyness…

Maybe the t1616 with UPDI but I’ve never done it on that MCU.

Indeed, here’s what happens when you take off the pins in the middle of a write with an AT1616 (tested with my TiTS10 and @thefreeman’s adapter, but I’m pretty sure it applies to any UPDI setting):

$ sudo avrdude -p attiny1616 -c serialupdi -P /dev/ttyUSB0 -Uflash:w:anduril.hex
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9421 (probably t1616)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file anduril.hex for flash
         with 10826 bytes in 1 section within [0, 0x2a49]
         using 170 pages and 54 pad bytes
avrdude: writing 10826 bytes flash ...

Writing | ####---------------------------------------------- | 7% 1.68 s 

avrdude error: commit data command failed
avrdude error: wait NVM ready timed out
avrdude error: updi_nvm_wait_ready() failed
 ***failed;

And then it hangs there until aborted with ^C or similar, so definitely no silent failures with UPDI like you reported with USBASP.

To sum it up, it seems USBASP sucks even more than I thought possible. Come on, even semi-decent communication protocols have had ACK at least for the last 50 years… it’s a real shame USBASP doesn’t, and one more reason for me to avoid it like the devil.

dmenezes · October 31, 2023, 10:44am

So, motivated by my TiTS10 arrival, I finally upgraded to TK’s latest (rev. 812 at least until a few minutes ago, multichannel seems to be changing in an hectic pace).

For those wanting to flash it but not willing or able to compile it themselves, here are the hexes: https://durval.com/xfer-only/toykeeper_-_flashlight-firmware_-_multi-channel_-_rev_812_-_00ALL_HEXES_THAT_BUILD.zip

Caveat emptor, use at your own risk, your mileage may vary, etc – but if anyone uses it successfully or not, please let me know.

I also did a version with my 8C-Quick_Aux_Swap mod built in, just posted it on the other thread: Anduril 2 feature change suggestions - #542 by dmenezes

wolfgirl42 · October 31, 2023, 1:15pm

I really think you overreact about it. It’s slightly less convenient to flash, it happens <1% of the time, and avoiding great lights because of their MCU is just disingenuous IMO. Would the t1616 be better? Definitely, but that doesn’t make them bad lights.

dmenezes · October 31, 2023, 4:39pm

I think you are overreacting to my overreaction But seriously, I didn’t say I was “avoiding great lights” (or any light, really) “because of their MCU” – just that I avoid USBASP in general because it sucks big time (I haven’t seen one positive thing about that piece-of-crap protocol yet: more pins, separate and more expensive flashing kit, less reliability, bad protocol design, etc just for starters).

And even without owning one yet, I agree: Hanklights are great, despite their reliance on USBASP, and should not be avoided just because of that. That’s why I’ve selected the KR1 to be my next light, a selection you yourself helped me to make: Hanklights with SBT90.2? - #26 by dmenezes

Tulpenzeit · October 31, 2023, 9:51pm

Hmm. I have quite a number of Hank lights which I constantly update via USBASP. I never had a problem of any sort. OK, if you don’t like this way to do updates - fine with me. But you being somebody who never did this kind of update, and at the same time shout loud via forum about how bad it is - I suggest you review your own statements, for yourself, and check for yourself weather all of your comments are adequate.

Jeffgoldblum · November 1, 2023, 12:20pm

Whoa big update, like every model. What did I miss?

Oh there’s a changelog! Well this answers my question lol

dmenezes · November 1, 2023, 12:39pm

Yep! A changelog is a big help. Just be aware that it’s a summary and for the details you will still have to dig into the raw revision comments, eg for investigating @Light_Veteran’s fw3x-lume1 issue, I had to resort to her raw commit logs as the Changelog didn’t make any specific mention.

dmenezes · November 1, 2023, 12:48pm

Looks like overreacting is the order of the day!

Seriously, I didn’t mean to offend you personally (nor your USBASP lights) and I’m sorry if you feel that way. And while I’m glad you never had any problems when updating your USBASP lights, I can see there are plenty of people who do.

Moreover, thanks for your suggestion to review my statements – I just did, and after re-reading everything, I keep standing by my comments: a protocol (or its implementation) that in the 21st century still doesn’t support ACKs (so the electric circuit can even be fully interrupted, by pulling out the pins in the middle of an update as @wolfgirl42 has reported, and it still goes merrily its way without reporting any errors) is a sorry piece of work and has no place among polite company.