Anduril 2 feature change suggestions

I have SC31Pro and I have had to buy a TS10 and a TS25 that this time if I get them sent by another company, the other one I’m giving it for loss.

If I can help you in your tests, you say so.

But I still don’t have the programmer, he’s on his way.

When I get them I’ll try!

I love total control of the flashlight.

Thanks for your job!
PD: My next purchase will be from the Emisar brand, in less than a month I bought 12 flashlights :person_facepalming:t2: ‍ this is not right :sweat_smile:

Edit: It would be nice to have Muggle mode again, this is more complicated as it has been removed from the main file by what I’ve seen, perhaps using part of the V1 code can be adapted with 6H for example instead of 6C, so we have the simple mode for everyone, the advanced for us and the Muggle for children or not so children.

With 10c you put the simple one and leave it to a friend and with 6H or 6C you leave it to a child.

If we lower the glow in simple mode and leave it to a friend, we have to take more steps to change from friend to child and from child to friend I have done it and I end up giving the children the simple way directly, so that it doesn’t complicate me but you miss direct change with the 6C

I’ve said it many times.

If it’s not possible, I’m not saying it anymore, sorry

Remember I use a web translator :person_facepalming:t2: ‍ I don’t know if you understand what I’m saying :sweat_smile:

1 Thank

Thanks for the report, and glad you liked it!

Looks like a great idea and shouldn’t be hard to do, just need to save the previous level somewhere before switching. Not sure there’s free EEPROM for that (non-volatile memory so it would survive the light having the battery pulled out) but there should be enough RAM. Are you ok with the saved level not surviving battery removal?

You’re not! :grinning: Really, thanks for the great suggestions, they’re actually helping me to delve deeper into Anduril which is something I’ve been wanting to, while producing useful stuff for other people in the process (which my previous efforts didn’t).

1 Thank

You’re not too hard to understand albeit it does sometimes sound strange. But you’re a native Spanish speaker, right? I speak some Spanish myself, I wonder what the BLF policy is for non-English use. Will enquire and let you know, perhaps things will be smoother if we can communicate in Spanish and whoever else wants to read it to use a translator instead.

Will comment on the rest of your post when we get that sorted out.

EDIT: just posted this: What's the BLF policy for non-English language use?, now waiting for a response

1 Thank

I like to test all technical staff!

Can you calculate free space in eprom or it’s complicate? Yes I am ok with not surviving battery removal if there is not space in the eprom.

Never did that with an ATTiny MCU and toolchain. With other AVR MCUs and toolchains it was not too difficult, just had to have the linker generate a symbol table and then run some awk to total byte usage per category IIRC.

@wolfgirl42 can you please offer any guidance? TIA!

Can’t you just directly link it to where the choosing of high or low aux is already saved to memory? I.e, just changing the clicks to access the same memory function?

My TS11(my only light with aux) remembers aux settings through battery changes.

1 Thank

No, because that “already saved in memory” variable is the one I have to change to actually change the current aux brightness. To be able to go back to the previous brightness I really need a new variable to save it on.

1 Thank

The EEPROM is 256 bytes on a t1616 or 1634, so it’s fine - I’m not sure how much is being used (had a go at getting it with preprocessor macros but it’s going to need more thought as to how) but I know it’s not close to the limit yet.

Still not that familiar with lowlevel stuff myself either, just gradually learning mostly due to anduril :sweat_smile:, but I’ll keep looking into it.

2 Thanks

A blink after 8C is good or is useless?

1 Thank

Thanks for the response!

I will go ahead and try to implement @Light_Veteran’s request by saving the previous state in EEPROM.

I expect to post the result here in a few hours if things go as planned.

IMHO in a general way that ‘completion’ blink is good to let the user know the command has been accepted and processed; also it’s kinda the ‘standard’ behavior on Anduril for commands that don’t do anything to the main LED.

In the specific case of 8C I’m somewhat divided: the user can see the command’s effect in the aux led immediately, so we could argue it’s not doing anything useful. OTOH in the original Anduril code, 7C (which changes the aux LEDs like 8C, but in a circular way) also blinks the main LED on completion, so according to the “minimum surprise principle” (don’t change expected behavior unless warranted) I would be inclined to leave 8C as-is, ie with the completion blink in place

What do you think?

Not knowing it exactly kept bothering me, so I decided to do something about it; had a look at the code and in load-save-config-fsm.h there’s a typedef for Config, which turns out to be a structure that represents exactly what is saved to EEPROM. There’s even a helpful macro at that same file defining EEPROM_BYTES as sizeof(Config) :wink:

So I did a quick and dirty kludge program (called helpfully t.c as per long-standing kludging tradition) where I copy-pasted the structure definition along with typedefs for other custom types it uses like uint8_t and int8_t, removed all #if/#endif preprocessor ‘braces’ so as to force space allocation for whatever was inside them, then defined NUM_RAMPS and NUM_CHANNEL_MODES to the largest values I could find with a quick grep in the source tree. The kludge’s main() function for this kludge just printfs the value of EEPROM_BYTES. The source for the kludge is here, in case anyone is curious: Quick kludge to find out how many EEPROM bytes are in use (at maximum) on Anduril multi-channel branch rev. 721 · GitHub

Anyway, here’s what compiling and running it produces:

$ make t
cc     t.c   -o t
$ ./t
EEPROM_BYTES=53

So now we know – and your gut assessment was right: at least ~4/5s (203 bytes, yay!) of the T1616/T1634 EEPROM is free.

Now I can finally go ahead with full knowledge and tranquility :wink:

2 Thanks

It’s the same and it works well but I think a blink is a fast way to be sure that the command is done

1 Thank

It took a bit longer than a few hours (had to modify a few other files, etc), but here it is, tested and and working on my TS10: https://durval.com/xfer-only/anduril.wurkkos-ts10_-_multichannel_rev_721+8C_Quick_Aux_Switch_20230615_-_default_config.zip

@Light_Veteran (and @litris if you’re so inclined), please give it a run and post me with your impressions!

Will post the diff patch for that RSN, will have to organize the stuff first and there’s a couple of points I would like to discusss with those who know it better ie @wolfgirl42 and @ToyKeeper if they have the leisure.

The current Anduril code blinks the main LED on command completion for lights with switch LEDs like the FC13 – for lights like the TS10 it doesn’t. I’m actually trying to build this latest version of the 8C mod for my FC13 now, that’s how I know :slight_smile:

1 Thank

Just finished fixing a few issues that only happened with the RGB aux code and my FC13 is now shining in all its glory with the latest 8C_quick_aux_switch code – and it even seems to be working as expected! :slight_smile:

Anyone reading this who has a Wurkkos FC13 (or any other light supported by TK’s Anduril rev 721) and a flashing adapter and wants to help test the new code, just give me a shout – and my offer to build an hex with your preferred configuration extends to you too.

1 Thank

You have to buy a D4V2 and I have to buy a Wurkkos FC13😂

2 Thanks

Had a look on github, nice work. Great to see other people hacking on it :slight_smile: Go for it with any questions.

3 Thanks

Perfect! Thanks.

I am waiting for the programmer, I have one but without pogo pin.

Edit:

Can you send it in .zip?

I do everything from iPhone and in .HEX version directly it downloads it to me in web/txt version without correct encoding.

I’m looking forward to try it, I would also try others, I’m even looking already at the D4V2 with doubts between the 18650 or 21700 version I will have to buy both :man_facepalming:t2:

Thanks!

Hola @Litris, recién recibimos el permiso oficial para comunicarnos en Español, desde que lo siga la traducción al inglés, véalo aquí: What's the BLF policy for non-English language use? - #20 by dmenezes

De ese modo, así le voy contestar en mis próximos comentarios, y le pido que por favor haga lo mismo.

¡Gracias de antemano!


Hello @Litris, we just received official permission to communicate in Spanish, as long as the English translation follows, see it here: What’s the BLF policy for non-English language use? - #20 by dmenezes

That way, that’s how I’m going to answer you in my next comments, and I ask you to please do the same.

Thanks in advance!