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

111 posts / 0 new
Last post
ToyKeeper
ToyKeeper's picture
Offline
Last seen: 33 min 22 sec ago
Joined: 01/12/2013 - 14:40
Posts: 10307
Location: (469219) 2016 HO3

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.

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

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.

ToyKeeper wrote:
But what we know so far is that a single byte decays completely in about 0.5s.

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.

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

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

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.

one year rookie

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

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.

one year rookie

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 33 min 22 sec ago
Joined: 01/12/2013 - 14:40
Posts: 10307
Location: (469219) 2016 HO3

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”.

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

dthoang wrote:
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.

Looking at Figure 7 in the paper, the transition region labeled Stage 2 is too narrow to reliably detect between long and short off time. Furthermore, the duration of each stage is dependent upon the capacitance of the power supply smoothing capacitor, as shown in Table 5.

In Section 8 on page 13, the OTC method is described as an alternative.

one year rookie

alexvh
Offline
Last seen: 3 years 4 months ago
Joined: 05/28/2013 - 23:40
Posts: 29
Location: Canada
dthoang wrote:
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.

Yes, exactly. I meant that we currently check a byte to determine a short press. Right now in my firmware I just check if the entire byte is still 0, if it is, that means that no bits have decayed to 1.

Also from the paper:

Quote:
Memory decay occurs in SRAM when a cell loses its
state during a power cycle and subsequently initializes
to the opposite state upon restoration of power. Given
that each cell typically favors one power-up state over
the other [23, 17], memory decay can be observed only
when the last-written state opposes the favored power-up
state.

After some experimentation it seems about 74% of bits in SRAM favour a state of 1. Even after really long off time 74% of bits decay to 1 and the remaining % don’t seem to decay. So it is better to set all bits to 0 and measure how many have decayed to 1.

I’m still experimenting, but this method looks promising. I don’t have a way to shut off the attiny for a measured amount of time, but just doing it by hand I’m able to see that longer presses result in more decay. Short presses of less than 500 ms result in no decay, which we already knew.

Here’s some quick measurements:
off time | % of memory decayed
615ms 8%
780ms 33%
825ms 40%
925ms 56%
1250ms 67%
1600ms 69%

I think this method could probably work.

I used 32 bytes of SRAM in my test. I counted the number of bits that are equal to 1 and output it as pwm so I could read it as a percent with a multimeter or oscilloscope by measuring duty cycle. Here’s my code if anyone wants to play with it:

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: 33 min 22 sec ago
Joined: 01/12/2013 - 14:40
Posts: 10307
Location: (469219) 2016 HO3

Cool, so maybe we can get 3 levels after all. Smile

I didn’t expect it to have a long enough decay window to be useful.

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

Alex, those are good findings. I performed my test on a breadboard and so there are differences such as capacitor values and lack of voltage divider for LVD. Both of these will affect the decay time due to dropping Vcc. So your results with actual driver trumps mine with breadboard.

Originally I had initialized SRAM to patterns with equal 1s and 0s. I then tested all 1s and all 0s and found that all 0s work best. This agrees with your results.

one year rookie

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

I think the stack is implemented using SRAM, so that may explain why you are getting 74% max decay rate. Can you try inlining the hamming_weight function?

one year rookie

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

I’m only checking 32 bytes, half of the total SRAM, and I declared it in my code. So I’m not checking any of the SRAM that would be used by the stack. I believe only 74% decays because the remaining SRAM just prefers to stay at 0. 74% of the bits seem to end up 1 whether I initialize to 1 or 0 so I think it’s just the hardware. I’d like to see some other people test this so that we can see what the decay rate for other attiny13’s is and how much it varies. If this is something that varies a lot and requires calibration there is probably no point to doing it this way, and the capacitor mod would be the better solution.

Also, does anybody know what off times correspond to short press and long press for firmwares that use the capacitor mod?

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: 33 min 22 sec ago
Joined: 01/12/2013 - 14:40
Posts: 10307
Location: (469219) 2016 HO3

I’ve been using:

  • Short: < 0.5s
  • Medium: 0.5s to 1.5s
  • Long: > 1.5s

So, the measurements shared a few posts ago look very promising.

If this method works, and if it can work with a smaller array, I’ll probably add it to my no-OTC firmware. I never did fill those 262 bytes I freed up by switching from on-time to mem-decay… Smile

Mike C
Mike C's picture
Offline
Last seen: 1 month 12 hours ago
Joined: 01/22/2014 - 08:03
Posts: 2486
Location: Sweden

alexvh wrote:
After some experimentation it seems about 74% of bits in SRAM favour a state of 1. Even after really long off time 74% of bits decay to 1 and the remaining % don’t seem to decay. So it is better to set all bits to 0 and measure how many have decayed to 1.

I’m still experimenting, but this method looks promising. I don’t have a way to shut off the attiny for a measured amount of time, but just doing it by hand I’m able to see that longer presses result in more decay. Short presses of less than 500 ms result in no decay, which we already knew.

Here’s some quick measurements:
off time | % of memory decayed
615ms 8%
780ms 33%
825ms 40%
925ms 56%
1250ms 67%
1600ms 69%

I think this method could probably work.

I used 32 bytes of SRAM in my test. I counted the number of bits that are equal to 1 and output it as pwm so I could read it as a percent with a multimeter or oscilloscope by measuring duty cycle. Here’s my code if anyone wants to play with it:


Good stuff! I’ll be testing this out on my ATtiny85 firmware tonight. Being able to do this will save me from using the reset pin as an IO, and that’ll be a major headache saver.

I did try something like this as soon as I had tested the simple 0 method, but I only tested with a single byte and only checked if the value was 0, 255, or anywhere between. I got some results but they where not reliable and put on hold. Counting individual bits in an array of bytes will give much more reliable results for sure. The ATtiny85 has 512 bytes of RAM so I can use more bytes for better resolution.

With the ATtiny13A one should pay a lot more attention to RAM usage when using this method as it only has 64 bytes of RAM. Adding a 32 byte array to an existing firmware with many features could exceed the 64 byte RAM capacity, resulting in unpredictable behavior.

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

I tried it with the attiny13 in my edc flashlight as well and it seems to decay to 70% 1’s. So maybe attiny13 SRAM tends to favour 1 in general.

It should be possible to use less bits for this. I just wanted to get a large sample size so I used 256 in the test.

I’m going to try to put this into a firmware soon and see if I can get it working reliably.

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

Mike C
Mike C's picture
Offline
Last seen: 1 month 12 hours ago
Joined: 01/22/2014 - 08:03
Posts: 2486
Location: Sweden

Getting 70% on the ATtiny85 too.

Been testing and it is working with three levels, but the testing made me realized that for me personally the decaying starts too late to use it for detecting three defined off time intervals. I’m used to my off time firmware where a medium press is well under half a second. For me it’s just easier to use double and triple clicks rather than holding the button for as long as it takes to get a reliable difference between off times.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 33 min 22 sec ago
Joined: 01/12/2013 - 14:40
Posts: 10307
Location: (469219) 2016 HO3

Do you share your code anywhere? It sounds like you’ve got a lot of interesting projects which others might want to see, and I’d be happy to include those in the shared repository.

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

I have a firmware with a medium press. It’s a little hard to actually get a medium press though. It might be possible to get it working nicely by using more bits and trying different thresholds for the medium press. Right now it uses 32 bits and a medium press is less than 20 bits of decay. Anything less than about 800ms seems to be a medium press.

I created a branch on github if anyone wants to try it out and experiment with different values:

https://github.com/alexvanh/basic_off_time_driver/tree/medium_press

Maybe it’s just the times for each type of press, but I think I agree with Mike C. I’m not sure if I like a UI with a medium press.

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

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

Hey! This is really cool, I can leave the mode on ramping! Smooth ramp is it? Absolutely genius! I really really like this. I wonder how long it will take me to use up that million writes? lol

Never! The ramping mode doesn’t use the eeprom. I store the value in SRAM, and it stays there until the next power on as long as it’s off for less than about 500ms. The firmware doesn’t actually touch the eeprom unless you enable mode memory.

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

Mike C
Mike C's picture
Offline
Last seen: 1 month 12 hours ago
Joined: 01/22/2014 - 08:03
Posts: 2486
Location: Sweden

ToyKeeper wrote:
Do you share your code anywhere? It sounds like you’ve got a lot of interesting projects which others might want to see, and I’d be happy to include those in the shared repository.

Once I’m done with my 85 firmware I can share it if there is interest, but it’s not going to be ready for a while. It’s pretty well organized and commented so it could be useful for others wanting to get into 85 programming, or AVR programming in general. However, it uses the I/Os differently than the standard Nanjg driver, but is easy to understand and change pins as needed.

alexvh wrote:
Never! The ramping mode doesn’t use the eeprom. I store the value in SRAM, and it stays there until the next power on as long as it’s off for less than about 500ms. The firmware doesn’t actually touch the eeprom unless you enable mode memory.

That’s what I really like about this. I might not be a fan of the different lengths of off times, but I’m all over the method of using the no init area. I’m stashing all kinds of stuff in there. My 85 firmware I am writing has a user reprogram mode where amount of modes and level of each mode can be set, and I’m using the normal short “brownout” press to do all the programming, only writing to the EEPROM when everything has been configured.

I also have the integer for the voltage readout in there so it’s always updated when the light is on and under load. When I do my voltage readout routine (three short presses) I blink the level that was stored there. Then I get the current level (not under load) and blink it out if it differs from the “under load” value.

I’ve got so much space in the 85, plenty of ideas and don’t have to worry about limiting myself… yet… Like a user enabled lock out code or similar. Who wants their children to be able to flash 10000 lumens in their face if they find the light lying around on your desk, or set fire to your backpack because the switch was bumped while hiking. These days lights are getting dangerous…

Stashing arrays, bytes and flags into the no init area without having to read and write between each press has made this all sooo much easier… So yeah, thanks again Beer

Microa
Offline
Last seen: 3 hours 27 min ago
Joined: 06/29/2011 - 21:20
Posts: 238

I have 5 pieces of Attiny85V ready for your new firmware. Thanks for your guys’ effort for us to have a perfect flash light what we want.

Mike C
Mike C's picture
Offline
Last seen: 1 month 12 hours ago
Joined: 01/22/2014 - 08:03
Posts: 2486
Location: Sweden

Microa wrote:
I have 5 pieces of Attiny85V ready for your new firmware. Thanks for your guys’ effort for us to have a perfect flash light what we want.

I should perhaps mention that the 85 firmware I’m coding is written with standard clicky button only in mind. I do have a few projects with both clicky and E-switches that I’ve yet to start coding (have all the hardware), but they all use the ATtiny24 or 84 which is a 14 pin chip.
Microa
Offline
Last seen: 3 hours 27 min ago
Joined: 06/29/2011 - 21:20
Posts: 238

14 pin chip is perfect for bigger light such as lantern and has more I/O pins to play with.

Mike C
Mike C's picture
Offline
Last seen: 1 month 12 hours ago
Joined: 01/22/2014 - 08:03
Posts: 2486
Location: Sweden

Microa wrote:
14 pin chip is perfect for bigger light such as lantern and has more I/O pins to play with.

I’ll be posting threads about the lights when I get around to them… Ahh, so many projects, so little time… And heading for a PC free vacation week on Sunday.

Anyhow, don’t won’t to hijack this thread any more with my off topic clutter. I’ll make new threads when I have something to show.

Microa
Offline
Last seen: 3 hours 27 min ago
Joined: 06/29/2011 - 21:20
Posts: 238

As you have mentioned, it is hard to get a medium press precisely. I prefer to the original one.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 33 min 22 sec ago
Joined: 01/12/2013 - 14:40
Posts: 10307
Location: (469219) 2016 HO3

Hi, I know this is way late… but I finally made a version of STAR which uses memory decay instead of a capacitor to measure off time. In case anyone wants it:

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

It’s just STAR_off_time 1.3 with the OTC bits replaced by mem-decay bits. No other changes.

Microa
Offline
Last seen: 3 hours 27 min ago
Joined: 06/29/2011 - 21:20
Posts: 238

Shall I need to set the high fuse to 0xED instead of 0xFF?

Microa
Offline
Last seen: 3 hours 27 min ago
Joined: 06/29/2011 - 21:20
Posts: 238

I have just tested my build is successful and working well but with 5 warmings. Need not set the high fuse to 0xED. 0xFF is OK.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 33 min 22 sec ago
Joined: 01/12/2013 - 14:40
Posts: 10307
Location: (469219) 2016 HO3

Hi, sorry, I forgot to include the flashing script and fuse settings. That’s fixed now, and re-published. Smile

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

ToyKeeper wrote:
Hi, I know this is way late… but I finally made a version of STAR which uses memory decay instead of a capacitor to measure off time. In case anyone wants it:

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

It’s just STAR_off_time 1.3 with the OTC bits replaced by mem-decay bits. No other changes.

Thanks for doing this, I’m sure quite a few people appreciate it. Beer Beer

Microa
Offline
Last seen: 3 hours 27 min ago
Joined: 06/29/2011 - 21:20
Posts: 238

I played the STAR_noinit for a while. It worked perfectly with my QX5241 buck driver but it did not work with my CL6807 ( similar to PT4115 ) driver. The driver became no memory. I thought may be the 3.3V VCC to the Attiny13A from the voltage regulator is too low for the ram retention. I will replace with a 5V regulator to test again when I am free.

Pages