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

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 :frowning:

You coding genius are incredible!

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.

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

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 0x04 to 0x03.
Do you plan to add strobes ? I love the blinkies :slight_smile:

I’m glad to hear more people are getting into reprogramming their lights! :slight_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.

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

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.

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

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?

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.

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.

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.

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.

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?

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.

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!

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.

Looks cool in general, but I get the impression that the attiny13a might not be able to use this trick. If I understand correctly, it is basically taking a sample of many bytes of “noinit” RAM instead of just one, and estimating time based on the ratio of decayed vs intact bytes. But that requires a lot of bytes in order to get a reliable measurement, and it probably needs a slower decay than what nanjg drivers have.

Maybe it could work if a significant chunk of RAM was set aside for it and we counted bits instead of bytes. But what we know so far is that a single byte decays completely in about 0.5s. I haven’t seen evidence yet to suggest that a larger sample would last significantly longer.

I could be totally wrong, but at a glance it looks like a long shot.

That’s interesting. We’d need to do some testing to better understand how the SRAM in the attiny13 decays. Maybe by using another microcontroller to switch the attiny off for a measured amount of time with a relay and counting the number of bits that have decayed when power has returned.

Actually, we just check if the entire byte is still zero. Which just means that no bits have decayed before 0.5s, but at least one bit has decayed after 0.5s. So we can’t rule out this method yet.

We need to count bits that decayed, not bytes. So if we initialize a byte array to 0xff, we can then count how many bits are set to 1. This is what I intend to do and to try to get a correlation between percent of 1 bits and off time.

I used 10 bytes and counted the number of bits that changes after a power cycle. I found that the percentage of bits that change value converges to 50% pretty quickly and consistently.

My conclusion is that the time constant for data retention in SRAM is too low for our use.

OTOH, the off-time cap on one of my drivers still gives me a nonzero value after being powered off for like an hour.

I could totally put in an easter egg where if you leave the thing off between 20 and 21 minutes, it’ll blink out the morse code for “pants are optional”.