VOB, really glad you find value in this! You are selling lights with your own custom firmware correct?
I've been adding some features to the stock programs per RMM's request, so those newly updated versions of the code can be found on Github now linked to from my website - http://www.jcapsolutions.com/flashlights/firmware/. I changed the name of the files for each program so that it will hopefully make more sense...
STAR - Original single clicky program
STAR_off_time - Same as STAR but with off-time memory with the use of a capacitor (brilliant idea by another member documented somewhere here - I should really put that info right in the program)
STAR_momentary - For lights that have a momentary switch, like the SRK
STAR_dual_switch - For lights that have a momentary switch and a rear clicky (bench tested but I actually haven't built a light with it yet)
The new versions are somewhat experimental, so you can always download the older versions from the old links on my site. I swear I will update my site with all of the new features once I find the time.
Hey Toymaker you could add :i to the eswitch.hex too, just so guys research the format field instead of just copy/paste
I modded Toms code a bit too for my white lights. EDIT Tested and updated. http://pastebin.ca/2866670 Final v.3
Its just a quick mod, all the main code is those guys. I didn’t even clean it up and check for high to low or low to high modes, which would be nice for turbo and voltage monitoring ramps. Just off, high to low eswitch. Hidden moonlight and beacon mode. Removed ramps. No memory, always starts off- Turbo and voltage monitoring optional. I got thinking about this and I don’t like writing to the chip for memory. I dunno why, think down the road some guy gonna get errors and roid rage if it’s anything like the old flash sticks.
Look in Toys collection there V and you’ll find pretty much anything you need. Tom Es mod of JonnyCs work is all commented and easy to understand as are a lot of gems you can pull out of the other work too. You can basically do anything you dream of with the code that’s there.
You are correct. I just had DrJones write me some code and he told me how to flash micros with it. My understanding of this stuff is pretty minimal at this point, but I am catching on a little. Thanks for putting this out for us.
Sadly it appears I am still not doing something right. I thought I was on a roll for a minute. After I got the code from toykeepers link my programmer did recognize the file, and it did seem to flash the micro. No errors reported and I got a string of OK!, OK! OK!s at the bottom of the page.
I then hooked up all the driver wires as normal (7135 based driver) and added the momentary switch between pin 1 and pin4 of the micro. However this is where the good news ends.
When I tired to power it on nothing happened. I tired it with 2 boards and it was the same. I then reflashed the micros with standard firmware and removed the mom switch and it worked fine.
I think the micro is getting the flash, but it seems that something is not translating. The ONLY flash of light I ever got was right when I hook up the battery. It give one very tiny pulse at first contact. This is repeatable if I disconnect and reconnect the cell.
I think I am flashing the micro correctly, because it does change something about the driver. I use the first box like this.
I’m not sure which firmware you used there, but I make a point of including a brief flash on boot on all eswitch-only firmwares I make. It lets me know the power is connected and the chip is booted, and any issues afterward are therefore some other type of problem. I don’t think I’ve seen this behavior on other people’s firmware though, unless you count Zebralight.
However, e-switch firmwares generally won’t make light just because they have power. Getting light requires activating the switch, so the switch must be wired up correctly. If it won’t activate, I’d check for switch issues.
That one click OFF is the most un sung hero of the world. OOOOOOOH how I have dreamed of this. No looooooong press for OFF. NO cycling through stobe, but STILL IN THERE!!!!!!!!!!
Had I written a Christmas list I could not have asked for a thing more!
Coolabs came in today, finished the blfdd light. I noticed something interesting putting firmware in my light. I looped this line in making the beacon off while monitoring button clicks.
PWM_LVL = 0; _delay_ms(50);
I assumed it would keep the FET closed, but it didn’t. When you loop the above it makes very little amount of light on fast pwm You can put your face into it and see the die clearly. Maybe someone is interested in that- thought it was pretty cool. If you want to try it, code is at the bottom. Hold the button for ~3 seconds to get beacon and you’ll see in between pulses. Could be an even lower moon
It’s a known “bug” that PWM=0 will still produce a little bit of light when using fast PWM on a high-powered driver (FET, or 32x7135). In phase-correct PWM mode, this doesn’t happen.
I’ve been meaning to tweak my ramping UI firmware to take advantage of this, but have been too busy so far.
Well known to you It’s kind of cool, can get something lower than PWM 1. It does turn all the way off with PWM 0 least on mine. But looping it on 0 causes the lowest moonlight and it’s not ghetto looking either, it’s a nice light up of the emitter. The only time seen this low was playing around with the buck drivers sense resistors, got a similar output.
Maybe running as default when you turn on the tail switch instead of sleep?
That would let whoever has the light know they left the tail on while still being almost parasitic. Just enough light to keep the ring glowing too maybe.
Or just add some status LEDs and use the Roche F6DD firmware. It keeps one status LED on at all times at about half power as a locator, plus the LEDs give you info about battery voltage under load (green/orange/red).
FWIW, the standby light is barely more than the MCU’s parasitic drain. With the light completely off and the MCU in sleep/powerdown mode, the parasitic drain is 0.33mA. With the green LED on but dimmed, the drain is 0.36mA. So, it costs almost nothing extra to leave that slightly on.
Leaving the green LED fully on costs more though; then it runs at 1.23mA. And a lowest-possible moon mode on the main LED is even more — it depends on the exact hardware used, but 5mA is a common amount for moon on a single emitter on a 8x7135 board.
For a 25R 2500mAh battery, that translates to 10.5 months of standby time with everything “off”, 9.6 months with the green LED barely glowing, 2.8 months with the green LED fully lit, or about 21 days with the main emitter in moon mode.
Voltage measurements are not performed while the light is in standby. That would drain the battery faster and require removing other functions to make room in the firmware.
Can the lower mod be little lower on that firmware?
I like moon mode to be very low.
Voltage measurements are not performed while the light is in standby but it remains with the color it was while was ON. So if it its red while it is ON, it will glow red on stand by.
FWIW, I finally added a battery check mode to my clicky-switch firmware (based on STAR). It’s what I use on my EDC lights, like a modded Convoy S7 or a CNQG brass beauty.
This firmware has a lot of modes… five solid modes across the full brightness range, three dual-level flashers, a heartbeat beacon, three fixed-speed motion-freezing strobes, two variable-speed strobes, and the battery check. Short-cycle memory to avoid the need to go through all the blinky modes when they’re not wanted. It’s a lot to fit in just 1024 bytes!
Mostly, I’m just happy that I no longer have to remove the battery from my EDC to find out if it’s ready to be recharged.
Yeah, previously the STAR_momentary program shut down the output (went to sleep) when PWM = 0, but RMM had me change it so that 0 is a valid mode so that he can utilize the Fast PWM "bug". Going to sleep is entirely dependent on the MODE_PWM value for that mode instead of the PWM value. That feature is in the latest version of the program from Github.
