Does it have the zener installed?
Yeah, it should be a lot less then that. What about the bleeder resistor, is that installed?
No zener no bleed resistor
Not a great photo but this is the driver
I always look at things from the widest possible view and try to pick features / options that will work for as many different possible situations as possible with as little work as necessary.
In this case it would need to be able to work with a low Vf LED where it will limit the PWM at full voltage and with a high Vf LED where the PWM does not need to be limited and only increased to maintain output in the mid range modes.
Basically the way everything works now is fine, the idea with this feature is to allow the modes to maintain some semblance of regulation as the cell voltage drops. The modes as they are at full voltage is fine and if the mode is high enough that it can not “maintain regulation” past a full cell, then so be it, that is the price of using turbo modes.
I never hear of people complain about the modes as setup for a full voltage cell like they are now, so I figure why change it, plus it will make setting up the ramp table and modes much harder in the software because you will always have to factor in the multiplier instead of the multiplier only trying to maintain output as voltage drops as best it can.
From the way I understand it basically flipping your code around so that instead of removing PWM as voltage increases it would instead add it as voltage decreases. Same thing, just reversed and allows all the modes to remain unchanged from how they are now because most of them are indeed setup for full charged cells. Otherwise we will have to increase all the PWM by 30% only to remove that 30% in the software regulation later.
Strange, looks good unless there is a minor short someplace or in one of the 7135’s.
I have never measured the narsil drain myself but I think tom has it under 1mA now. No idea myself. I might check one of my lights to see what it does.
I just checked one of my Narsil triple drivers and I got 5.3ma, so actually seems like it is working fine. Just not sure why it is so much higher then the normal narsil. That would be a question for Tom.
Hmmm? I’ll look over everything again. Maybe he has not tested parasitic drain on the triple channel version? If I can rule out a software bug then it must be something about the driver itself. Otherwise is there another eswitch firmware for the triple channel drivers?
Ah… that helps much! Thanks. I’m not sure if I can live with that or not? The light will eventually go to a paying friend so I don’t want it to drain the cells on him. I’ll have to think about that.
I’ve sent tom a number of messages over the last couple weeks and have not received a response so?
Yeah, I didn’t expect it to be that high either, no idea why it is that way. Although in my case I only have narsil drivers in SRK’s, L6 and a D01, all of which have enough batteries to last a few years at those drain levels lol. Just not a big e-switch guy for the smaller lights.
He has been super busy lately and his computer went down IIRC. So who knows when he will get back on here.
At 5ma wouldn’t it drain an 18650 3000mah in less than a month. So for your four battery lights that would be four months? Or is my math wrong?
Opps, your right, I was thinking of .5ma instead of 5ma (been working with the lighted tailcaps a lot with that kind of drain).
Yeah, 5ma is very high indeed.
I gave it a shot with BOD disabled as well but I get the same result. 4.6ma.
4.6ma is with power supply voltage at 3.8 btw. So my number lines right up with yours. Makes me pretty confident it’s a firmware issue.
Edit: Tom did say he has a v1.3 completed for Narsil triple. It has no dividers and support for an indicator led on pin 7. He has yet to post any links though. I wonder if the parasitic drain was addressed in the latest update?
Quite possible, he is up to 1.4 and working on 1.5 last I checked. So that is very possible.
Thanks, that makes more sense now. I’m fairly certain it can be reversed without too much difficulty and with little extra code size. But later.
Yeah, the base idea is great, it would just make is simpler long term and more widely applicable by having it increase PWM instead of decrease it. Increasing it is applicable to all FET modes, decreasing it is only applicable to the turbo modes.
OTSM in Bistro
No time to catch up yet, but anyway,
I have an OTSM implementation working in bistro with BODS, and it fits a 25. 2018 bytes, without trying to squeeze yet. (includes all recent changes)
Now when I say working, I mean the software does everything it's supposed to. I'm just testing by shorting pin 7 to simulate a power-down. It detects the voltage drop, sleeps. It wakes on watchdog every 250ms just to mark time, and finally it wakes on power pin rise and restarts the code without delay. I'm using ram persistency to get debug info even through minor power downs (basically like bistros OTC-less OTC trick). Basically I've verified all the steps are working and in the end it reports back to main code how many loops it slept through and I'm translating that straight into a "cap_val" variable so everything else is the same from there. The code is skirts the edge of the rules , but it works.
That said, I have no solid idea how well it works. I know it's pulling about 6~7uA throughout the sleep loops (this is a little better than with the ADC but only because using BODS has the current so low anyway) . From what I'm seeing I suspect it wastes about 10uF of capiticance just getting shut down and right now I'm just quite understanding my hardware situation with that, but anyway, I'm aiming for 40uF and I think should probably get there. I don't have 40 now and I don't have a low voltage chip, so I'll have to work on hardware to get it going now.
I'll be happy to post highlights of the new code if anyone is interested.
There is a much better reason in my opinion and it's the main tradeoff I've been arguing about which approach to use for targetting these PWM curves. The reason is if all the FET modes have 100% 7135s plus some PWM level on the FET, you are guaranteed that all the FET modes, regardless of low the PWM level is, are higher than the ALL7135 modes. If you didn't do that a mode that started out above all 7135s at full battery would end up below all 7135s with a weaker battery. You'd get mode orders that change with battery level and the number of 7135's you have. However, once you're doing voltage correction, this argument doesn't go away, but it gets better and other arguments favor well, not FET only, but PWMing the 7135s with the FET. There's still pros and cons either way there though.
The FET can handle the current. Although, sure, spreading heat a bit helps too.
I thought a little about testing power off detection times to help optimize them. The thing is you need to measure start time well, which means you need the mcu to shut the power off itself. I was staring at the 7135 pads, it might just be possible to wire one sideways for this purpose. It's a bit of fuss just to get some tests though.