Why not have a really programmable light?

i guess i should also require EDC size—at least for me

i saw those nextorches, they are too big, and some are apparently discontinued?

anyone ever try one?

also i think they just allow you to design your own sequence only of some predetermined functions
which would be good but still i want more
oh and it has to be cheap too
and small

what do i not care about? tint, not too picky about pattern, anodizing, knurling, threads, mineral glass, breathing dragon modes, over 500 lumens, usb recharge

wle

It’s not just software (UI) that prevents some of this. There’s not always a lot of space on a driver board to put all the components necessary to enable all of these features. Cost is another factor.

The Emisar D4s has already pads for flashing on the head.
And you can use ToyKeeper FSM firmware or tinker with Andúril
Go for it
http://tiny.cc/TKAnduril

Most lights are "really programmable". You just have to flash the controller with your code.
If you don't know how to do it you also will not be able to program it using another interface.

That’s the whole idea of using USB and dedicated app in my opinion. One doesn’t have to know anything about flashing the controller. If they know what output they would like to have or functions (strobe, etc.) it should be doable be choosing it in app by setting on/off options and values.

Like Manker Godmes but without bluetooth remote control - USB cable should be enough.

Now you need a USB port on the driver, as well as much more circuitry to interface with a computer, and flash the firmware itself.
Not as simple as flashing a firmware chip during production.
Also much more things that can go wrong, if the firmware gets bricked.

Have a look at this caving light that has a remote control to configure modes
http://www.littlemonkeycaving.co.uk/Rude-Nora-3/

So, basically - it’s too complicated and too expensive to implement. So far :wink:

I do like that more and more lights give you a way to turn mode memory on/off. I find nothing more frustrating than mode memory.

I can deal with sub-optimal mode orders as long as I'm confident which mode is the starting mode.

I programmed my HDS 9 years ago and haven't messed with the programming since. It's totally cool to be able to set the light exactly the way you like, but if you can just buy a light that already has that UI, then there's no benefit to programming.

--flatline

I don’t think you fully understand computer programming.

Every “option” your software has available is a chunk of very specific code that some programmer put together. A “programmable” light would either have set options to enable (strobe on/off etc) or would require you to essentially build custom firmware, something you can do already. These set options are available already in custom firmware for many lights and driver, they are just ever so slightly more difficult to connect then USB.

Perhaps an open source community software would allow many developers to add set “features” to a repository, but this is a rather small community and getting enough of the necissary folks together to reach minimum critical mass is very difficult.

It would be kind of cool if the USB charging port could also be used to upload new firmware. Why open up the driver so you can get a clip around the ATiny when you could just plug a USB cable into the charging port?

I suspect that might require a lot of custom circuitry and programming though.

Pelican 7070R can be programmed via Bluetooth… though hardly in the “budget” category…

All it needs is a slight more capable attiny. The attiny85 can actually do native USB already, that’s what a digispark is (the smallest “arduino”). The issue is doing it takes 2 pins and the bootloader / USB code is quite large cutting down on executable code space.
Either of the larger 2 attinys toykeeper is currently looking into would be powerful enough to do both native USB and multiple channel pwm outputs!

While USB programming* would be great, Bluetooth would be even better.
That way you could upload settings with your smartphone.

*= With that I mean writing to the flashing; I’m and old geek that programmed EPROMs for his computer :slight_smile:
The programming should be no more that the ability to set truckloads of parameters.
Very useful would be setting the amount of steps and linking output to each step.
Set if the light defaults to a certain output level or not.
See stats like battery level, amp, temp, etc

With Bluetooth you could turn disco mode into DISCO MODE!

So that when you’re playing music from your phone, your flashlight would turn on and off in time to the music. :wink:

“Programming” doesn’t have to mean writing in code on a smartphone. A relatively simple UI where parameters are input then sent to the phone would be great! Even more awesome would be the remote control of a light through the smartphone, such as turn on/off, enter any mode or brightness level almost instantaneously, color mixing (for color mixing LEDs or LED boards/optics)… I may have to do some tinkering myself. I bet some grade-schooler could program a Raspberry Pi Zero to do this stuff.

You hacked my bluetooth connection, otherwise you impossibly can know my thoughts! :slight_smile:

I wouldn’t use it for that but I can imagine there are some speciality uses for such stuff. :partying_face:

Personally I would program mode sets for certain situations.
Personally I don’t like to have many modes. Three is max for me.
The amount of output varies by the task.
Two examples of what I would program:
A] Bedside light:
2 output levels.
Always defaults to the moonlight output.
The second would be something like 100 lumen.
Perhaps a hidden turbo.

B] Job light
Again 2 brightness levels and a hidden turbo.
But no moonlight.

i’d have 11 levels
1 2 4 8 16 32 64 128 256 512 1024
with a very fast light tap to go up, hold to go back (like BLF A6)
configurable mode memory
it would be like ramping but faster

or 1 3 10 30 100 300 1000

wle

Sets
[
Set1
[
ModesType: ramping (ramping/modes)
RampingSettings:
[
Start: 0.1% (0..100)
Finish: 80% (0..100)
Speed: 5 (1..10)
],
ModesSettings
[
modes: [10,20,60,80,100]
ModeChange: instant (instant / smooth)
],
ThermalProtection (rules)
[
if temperature > 55c and level > 80 SetLevel 50(%)
if timer > 70seconds and level > 60 SetLevel 40(%)
...
...
],
VoltageProtection (rules)
[
if voltage < 5.4 turnoff
if voltage < 6.2 set maxlevel 60%
...
...
],
...
...
...
],
Set2
[
...
...
...
]
]

Something like this, "minimized" in a way the driver software can use, could be uploaded to the flash memory of a flashlight. Easy to use for a little advanced users. If we create a user interface (native or web application) for manipulating such an array of values, we will have a programming GUI. After that, share your ini files with the rest of us!

So, we need compatible driver software (modified Narsil / Anduril?), minimizer + GUI, easy flash method (via a connection of some type, usb, bluetooth etc)