That’s the first report of how it works in practice that I’ve seen. Thank you.
I’m interested. Looks great!
I am in for 1 please! Reading back through I didnt see my name on the list. My wife is gonna throw me out of the house soon, also waiting on a Convoy L6 and an Emisar D1s……. Really debating the D1s since I keep hoping Hank will do a 26650 or 27700 version like with the D4s….
Please don’t repeat your request for 1 light. It makes things confusing. You’ve only just asked, give it at least a week before looking for your name on the list. Thanks.
Maybe not for the graphic, I was thinking mainly of anduril.txt for stock Anduril. I guess this has now been deprecated in favour of anduril-manual.txt?
Sorry about that then! Im rather excited hahaha
I reckon a phone app could work well. Better than using a computer monitor.
A modern smart ’phone has a light / proximity sensor, and a selfie camera, either of which could be used to establish bi-directional comms. with a robust protocol.
Also to have phone ability to back-up several user-configurations for quick re-use according to circumstance. A bit like choosing ringtones.
Or use the rear camera and it’s LED flash as the comms. port.
It might even be possible to re-use a standard half-duplex comms. protocol, and software stack.
A modern smartphone can display HD video at 30p or 60p, maybe even faster, and has a dedicated graphics processor to keep it flowing smoothly. It might even be possible to use an LCD display at much higher data rates by strobing the LCD backlight rather than modulating the LCD itself.
I don’t see much point in using this to change complete firmwares, which would also need a bootloader to be integrated with the protocol, and permanently resident (taking up space), but as a way of making configuration changes it would be nice. The app. also being an interactive manual to the UI, rather than the crib sheets that are increasingly necessary as complexity grows.
Just using a few tick-boxes to begin with.
A complete re-configuration, even a re-write of the ramping table to fine-tune it for different emitter options, or change thermal management control loop parameters to suit ongoing development or user preference, could surely be done in a reasonable time, seconds, or a few minutes. And perhaps monetized with micro-payments.
It could be a real money-spinner for whoever develops it, defines the protocols, controls the encryption keys, or rolling code, and sells the app.
As well as an interesting new skill to develop with other marketplaces that I haven’t even thought of yet. Internet of things sort of stuff, but without the security worries. Just wave your ’phone, or a “smart torch” over a (very inexpensive) terminal containing not much more than an LED and a small MCU, no NFC, no WiFi, no Bluetooth parts to pay for or to configure, or software stacks to license. Shield the light (or IR) from interception, even just by holding a hand over. Phone to ’phone, or torch to phone, or terminal, like a 1D or 2D barcode or QR reader but so much cheaper to implement.
A full 2D barcode conveys only 4kbytes of information. I reckon, even if that was all needed, even that could be transferred reasonably swiftly. The 1D ones are trivial.
Door locks, hotel room entry, ID badges with swipe or RFID stuff, keyless car entry and mobilisation, supermarket sales, chip and PIN, boarding passes, all potentially replaceable with either a dirt-cheap key-ring sized device, or just an app. The USP being the low cost of the terminal, compared with what we have now.
For firmware updates, let’s first see whether the various disparate pogo pin connectors gain any traction in the field. Even amongst those who regularly re-flash, whom I suspect are actually a very small minority here. Most using pre-compiled binaries and fuse maps. A very few trying out their own ideas.
Some study material:
I worked on a free space optical network around the science site of my university as a student. Back then we didn’t have affordable LEDs or laser diodes or PIN photodiodes. We were modulating filament bulbs, using ex-army phototubes as detectors, and cheap Russian binoculars (one eyepiece for transmit, one for receive, full duplex), and got it working over a km at 300 Baud ISTR. Fun, and we learned a lot about many aspects of Applied Physics.
It would be so much easier these days. A scrap DVD or BluRay burner for the laser and photodiode and lenses, Arduino or RasPi, some minimal extra hardware, cheap binoculars or just magnifying glasses, ingenuity and basic knowledge of optics, physics, electronic hardware design and software. I.e a great little student project, that might still have some relevance and useful application.
Also handy for stimulating the optic nerve, and reading back the results, if a smartphone app. isn’t good enough.
Consider that Ronja can run 10 Mbit/s Ethernet over much more than a km just using a pair of cheap magnifying glasses as optics, and it is entirely open-source. And quite old, over ten years, and LEDs now are far better.
Imagine the possibilities with our sophisticated bits and pieces nowadays.
Surely there is something there that can be re-used ?
Or instead start with proven robust simplex 1D barcode protocols. At the end of the day they are just read by scanning, i.e looking out for some blinking light reflected back into the scanner, which as we all know is very robust, mature technology, and tolerant of all sorts of difficulties that do not stop them working admirably.
It’s all available, open-sourced, e.g Zint Barcode Generator download | SourceForge.net
As are the 1D, 2D and QR code scanners, using phone cameras with static images rather than hardware scanning.
Just blink them into the torch, from the ’phone, having first “scanned” and interpreted them in the phone app, using it’s camera. Even send them to the ’phone as an MMS
I happened to be looking into this a couple nights ago out of curiosity.
While not in the graphic or anduril-manual.txt, it seems we can get the model-specific info from the config files she keeps in the firmware repository. These get optionally incorporated when compiling the code. I suppose the config file could specify the defaults directly, but the few I’ve checked do so indirectly by identifying the number of PWM channels and the max level of the 2nd channel if there are 3 channels. The normal logic is to set the smooth ramp floor to 1, and the discrete ramp floor to 20.
Then both the smooth and discrete ramps ceilings are set to 120 unless the driver is identified as a triple channel. In that case, both ceilings are set at the Nx7135 channel max.
For the FW3A, that is level 130.
But really, the defaults shouldn’t be too important. As long as you know how to configure the levels, you can set whatever ramp ceiling fits your needs and not worry about what it was originally.
I would like one please.
Put me down for 2 please!!!
Please add me to the list for one. Thanks!
Guys what are you thinking about this:
In LOCKOUT MODE:
- hold : momentary moon (= floor from current ramp)
- click, release, hold : momentary 10 lm (= floor from other ramp)
Good or bad?
(but I don’t know if this possible to program)
I would like to sign up for an additional 2 lights, for a total of 4.
I like the dark gray, and I think one of my friends will like it too.
I’m indifferent. I keep both ramp modes at very low levels, so it wouldn’t make much difference to me.
And as I understand it, lockout mode uses the floor of the current ramp, so with a couple extra button pushes, you can switch ramps and lock out again to have the other floor.
I would not object if it’s possible to add, though, since I don’t see it interfering with other existing functions. I know TK has said several times in the past that Anduril is basically at the limit of the ATTiny85’s memory, so it might not be possible.
I just changed lockout momentary to act like momentary. Uses the memorized level.
Sorta a workaround for me not wanting to unscrew tail cap all the time.
In general I want the ramp start at moonlight.
And for normal carry I lock high power lights out.
It is for the same use case as Lockout momentary, but when you use it and realize you need more light, like: Oh, 1 lm is not enough I need ten times more.
I recently found a way to eliminate a bunch of code, to make room for new things. I’m hoping to do some fancy stuff with aux LEDs in that space, but no hardware exists for it yet.
Anyway, putting other-ramp floor on “click, hold” costs about 60 bytes and makes the light act a little weird when doing 4 clicks to unlock. Instead of “moon moon moon moon”, it goes “moon LOW moon moon” or “LOW moon LOW LOW”. So for now I think I’ll leave it as a compile-time option which isn’t enabled by default.
If there was ever a way to set the lockout brightness independent of moonlight/floor that would be one of thevfew improvements I could think of for Anduril.