Mode idea - Method for low footprint, high customization

(This is now a breakout thread)

Or one better. There is a large array to work with, and the user just sets the startPosition and endPosition.
Something like this hard coded, where numbers are percent of perceived output:
[1,100,50,1,25,50,75,100,60,40,10]

So if someone wants just high, med, moon (100,50,1) they set “2” for start, and “4” for end.
If they want to reverse that, they set “4” for start, and “2” for end.
For ‘moon, low, med1, med2, high’… they can set “4” and “8”.

Notice I eliminated the zero-based notation for user sanity. The array could be larger for even more choice, but the usage is exactly the same.
That sounds awesome to me. I take full credit for the idea :slight_smile:

It’s not awkward or complex at all. Check out my code plan:

User instructions:
Enter programming mode. It will flash once to confirm. Enter the first number. It will flash once to confirm. Enter second number. It will flash twice to confirm and save.

Choose your numbers from below:
1,2 = 1,100
2,1 = 100, 1
1,3 = 100,50,1%
3,1 = 1,50,100%
4,8 = 1,25,50,75,100%
8,4 = 100,75,50,25,1%
8,11 = 100,60,40,10
11,8 = 10,40,60,100
3,4 = 50,1
4,3 = 1,50

The real beauty is offering the reverse sets, and the reduction of low and high recurrences.

Is the user restricted to your list of start/end choices? What if the user chooses to start at position 1 and end at position 4? He’ll end up with two positions that are exactly the same output: position 1 and position 4 are 1%. If the user presses the button, the mode position will change, but the output will not change, which could confuse the user.

This looks very interesting as a mode selection for mode groups. I do not know code, but I get what you are saying here JoshK….

There is a ton of versatility in being able to select mode order and groups from a string…

Subscribed…

It looks like it could provide some nice extras, like “50, 100, 1” for people who like things out of order.

Just spitballing but it would be neat if there were a scheme to select # of modes, then the exact PWM value of every mode.

So It would ask # of modes, then “single digit, double digit, or triple digit,” once for each mode.

If single digits, it would do 1-9 blinks, allowing a PWM value of 1-9.

If double digits, it would do 1-9 blinks for the first digit, then 1-10 blinks for the 2nd digit. The 10th blink would represent 0, allowing any PWM value from 10 to 99 to be selected.

If triple digits, it would do 1-2 blinks for the first digit, then 1-10 blinks for the 2nd digit, then 1-10 blinks for the 3rd digit.
-The simplest rules for this would just make it so any value above 255 would be PWM 255.

Hoop, I’ve considered doing something like that. Instead of entering the PWM values directly though (which would get pretty long on multi-channel drivers), I figured I’d just let the light ramp until the user stops it. Use a visually-linear ramp with however many levels will fit, and stop when you get to the desired brightness. Sound good?

It’d be easiest on an e-switch light, but should still be feasible on a clicky switch. I think DrJones may have even done something like it already.

The upside is it would allow configuring a mode group or two with any modes in any order. And some people want sequences like med/high/low instead of a strict low-to-high or high-to-low, or might want blinkies in the main sequence. Or they might not want a low mode, or might only want exactly 100% 7135 and exactly 100% FET with nothing else, or other misc configs.

I’m just not really convinced that it’s worth doing. It’d take a bunch of extra code, it’d be harder for users to understand, and the people who really want that much control might be better off changing a line of code and reflashing.

Unless we added bluetooth or something, like the FLEX Asgard. Then there would be an app instead of a config mode, so it’d be an obvious win.

So the question is… Are there a lot of people who want that much control, who are willing to learn a cryptic one-button one-pixel menu system, but aren’t willing to flash a driver? I don’t know the answer.

Ramping would be the simplest method to select any output level, for sure, though not quite so exacting. It would just have to ramp very slowly during the selection process, at least on the low end.

I do think that flashing is easy enough for anyone willing to take a little time to read some guides and buy a programmer. If you’re this picky about custom mode levels, you might as well.

That’s cool combo for the list. And others like 100% only are hiding in there too.

It’s all just a proposition, I think it’s all laid out now, so I will relax. I don’t know if it needs to exist, just sharing an clever compression idea.

Complete customizability is nice. As was mentioned, Dr. Jones implemented this in his lucidrv FW that comes on the H17F driver. This driver is almost perfect for me, but the FET has a relatively high on-resistance, which is a pretty big compromise when you are after max brightness.

The Bistro FW has a nice level of customizability and works great for me, but sometimes none of the available options is what you want, so complete customizability is ideal.

I will have to look into lucidrv. This idea is best described as guppydrv on steroids, and compressed.

Not at all, advanced users can find their own combos. The list is just for basic users.

Maybe the flashlight would have a photo-detector at the rim, and you lay it over your smartphone screen for IR Remote style communication :slight_smile: It would take a lot of code to implement, but in theory you could use an app for total customization, then set the flashlight on top and activate the screen flash sequence to ‘program’ the flashlight sitting on top of the screen. :smiley: It’s a lot of work, but it avoids users ever coding and buying a programming cable and learning to use it.

Another option for compressing the mode group table is to use Pascal-style string length prefixes or C-style null suffixes instead of padding out to the maximum length with zeroes. This would reduce bistro’s mode table from 76 bytes to 47, then require a little bit more code to parse the table.

Maybe in a future version I’ll do it that way if I need another 20 bytes. But the things I want to add are likely going to take quite a bit more space than that, so I’m looking at bigger MCUs instead.

Another, likely more effective way to save space would be to encode the multichannel power ramp differently, to avoid all the 255s at the end of the 7135 ramp and all the 0s at the beginning of the FET ramp. Potentially also more, on drivers with more channels. It could cut the ramp size in half, plus a few extra bytes in the code which interprets the ramp. However, it also eliminates the option of using those channels to power separate LEDs.

It’s too bad RAM isn’t plentiful on these chips. If it was, we could do actual compression on the ROM, give it a decompression stub, and expand the program into RAM for execution. That’s how most of the “4K demos” and “64K demos” work in the PC demoscene, packing a ridiculous amount of neat stuff into a few thousand bytes. But that would only work if the RAM was several times bigger than the ROM.

Sorry, I’m just thinking out loud.