FW3A, a TLF/BLF EDC flashlight - SST-20 available, coupon codes public

I believe that he was asking what the vision pin and optic nerve actually were, the reason for either being included in the file or whatever else you could tell us about the two terms.

It’s actually talked about in this thread, somewhere way back ago. TK has come up with a way to program the driver using the main LED as a receiver and literally “flashing” the driver with a computer screen. The FW3A will NOT have this functionality, but the firmware has code for it, because it is firmware that will work for more than just the FW3A. It’s really cool stuff. But maybe not as cool as a flashlight that can spy on people. :cowboy_hat_face:

Is it like the Oveready Boss programing?

Wow that’s cool, I would love to read up on the idea if anyone’s got any links. I have a few driver projects going on now following the FW3A driver setup so maybe it’s something I could implement too in the future.

Is there a thread about this? I plan on doing something similar.

Actually I was the one who brought this up on BLF - an EE friend at work mentioned it and I posted bout it, and TK actually did something about it. It's not truly new/unique - it's been done before in flashlights, just didn't make it the the big league. Forget the make/brand, but it was pricey - maybe 3-6 years ago.

Edit: think hexbright: http://bestflashlighthq.com/hexbright-flex-world-smartest-flashlight/, I could be wrong...

[quote=Tixx]

[quote=DavidEF]

Why do you think they call it Boss?
Who controls that programming?
What country do they live in?
Behind what curtain?
Made of what metal?
(Lol)

The idea is a LED is a diode - it can react to light (detect light), not just emit it. So, the theory is hold the light up to a screen (cell phone for ex.), and with a series of timed blinks, it can be programmed - not much extra hardware required, so cheap method, and effective.

Thanks for the explanation(s) and education.

It seems not everyone recognized the presence of a joke.

A while back, I taught a flashlight how to see, how to receive information from a computer screen using its own built-in LEDs as a sensor. And in my excitement, I asked DEL to add the requisite connections for this on the FW3A driver since it had an unused pin. And he did.

But in the process of developing a working proof of concept, I discovered that the concept is not actually very useful or practical. It’s about as useful as putting a sun roof on a motorcycle. Transferring data that way is slow, awkward, fragile, complicated, high-risk, low-reward, and did I mention slow? It’d take hours to transfer an entire ROM, and could quite easily brick itself. It didn’t seem worth the cost in terms of ROM bytes and development time. So I kinda abandoned the idea.

The optic nerve is still there in case anyone wants to use it, but the Lux-RC (Boss) optical programming thing isn’t really a practical feature; it’s more of a novelty or a way to entertain the user.

How about using your optical programming thing with a phone app?

Make an app that lets you customize a few options in your driver. What you want your ramp settings at or shortcuts. Minimal things like that.

Then you could use your optical sensor as a way to get these inputs from the phone to the light. As long as the amount of data being transferred is mininal the slow data-transfer speed shouldn’t be an issue.

No! KIS, use Blu2th!

Ohh yes, that's the company: Lux-RC here: http://lux-rc.com/content/NXS/NXS_R1_setup

Would still be a great option for custom config - easier, way less data, can't brick it, and yes - from a cell phone. But real practical issues do get in the way, as TK said.

Also bluetooth has been done before, never quite made it - metal reflector interfered w/signal, expensive, bulky, software/app issues w/compatibility, etc. Not saying it shouldn't be explored with more recent tech, or other wireless options.

I don’t get it. I mean, really. I’ve built literally hundreds of drivers for hundreds of lights, very rarely change the UI after the fact. I don’t see the need, it’s not like it’s such a big deal to pull the driver and re-flash it if it becomes necessary or desired. I mean, it really isn’t much more difficult than, say, brushing your teeth before bedtime. So why go to all the trouble to make it “easy”? Like having your teeth pulled and getting dentures so you can drop your teeth in a glass for overnight cleaning while you sleep cause your’e tired of brushing them. :wink:

As I had something similar in mind (just flashing options and the scheme which action results in which state, if that’s possible) - please forgive me if I am asking something stupid or did some mistakes, but why is it that slow? A PC monitor should provide 60Hz input, so 60b/s, which would be somewhere around 26kB/h without error correction, so 1kB should be able to be transmitted in less than 3 minutes without corrections, with heavy error correction and checksumming probably still in less than 10(?).

If TK says the result is an easy brick, then trust that it is so. When the Goddess gives up on it, there is no magic… :wink:

Yes, that is what it would be limited to. But making a cross-platform app which runs on everyone’s devices is no easy task. So I’d probably design it as a web page with most of the features implemented via javascript. And then make a different version of the page for each version of each supported model of flashlight. Abstract out the options so each version and each light can be loaded in from a bunch of definition files. The app would most likely involve significantly more code than the actual firmware it’s meant to configure.

But doing it via a phone app isn’t really much faster or easier than clicking the button a few times to configure it. And if the flashlight needs a companion app in order to configure it, that’s mostly a sign of a bad UI design.

It could be pretty useful as a means of reflashing the firmware or for makers who want an easy way to calibrate things before shipping an item to a customer. Sending an entire ROM is slow though. With no meaningful control over the device being used to transmit data, it would be unsafe to assume a high frame rate. In a browser, for example, even 15 fps may be pushing it. And although the sensor is pretty fast, the sender (screen) is generally pretty slow and possibly even inconsistent because it’s common to see timing aberrations when other parts of the system are busy. Like, if the OS decides to do a routine maintenance task in the middle of transmission, the browser is likely to lose some time slices here and there. So the data transmission timing windows need to be pretty large. And it’ll need a way to detect corrupt or failed data transfers. But when errors happen, the light has no way to send data back so it can’t request corrections. It may thus be necessary to send each byte two or three times to be sure.

Basically, with all the complications added up, it’s an awful lot of effort for very little benefit, and would only be usable for small amounts of data. Maybe a few dozen bytes. And it would likely mean removing other firmware features to make room.

Actually an LED gives of a bit of current when you shine on it.

Try this, if you can:
Shine a laser on one of 2 LEDs connected in parallel.
The other one will light up. (yes, very dim of course).

I discovered this when my cheapo blue / purple laser still worked.
I had a bunch of 5730 LEDs on a LED board, in parallel.
I was playing “excite the phosphor with a laser” :stuck_out_tongue: and then i noticed all the other LEDs lit up (yes, dimly of course).

It would be cool if it were possible via the USB charging port, if a light has one.

My BOSS 70 is my second most used light and I would very much disagree that the optical programming is not practical. It makes the initial programming much easier than, for example, an H17F and I don’t need a cheat sheet to remember various combinations of clicks. I can also keep a few other programs downloaded as videos on my phone if in case I want to change the mode groups for single mode, CR123 friendly, etc.

I don’t really see it being useful on anduril as there isn’t much end user tweaking to be done, but for programmable mode groups I find it to be a very nice feature.