What will be included in the kit? All parts? Or just the pogo key?
Looks good!
The programmer, cable, and pins are all included in the kits, all you need you to
do is to take the kits out from the box, connect it with you PC, install the software, reflash ,done.
Yes, thank you very much.
Everything for better lights :innocent:
Thank you for your quick and detailed reply!
Hopefully, the reflashing kits can be for sale in a week time.
Now, I would like to write an instruction to explain the steps on how to reflash,
a video would even be better, but I’m afraid my English is not good enough for the instruction video,
I hope some native English speakers could help to shoot the video.
Perhaps a lock on configuration mode so when we get it set up like we like it it could then be locked to prevent accidental entry? 22 clicks to lock out Configuration. (Ok, so I Love Titanium! [and have always been a Bob Hayes fan])
Ti is a little excessive, Neon would do.
In the example above it was more to show how color auxs could improve a UI like NarsilM. The bad part of NarsilM is that you have to sit there counting blinks while holding the sheet … buzz 1 blink… buzz 2 blinks … etc. If you lose count you have to start again, plus if you change the wrong setting it is not always obvious.
(I do not say ‘bad’ as an insult, it is inevitable to have this type of configuration process when we have only one input and one output).
Arduril does not function exactly like this - however there are parts of the UI which require counting blinks and so forth, so I think something similar could apply.
4.2V being displayed as 4 blinks green, 2 blinks blue …. (or same for temperature) yes, I agree good idea.
With time I think UI designers will think up dozens of uses for colored aux lights.
“For sale” to who exactly?
To me… exactly…
[quote=Hank Wang]
How much does it cost?
[/quote]
I would not expect a design engineer to think of testing that. I would, however, expect a good system tester to think of it. Test all states, and all state transitions. Just because something is unlikely to happen, doesn’t mean it shouldn’t be tested.
I don’t think it’s reasonable to expect the D4 to get a good system test, though. Too small an operation to afford the time and effort to do that. And Anduril is getting too complex with too many things to properly test.
It would be better to simplify the firmware, so there’s less stuff that can go wrong. Maybe that’s not ideal for flashaholics, but maybe it is for future homeless flashaholics?
There’s a difference between “safe” from accidentally burning yourself because a hotrod light gets hot, and “safe” from the light spontaneously turning itself on and burning whatever it is near. I think most people understand that these lights will get hot, and you have to be careful. What people do not expect, is that a light will randomly turn itself on, ramp up full, and begin burning stuff when you’re not around.
Sure, you can say that batteries should always be removed from high-power lights when not in use. But, that’s an unreasonable demand on users. I want to grab a light, and use it right away. I expect “off” to remain “off”, until I pick up the light and turn it on.
Yeah, this is totally a weird bug. I don’t think it’s sloppy coding or even testing. I think the problem is the code and hardware it interfaces with is getting too complex.
Do you really need candle modes and lightning modes and muggle modes and dozen different ways to click the light? Or, would you rather have a “safe” light? I know the former is fun, but not if it burns your house down.
I dunno. Maybe the solution is for Hank to offer the D4 with two different firmware versions. One, a “safe and simple” version, with basic features. And another, with full-blown Anduril, use-at-your-own-risk.
Love it!! 
Come on, TK, it should be totally obvious. Ears back at the idea of those changes, this cat is definitely not happy about it! 
Me neither. I’m a man… I can change, if I have to… I guess… but c’mon, I don’t want to!! LOL. I just learned how this thing works, and I don’t want to re-learn with the next light I buy!
It’s getting to where flashlight mfrs need to start building them with config dip switches or something………
There’s a big difference between “thorough” testing (TK’s testing was thorough) and “exhaustive” testing (which nobody does due to the law of diminishing returns). If anyone insists upon having an exhaustively tested, super-safe light, here ya go:
It’s probably worth mentioning that “safe” and “simple” are not the same thing. The majority of issues reported this year have been related to the “simple” mode… not the full-featured mode. Trying to dumb it down is what caused the problems.
That would definitely be an issue.
If “4C/4H from off” was used for aux LED control, how would the user enter lockout mode?
I have a light which works much like the linked post describes. I find it difficult and confusing to use. Its menu options use 15 different color patterns to indicate which item is selected and what the value is, and I have to look it up in the manual every time I use it.
In the case of D4v2 and Anduril, there are additional complications.
- The aux LEDs are nowhere near as bright as this other light, so it would be difficult to configure in a lighted environment since it can be hard to see the aux LEDs without pointing the light directly at one’s face. And I don’t recommend pointing a D4 at anyone’s face.
- Most supported lights don’t have RGB features, so they would still need a different config method. This means people would have to remember two sets of instructions instead of just one.
However, I did make use of color on my lightsaber. It ended up with a menu 7 items long, so I used color to help organize those items and reduce the number of blinks:
- 4 red options control the color pattern: R1, R2, R3, R4
- 3 blue options control the brightness pattern: B1, B2, B3
When entering a value, the saber shows a realtime preview of how it will look. When selecting a color, it simply shows the color while the user navigates around color space. And when entering a number, the user can simply keep clicking until it looks right, then hold to save.
So I think the colors can definitely be used to good effect, but it’s very context-dependent, not universal.
Agreed, except that the aux LEDs may not be bright enough to be used effectively for battery check purposes.
The way I did it on another light was to use color to indicate voltage, while also blinking out numbers to give more precise details. So the user could see from one blink whether the battery is full, half full, or low. But they could also keep watching to get more detail. That one wasn’t just red, green, or blue though… it used the whole rainbow.
I’m wondering if something like this might serve everyone’s needs without adding too much complexity:
- Remap “4 clicks for ramp config mode” to something which is more unlikely to happen by accident. Perhaps “5 clicks and hold the last click”. Or 6H, or maybe even 7H.
- Move manual memory from 5C/5H to 4C/4H.
- Remove beacon config mode, and replace it with “hold during beacon mode to choose a timing”. For example, to set a 5-second cycle, simply hold the button for 5 seconds then let go.
- Maybe remap thermal config mode too? It’s less necessary when there’s a factory reset auto-calibrate function.
Changing the interface is typically an unpleasant process for everyone involved, even if it produces an objectively better result in the end. So before making any UI changes which break backward compatibility, I’d like to make sure the changes are pretty solid. However, waiting makes it even more unpleasant later, so these things are usually best done as soon as possible.
Exactly. That’s why I’m hoping to work out all the details first, to make sure we don’t have to go through this again any time soon.