alexvh's firmware. Update: Hidden strobe, Ramping and optional mode memory added.

111 posts / 0 new
Last post
alexvh
Offline
Last seen: 3 years 5 months ago
Joined: 05/28/2013 - 23:40
Posts: 29
Location: Canada

Just bumping the thread so people can see my update at the top. Ramping and optional mode memory added to firmware.

My firmware for nanjg attiny13 flashlight drivers: https://github.com/alexvanh/basic_off_time_driver

Discussion: http://budgetlightforum.com/node/36932

Off-time mode switching on stock drivers (no off time capacitor mod necessary) and ramping withou

wight
Offline
Last seen: 3 months 4 weeks ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

Thanks, I’ll take a closer look very soon!

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

FmC
FmC's picture
Offline
Last seen: 2 months 1 week ago
Joined: 03/31/2013 - 05:23
Posts: 2197
Location: Brisbane, AU

Thanks. I’ll give this a run through AVR Studio to see if I have the same problem as before.

alexvh
Offline
Last seen: 3 years 5 months ago
Joined: 05/28/2013 - 23:40
Posts: 29
Location: Canada

FmC wrote:
Thanks. I’ll give this a run through AVR Studio to see if I have the same problem as before.

I’m hoping that problem was fixed by making the variables that are held after a power off volatile. It should prevent the compiler from doing optimizations that stop the trick from working.

My firmware for nanjg attiny13 flashlight drivers: https://github.com/alexvanh/basic_off_time_driver

Discussion: http://budgetlightforum.com/node/36932

Off-time mode switching on stock drivers (no off time capacitor mod necessary) and ramping withou

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 4 hours 5 min ago
Joined: 01/12/2013 - 14:40
Posts: 10348
Location: (469219) 2016 HO3

I tried this on a different driver, a FET-based one designed by BLF members. It works! The lows aren’t low enough on a FET, and the ramp shape is a little weird, but the off-time memory seems to work as intended.

I will probably try using this technique on some of my non-OTC lights, since it seems like a solid improvement over “short-cycle” on-time memory.

Also, I added this code into my repository, linked in my sig below. Thanks for making it GPL! Smile

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 4 hours 5 min ago
Joined: 01/12/2013 - 14:40
Posts: 10348
Location: (469219) 2016 HO3

FWIW, I adapted this technique into my brass-edc.c firmware just now, and it seems to work well.

Additionally, it reduced the size of the ROM by 262 bytes! Now I have more than a quarter of the ROM to play with if I want (it went from 1018 bytes down to 756). This method allowed me to remove everything related to the WDT, eeprom, wear levelling, and the “short cycle” memory bit.

It’d be better if it could detect short/med/long presses instead of just short/long, but it’s still a big improvement over on-time memory. Smile

(I’m particularly happy about this, because I wanted off-time mem on this light but it doesn’t have enough room to add a capacitor and still be able to reflash it or fit a battery)

DrJones
DrJones's picture
Offline
Last seen: 4 years 2 months ago
Joined: 01/05/2011 - 13:30
Posts: 1044
Location: Frankfurt, Germany

I found short-cycle still useful with off-time memory: have memory, but no need to cycle through all modes.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 4 hours 5 min ago
Joined: 01/12/2013 - 14:40
Posts: 10348
Location: (469219) 2016 HO3
DrJones wrote:

I found short-cycle still useful with off-time memory: have memory, but no need to cycle through all modes.

Could you elaborate on that?

I could see short-cycle being really useful for lights which are configurable via button presses, or as a shortcut back to mode 0 when “long press” isn’t mapped to that. Or generally for increasing the inputs from “long/short” to something deeper… “short(off)-short(on) / short-long / long-short / long-long”. But I don’t know specifically what you do with it.

DrJones
DrJones's picture
Offline
Last seen: 4 years 2 months ago
Joined: 01/05/2011 - 13:30
Posts: 1044
Location: Frankfurt, Germany

With normal (off-time) memory, a tap cycles through all modes, while with short-cycle (off-time) memory, a single tap restarts at the first mode, and only consecutive taps switch through the modes; i.e. long-off -> memory; long-on, short-off ->mode 0 ;  short-on,short-off ->next ; (and I actually found it comfortable to additionally have long-off, short-on, short-off -> mode 0, too).

 

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 4 hours 5 min ago
Joined: 01/12/2013 - 14:40
Posts: 10348
Location: (469219) 2016 HO3

Okay, that makes sense. I pretty much always prefer no memory on clickies, so I have “long-off -> mode 0” and “short-off -> next”. Or for on-time memory, “long-on,tap -> mode 0” and “short-on,tap -> next”. I haven’t ever felt a need for both.

The main thing I change with an off-time cap is to add a “medium-off” action, which either goes to the previous mode (if mode > 0 ) or to a sequence of hidden modes (if mode <= 0 ). It’s nice as a shortcut to turbo or battery-check.

For e-switches though… memory can be pretty nice. From off I’ll usually do “long-press -> moon”, “short-press -> memorized mode”, and “double-press -> turbo”. I like the instant access to all three.

alexvh
Offline
Last seen: 3 years 5 months ago
Joined: 05/28/2013 - 23:40
Posts: 29
Location: Canada

ToyKeeper wrote:
The lows aren’t low enough on a FET, and the ramp shape is a little weird, but the off-time memory seems to work as intended.

You can of course just ramp up linearly by incrementing the pwm in a loop with a delay, I might add this. I used an array because I liked the smooth ramping, you can tell when you are near the max or min brightness because it is increasing or decreasing more slowly (also, I just think it looks cool). You might prefer the SQUARED ramp profile. If anyone has any ideas for different ramping profiles I’d be interested in trying them. Or if someone wants a different min or max in the ramp I could add that to the firmware.

My firmware for nanjg attiny13 flashlight drivers: https://github.com/alexvanh/basic_off_time_driver

Discussion: http://budgetlightforum.com/node/36932

Off-time mode switching on stock drivers (no off time capacitor mod necessary) and ramping withou

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 4 hours 5 min ago
Joined: 01/12/2013 - 14:40
Posts: 10348
Location: (469219) 2016 HO3

alexvh wrote:
You can of course just ramp up linearly by incrementing the pwm in a loop with a delay, I might add this. I used an array because I liked the smooth ramping, you can tell when you are near the max or min brightness because it is increasing or decreasing more slowly (also, I just think it looks cool). You might prefer the SQUARED ramp profile. If anyone has any ideas for different ramping profiles I’d be interested in trying them. Or if someone wants a different min or max in the ramp I could add that to the firmware.

On that topic, see ramp_calc.py and Ramping_UI_table.c in my firmware collection:

http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/files/h...

It implements a few different ramp curves, but it requires an e-switch to work properly. My favorite is logarithmic, but cubic is closer to visually-linear. Also, it can optionally smooth out the lowest few levels by using PFM in addition to PWM, but this extra-low part of the curve has a different shape than the rest and is intensely voltage-sensitive.

I haven’t attempted to do ramping on a clicky switch light, because the interface is awkward and I didn’t like the idea of grinding through eeprom write cycles while it ramps. You solved the eeprom issue, but the UI is still a concern.

Anyway, I’ve been playing with my new no-OTC off-time light (ToyKeeper/s7/brass-edc.c) for a couple hours now and I’m really happy with it. Thanks!

FmC
FmC's picture
Offline
Last seen: 2 months 1 week ago
Joined: 03/31/2013 - 05:23
Posts: 2197
Location: Brisbane, AU
alexvh wrote:
FmC wrote:
Thanks. I’ll give this a run through AVR Studio to see if I have the same problem as before.
I’m hoping that problem was fixed by making the variables that are held after a power off volatile. It should prevent the compiler from doing optimizations that stop the trick from working.

Tested fine compiling with AVR Studio.

Flashed to a 105c, works fine.

Beer
DrJones
DrJones's picture
Offline
Last seen: 4 years 2 months ago
Joined: 01/05/2011 - 13:30
Posts: 1044
Location: Frankfurt, Germany

Hm, it seems I have to try again on a different driver, as I found it too short when I had tried, and I'm not a slow 'half-press'er Smile

Edit: Tried again, indeed works well. Must have tried it with some old drivers with slight differences, don't know. Oh my, I could have had that months ago. /edit

ToyKeeper: Yes, for momentary buttons most of my firmwares allow switching on directly to memo/moon/max, too. For Clickies I like no-memory and short-cycle memory: My EDC (currently the brass, too) I have 2 groups, one for normal use with moon/L/M/H with (short-cycle) memory, so I don't have to click to the right mode every time, and one with moon1,moon2,lower,low,med without memory for indoor night time, always comes on at lowest, so it doesn't disturb anyone.

FmC
FmC's picture
Offline
Last seen: 2 months 1 week ago
Joined: 03/31/2013 - 05:23
Posts: 2197
Location: Brisbane, AU

ToyKeeper wrote:
I've been playing with my new no-OTC off-time light (ToyKeeper/s7/brass-edc.c) for a couple hours now and I'm really happy with it. Thanks!

I'm trying to flash the brass-edc firmware, but I'm getting the following verification error;

avrdude: verification error, first mismatch at byte 0x0000
         0x00 != 0x0c
avrdude: verification error; content mismatch


I've compiled it, as well as trying your .hex file.

Command line;

avrdude -p t13 -c usbasp -u -Uflash :w:brass-edc.hex:a -Ulfuse:w:0x79:m -Uhfuse:w:0xed:m


I have stars 3 & 4 grounded, but I don't think that would interfere with the process.

Any idea what's going on?

 

WarHawk-AVG
WarHawk-AVG's picture
Offline
Last seen: 1 month 1 week ago
Joined: 01/04/2014 - 06:47
Posts: 5071
Location: H-Town

all you coders are AWESOME!!!!

Gotta try the ramp on my triple build where I attempted to tweak the code and now the darn thing only starts in moon mode Sad

You coding genius are incredible!

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 4 hours 5 min ago
Joined: 01/12/2013 - 14:40
Posts: 10348
Location: (469219) 2016 HO3

FmC wrote:
I’m trying to flash the brass-edc firmware, but I’m getting the following verification error;

avrdude: verification error, first mismatch at byte 0×0000
0×00 != 0×0c
avrdude: verification error; content mismatch

Command line;
avrdude -p t13 -c usbasp -u -Uflash :w:brass-edc.hex:a -Ulfuse:w:0×79:m -Uhfuse:w:0xed:m

I have stars 3 & 4 grounded, but I don’t think that would interfere with the process.

That sounds like what always happened before I switched from a 5-wire connection to a 6-wire one. I could flash (sometimes), but the verification step would always fail.

I doubt stars 3+4 should matter, assuming they’re on pins 2 and 3. The flashing process uses pins 1/4/5/6/7/8 but not 2/3. However, it could still potentially be an issue. I’d suggest double-checking the other six pins though, in case one isn’t making full contact.

My command line is in flash-noinit.sh:

  #/bin/sh
  FIRMWARE=$1
  avrdude -c usbasp -p t13 -u -Uflash:w:$FIRMWARE -Ulfuse:w:0x79:m -Uhfuse:w:0xed:m

The only differences I see are a space after -Uflash, and a :a after the firmware file.

FmC
FmC's picture
Offline
Last seen: 2 months 1 week ago
Joined: 03/31/2013 - 05:23
Posts: 2197
Location: Brisbane, AU

ToyKeeper wrote:

That sounds like what always happened before I switched from a 5-wire connection to a 6-wire one. I could flash (sometimes), but the verification step would always fail.

I doubt stars 3+4 should matter, assuming they’re on pins 2 and 3. The flashing process uses pins 1/4/5/6/7/8 but not 2/3. However, it could still potentially be an issue. I’d suggest double-checking the other six pins though, in case one isn’t making full contact.

Thanks. It appears it was a connection problem. I just tried again now, & it flashed fine.

ERDOS
Offline
Last seen: 10 months 2 days ago
Joined: 01/30/2015 - 16:46
Posts: 21
Location: Milky Way

Flashed to NANJG AK-47A and works very nice. Actually first time flashing with arduino and a DIY soic clip.
Edit: Customized modes from H -> L to L -> H and moonlight from 0×04 to 0×03.
Do you plan to add strobes ? I love the blinkies Smile

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 4 hours 5 min ago
Joined: 01/12/2013 - 14:40
Posts: 10348
Location: (469219) 2016 HO3

ERDOS wrote:
Flashed to NANJG AK-47A and works very nice. Actually first time flashing with arduino and a DIY soic clip.
Edit: Customized modes from H -> L to L -> H and moonlight from 0×04 to 0×03.
Do you plan to add strobes ? I love the blinkies Smile

I’m glad to hear more people are getting into reprogramming their lights! Smile

I like blinkies too. Depending on what you want, I have some other firmwares available. I’m using this memory-retention offtime trick on my “s7” and “brass-edc” firmwares, which are basically the same as each other except for different moon mode calibration. They do the following modes, in order (but a long press resets to moon so you don’t have to cycle through all modes):

  • moon, low, med, high, higher
  • moon-med, low-high, med-higher dual-level “stutter” flashers
  • 1Hz heartbeat beacon
  • 12Hz, 24Hz, 60Hz motion-freezing strobes (party, not tactical)
  • two self-ramping variable-speed strobes
  • battery check mode

The link is in my signature; source and binaries are included.

alexvh
Offline
Last seen: 3 years 5 months ago
Joined: 05/28/2013 - 23:40
Posts: 29
Location: Canada
ERDOS wrote:
Flashed to NANJG AK-47A and works very nice. Actually first time flashing with arduino and a DIY soic clip. Edit: Customized modes from H -> L to L -> H and moonlight from 0×04 to 0×03. Do you plan to add strobes ? I love the blinkies Smile

Yeah, I have some plans to add some semi-hidden strobe modes soon.

My firmware for nanjg attiny13 flashlight drivers: https://github.com/alexvanh/basic_off_time_driver

Discussion: http://budgetlightforum.com/node/36932

Off-time mode switching on stock drivers (no off time capacitor mod necessary) and ramping withou

ERDOS
Offline
Last seen: 10 months 2 days ago
Joined: 01/30/2015 - 16:46
Posts: 21
Location: Milky Way

Some feedback after flashing brass-edc.hex to nanjg ak-47a:

- the 12Hz, 24Hz, 60Hz stobes are very dim (low to low-medium) (don`t know if this is intended)
- short-cycle memory (hybrid mode memory) doesn`t seem to work, it behaves like no-memory (I`m using a reverse clicky)

Also wanted to test starry-offtime but doesn`t compile – it`s a few bytes larger.

WarHawk-AVG
WarHawk-AVG's picture
Offline
Last seen: 1 month 1 week ago
Joined: 01/04/2014 - 06:47
Posts: 5071
Location: H-Town

I meant to ask…does this retain the low voltage warning flash of stock nanjg drivers?

Ronin42
Ronin42's picture
Offline
Last seen: 8 months 1 week ago
Joined: 12/17/2014 - 22:17
Posts: 1760
Location: Alameda, CA

Now in my ignorance I have been searching for a CC/ ramping driver for a 3S MT-G2 (does such a thing exist here?)

I found some reference that the 7135 either is, or can be part of a constant current driver. See I though that the “pic, 7135, 105x,) were all describing linear drivers.

Are we on the verge of having a constant current / ramping / 6v emitter capable driver?

(“It’s good that most people can’t remember their previous lives. Otherwise
things would be a lot more complicated than they already are.”
Ajaan Lee Dhammadharo)

DrJones
DrJones's picture
Offline
Last seen: 4 years 2 months ago
Joined: 01/05/2011 - 13:30
Posts: 1044
Location: Frankfurt, Germany

WarHawk-AVG: Stock NANJG/Qlite doesn't have RAM retention; that requires a special firmware. [Edit: I probably misunderstood the question.]

Ronin42: The 7135 is a linear constant current regulator. With a Zener mod or other methods it can be used for 2S and 3S setups. Also a ramping firmware has been available with source for ages: luxdrv. So a ramping 2S CC driver was available all along.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 4 hours 5 min ago
Joined: 01/12/2013 - 14:40
Posts: 10348
Location: (469219) 2016 HO3

ERDOS wrote:
Some feedback after flashing brass-edc.hex to nanjg ak-47a:

- the 12Hz, 24Hz, 60Hz stobes are very dim (low to low-medium) (don`t know if this is intended)
- short-cycle memory (hybrid mode memory) doesn`t seem to work, it behaves like no-memory (I`m using a reverse clicky)

Also wanted to test starry-offtime but doesn`t compile – it`s a few bytes larger.


Those strobes are calibrated to freeze motion, not to stun people… so yes, they’re not supposed to be terribly bright. The duty cycle is only 0.3 to 1.0 milliseconds per flash. I find it entertaining to see still frames of fast-moving water and such, so I built it into my EDC. It’s fairly easy to change though, just by editing a few numbers in the code.

The brass-edc firmware used to have short-cycle memory, but I changed it to use the memory retention trick described earlier in this thread. So, the end result is offtime no-memory. (also, I think there may be at least two different definitions of “short-cycle memory” floating around BLF)

The starry-offtime firmware requires an actual offtime capacitor in order to work, which the stock AK-47 driver doesn’t have. Also, it’s designed specifically for drivers with two independent PWM channels, which the AK-47 also doesn’t have. Probably not a good choice for this purpose. When I compile it locally, it works out to 1018 bytes, so it’s almost but not quite at the limit of 1024.

Warhawk-Avg wrote:
I meant to ask…does this retain the low voltage warning flash of stock nanjg drivers?

Not sure about the OP’s firmware. I took the flash out of mine to save space, but retained low-voltage step-down and eventual shutoff.
Ronin42 wrote:
I have been searching for a CC/ ramping driver for a 3S MT-G2 (does such a thing exist here?)

With a zener mod on the driver, almost any common attiny13a firmware should work. The only caveat there is that low-voltage detection might not function… and serial battery configs are significantly more risky than single-cell or parallel configs.

Beyond that, it mostly depends on what kind of switch you use (clicky or e-switch) and what you mean by ramping. I have a smooth-ramping e-switch firmware available (ToyKeeper/Ferrero_Rocher/Ramping_UI_table), DrJones has a clicky switch one (luxdrv), the OP of this thread implements ramping and the memory-retention trick for clicky switches, etc.

Personally, I like ramping with an e-switch and dislike ramping on a clicky switch. The e-switch means I can press-and-hold to ramp, then let go when it gets where I want. To ramp again, just press-and-hold again. Otherwise, you have to enter a specific ramping mode first, wait until it gets to the right level, then tap to select it as a steady mode. I’m not sure how you would enter ramp mode again after that, or how to quickly go to the highest or lowest mode without ramping.

Ronin42
Ronin42's picture
Offline
Last seen: 8 months 1 week ago
Joined: 12/17/2014 - 22:17
Posts: 1760
Location: Alameda, CA

Good points about the different switiches. Now does the “issue” with mechanical switiches apply to all as a class, or only to reverse clicky? I would think/hope/guess that a forward clicky could simply be released hopefully like an electrical switch?

And would a magnitic switch be considered Mechanical or Electrical?

I guess I made an incorrect assumption.

I thought I understood correctly that CC drivers were more efficent and did not produce as much drain or wasted energy in heat. I thought that Zener Diode mods were very inneffiecet at lower power levels(lost of wasted energy into heat), thus I thought that CC and Zener were mutually exclusive designs.

I guess I made a mistake but I dont know where?

(“It’s good that most people can’t remember their previous lives. Otherwise
things would be a lot more complicated than they already are.”
Ajaan Lee Dhammadharo)

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 4 hours 5 min ago
Joined: 01/12/2013 - 14:40
Posts: 10348
Location: (469219) 2016 HO3

There are basically two types of common switches in lights… one type works by cutting power entirely. This applies to basically all clicky switches, whether forward or reverse or other. It’s like a light switch (rocker switch) on the wall, on or off.

The other type works by continuously sending a “high” or “low” signal to the driver (shorted or not), and the power stays connected in both cases. This is the e-switch I was referring to, and can be magnetic or not. It’s like a button on a game pad.

Zener diodes tend to have a constant small drain whenever power is connected, so for an e-switch that means it would keep using power even when the light is off… unless you physically disconnect the power by loosening the tailcap or something. There are more efficient approaches, but I haven’t really looked into the details very much. I think wight has a driver or two specifically for this purpose.

Some lights have both, like the Convoy L4. It has an e-switch near the head and a clicky switch on the tail… so you can get the best of both worlds.

I’m leaving out other types of inputs, like Nitecore’s 2-stage e-switch and magnetic twisty rings like on the Jetbeam RRT01, and lights with multiple e-switches. We don’t have common firmware which supports those.

Mike C
Mike C's picture
Offline
Last seen: 2 months 1 week ago
Joined: 01/22/2014 - 08:03
Posts: 2486
Location: Sweden

This works very well on the ATtiny85 too. I tested with brownout levels at 1.8V and 2.7V. Maybe there was a slight difference in window time with the 2.7V level, but note that I have a 4.3V zener on the PCB which might have an impact on the 2.7V level detection.

Edit: Hmm, there might be a difference in window time with the low voltage versions… Might test that someday. Will probably be too short to care about, if there is any difference at all.

Anyhow, this is good stuff. Thanks Alex!

dthoang
Offline
Last seen: 1 year 5 months ago
Joined: 10/09/2014 - 13:30
Posts: 319
Location: Austin, TX USA

This research paper details a technique that can be used to detect short versus long off-time. Look at Figure 1.

I’m going to test to see if this works, but the impatient may want to try this on their own.

one year rookie

Pages