Attiny25/45/85 FW Development Thread

1922 posts / 0 new
Last post
Texas_Ace
Texas_Ace's picture
Offline
Last seen: 1 week 3 days ago
Joined: 03/24/2016 - 07:44
Posts: 9036
Location: Everything is brighter in Texas
Flintrock wrote:

 I don’t get the resistance.


 


In a 100% FET mode you can’t regulate it period.  We’re talking about having regulated middle modes.  We already have that for the all 7135 mode but it just depends how many 7135s you have on how long that can stay in regulation, and when it goes out, so do all the modes under it above one 7135.   You MUST at least take into account pwming all channels even in fet modes or you just won’t get this right at all, but if you don’t take into acount in one way or another the 7135 output, you’ll also end up with modegroups that are a confusing out-of-order mess that depends on battery level. The thing that kept them in order was leaving the 7135s on full while the FET is on, but you just can’t do that now, well not without even more work to sort it out.  And then you might as well just do things right:


 


 


This is what makes sense:


 


#define ALL7135_MAXVF  // the Vf expected at the current level provided by all 7135s


#define ONE7135_MAXVF // the Vf expected at the current level provided by one 7135s


 


target_vf=vf_targets[mode_idx]; 


 


while (1){


  actual_voltage=get_voltage();


   if(target_vf>actual_voltage) {// Set a target we can actually reach.  Correct for voltage sag next time around.


       target_vf=actual_voltage; // better yet would be to lock out a mode once the target_vf of the next lower mode is>= voltage


   }


 


  if (target_vf>ALL7135_MAXVF){ // More than 7135's can handle, use everything.


      PWM=light_output(target_vf)/light_output(actual_voltage);


      PWM_ALL_CHANNELS(PWM);


  } else if (target_vf > ONE7135_MXVF){// Using all 7135s


 // compare desired light to what we'll actually get at the lesser of this voltage or the max 7135 voltage


 // Note if target_vf is set equal to ALL7135_MAXVF we'll still have a no PWM mode.


     PWM=light_output(target_vf)/light_output(actual_voltage);  


     PWM_ALL7135s(PWM); 


  } else { // Using one 7135


.. ok using voltage down here in the weeds probably doesn't make much sense.


.. just translate these to fixed single PWM levels.


  }


// loop to keep up with voltage sag and drain.


} 


 


light_output is the normalized lumens expected at a particular Vf.  We rarely see this curve actually, but we have vf vs current curves and current vs light curves so you can combine them and work it out.  I've never seen it.


 


The ratios are the thing to be approximated and can probably be done by


255-(actual_voltage-target_vf)*LED_CAL


Instead of by division.


It seems that multiplication by a constant isn’t very expensive.  The optimizer works out a a fixed algorithm for it.  


I think it’s multiplication or division of two variables that is expensive. 


 


The hard part here is just knowing what the Vf corresponding the current of your ALL7135s is.


That depends on how many 7135s, and both that and LED_CAL will depend on the LED in use.


 


If configured right this will keep all the modes in order and all regulated as long as possible. 


edit: removed a redundant comparison in  second conditional.

How much space does this take up? It would also need to be selectable for which channels it effects, in the new driver it can not effect 1 of the channels or it will totally screw with how the light works. It also must be able to adjust the remaining channels “individually”, aka, if one of them is set to 0, it will need to stay at zero.

Flintrock
Offline
Last seen: 3 years 3 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

So basically I think the code outline I have is a good starting point regardless of these arguments.  Gchart and I actually aren't far off in our lagnuage.  He references the voltage where his curve hits 100% (what I call the target_vf) and the PWM level for 4.2V.  Equivalently use target_vf and a slope (PWM drop per V).   You could use 4.2V PWM level and slope, but you can get from one to other and it's all the same in the end.  

 

The biggest question is how will things work switching from Vcc mode to normal mode.  Right now we don't really have a voltage number.  In normal mode the ADC could at least be proportional to voltage but in Vcc mode it's definitely not and the voltage we're generating now is too course for this (you don't want big step downs).  The ADC is not even linear with voltage.  I'd say fine, just use the inverted ADC number anyway and set adc_targets and PWM vs adc slopes.  But then you'll need two sets of calibrations for these slopes and levels.  And if you do want to regulate lower modes (I would) you'll need a third calibration for that since it will have to be done differently.   

 

You do add significantly more non-linearities with this mixed mode approach.  However you do guarantee that the FET modes won't cross below the ALL7135 modes, because the ALL7135's are always on full in them.

Flintrock
Offline
Last seen: 3 years 3 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

Cross posted.  My biggest question is how does it deal with swtiching between ADC modes.  The two ADC modes behave very differently.

Flintrock
Offline
Last seen: 3 years 3 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

Texas_Ace wrote:
How much space does this take up? It would also need to be selectable for which channels it effects, in the new driver it can not effect 1 of the channels or it will totally screw with how the light works. It also must be able to adjust the remaining channels "individually", aka, if one of them is set to 0, it will need to stay at zero.

 

I think it's pretty small. Maybe not 25 small.  Not much is.  The whole point of that approach is adjusts all the channels you want to use equally.  But you can use or not whatever channels you want. I'd have to look at the driver to make it final of course, but I don't see a problem.  Then again I have no idea what you've  done that's so special about one channel.  If this is anything related to your op-amp ideas I don't know why you'd care about fet regulation.  Anyway, I don't know what I don't know.  It's just a code sketch at the moment though.  It could be selectable for many things.  It also still hasn't dealt with the issue of switching  betwen ADC modes yet, although it's a bit easier in the PWM-everything-in-use-equally approach than the leave-the-7135s-on-full-blast-and-just-PWM-the-FET approach, but still needs some calibration defined for both.

fixed it
Offline
Last seen: 1 year 3 months ago
Joined: 12/08/2015 - 14:27
Posts: 396
Location: Canada
Texas_Ace wrote:
fixed it wrote:

Here’s my attempt at regulation. I don’t have time to test it on a light but I have tested the code on a PC and it appears to produce a decent ramp. It’s 80 bytes on AVR as a function, probably a few less once inlined. Hopefully the comments are enough explanation but feel free to ask questions. Just don’t expect too many answers before tomorrow.


 

The values I put in there for V_ZERO_AMP and V_FULL_PWM are placeholders, you’ll need to figure out your own for a given driver and LED.

I am not sure how it works exactly but it looks good.

So when you say Zero_amp, that would basically be a dead battery? It will increase the FET as voltage drops until it reaches 255pwm, regardless of the starting duty?

Can multiple channels be selected/use this?


The zero amp voltage is more of a hypothetical figure, if you were to draw the Vf/A curve as a straight line. For example, using djozz’s 219C test it would be about 3V. It has an effect on the shape of the ramp after V_FULL_PWM.

And this works the other way around: it reduces PWM value when Vcc is above V_FULL_PWM. So you should be able to leave the modes mostly as they are now, pick V_FULL_PWM where you think the light is as bright as it should be and the code will try to prevent it getting brighter. For example, if you pick V_FULL_PWM of 3.8V, then a PWM value of 255 will remain 255 below 3.8V, might turn into 235 at 3.9V, 220 at 4.0V, 205 at 4.1V and 195 at 4.2V (these are just guesses but it does look something like that).

And yes, you just call the function on whatever channels you want to, right where the PWM value is set. In bistro, that means changing something like “PWM_LVL = pwm1;” to something closer to “PWM_LVL = regulate_fet( get_voltage(), pwm1 );”. Although the diode drop probably needs to be added to get_voltage() too.

Edit: I was tired when I wrote that code so the constants are pretty badly named. V_FULL_PWM would probably be better understood as V_REGULATION_CUTOFF or something similar. And perhaps V_ZERO_AMP as V_CURVE_ORIGIN or something else which doesn’t give any wrong ideas.

fixed it
Offline
Last seen: 1 year 3 months ago
Joined: 12/08/2015 - 14:27
Posts: 396
Location: Canada

Texas_Ace wrote:
Which since the test yesterday went ok I guess I can say a little about the new design, it is an op-amp based design, basically think open source LD-3. In this case it will not need any software regulation for the op-amp channel (it will for the others) as the opamp will take care of that internally.
I don’t know the details but why keep multiple channels at all? If you’re operating the FET in linear mode (which I imagine you are if there’s an op-amp involved), it can do everything from the lowest low you can imagine to fully on as we currently have.
Texas_Ace
Texas_Ace's picture
Offline
Last seen: 1 week 3 days ago
Joined: 03/24/2016 - 07:44
Posts: 9036
Location: Everything is brighter in Texas

It is not that it is anything super special with the new driver, as super basic actually. In a nut shell moon will be controlled directly from the MCU and it will need to have voltage compensation on the PWM output. It will also have an FET channel that needs regulation for the same reasons we need it now.

What I have come to find with flashlights is that precision in light output is not all that important. Particularly in the high modes. Our eyes simply can’t register the change we would see. Heck 800 vs 1100 lumens is hardly noticeable by eye, you have to go back and forth quite a few times to figure it out if you don’t already know.

This is why I am just not worried about it being super precise, our eyes will not notice it anyways. I just hate thinking that there is another 30% duty left on the table for turbo as the voltage drops that is wasted for the entire life of the battery. Having the mid range FET modes for triples have some regulation is great as well.

The code is over my head but here is what should happen at the most basic level:

Increase PWM for selected channels (they can be controlled by the same multiplier if needed) by a (user adjustable) multiplier as voltage drops.

Anything past this is a bonus only needed if the space usage is worth it (or those features can be disabled if not needed).

The next most important thing I would say would be a further multiplier for the lower voltage ranges as those areas might need to be adjusted at a faster rate. It could be as simple as use X multiplier from 3.6-4.2V and use Y from 3v to 3.6V. The key is simple and space saving

As far as the 7135’s go, I am simply not worry about controlling them with software regulation. If it can do it with very little space used and can be disabled, then that is great although I find in the TA drivers that the mode spacing is quite good by simply turning the 7135’s on full blast after you get past moon and low.

If fixed it’s code is only 70 bytes then that is a much more feasible option IMHO, although like I said I don’t understand either one of ya’lls code. So I will leave it to the expert on how to do it.

The key is simple and small.

Texas_Ace
Texas_Ace's picture
Offline
Last seen: 1 week 3 days ago
Joined: 03/24/2016 - 07:44
Posts: 9036
Location: Everything is brighter in Texas
fixed it wrote:
Texas_Ace wrote:
Which since the test yesterday went ok I guess I can say a little about the new design, it is an op-amp based design, basically think open source LD-3. In this case it will not need any software regulation for the op-amp channel (it will for the others) as the opamp will take care of that internally.
I don’t know the details but why keep multiple channels at all? If you’re operating the FET in linear mode (which I imagine you are if there’s an op-amp involved), it can do everything from the lowest low you can imagine to fully on as we currently have.

It boils down to heat, cost and space constraints. To get it to do everything with the op-amp would require very expensive components that are not available in small enough footprints to fit on a 17mm driver. Also according to DEL, to get a true moon mode out of the op-amp at all would be quite difficult.

The reason for the FET channel is that the op-amp and “regulated” mode can only dissipate so much heat, so you can not dissipate 5W in the driver, the driver will literally melt down (the negative wire desoldered itself from the FET today with only 3W of dissipation).

So once you reach the max that the driver can regulate / dissipate as heat you are stuck, you can’t go any higher.

So this is why the FET is PWM directly. This way it doesn’t overheat the driver but still allows for almost unlimited amounts of current.

It is a compromise but the best we can do with the constraints we have. If people were willing to spend $15-20 on the parts for the driver alone then other options could be pursued but that not a practical option for a group buy light. Doing it this way cuts the cost down drastically.

The real difference of this vs the TA drivers will be space savings, you can easily use retaining rings on all your lights. Adjustable output with no PWM in place of the 7135’s and it will be able to work with 3v LED’s all the way up to 12V LED’s without having to change anything but a resistor or 2. So it will power things like the XHP35 without a hitch (which is what it was designed for actually).

Texas_Ace
Texas_Ace's picture
Offline
Last seen: 1 week 3 days ago
Joined: 03/24/2016 - 07:44
Posts: 9036
Location: Everything is brighter in Texas

fixed it wrote:

The zero amp voltage is more of a hypothetical figure, if you were to draw the Vf/A curve as a straight line. For example, using djozz’s 219C test it would be about 3V. It has an effect on the shape of the ramp after V_FULL_PWM.

And this works the other way around: it reduces PWM value when Vcc is above V_FULL_PWM. So you should be able to leave the modes mostly as they are now, pick V_FULL_PWM where you think the light is as bright as it should be and the code will try to prevent it getting brighter. For example, if you pick V_FULL_PWM of 3.8V, then a PWM value of 255 will remain 255 below 3.8V, might turn into 235 at 3.9V, 220 at 4.0V, 205 at 4.1V and 195 at 4.2V (these are just guesses but it does look something like that).

And yes, you just call the function on whatever channels you want to, right where the PWM value is set. In bistro, that means changing something like “PWM_LVL = pwm1;” to something closer to “PWM_LVL = regulate_fet( get_voltage(), pwm1 );”. Although the diode drop probably needs to be added to get_voltage() too.

Edit: I was tired when I wrote that code so the constants are pretty badly named. V_FULL_PWM would probably be better understood as V_REGULATION_CUTOFF or something similar. And perhaps V_ZERO_AMP as V_CURVE_ORIGIN or something else which doesn’t give any wrong ideas.

According to djozz’s test, 3V will be about 1A of current to a 219C and 400 lumens?

So this code will not increase the PWM as voltage drops? Only decrease it as the voltage rises?

Either way I suppose some modes will have to be adjusted but ideally only the last few of the ramp table would need to be adjusted (those that limit the duty to keep current in check).

Texas_Ace
Texas_Ace's picture
Offline
Last seen: 1 week 3 days ago
Joined: 03/24/2016 - 07:44
Posts: 9036
Location: Everything is brighter in Texas

I also want to say thank you very much to all of you for working on this. I am a bit of a perfectionist and like to understand how things work, not just that they work, this can cause me to come across as ungrateful or unhappy when I am actually exactly the opposite.

I just like to understand things and sometimes that requires breaking them down a a few levels for it to sink in.

fixed it
Offline
Last seen: 1 year 3 months ago
Joined: 12/08/2015 - 14:27
Posts: 396
Location: Canada
Texas_Ace wrote:
fixed it wrote:
I don’t know the details but why keep multiple channels at all? If you’re operating the FET in linear mode (which I imagine you are if there’s an op-amp involved), it can do everything from the lowest low you can imagine to fully on as we currently have.

It boils down to heat, cost and space constraints. To get it to do everything with the op-amp would require very expensive components that are not available in small enough footprints to fit on a 17mm driver. Also according to DEL, to get a true moon mode out of the op-amp at all would be quite difficult.

So this is why the FET is PWM directly. This way it doesn’t overheat the driver but still allows for almost unlimited amounts of current.

Ah sorry, I thought the op-amp was used to amplify a sense resistor or something similar. It sounds like it’s instead used as a better 7135. I don’t know much about op-amps so I’ll leave it at that and wait until the whole thing is released. I wish I had free time to design my own driver, it certainly seems fun.
fixed it
Offline
Last seen: 1 year 3 months ago
Joined: 12/08/2015 - 14:27
Posts: 396
Location: Canada

Texas_Ace wrote:
According to djozz’s test, 3V will be about 1A of current to a 219C and 400 lumens?

Maybe, does not really matter. That value is only to define a straight line which is used to approximate the graph in the area where regulation happens (ie. in the 3A+ range, presumably). What the graph looks like below the regulation threshold is unimportant as I don’t do anything about it.
Texas_Ace wrote:
So this code will not increase the PWM as voltage drops? Only decrease it as the voltage rises?

Either way I suppose some modes will have to be adjusted but ideally only the last few of the ramp table would need to be adjusted (those that limit the duty to keep current in check).


Yes but it really amounts to roughly the same thing when you think about it. The only difference is what PWM values you have to start with and how you calibrate the whole thing. Either your modes/ramp have lower PWM values which get increased by regulation or they have the higher PWM values which get decreased by regulation.
Texas_Ace
Texas_Ace's picture
Offline
Last seen: 1 week 3 days ago
Joined: 03/24/2016 - 07:44
Posts: 9036
Location: Everything is brighter in Texas
fixed it wrote:
Yes but it really amounts to roughly the same thing when you think about it. The only difference is what PWM values you have to start with and how you calibrate the whole thing. Either your modes/ramp have lower PWM values which get increased by regulation or they have the higher PWM values which get decreased by regulation.

True, I was just thinking it is less work to add PWM to modes as the voltage drops since the modes would largely remain the same as they are now except for turbo (well technically it would as well, since you already need to lower turbo in the low Vf lights).

By subtracting it, you have to start all over on the modes and mode spacing. Not impossible if this proves to be the more effective and smallest option, just more work. It also means you are committed to the regulation being active at all times as the modes will be wrong without it.

EDIT: Actually I did just realize a possible issue with this option, using this method you will run into issues where a mid range mode will reach 255pwm before the subtraction and thus not allow any more resolution, so all the midrange modes would basically be the same as turbo? Or am I missing something?

Texas_Ace
Texas_Ace's picture
Offline
Last seen: 1 week 3 days ago
Joined: 03/24/2016 - 07:44
Posts: 9036
Location: Everything is brighter in Texas
fixed it wrote:
Ah sorry, I thought the op-amp was used to amplify a sense resistor or something similar. It sounds like it’s instead used as a better 7135. I don’t know much about op-amps so I’ll leave it at that and wait until the whole thing is released. I wish I had free time to design my own driver, it certainly seems fun.

We thought about going a lot more advanced with the setup, such as controlling the FET directly with the Attiny through a DAC to give full control and reduce components / cost. This would take completely new firmware though and quite advanced firmware at that. I didn’t see this as a viable option at this point so opted for the simpler option that would work with a tweaked bistro/narsil.

I will release the driver once it is ready for the public eye, it still has some work to tweak to get the design finalized. It has been a royal pain trying to keep the components 0603, if it was machine made it could be made with 0402 or 0201 and be way nicer. I think it would also be able to fit a tiny85 in that case.

LightRider
LightRider's picture
Offline
Last seen: 3 years 9 hours ago
Joined: 08/05/2015 - 09:52
Posts: 2007
Location: U.P. MI, USA

Sorry this is a bit off the current topic but Ive got an “im in the middle of modding something” question.

Is it common for Narsil (Narsil triple) to run on 4.6mA of standby current? If not, anyone know what I might have done incorrectly? I’m using 220k and 47k dividers.

Texas_Ace
Texas_Ace's picture
Offline
Last seen: 1 week 3 days ago
Joined: 03/24/2016 - 07:44
Posts: 9036
Location: Everything is brighter in Texas

Which driver are you using?

LightRider
LightRider's picture
Offline
Last seen: 3 years 9 hours ago
Joined: 08/05/2015 - 09:52
Posts: 2007
Location: U.P. MI, USA
Texas_Ace wrote:
Which driver are you using?

I’m using the ta17 all three channels.

Edit
This is unexpectedly high correct?

fixed it
Offline
Last seen: 1 year 3 months ago
Joined: 12/08/2015 - 14:27
Posts: 396
Location: Canada

Texas_Ace wrote:
True, I was just thinking it is less work to add PWM to modes as the voltage drops since the modes would largely remain the same as they are now except for turbo (well technically it would as well, since you already need to lower turbo in the low Vf lights).

By subtracting it, you have to start all over on the modes and mode spacing. Not impossible if this proves to be the more effective and smallest option, just more work. It also means you are committed to the regulation being active at all times as the modes will be wrong without it.

EDIT: Actually I did just realize a possible issue with this option, using this method you will run into issues where a mid range mode will reach 255pwm before the subtraction and thus not allow any more resolution, so all the midrange modes would basically be the same as turbo? Or am I missing something?


I’m not sure I follow you there. From what I understand, most firmware already has modes which use the full PWM range up to 255. My code will require no change there. It simply tries to make the light behave the same above eg. 3.8V. So unless you’re unhappy with the current behavior on a partially drained cell, there is no need to change the modes.

I imagine it might be the case that most modes/ramps were tuned for full cells and might not be quite as nice with partially empty ones… but I really don’t know. Then again, they were probably tuned for LEDs with higher Vf which did not need scaling back at high Vcc so this might all cancel out. It’s hard to say how much change will be needed to the modes without trying it in an actual light. And no two people seem to want the same modes anyway Smile

About your edit: the only range issue is that the highest power settings at the highest voltage are unavailable. But that’s the whole point of it, I think. Of course you could still make an exception for turbo, if you mean to cook an egg or something.

fixed it
Offline
Last seen: 1 year 3 months ago
Joined: 12/08/2015 - 14:27
Posts: 396
Location: Canada

Texas_Ace wrote:
We thought about going a lot more advanced with the setup, such as controlling the FET directly with the Attiny through a DAC to give full control and reduce components / cost. This would take completely new firmware though and quite advanced firmware at that. I didn’t see this as a viable option at this point so opted for the simpler option that would work with a tweaked bistro/narsil.
Yeah, I did roughly that but without the DAC, instead using the pull-up resistor + careful timing as a poor man’s DAC. It took a long long time. It’s not realistic to adapt existing firmware to that kind of system so it was probably a good choice to pick what you did.

It’s an interesting long term project though and I’m still wondering if the two PWM channels could be combined into a basic, highly accurate DAC for this purpose. Someday I’ll find out.

Texas_Ace
Texas_Ace's picture
Offline
Last seen: 1 week 3 days ago
Joined: 03/24/2016 - 07:44
Posts: 9036
Location: Everything is brighter in Texas
LightRider wrote:
Texas_Ace wrote:
Which driver are you using?

I’m using the ta17 all three channels.

Edit
This is unexpectedly high correct?

Does it have the zener installed?

Yeah, it should be a lot less then that. What about the bleeder resistor, is that installed?

LightRider
LightRider's picture
Offline
Last seen: 3 years 9 hours ago
Joined: 08/05/2015 - 09:52
Posts: 2007
Location: U.P. MI, USA

No zener no bleed resistor

LightRider
LightRider's picture
Offline
Last seen: 3 years 9 hours ago
Joined: 08/05/2015 - 09:52
Posts: 2007
Location: U.P. MI, USA

Not a great photo but this is the driver

Texas_Ace
Texas_Ace's picture
Offline
Last seen: 1 week 3 days ago
Joined: 03/24/2016 - 07:44
Posts: 9036
Location: Everything is brighter in Texas

fixed it wrote:
I’m not sure I follow you there. From what I understand, most firmware already has modes which use the full PWM range up to 255. My code will require no change there. It simply tries to make the light behave the same above eg. 3.8V. So unless you’re unhappy with the current behavior on a partially drained cell, there is no need to change the modes.

I imagine it might be the case that most modes/ramps were tuned for full cells and might not be quite as nice with partially empty ones… but I really don’t know. Then again, they were probably tuned for LEDs with higher Vf which did not need scaling back at high Vcc so this might all cancel out. It’s hard to say how much change will be needed to the modes without trying it in an actual light. And no two people seem to want the same modes anyway Smile

About your edit: the only range issue is that the highest power settings at the highest voltage are unavailable. But that’s the whole point of it, I think. Of course you could still make an exception for turbo, if you mean to cook an egg or something.

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.

Texas_Ace
Texas_Ace's picture
Offline
Last seen: 1 week 3 days ago
Joined: 03/24/2016 - 07:44
Posts: 9036
Location: Everything is brighter in Texas
LightRider wrote:
Not a great photo but this is the driver

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.

Texas_Ace
Texas_Ace's picture
Offline
Last seen: 1 week 3 days ago
Joined: 03/24/2016 - 07:44
Posts: 9036
Location: Everything is brighter in Texas

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.

LightRider
LightRider's picture
Offline
Last seen: 3 years 9 hours ago
Joined: 08/05/2015 - 09:52
Posts: 2007
Location: U.P. MI, USA
Texas_Ace wrote:
LightRider wrote:
Not a great photo but this is the driver

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.

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?

LightRider
LightRider's picture
Offline
Last seen: 3 years 9 hours ago
Joined: 08/05/2015 - 09:52
Posts: 2007
Location: U.P. MI, USA
Texas_Ace wrote:
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.

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.

LightRider
LightRider's picture
Offline
Last seen: 3 years 9 hours ago
Joined: 08/05/2015 - 09:52
Posts: 2007
Location: U.P. MI, USA
Texas_Ace wrote:
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.

I’ve sent tom a number of messages over the last couple weeks and have not received a response so?

Texas_Ace
Texas_Ace's picture
Offline
Last seen: 1 week 3 days ago
Joined: 03/24/2016 - 07:44
Posts: 9036
Location: Everything is brighter in Texas

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.

Texas_Ace
Texas_Ace's picture
Offline
Last seen: 1 week 3 days ago
Joined: 03/24/2016 - 07:44
Posts: 9036
Location: Everything is brighter in Texas
LightRider wrote:
Texas_Ace wrote:
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.

I’ve sent tom a number of messages over the last couple weeks and have not received a response so?

He has been super busy lately and his computer went down IIRC. So who knows when he will get back on here.

Pages