Sounds like we’re in the same boat. Nice to hear that this is not uncommon. I am really looking forward to the arrival of my 219 D4. I am sure it will be worth the wait.
Thanks for your comments.
The blink happens at the boundary between regulated modes and unregulated (er, partially-regulated) modes.
This serves two purposes:
- A general reference point to show how far up the ramp you are.
- Let the user know whether to expect brightness to stay steady or drop over time.
This point is indicated by a dashed line on the ramp of the UI diagram, with regulation info off to the side:
I’ve noticed it also blinks at the highest and lowest brightness levels.
XP-L Hi V3 1A CW 6500K on the way! :partying_face:
Originally wanted a Nichia 219CT 83CRI 5000K but changed my mind. I think maybe bcos of lower temperature & higher lumen output. Anyone here think XP-L CW is a bad choice? at $18 bucks extra am seriously need to go FL rehab soon :person_facepalming:
Yes, people requested that it blink at both ends in addition to the point where the power channel changes.
Well, it’s not something I would have picked, nor would most others here in terms of color temperature.
If you went with cool white over neutral white in the XP-L HI just for the difference in output, then I think that was a bit silly. One flux bin is around 7% output, which is less than you can detect without instruments. Accepting worse tint, if your tint preferences are in line with the majority here for an output difference you can’t even see doesn’t sound good to me.
On the other hand, if you like cool white, there’s nothing wrong with that option.
i want one…is there any simpliest way to understand how to use this flashlight? sorry…the picture is for me spain village:))
I just got it and started playing. I understood it quickly. The only problem was accidental activation of momentary mode, which even removing power doesn’t reset. I needed to look at the diagram to fix it.
You might be happy to hear I used a totally different method for momentary mode in the all-in-one UI I’ve been making. Once the user enters momentary mode, removing power is only way to exit. That way they can make it produce any pattern of blinks they want.
Also, I made the momentary mode use whatever level they last ramped to, so it doesn’t have to be at turbo.
Sounds interesting.
But really, I’ve been dreaming about even more configurability.
Leave one way to enter programming mode. Keep everything else configurable.
Pretty much what you do know, but with an interpreter for a scripting language. Script would be loaded by flashing. Then users could tweak as much as they wish and share UIs with each other. Easily make all flashlights use the same UI and when there’s something new that you wish to have everywhere - no problem, program your biggest flashlight to blink it out in a loop in an otherwise dark room and just put other flashlights in a programming mode one by one. 10 seconds per flashlight, even the largest collection will be updated easily.
@DB Custom
The clip is black or?
I put a shrinking tube on them to avoid scratches.
I cut them 5mm longer than the clip and shape the end as a half circle.
After heating up and shrinking I press the end with pliers together.
That last longer as a straight cut and shorter than the clip.
Normally I glue a little magnet on the clip and shrink wrap then.
I prefer the NW too especially in the light this small, you will be using it for short distance illumination and for me NW or rather WW is more pleasing but having said that, the tint on the 219c on the D4 is still too white for me, i prefer the warmer/rosy tint of the 219b and by reading few posts back the XP-G2 5D could be the nicest tint of them all.
Well unless if you are into CW tint. 
Very nice improvement :+1:
Maybe someday.
Transferring a new ROM from a computer screen is going to be slow, and requires driver modifications. Some screens are only capable of 30 fps, and in a web browser we can’t even count on half of that, so this limits data transfer to a few bits per second. It could take hours to transfer enough to fill the ROM on an attiny85.
In theory, it could be faster when sent from one light to another, but that doesn’t really work over the internet.
In case of a botched firmware update, it’d still need a way to get back to programming mode… which probably means additional hardware modifications, like having a button or something which could be shorted at boot time. It can theoretically be done; my keyboard has something like that… but it’s significantly harder on the smaller more limited hardware of a flashlight.
For now, it’ll remain necessary to flash drivers with a traditional AVR programmer and a clip. And when I get web-based configuration working, it’ll be limited to eeprom at first.
That’s why I said about an interpreter. An UI script compiled to special bytecode should be no more than like 400 bytes, compressible to 200-250. It’s a matter of several minutes and with the technique that I’ve shown, one can flash many lights at once.
Botched update? Just checksum the transfer and don’t overwrite the current script unless the checksum matches.
Compression? Don’t overwrite unless the checksum matches? These things require a lot more RAM than these tiny chips have. It could checksum a few bytes at a time, but not an entire ROM worth of data. Compression doesn’t work because there is nowhere to decompress to. It works well on regular computers, but not when there are only a couple hundred bytes of RAM.
An interpreter could theoretically be possible, but if a UI is only a few hundred bytes it’s either going to be a very simple UI or a very limited scripting language.
What I’m thinking is that programming mode would basically be a bootloader. It could be triggered from within the UI or by a special condition when connecting power, and then it would read data and dump it directly into ROM, effectively reflashing without a clip. Perhaps a bootloader could fit into the first 1-2K of ROM and the remaining 6-7K would be available for flashing. Instead of using an interpreter, the code would run natively. The main benefit there is the ability to reflash from a web page without taking the light apart. I’ve found that a pretty extensive UI can fit into 6K, since the one currently on my D4 is feature-packed and weighs in at 5950 bytes.
Compression starts at 1 KB ROM and 50 B RAM. Checksum? Come on, it’s trivial. Simple checksums need several bytes of RAM and under 100 ROM. With modern chips which have 16 KB ROM and 2 KB RAM this shouldn’t be a problem. Not-overwriting requires several hundred bytes, either in RAM or ROM. Interpreter seems like the only component where I view memory limits as a risk. As well as performance.
As to size, let’s see a simple UI:
on
on_now = 1
PWM1_LVL = brightness
PWM2_LVL = 0
off
on_now = 0
PWM1_LVL = 0
PWM2_LVL = 0
momentary_state
if (event == EV_click1_press)
brightness = 255
light_on()
empty_event_sequence()
return 0
else if (event == EV_release)
light_off()
empty_event_sequence()
standby_mode()
return 0
return 1
low_voltage
if (brightness > 0)
debug_blink(3)
brightness /= 2
if (on_now)
light_on()
else
debug_blink(8)
light_off()
standby_mode()
setup
debug_blink(2)
push_state(momentary_state, 0)
It’s your momentary, just with some redundancy removed.
I think you’ll agree with me that if we removed verbose names and converted it to bytecode it would shrink a lot. As it is it’s 648 bytes.
Will a much more complex UI fit in 400 bytes? I think it will. But I am not sure. Nevetheless it’s still going to be much smaller than an image.
I’ve been thinking about whole ROM flashing, but for reliability you need either 2 banks and watchdog to make sure that use hasn’t broke anything or (better) fallback firmware that may not be able to shine, but at least is able to reflash the chip.
It’s way more powerful like that, but as you mentioned, would take way longer to flash, be harder for users to make UI mods because of a more complex language, make it easy to flash wrong firmware to wrong light. Overall, I think that user friendliness beats capabilities in this case.
Another option would be to send compiled library that’s linked into the main firmware during flashing. I guess it would be a compromise between full firmware flashing and interpreted script. Still, different lights would need different images, size would be higher than with a script.
Speaking as a software engineer, I think I’ll take TK’s word for it.
Considering the Nichia does get hotter than the xp-l hi, I’m definitely glad I chose the xp-L hi. As it is, it almost gets too hot too fast to be useful. Any hotter would start to get frustrating for me. Also, the throw (beam distance) of the Xp-l hi seems to be quite a bit better than the throw of the other two emitters if you compare the figures that ToyKeeper posted.
With that said, I chose the xp-L hi in the neutral white tint. I find that 5000k is my favorite color temperature for a flashlight becaus it’s good at night but also good during the day. It seems only a little too warm compared to daylight and only a little cool compared to incandescent light. I might even prefer closer to 5600k in tint but no cooler than that. It’s your preference however. If you like 6000k+ go with the cool white.
The one good thing about the nichia is it apparently has a more even beam patfern( the hotspot is larger). So while that’s worse for throw, I imagine it makes it easier if you’re trying to take a photograph up close at night. But if it burns your hands before you can frame the shot and take the pic, maybe it’d be a little trickier. .
Even so, the xp-L hi is pretty good for lighting things. Here’s a photo I took with just the flashlight for light using the camera on my iPhone 6 plus.
Thank you! Needed to see where it was worth changing.