Attiny25/45/85 FW Development Thread

1922 posts / 0 new
Last post
LightRider
LightRider's picture
Offline
Last seen: 3 years 2 days ago
Joined: 08/05/2015 - 09:52
Posts: 2007
Location: U.P. MI, USA

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?

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

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

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?

Texas_Ace
Texas_Ace's picture
Offline
Last seen: 6 hours 49 min ago
Joined: 03/24/2016 - 07:44
Posts: 9036
Location: Everything is brighter in Texas

LightRider wrote:
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.

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

Texas_Ace wrote:
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.
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.
Texas_Ace
Texas_Ace's picture
Offline
Last seen: 6 hours 49 min ago
Joined: 03/24/2016 - 07:44
Posts: 9036
Location: Everything is brighter in Texas
fixed it wrote:
Texas_Ace wrote:
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.
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.

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

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.

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

Texas_Ace wrote:
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.

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.

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

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.

 

Texas_Ace
Texas_Ace's picture
Offline
Last seen: 6 hours 49 min ago
Joined: 03/24/2016 - 07:44
Posts: 9036
Location: Everything is brighter in Texas

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.

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

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.

 

 

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

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.

Texas_Ace
Texas_Ace's picture
Offline
Last seen: 6 hours 49 min ago
Joined: 03/24/2016 - 07:44
Posts: 9036
Location: Everything is brighter in Texas
Flintrock wrote:

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.


 


 

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.

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

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 Facepalm 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. Facepalm Facepalm Facepalm

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.
Texas_Ace
Texas_Ace's picture
Offline
Last seen: 6 hours 49 min ago
Joined: 03/24/2016 - 07:44
Posts: 9036
Location: Everything is brighter in Texas

Yep, you are correct, it dropped down to 16ua after about 10 seconds.

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

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

Texas_Ace
Texas_Ace's picture
Offline
Last seen: 6 hours 49 min ago
Joined: 03/24/2016 - 07:44
Posts: 9036
Location: Everything is brighter in Texas

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. Sick

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

 

 

[/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).   

 

 

 

 

 

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

 Anyway, I'm really not that worried about that, was just trying to point out several nuiances that matter but the two adc setups is a bigger one to watch out for.

 

What I care more right now, is does anyone know what happens to the RAM on these things when they're unpowered?  Does it decay to all zeros?  To all ones?  Or to something random?  If it's either of the first two, I can take advatage of it.  If it's the last, I probably better switch to eeprom.  Mostly I don't actually need memory rentention during power off.  I just need retention when restarting the program using a variable that won't get reinitialized.  But I have no way to tell the difference between a restart and a cold start other than this variable, and in the cold start the uninitialized variable would be corrupt.  I'll probably just switch to eeprom.  I'm not sure this wear levelling is really needed anyway.  Is anyone planning to change modes on their light 100,000 times?  I might be able to find a way to squeeze it into the mode save wear levelling as the second byte in the train.  It needs a few bytes of code though and, well, I have a  few left.

 

hmm.. another way to do this is to turn main into a subroutine fake_main, and have real main just call it.   The global variable are initialized in main, but I jump to fake_main to bypass initialization.  I'd have to figure out how to reliable get the jump address for fake_main.  It shouldn't be a function call because I'm inside an interrupt (or two) and want to clear the stack. Hmm maybe I could just clear the stack at the start of fake main.  Very hackish, but it's all a bit hackish.

 

 

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

My friend, you are arguing in a circle. The different channels share the load however all 7135s + %1 of the fet is still brighter(unmeasurable but…) than all 7135s on there own. Whatever percent load you add from the fet will cause some voltage sag, but the 7135s don’t care, they dump off extra voltage anyway. Less voltage to dump off even makes them more effitient. Correct? I should keep quiet cause you are much smarter than I. So just take my comments as trying to help.

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

It doesn't matter because in the end you're going to adjust the correction factor from experience.  There are just things easier about doing it one way, and other things a little easier about the other.  As far as the 1% difference in having both channels, both ways reach that at 100%.

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

fixed it wrote:
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.

 

This is all right.  A line is a line is a line.  ONe just has to figure out how to do it in the fewest bytes, make it most comfortable for mode definitions, and avoid things like overflow errors.  Starting from the bottom (which is also what I did) has a physical significance because the bottom battery voltage is the real equivilent vf you're  targetting.  Starting from the bottom does make overflow a little easier too.  If your slopes are right nothing should ever PWM to zero (because that's just the all7135 mode and you should have just been using that anyway then).  However starting from the top the math will try to produce more than 100% at some point as your voltage drops too low and you'll have to catch the overflow in the calculation, or just know where the bottom is and put a conditional to catch it.  But once you know where to put that, you've already found the bottom anyway.  No matter what, you need to know  where the bottom is.  And might as well approach it with that idea so you can just get to it and figure out if your battery even has enough juice to hit the mode.  

That's why I just went ahead and defined modes by bottom voltage. You can still use a ramp table like we have.  You'll just have to calculate the bottom voltage from there.

Texas_Ace
Texas_Ace's picture
Offline
Last seen: 6 hours 49 min ago
Joined: 03/24/2016 - 07:44
Posts: 9036
Location: Everything is brighter in Texas

While you are correct in your technical thinking, I am a much more practical guy. If all the 7135’s are on, the total current through the light with any PWM to the FET will be higher then the combined 7135’s. Will the efficiency be effected some? Sure but it will still have more current and be brighter with any added FET PWM on top of the 7135’s.

The tiny amount of technical variance that you are describing will not even remotely be noticeable to the human eye, as such I am not worried about it.

This setup will not be anything close to perfect anyways, the idea is to simply improve things better then they are now and see how it plays out. What we learn from this can be applied to a future tiny85 version of the firmware where it can be expanded to take into account the tiny things you are mentioning bringing up.

At least that is how I see it.

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

Wow, what I'm finding is this ram lasts an enormously long time with 10uF cap in place.  So far it's remembered for about 3 or for minutes.  Haven't tested longer.  Anyone interested in a memory mode that remembers for say half an hour but eventually resets to default?  That would actually fit my usages.  Would have to tackle this eventual corruption issue though.  Maybe set  four or 5 bytes to 170 (10101010) and check all 5 to verify non corrupt state.  It's an idea for my restart problem too though.

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

Texas_Ace wrote:
While you are correct in your technical thinking, I am a much more practical guy. If all the 7135's are on, the total current through the light with any PWM to the FET will be higher then the combined 7135's. Will the efficiency be effected some? Sure but it will still have more current and be brighter with any added FET PWM on top of the 7135's. The tiny amount of technical variance that you are describing will not even remotely be noticeable to the human eye, as such I am not worried about it. This setup will not be anything close to perfect anyways, the idea is to simply improve things better then they are now and see how it plays out. What we learn from this can be applied to a future tiny85 version of the firmware where it can be expanded to take into account the tiny things you are mentioning bringing up. At least that is how I see it.

 

I'm not worried about any tiny technical variance.  It will quite drastically impact the correct slope to use.  But anyway, the slope will get set by testing.  The difference in those slopes affects how easily you cna define regulation modes for all levels vs just the top ones.  And more importantly to you, it means that determination depends on how many 7135s you have. That's all.  The variation from whatever wrongly shaped line we use probably isn't a big deal since it will be wrongly shaped regardless.

 

Bottom line, you're going to need different calibration constants for different numbers of 7135s, especially switching between tripple's and FET+1's.  That's a huge effect, not tiny.  If you PWM it all together there's less impact from that and you'll get regulated modes that work pretty well on all drivers.  The flip side though is your mode orders might get out of whack when switching drivers.  So either way, you need some setting changes.  Just different ways to skin the cat.

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

Yeah, I just got 20 minutes of RAM memory.  Of course in reality there will be 40uF not 10 but the power will get run down to 1.8V or so by OTSM.  so who knows how long it will last if at all.  It has to just accidentally work out to 20 to 60 minutes probably to be useful.  For temporary memory less or more isn't useful. It's like OTC all over again, on longer scales. Will depend on every resistor in the driver.  Too much nuisance.

 

Of course I'm being abusive with this program restart.  Nobody encourages programming this way.  The kosher way to do things is to set flags and unroll out of the (nested) interrupts back into the main program.  Then I'd need to add checks to short circuit the delay functions to bypass all the strobbing and menus and whatever going on, and then break out of the loop at the end and restart initialization from there, keeping the variables I want.  It's still a possibility but I don't like it.  There are many places where variables between user click and true restart will get messed with where they just weren't designed to be messed with because a full reset was anticipated.  It requires really rethinking the whole program, so I continue with the hacks.

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

RAM corruption test.

 

So I got my answer on this particular byte of ram in this chip.  If loaded with 10101010 it always corrupts to 00011001  or 25 after shorting the caps (no, not 255).   Slightly surprising that it's stable, but still mostly useless.  I don't like betting that the byte I care about isn't the first one to get a bad bit either, so checking other bytes for corruption probably isn't a solution.  It will have to be one of the other three solutions to carry data back to the start (post init jump, eeprom, or interrupt unrolling).

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

Now that I'm staring at assymbly more anyway, I'm a bit less ethusiastic. Below is a do-nothing interrupt handler (intentionally does nothing), in C it was empty:

 

 

ISR(WDT_vect){
00000197 PUSH R1 Push register on stack
00000198 PUSH R0 Push register on stack
00000199 IN R0,0x3F In from I/O location
0000019A PUSH R0 Push register on stack
0000019B CLR R1 Clear Register
0000019C POP R0 Pop register from stack
0000019D OUT 0x3F,R0 Out to I/O location
0000019E POP R0 Pop register from stack
0000019F POP R1 Pop register from stack
000001A0 RETI Interrupt return

 

Well, yes, that does absolutely nothing, except move some bytes there and here, and back there again.  It seems like probably standard ISR setup to save things (working registers and status register) to stack and clear register (R1 anyway) so you can do something, and then pull the stuff back off the stack again at the end to put it back as it was.  But I'd kind of think since nothing is being done, it should be kind of smart enough to actually do nothing. It sure seems to me like the only instruction needed here is "RETI".   Looks to me like a bit of inline assymbly could save some more bytes.  I wasn't really looking for this.  Just ran into it trying to understand something.

 

Ahh, more details here:

http://www.avrfreaks.net/forum/why-code-empty-interrupt-routine

The first answer isn't helpful at all but it gets better.

 

 

Texas_Ace
Texas_Ace's picture
Offline
Last seen: 6 hours 49 min ago
Joined: 03/24/2016 - 07:44
Posts: 9036
Location: Everything is brighter in Texas
Flintrock wrote:


 


I’m not worried about any tiny technical variance.  It will quite drastically impact the correct slope to use.  But anyway, the slope will get set by testing.  The difference in those slopes affects how easily you cna define regulation modes for all levels vs just the top ones.  And more importantly to you, it means that determination depends on how many 7135s you have. That’s all.  The variation from whatever wrongly shaped line we use probably isn’t a big deal since it will be wrongly shaped regardless.


 


Bottom line, you’re going to need different calibration constants for different numbers of 7135s, especially switching between tripple’s and FET+1’s.  That’s a huge effect, not tiny.  If you PWM it all together there’s less impact from that and you’ll get regulated modes that work pretty well on all drivers.  The flip side though is your mode orders might get out of whack when switching drivers.  So either way, you need some setting changes.  Just different ways to skin the cat.

I am looking at things from the big picture, what you actually see with your eyes point of view.

From this point of view it is a tiny effect that will be all but unnoticeable to the human eye. In fact I would venture to say it would be totally unnoticeable as any mode that would use software regulation would be after the 7135’s are already on and at that point the human eye just can’t make out rather large differences in output.

When the difference from the 7135’s to turbo is ~800 lumens to ~1100 lumens and you have to got back and forth a few times to make sure turbo was actually working, I am simply not worried about something that would make a fraction of that amount of difference in output.

As far as needing septate calibrations for different numbers of 7135’s, I actually kind of doubt this will be the case, I don’t change the firmware at all for the different 7135’s levels I use right now. at least not for a change of 1-2 7135’s. The 22mm drivers have 9 of them and the 17mm have 7. Both work perfectly fine with the default firmware needing no changes. The LED used plays the much larger role from my experience.

Now triples might need a different table but even this I think will work fine with the same basic slope, sure it will not work the same but once you get into triple lumen levels even larger differences in output are unnoticeable to the human eye. 3000 vs 3800 lumens in a triple is hardly noticeable if the beam profile is the same.

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

Yeah, 7 vs 9 won't be a big deal.  4 vs 9 though, yeah, maybe.  1 vs 9 certainly.  Anyway,  perception and usefulness are not the same thing.  More light is more useful, especially in traffic.

Pages