Should be removed? It has all sorts of interesting ideas for reference and educational purposes, and is clean and reader-friendly. I’d prefer not to remove it, but I could move it to an attic or add disclaimers about not being supported or something… If you don’t want your name attached, should I anonymize it? Are any of those ideas acceptable?
Correct, the LED will read enough voltage to be programmed by a screen. A new trace will be needed and possibly a resistor inline with said trace to limit voltage in 2S+ setups. Although if you “float” the pin when not in programming mode I think it will be ok even if it got full voltage? That is pretty easy to work around though. At worst it would need a voltage divider.
This will only work with an MCU with more pins though, such as the 841. BTW, does anyone know if there is an MCU option that has more then 8k of memory? I think we will VERY quickly run out of space with programming options.
For the earlier talk of dual switches, the best option here is to go to the 841 MCU and use another pin to detect power off by taking the voltage reading from before C1. Although if using 2s+ voltage it might need some form of zener / ldo. I would have to think on it more to figure it out. Either way I see a lot of things that could be fixed with more pins to play with.
Or could it be as simple as taking the voltage divider reading from before C1?
Tom E did some changes in Narsil 1.4 which I had asked for
You can choose in code for the standard 2 blinks, brightest mode or nothing to happen when powered on
As he is busy I didnt ask if he would do additional to the on at full brightness the hold sideswitch and turn on for moon mode
If you have a sideswitch plus clicky I would never consider to control modes with the clicky, just dumb forward clicky
The light does not need to be turned off with side switch, many lights from Nitecore and others are designed that way
Well, if you put it that way no need to do anything. Keep as is. There are not many of those drivers outside of my hands anyways, at least not in the hands of people who flash their own firmware.
Do you know what exactly that trace would connect the MCU to? LED- maybe?
On a bistro driver like MTN17DDm there is still one extra pin available. I could probably just add a little wire from that pin to some other part of the driver and get screen-based input to work. There might be enough room for that on a tiny25, given that it would no longer need most of the code for config mode and the various config options.
For Lexel or anyone interested, I'm figuring out the support for adding R1/R2 LVP (2S cells) to NarsilTriple, but it will mean losing the Indicator LED support, so must be a compile switch then.
If someone gets this to work I’m going to fall over! So many advancements in such short time! Very fun to watch. 
It depends on if you want to see the ground or V+ from the LED. I just tested it and the LED put the power out in the same polarity it gets it in, so if you run it to the LED- out from the driver you will see the ground from the LED.
I am not really sure if it will be easier to see the V+ from the LED or ground when it comes to voltage references and the like that you will use to check the voltage. Either should work though.
I also would be ecstatic to see this come into being! Plus it would be nice to see how much code space we are looking at for this to get an idea on if 8k will be enough before we settle on a new MCU for future development.
I’m just catching up with all of this as well - a couple of years ago we were hand-soldering a FET to a nanjg & calling it done!
I’m wondering what it would take to utilize the voltage produced by the LED during daylight hours to charge the battery in place.
Imagine something like an SRK with plenty of room in the driver cavity for a boost/charging circuit, being fed by it’s own array of emitters.
Also remember that you can use the reset pin as an input without enabling it with fuses. All you have to do is keep the voltage above the reset threshold. It might not be the most practical way, but for sure it should be possible to start concept testing it on a 85 based driver.
Well, I don’t really know. I was hoping you knew.
If I put a wire between pin 3 and LED-, I get the following results:
- Black screen: ADC=167/255 (2.35V)
- Computer screen (white): ADC=159/255 (2.24V)
- Phone screen (white): ADC=151/255 (2.13V)
- Shining ~8 lm from another light: ADC=111/255 (1.56V)
This was using a VCC as the reference, and a 3.60V cell. With the internal 1.1V reference, all readings were 255. I was kind of hoping to use 1.1V so it wouldn’t be battery-sensitive and so it would have more resolution, but it’s getting higher values than I expected (and going down with more light instead of up). It appears that turning the screen brightness all the way up will be helpful.
I haven’t tried LED… but considering that LED and BAT+ (and VCC?) are electrically the same, I’m not sure it’ll be useful. And I’m feeling too lazy to move the dang wire at the moment (it took forever to get it connected the first time).
So, long story short… Yes, the LED can be used to “see” how bright the environment is. But it remains to be determined what the best method is for doing that, and the resolution might be rather limited.
Don’t get your hopes up… LEDs are not solar panels.
For the computer side of things, I’m guessing the most accessible way to do it would be a web page using javascript to blink a portion of the page light and dark based on the settings selected by the user. Pull it up in a browser, select some options, put the flashlight in receive mode, point the light at the screen point-blank, and hit the “go” button in the web app. Then wait until it’s done blinking, and the light should have new settings.
To save ROM space, the light could be told to merely dump the data directly into eeprom, then load_state() afterward. No need to even interpret the data. And to avoid all the messes with mode groups, the mode array could be read directly from eeprom. That way you get whatever modes you want, in any order.
As for the binary protocol, I think it’d need a few initial blinks to calibrate itself, and then it could simply go bit by bit. Rest at black, then go white to signal each new bit. After the signal, wait like 67ms (4 video frames) and take another reading. If it’s still white, that bit is a 1. If it’s black, that bit is a 0. Then go black and wait for the next signal. Something very roughly like this on the flashlight side:
threshold = calibrate(); // threshold = lowest + ((highest - lowest) >> 1);
for(eep_pos = EEPSIZE - MAX_CFG_LENGTH;
eep_pos < EEPSIZE; eep_pos ++) {
byte = 0;
for(bit=0; bit<8; bit++) {
byte <<= 1;
wait_for_white(timeout=200);
sleep(67ms);
color = look();
if (color < threshold) {
byte |= 1;
}
wait_for_black(timeout=100);
}
eeprom_write(eep_pos, byte);
}
This basically gives it a Morse code system with a built-in clock pulse to avoid getting de-synced. Bandwidth is about 8 or 10 bits per second. So, a full config cycle might take about 15 seconds.
I think this is probably feasible on a tiny25.
Anyone good with javascript? I’ve mostly avoided it.
To be honest while this is fantastic, or maybe I should even say fantanstical, I"m probably at least as happy with TA's modegroups. If I could flash whole drivers from the smartphone that would be something, then we're talking about a boot loader. But we can fit a ton of modegroups in the light as it is and this won't give the ability to customize new ideas for crazy up-up-down-up fatality combo presses anyway, or not very easily (changing some pre-configured options for such could be possible, but only pre-configured options). Those voltage readings are curious. Better play with it at different temperatures too.
At lightrider, all those configs in HD are pre-compile configs. There is no active code that processes a variable to switch between those options. So it's not something you can just flash a boolean through the screen and change the light from OTC to OTSM. Most of those things are fairly hardware specific anyway though, with a few excpetions, of course including the modegroups and strobes. But for example if you want to choose between avaiilable strobes through the led interface, you'd need to have all the strobes compiled in to begin with. There's room for that on an attiny45 even with the full bistro UI.
Things that defintely could be removed from the UI are memory, and reverse modes, and likely even temp cal. Those things are there to make the firmware universal, but most people probably set it one way and leave it. The underlying code to deal with those options doesn't dissappear though(edit: ok some of it does, like reverse modes and moon, and HD knows how to strip that out), so we're just talking about removing the menu toggle. So about that...
In HD right now though, extra toggles in the UI aren't taking up much extra space. Maybe 4 bytes to set the initial value (ldi and sts), and an extra byte related to mode overrides. That one last byte (too technical to explain) gets cut out and the others might (maybe you don't need an enable_moon variable at all anymore).
The instruction set doesn't get bigger or smaller as more toggles are added now though, because it's just a loop over however many toggles there are. This clearly saves space for many toggles but does it for a few? Well on biscotti, just the menu part alone broke even using the loop or the orginal unrolled version, so it never hurts. The whole biscotti-HD still came in a smaller and some of that may have been from the tighter toggle saves done in a similar way. There is the old BLF A6 way where you get to get rid of the save and restore functions and piggy back it on the mode_idx wear levelling if you really can it down to just a couple of built in toggles, but I doubt that will apply. You'll still need a full save and restore function for the configs. My BLFA6-HD comes in about 60 bytes too big as I recall, so that's not saving more 60 bytes anyway (I'm sure less). Basically the bottom line is unless you completely remove toggle code from the UI, I really don't see THAT much savings there, maybe enough to matter if things get tight though. A big part of this is because I've already clawed back a bunch of the space for these things anyway.
Of course if you're happy with one modegroup flashed at a time, you get to get rid of the modegroup menu and you could also get rid of the temp cal and just set it by making adjustments from the app until you like it.
I’ve hacked up a version of bistro to test this idea. I broke a bunch of stuff while hastily ripping out half its config options, but I have some of the light-based config stuff working. Specifically, it enters a “read from the screen” mode, it auto-calibrates the sensor, and then it reads bits one at a time and correctly blinks out the values it received, and writes those values to eeprom.
To test it, I haven’t been using a computer screen though… instead I just point another flashlight at it and manually do something like Morse code.
This is on an old Bistro driver from Manker, totally stock aside from the “optic nerve” I added between its spare pin and LED- .
Pretty neat. Can you add a two-way tcp-ip protocol, maybe a built in web interface?
We'll call it TCPOF, TCP over flashliight.
Really thinking about breaking from the "one file" tradition on these firmwares. HD is almost getting very modular, might be possible to start thinking out to compeletely separate mode selection/ui/config details from the main code structure. I think within the context of fixed modes, that's actually basically done and it would make sense to separate out a separate code file for those parts. (config initialization, change_mode, count_modes, and menu, all separate routines now anyway) However opening things up to ramping too, makes less obvious if there's a tidy boundary anywhere. Of course there's something to be said for just "hacking" things up lean and mean from scratch too. In the end HD makes 64 hex files already and it's good to focus on one and just get it right. It's also nice to lock in improvements though and have them automatically port over to the other builds. There's pros and cons.
I assembled a Convoy C8 host with XP-L2 and TA17 driver. And with Lighted tailcap. The long taps for going revesre and into the hidden modes really long. I need to wait 3-4 seconds to go to the previous mode. Short taps working OK. What shound I do to shorten the time? When it was too short on Nanjg drivers I changed the C1 capacitor to bigger. Should I need to change the OTC capacitor to smaller value?