No, that's because of the clicky switch: it cuts power when pressed, so the light can't operate then.
The link to 0.22 will be updated soon, sorry for inconvenience.
Several people have tested the AVR EEPROM wearout life using various techniques and in real life it seems to be something over 5 million cycles. I don't think your clicky will click that long...
Hey.
You fix the link the program version 0.22. You have made changes to the program?
thanks
texaspyro: Yes, even 100000 clicks is more than enough - however with ramping things get worn out more easily, since you have to write a new value for each step of the ramp. Depending on the number of steps, one minute of ramping might need 300 to 3000 writes.
Medicina2004: I'll put up version 0.3 in a few days; this version includes battery monitoring.
Currently I work on v0.4 though which is programmable (i.e. modes are configurable by the user, even the number of modes can be changed). The code has become quite ugly though and I won't publish it. Also I started selling drivers like these to increase my flashlight budget a bit...
One thing most people don't realize is that EEPROMs are usually configured in rows (pages). When you write a single location the row it is in is read into an internal buffer, the data is changed in the buffer, the row is erased, and the whole row is re-written to the chip from the buffer. You can wear out the whole row of cells just by repeatedly writing a single location in the row. Proper wear leveling must take this into account. You need to know the row size, etc.
Note that some chip makers can be rather misleading about this row wearout mechanism... some even downright lie to you... beware!
Thats something really awesome!
I've been writing PMs with DrJones for a few days now, he's been very helpful about his driver UI, will do soldering on the drivers (AMCs), program them for me and send them once I have my lights and tell him exactly what I want (custom modes, yay!). Having the delivery time reduced to a few days rather than several weeks is already worth a lot, not to talk about saving me from buying programming hardware and all that stuff.
texaspyro: Thanks for pointing that out! Attiny13 seems to have a page size of 4 bytes. Fortunately my wear leveling mechanism evenly spreads the writes, so whatever the page size is, it makes the best out of it.
NightCrawl: Thanks! :shy:
Actually, you probably can use them. Those small size clips usually do work on SOIC-8 packages. They don't tend to work well on things like SMD resistors and caps since there is no lead to grip . I use the ones from my HP logic analyzer all the time on SOIC/PLCC packages. I even have some that work on TSOP and TFQP packages.
Are you sure about this? AFAIK, unlike high density flash devices, EEPROMs are usually byte-erasable, but can have page-access modes for faster programming. The ATtiny13's datasheet doesn't mention pages in the chapter about software access to the EEPROM (5.3 EEPROM Data Memory). Page-access is only mentioned in the chapter about programming the chip's memories via SPI (17. Memory Programming) and seems to be used solely for speeding up the process.
about time :)
Yep, the locations appear to be byte erasable, but they appear to do that by doing a read-modify-write cycle on the page. Atmel is one of the places that dance around the issue. Some of their people claim they don't write pages, but when pressed one of their factory engineers said they do. The reason the issue was pursued was because of what showed up during sone wearout testing. With all the he-said she-said dancing around, who knows for sure what they are doing on which chip?
I published version 0.30 with battery monitoring:
the light will step down when the battery is low,
also the beacon mode has a battery indicator: at beacon start a number of blinks indicates battery level, ~12 blinks is full, ~5 blinks is nearly empty. It's about one blink for every 0.1V over 3.0V (cell voltage without load).
Awesome, that is a great program. Thank you so much for sharing your work.
3.5V isnt really "nearly empty" imo. O.o
Ussually the protected li-ion battery cut-off at 2.5V-2.7V. I employ the protection IC which cut -off at 3.0V. The remained run time is also co-related to the current drawn. So the definition of nearly empty is a personal preference. The key point is you can adjust to what you want.
To my experience, a cell with 3.5V *without load* is quite empty. As soon as a load is applied, voltage sags quite a lot.
Low battery step down is applied at 3V (under load).
Dear DrJones,
Is there a simple modification of the C code of luxdrv_0.22 to omit the function of 251, strobe and 252, beacon? The elderly likes fool proved simple operation sequence. Hi>Med>Low>Ramping are good enough.
The luxdrv_0.3 is great. Will you release the remote switch version for download?
Just remove those codes from the modes[] line in the config section:
PROGMEM byte modes[]={ 0, 6,51,255, 254, 251, 252, 253 }; // with ramping
change to:
PROGMEM byte modes[]={ 0, 255,51,10, 254 }; // with ramping
that's high, med, low, ramping (with a bit brighter low)
By "remote switch version" you mean lumodrv (for electronic switches)? No, I decided to sell these to increase my flashlight budget a bit (I actually wrote lumodrv for that purpose, because I didn't even have any suitable flashlight at that time)... The same applies to the newest version of luxdrv (0.40) which is 'programmable', i.e. the user can reconfigure the modes, even the number of modes. The code got quite ugly and unelegant, too, which is an additional argument for not publishing it.
Thanks DrJones. My mother loves the modified code.
Is there a way to increase delay time between blinks for battery level. Sometimes it's difficult to read out number of blinks.
I'm not too comfortable with C but i presume it's defined in case 252 line...