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.
Good to hear you have some bistro based OTSM code coming along!
As far as the regulation goes, I am not understanding what you are saying.
The FET modes will indeed always be higher then the 7135’s, this is how it is designed, how it should be and I don’t see anyway where this will not be the case unless the ramp table is vastly changed around.
You only ever bring the FET online after the 7135’s are at 100%, thus the FET can only add power to the 7135’s not subtract it no matter what the FET PWM is.
Let the 7135’s regulate best they can using hardware and let the software try to improve the FET best we can. We are not going for perfection here, just improvement and trying to not waste all that extra duty cycle on the FET modes.
Mostly I was just pointing out exactly what you just said, that yeah, if done that way, it keeps the modes in order. That's why their doen that way. But things are more complicated with voltage feedback. You say leave the 7135s alone, but you're not leaving them alone. When you change the PWM you're changing the amount of time speant in 100% on AND the amount of time speant instead at 7135 ON level. You're changing both. If you want to think of it like you're just changing the FET duty cycle, ok, but that's not the case, you're changing both duty cycles, and in a way that's more non-linear than changing PWMimg it all together. Anyway, it can work either way. if someone writes up some code that works with multiple levels or just a turbo for low vf leds, and has defines for both adc modes and does it that way, great.
For the otsm the biggest thing is right now I'm just using ram to store the sleep data. That's ok if you wake back up, but if you dont' the ram gets corrupted and might sometimes look like a valid short sleep time by accident. So that gets a proof of concept working but it's not ideal. I either need some ssymbly magic to let me initialize the variable but jump past the initialization on restart, or I'll have to revert to eeprom, but as it's on every click, it needs wear leveling. So a little left to work out to really polish it off.
Thats just it, The 7135’s PWM should not be changed, only the FET (although for the new driver 2 channels will need to be able to do this so it needs to be able to select which channels are effected.)
Why do you think that the FET pwm duty has an effect on the 7135 pwm duty? they are addressed independently in bistro as far as I know and one does not effect the other unless you try to make it that way.
If both duty cycles were being changed then you are correct (although I still don’t think it would be a noticeable difference for any mode where the FET is active). They should not both be changed though, this is key to the software regulation working properly.
TA. Could you remeasure the standby current on one of your drivers running narsiltriple? However, keep measireinf for 10-15seconds and see if the current drops down after a bit.
I’m thinking it will. I totally rearranged, cut up, rewired, and removed all amc7135s from the driver to make it comparable with standard Narsil. It works but I measured the current draw and it was 4.6ma :person_facepalming: I then remeasured and watched it for a while and it dropped all the way down to .04ma. So I may have reacted too soon and done all that for nothing. :person_facepalming: :person_facepalming: :person_facepalming:
I would like to know for sure though. So if you could measure that when you have time that would be appreciated. Well, I do have an indicator led now.
Yep, you are correct, it dropped down to 16ua after about 10 seconds.
Well it made me be creative atleast. Geesh
That does make me feel better about Narsil triple though. I thought I was going to be lost for my next few eswitch builds
lol, glad you kept at it, I was worried all my last narsil builds were in vein lol.
I do know the feeling though, I went to the trouble to add a voltage divider to some 15mm drivers only to break the drivers when trying to press-fit them to the pills. :confounded:
[/quote]
Why do you think that the FET pwm duty has an effect on the 7135 pwm duty?
[/quote]
Because it abosultely does. You're thinking about it from a pin output persepcetive, not a perspective of what the currents through the FET and 7135 are actually doing. It's a parallel source, but not a separate load
The PWM is a series of up and down pulses of course. There's an on duty cycle D and an off duty cycle 1-D. RIght, you're only applying that to the FET but what actually happens is this. During on time, both the FET and 7135's are "on" right? But what does that mean? You get Fet light plus 7135 light? No. It means you get 100%. It means the led sees 4.2 V. It's almost exactly the same as if the FET was on and the 7135s were off. They don't add.
Now what happens during offtime? You get 7135 power. during offtime of course. The amount of time you have a full fet power level is D and the amount of time you have 7135 power level is 1-D. That's still the expression for PWM, but the opposite PWM.
The total power is calculated by PFET*D +P7*(1-D). P7 mean s7135 power.
You can write that in another way more like you're thinking because if we replace power with voltage it rearranges to D(V-V7) +V7. So you can call the first part FET power, but the point still is FET power interpretted that way isn't just proportional to V anymore. You have to correct it for all7135 contribution.
In the end though, yes, if you increase PWM as battery voltage goes down, sure, you'll be going the right way (if you don't do it much of course).