I’m curious if such a feature can be added to a 105C driver, it would be interesting to be able to link it to a computer and see how many hours of runtime has been put on a light (or at least the driver)
The hardware on a 105c does not allow for accurate counting of time. A dedicated RTC would probably be the best route, but even an external xtal would be a big improvement I think. Hooking an ATtiny13A up to the PC to read that out would also be impractical. Interfacing that way with the ATiny85 would potentially be much more practical, but it’s got the same timekeeping issues.
I figured it might not have a clock in it, but i was unaware of anyone ever asking this question so i hoped it might
You can still keep track of time, it’ll just be wrong/inaccurate. So for example if you simply wanted to know which of a pair of drivers had more runtime on it, it might be possible to guess at that using the numbers produced from such a system.
If nothing else it’s a fun idea. Maybe it’ll crop up in the first generation of open source drivers which allow for directly interfacing with a PC.
Some AVRs let you use a 32.768khz crystal. Then you can skip the dedicated RTC chip. I know it works on attiny85, ADC can lose accuracy but it may still be good enough.
can it store a cumulative runtime or just that session?
Just about any microprocessor can calculate hours from its oscillator but there is a couple of caveats:
You need a timer, the Tiny13A only has one and that is usual used for pwm in a flashlight.
You need a place to save the time, the 13A has a EEPROM, but it is limited to 100000 writes. This means that if you want to keep second resolution it will only work for 28 hours.
The oscillator inside the 13A is not very precise, probably around 5% (It depends on temperature and voltage). An external Xtal will improve that significantly.
You need some way to get the data out and that requires some pins on the processor.
You need some code inside the processor to handle it, both counting and also transmitting of data. The 13A does not have that much space for software.
There is no need for a RTC or a 32768Hz Xtal, this is only used when you need to keep track of the clock, not for counting runtime.
Wear leveling should improve the lifetime of the EEPROM. Maybe use a 20s resolution and about 40 bytes of the EEPROM for a few years of runtime data? Considering the flashlight is off most of the time that should get you enough runtime data to cover the life of the flashlight.
Be an interesting additional feature to add to a light like the TM26 which has a OLED readout display and some type of microprocessor I presume. Need to add a clock crystal and clock circuitry but considering what complete cheap LCD watches sell for the added expense per light should be minimal.
Could any of this be implemented on a 105C?
No, attiny13 has only one timer and its used for pwm as HKJ said.
A couple of ideas on some of these issues. First, what if you just write to the eeprom at state change (power up, mode change or power down)?
Second, what if you had a mode that dumped runtime data by modulated the light output that could be read out from an arduino or something with a photosensor?
Only with a side button light (which never actually turns off the attiny) could you write at power down.
could you add a capacitor for some split second extra juice, or write every second?
Using a capacitor in that way is not feasible. Writing every second is what HKJ was talking about. Without wear leveling it would wear out a section of EEPROM in 28 hours.
I don’t really see why having only a single timer is crippling here, but then again I haven’t tried it.
Even with wear leveling, if your writing every second & working with a small amount of eeprom you won’t have the room to spread it out.
Move away from the nanjg 105C & you can do anything.
Sure, you’ll definitely have to be more granular than 1s. Maybe 20s or so as I mentioned earlier.
Yes, easily possible with a NANJG105C with wear leveling and 20s precision. A hidden mode could blink out days-hours-minutes or similar. The internal RC clock isn't very accurate though, as written above.