After someone else confirms it works, and maybe the defaults are tweaked back to a more user-focused config, I should be able to merge the tripledown-bistro code into trunk. For now, it’s working but is only in the tiny25 development branch.
For tiny13-based tripledown drivers, that’s a different matter. It can’t do PWM on the FET pin, and it has only half as much space, so it’s significantly trickier to get working.
Dear ToyKeeper,
I have flashed your Baton FW for my light and it is great. I noticed that the green and the red indicators were turned on and off during the transition period when the voltage was dropping to the on/off threshold. Can you help me to make it turned on/off sharply.
Hi, um, what exactly is it doing, and what do you want it to do?
In my testing, the indicator tends to stay green above 3.9V or so, then starts to flicker orange occasionally, and the flicker gets longer and more frequent as it gets near the next voltage threshold. Eventually it goes fully orange and stays that way. Then as the cell voltage drops more, it eventually turns red. But I haven’t seen the same soft flickering transition effect between orange and red.
I think this is because the voltage measurement is made out of phase with the PWM signal. So, sometimes it measures with the main emitter off, sometimes with it on. And this results in pretty different readings depending on when exactly the measurement was taken. It was unintentional but I kind of like the result since it gives a finer resolution, more than just green/orange/red.
At lower voltages it doesn’t seem to matter as much. The emitter isn’t using as much power so it probably doesn’t vary as much.
If you want it to not flicker orange as it nears the orange threshold, it’ll need to sync the measurements to happen at a consistent part of the PWM cycle. I’m not sure how to do this though.
Thanks for your prompt reply.
What I want to do is that you have explained. I have modified the code that
FULL BATT indicator off
LOW BATT indicator on
ALMOST EMPTY indicator blink
As you have said, the led flickered before it was stably on. I try to get rid of the flickering. It seems that is not easy to be done by changing a few lines of the code.
ive been playing around with tk’s starry-offtime firmware(and others). Does anyone know where i can find the .h files that are referred to in the STAR firmware? Or do i not need them? Thanks for any help! These are the files i am talking about:
#include <avr/pgmspace.h>
#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/wdt.h>
#include <avr/eeprom.h>
#include <avr/sleep.h>
//#include <avr/power.h>
oops!
#include <avr/pgmspace.h
#include <avr/io.h
#include <avr/interrupt.h
#include <avr/wdt.h
#include <avr/eeprom.h
#include <avr/sleep.h
//#include <avr/power.h
PPDB22, they are installed with the “avr-libc” package on linux distributions. Not sure what the equivalent is on windows. If everything is installed correctly, they should be found automatically by the compiler.
hmm. ok so are they created when i build the hex? excuse my ignorance!
or are you saying they should be part of my avr software package? sounds like i should just build the file and give it a try then…
Yes, they should come installed with the compiler. You won’t be able to compile most firmware without them. They’re official atmel stuff: http://www.atmel.com/webdoc/AVRLibcReferenceManual/group\_*avr*\_eeprom.html
What are you using to compile? On which OS?
I’m on Windows 10. I’ve only flashed four drivers so far. I asked about these files because I compiled a different firmware with errors caused from missing files. I fumbled through fixing that so when I came to this firmware and saw it referenced some files I went looking for them. Thanks for you help. I’ll get to try it out tonight if my day goes well:)
In C, any include with <> symbols is assumed to be provided by the host system. Includes with quotes come from the specific project being built.
So, all those mentioned should be available by default if the AVR toolchain is installed correctly.
i have been preparing myself for using the triple down drivers for some lights to spot game at night. So I was thrown off a bit when I was asked to build some lights with red emitters. Anyway, I searched for some code for 7135 drivers that could be modified with an “off” mode as well as battery check mode. Ironically, the code I now have working is tk’s s7 firmware which is designed for advanced flashy modes. It now has five modes, off-low-med-high-battcheck, and memory is disabled. So from any mode I can turn the light off and then back on again without a “click”. I’ve found the click from a tailcap switch to carry quite far in the still of the night. I will be curious to see if this is helpful or not.
Thanks to tk and the other firmware builders!
I’m after a bit of help. I have a MTG2 light which is causing me a bit of a headache. The LVP kicks in really early, I have the right voltage dividers and I’ve tired getting the readings with TK’s firmware but they just don’t seem to be right. I suspect its down to the voltage drop when the light is pulling high currents. Is there anyway that I can get these readings while there is the voltage drop?
Thanks
Does the firmware you use have some sort of voltage readout ability?
I did some testing with storing the voltage value under load in the no init area and then retrieving it on readouts. It worked ok but I found it rather useless for my purposes. Now I have it so that when boost mode is active the LVP step down kicks in at critical voltage level, not low voltage level.
No I don’t have a readout on the firmware I’m using but willing to look into those that do as it is driving me mad. It makes the light unusable as it just steps down as soon as it get into a high mode.
What MCU are you using? If it’s 13a based I can’t help much with code, I haven’t touched that little thing in a long time and have no code for it left.
Another thing that might be affecting your readings: The internal 1.1v reference voltage is different on each MCU. Datasheet specifies it can be between 1.0v and 1.2v. Normally it’s very close to 1.1v and nothing needs to be done, but I have had the odd MCU where it has been at the very limits. This caused readings to be off enough that I wrote a calibration routine.
May I ask what driver you have, and what the values of the voltage divider resistors are?
I have some 85s that I can use. Currently using 13 on Wights 22mm DD+single
I can’t remember the values I’m using off the top of my head, I can look later.
Thanks
If you have a working 85 firmware that has some sort of readout function it could be modified to write the voltage value to EEPROM or no init area. I can give small tips on how to do that but I won’t make a whole flashable firmware as my hands are full with getting my own firmware ready.
I have no experience with Toykeepers firmware so I can’t really help with those readings that appear wrong either.
Did you actually measure the resistors of the divider? What are the values? If you’re unlucky and they’re both 5% off in the wrong direction, you’ll get a reading about 10% off. That’s over 0.3V.
Also, what is the LVP set to in the firmware? I mean the actual ADC value (something around 100-120), not what the comments claim the voltage to be.
Which firmware are you running?