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

Excited that this light is another step closer to reality!

To whom? I’ve done a few weddings before, but I hope you don’t expect anything traditional or serious. It’s more fun to do the marriage scene from The Princess Bride, or some other silliness.

Pay no attention to the man behind the curtain.

I can tell you with 100% certainty that we are definitely, absolutely, unequivocally not using the FW3A to spy on anyone. Only crazy people would think that.

Now, back on topic…

I generally like deep-carry clips too, but I find this one is still pretty good. I think it’s my favorite non-deep-carry clip so far.

Yeah, I did. Flowing unicode characters along the curve was a really clever idea, but I went for something a bit simpler instead. It’s just a thin white line on top of the wider green line. I should probably move the arrow heads up to a higher layer to avoid the white going into the arrow, but that was extra effort and it’s more visually distinct this way. Maybe I’ll do that later.

There was also the option of converting the path to a solid, and using strokes along the edges of the solid, but that has its own difficulties.

I may change some of these things too, depending on how it looks when printed.

Yes, I’ve just had a large backlog to catch up on.

I am new to collecting flashlights and to this forum. ToyKeeper, you are a kind, helpful and generous lady to share your brilliant work so that novices like me can get such enjoyment with the amazing technology in flashlights. Two years ago I would have never believed what is possible today. Keep up the good work.

Fwashwights. Fwashwights are what bwings us….together…on weddit. That bwinding emitter. That hotspot within the beam.
….

Have you an HDS with wotary control wing?

Why do I get the sense that it is watching my computer monitor? :wink:

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: