More Arc5 information.. (proto photos inside)
- Thread starter Gransee
- Start date
Help Support Candle Power Flashlight Forum
- Status
Willmore
Enlightened
What a bunch of pansies! The code *is* the documentation. If you cannot read the documentation than you are not a programmer. Making the documentation separate from the code just provides one more place for errors to creep in.
Let me disspell this silly 'maintainable' nonsense right here. Embedded code does not need to be 'maintainable'. Embedded products--and not just misuses of the term--are very highly optimized to their environment. For large scale manufacturing, every penny counts. For portable applications, every mA or uA counts. Every fraction of a gram *counts*. Every additional feature Peter can stuff into a light means more lights sold and happier customers.
There is a tradeoff in effort vs functionality. Generally with increasing effort, you get increased functionality. It's not a linear relationship and gets much less so the further along the curve you go. So, yes, most projects only go for the 'low hanging fruit'. Most programmers have never worked on projects that went beyond that. And in that market, sure, code will migrate from generation to generation of 'product'.
In embedded design, the lifecycle is much different. Each product is much more highly optimized. One generation to the next may bear almost no resemblance. Complete designs are thrown away and new ones adopted--because the parts available and their cost (in money, power, size) have changed.
Peter, please keep up the good work and continue your migration to assembler. It sounds like you actually have a good programmer there, congratulations.
Let me disspell this silly 'maintainable' nonsense right here. Embedded code does not need to be 'maintainable'. Embedded products--and not just misuses of the term--are very highly optimized to their environment. For large scale manufacturing, every penny counts. For portable applications, every mA or uA counts. Every fraction of a gram *counts*. Every additional feature Peter can stuff into a light means more lights sold and happier customers.
There is a tradeoff in effort vs functionality. Generally with increasing effort, you get increased functionality. It's not a linear relationship and gets much less so the further along the curve you go. So, yes, most projects only go for the 'low hanging fruit'. Most programmers have never worked on projects that went beyond that. And in that market, sure, code will migrate from generation to generation of 'product'.
In embedded design, the lifecycle is much different. Each product is much more highly optimized. One generation to the next may bear almost no resemblance. Complete designs are thrown away and new ones adopted--because the parts available and their cost (in money, power, size) have changed.
Peter, please keep up the good work and continue your migration to assembler. It sounds like you actually have a good programmer there, congratulations.
mattheww50
Flashlight Enthusiast
Let me state for the record that imbedded CODE DOES NEET TO BE MAINTAINED. I have never known a case where the code as originally shipped was completely error free. Let you give you one particularly unpleasant example that actually happened. I suggest you read about how errors that were not at all obvious killed people. This is still considered one of the case studies on the need for software testing, and maintenance.
http://courses.cs.vt.edu/~cs3604/lib/Therac_25/Therac_1.html
http://courses.cs.vt.edu/~cs3604/lib/Therac_25/Therac_1.html
coccolithophorid
Newly Enlightened
Next gen tint control...what the?
gransee wrote (in the first post way up there):
- Next gen tint control reduces shift across power range
could someone explain this?
Thanks,
Kevin /ubbthreads/images/graemlins/thinking.gif
gransee wrote (in the first post way up there):
- Next gen tint control reduces shift across power range
could someone explain this?
Thanks,
Kevin /ubbthreads/images/graemlins/thinking.gif
Re: Next gen tint control...what the?
> What a bunch of pansies! The code *is* the documentation.
Your attitude causes tremendous problems for others - both coders who take over your projects and employers who have to eat the expense of supporting your "self-documenting" code.
Coders who are lazy, arrogant, or careless don't document their code. Experienced coders document as a matter of course, and experienced employers insist that they do so.
>If you cannot read the documentation than you are not a programmer.
It's not an issue of "reading the documentation" (ie, understanding your code); any decent coder can do that, given time. The greater the complexity of the project - and the lower the level of the coding language used - the more time required to get up to speed with someone else's codebase. This time will cost your employer money - potentially lots of it. This is especially critical to a small company like Arc.
Completely rewriting the codebase with each product revision sounds completely insane to me. Not only do you lose the opportunity to refine and extend your code incrementally, you incur tremendous redevelopment expense with each product revision.
> What a bunch of pansies! The code *is* the documentation.
Your attitude causes tremendous problems for others - both coders who take over your projects and employers who have to eat the expense of supporting your "self-documenting" code.
Coders who are lazy, arrogant, or careless don't document their code. Experienced coders document as a matter of course, and experienced employers insist that they do so.
>If you cannot read the documentation than you are not a programmer.
It's not an issue of "reading the documentation" (ie, understanding your code); any decent coder can do that, given time. The greater the complexity of the project - and the lower the level of the coding language used - the more time required to get up to speed with someone else's codebase. This time will cost your employer money - potentially lots of it. This is especially critical to a small company like Arc.
Completely rewriting the codebase with each product revision sounds completely insane to me. Not only do you lose the opportunity to refine and extend your code incrementally, you incur tremendous redevelopment expense with each product revision.
Gransee
Flashlight Enthusiast
Re: Next gen tint control...what the?
[ QUOTE ]
coccolithophorid said:
gransee wrote (in the first post way up there):
- Next gen tint control reduces shift across power range
could someone explain this?
Thanks,
Kevin /ubbthreads/images/graemlins/thinking.gif
[/ QUOTE ]
Hello Kevin. I will give it a shot.. /ubbthreads/images/graemlins/smile.gif
LEDs shift their tint as the power input and tempurature changes. This can be managed by a microprocessor to minimize the amount of shift for a given output.
This was one of the reasons to make the Arc4 "smart".
Peter
[ QUOTE ]
coccolithophorid said:
gransee wrote (in the first post way up there):
- Next gen tint control reduces shift across power range
could someone explain this?
Thanks,
Kevin /ubbthreads/images/graemlins/thinking.gif
[/ QUOTE ]
Hello Kevin. I will give it a shot.. /ubbthreads/images/graemlins/smile.gif
LEDs shift their tint as the power input and tempurature changes. This can be managed by a microprocessor to minimize the amount of shift for a given output.
This was one of the reasons to make the Arc4 "smart".
Peter
James S
Flashlight Enthusiast
Re: Next gen tint control...what the?
[ QUOTE ]
> What a bunch of pansies! The code *is* the documentation.
Your attitude causes tremendous problems for others - both coders who take over your projects and employers who have to eat the expense of supporting your "self-documenting" code.
[/ QUOTE ]
Don't worry, someday he'll have to work on some of his own code that is old enough that he won't remember it /ubbthreads/images/graemlins/smile.gif
I've fired people for trying to convince me of that kind of garbage.
self documenting code indeed /ubbthreads/images/graemlins/grin.gif I want a list of companies that use self documenting code so that I can enter their market and when their revisions in the future get further and further apart and more and more expensive I can steal their market out from under them...
[ QUOTE ]
> What a bunch of pansies! The code *is* the documentation.
Your attitude causes tremendous problems for others - both coders who take over your projects and employers who have to eat the expense of supporting your "self-documenting" code.
[/ QUOTE ]
Don't worry, someday he'll have to work on some of his own code that is old enough that he won't remember it /ubbthreads/images/graemlins/smile.gif
I've fired people for trying to convince me of that kind of garbage.
self documenting code indeed /ubbthreads/images/graemlins/grin.gif I want a list of companies that use self documenting code so that I can enter their market and when their revisions in the future get further and further apart and more and more expensive I can steal their market out from under them...
Willmore
Enlightened
Re: Next gen tint control...what the?
> Your attitude causes tremendous problems for others - both
> coders who take over your projects and employers who have
> to eat the expense of supporting your "self-documenting"
> code.
There are some kind of code that need certain degrees of documenting and there others that don't. Clearly you're talking about the former and that is not the class of software that is often used in embedded designs. Yes, I've worked on huge projects with hundreds of programmers where documentation took three or more times as much effort to write and maintain than the actual code did. In some environments that makes sense--such as when the code will survive as part of a long term project or when the documentation will be used by other developers in the future.
The situation to which I refer is where an embedded device is effectively 'one off'. In that case documentation is a complete waste of time as it *will not be used*.
> Coders who are lazy, arrogant, or careless don't document
> their code. Experienced coders document as a matter of
> course, and experienced employers insist that they do so.
In your experience, it seems. Not in mine.
> >If you cannot read the documentation than you are not a programmer.
> It's not an issue of "reading the documentation" (ie,
> understanding your code); any decent coder can do that,
> given time. The greater the complexity of the project -
> and the lower the level of the coding language used - the
> more time required to get up to speed with someone else's
> codebase. This time will cost your employer money -
> potentially lots of it. This is especially critical to a
> small company like Arc.
Since we're talking about one coder who needs to be very experienced with the platform in question, who are we writing the documentation for? Why should a progammer spend time and effort to write and *maintain* a document which will go unread? The cost of documentation is generally several times the cost of writing the associated code. Small companies, like Arc, cannot affort to waste money and time like that.
> Completely rewriting the codebase with each product
> revision sounds completely insane to me. Not only do you
> lose the opportunity to refine and extend your code
> incrementally, you incur tremendous redevelopment expense > with each product revision.
Maybe you're not familiar with the amount of testing that takes place for consumer or industrial devices? You don't get to skip testing just because you're working on an 'extended' code base vs a new one.
Code reuse is helpful in projects where you have generic components to deal with--PCs, etc. In embedded applications, the code, to be efficient, is so specific to the devices in question that 'reuse' simply cannot happen in any signifigant sense.
The cost of developing highly documented code is several times that of non-documented code. Unless you reuse the code enough to justify the documenting effort, why do it?
The processor used on a previous generation may not exist as a cost effective or functional choice for a new project. The peripherials may be designed completely differently.
There is a time an a place for highly documented code that is designed for reuse, but embedded application of this nature certainly one of them.
Beware of any employer who doesn't understand the realities of their situation and requires you to develop as if you are in a different situation for they won't be competetive and may not be in business very long.
> Your attitude causes tremendous problems for others - both
> coders who take over your projects and employers who have
> to eat the expense of supporting your "self-documenting"
> code.
There are some kind of code that need certain degrees of documenting and there others that don't. Clearly you're talking about the former and that is not the class of software that is often used in embedded designs. Yes, I've worked on huge projects with hundreds of programmers where documentation took three or more times as much effort to write and maintain than the actual code did. In some environments that makes sense--such as when the code will survive as part of a long term project or when the documentation will be used by other developers in the future.
The situation to which I refer is where an embedded device is effectively 'one off'. In that case documentation is a complete waste of time as it *will not be used*.
> Coders who are lazy, arrogant, or careless don't document
> their code. Experienced coders document as a matter of
> course, and experienced employers insist that they do so.
In your experience, it seems. Not in mine.
> >If you cannot read the documentation than you are not a programmer.
> It's not an issue of "reading the documentation" (ie,
> understanding your code); any decent coder can do that,
> given time. The greater the complexity of the project -
> and the lower the level of the coding language used - the
> more time required to get up to speed with someone else's
> codebase. This time will cost your employer money -
> potentially lots of it. This is especially critical to a
> small company like Arc.
Since we're talking about one coder who needs to be very experienced with the platform in question, who are we writing the documentation for? Why should a progammer spend time and effort to write and *maintain* a document which will go unread? The cost of documentation is generally several times the cost of writing the associated code. Small companies, like Arc, cannot affort to waste money and time like that.
> Completely rewriting the codebase with each product
> revision sounds completely insane to me. Not only do you
> lose the opportunity to refine and extend your code
> incrementally, you incur tremendous redevelopment expense > with each product revision.
Maybe you're not familiar with the amount of testing that takes place for consumer or industrial devices? You don't get to skip testing just because you're working on an 'extended' code base vs a new one.
Code reuse is helpful in projects where you have generic components to deal with--PCs, etc. In embedded applications, the code, to be efficient, is so specific to the devices in question that 'reuse' simply cannot happen in any signifigant sense.
The cost of developing highly documented code is several times that of non-documented code. Unless you reuse the code enough to justify the documenting effort, why do it?
The processor used on a previous generation may not exist as a cost effective or functional choice for a new project. The peripherials may be designed completely differently.
There is a time an a place for highly documented code that is designed for reuse, but embedded application of this nature certainly one of them.
Beware of any employer who doesn't understand the realities of their situation and requires you to develop as if you are in a different situation for they won't be competetive and may not be in business very long.
Willmore
Enlightened
Re: Next gen tint control...what the?
[ QUOTE ]
James S said:
Don't worry, someday he'll have to work on some of his own code that is old enough that he won't remember it /ubbthreads/images/graemlins/smile.gif
[/ QUOTE ]
Worse yet, I've worked on other peoples code that they don't remember. I've never really found that to be a problem. Code is, by itself, a language. If you speak that language, why would you need a 'phrase book'? I'll point out, that the most common sort of error is the 'programming the comments' type wherein one reads the comments to understand what the code does, but they do not check it against the actual code.
[ QUOTE ]
I've fired people for trying to convince me of that kind of garbage.
[/ QUOTE ]
And I've quit jobs for trying to use inappropriate development practices. But I didn't call them garbage.
[ QUOTE ]
self documenting code indeed /ubbthreads/images/graemlins/grin.gif I want a list of companies that use self documenting code so that I can enter their market and when their revisions in the future get further and further apart and more and more expensive I can steal their market out from under them...
[/ QUOTE ]
See, this is exatly the kind of junk that one can expect from people who believe that documents will make them invulnerable and superpowerful. Rubbish. The companies that you postulate will not produce generations of product further and further appart as their development costs will not skyrocket with complexity as does the highly documented variety.
The 'documentation is god' school comes in favor when large expansions in the industry happen. There are the times when there is a large demand for developers and every effort is made to make a development environment that can accept developers of all skill levels. It's the 'millions of monkeys and millions of typewriters' school of code development. It's slow and horribly costly. But, sometimes you have no choice as all you have are monkeys. On the plus side, there seems to be a large supply of monkeys, but a limited number of good coders.
[ QUOTE ]
James S said:
Don't worry, someday he'll have to work on some of his own code that is old enough that he won't remember it /ubbthreads/images/graemlins/smile.gif
[/ QUOTE ]
Worse yet, I've worked on other peoples code that they don't remember. I've never really found that to be a problem. Code is, by itself, a language. If you speak that language, why would you need a 'phrase book'? I'll point out, that the most common sort of error is the 'programming the comments' type wherein one reads the comments to understand what the code does, but they do not check it against the actual code.
[ QUOTE ]
I've fired people for trying to convince me of that kind of garbage.
[/ QUOTE ]
And I've quit jobs for trying to use inappropriate development practices. But I didn't call them garbage.
[ QUOTE ]
self documenting code indeed /ubbthreads/images/graemlins/grin.gif I want a list of companies that use self documenting code so that I can enter their market and when their revisions in the future get further and further apart and more and more expensive I can steal their market out from under them...
[/ QUOTE ]
See, this is exatly the kind of junk that one can expect from people who believe that documents will make them invulnerable and superpowerful. Rubbish. The companies that you postulate will not produce generations of product further and further appart as their development costs will not skyrocket with complexity as does the highly documented variety.
The 'documentation is god' school comes in favor when large expansions in the industry happen. There are the times when there is a large demand for developers and every effort is made to make a development environment that can accept developers of all skill levels. It's the 'millions of monkeys and millions of typewriters' school of code development. It's slow and horribly costly. But, sometimes you have no choice as all you have are monkeys. On the plus side, there seems to be a large supply of monkeys, but a limited number of good coders.
PeLu
Flashlight Enthusiast
Re: Next gen tint control...what the?
[ QUOTE ]
Wilmore said:What a bunch of pansies! The code *is* the documentation.
[/ QUOTE ]
[ QUOTE ]
Don't worry, someday he'll have to work on some of his own code that is old enough that he won't remember it /ubbthreads/images/graemlins/smile.gif
I've fired people for trying to convince me of that kind of garbage.
[/ QUOTE ]
Me, too, unfortunately always fired them too late. And there arguments were pretty the same ones as Wilmore's above .-)
Anyway, I rather want to know about the tint control:
[ QUOTE ]
coccolithophorid said:
- Next gen tint control reduces shift across power range
[/ QUOTE ]
[ QUOTE ]
Gransee said:
LEDs shift their tint as the power input and tempurature changes. This can be managed by a microprocessor to minimize the amount of shift for a given output.
[/ QUOTE ]
As much as I understood it, this is exactly what the Arc4 does now. So what will be different with the next generation (not how it is done, which you will not tell us anyway)?
[ QUOTE ]
Wilmore said:What a bunch of pansies! The code *is* the documentation.
[/ QUOTE ]
[ QUOTE ]
Don't worry, someday he'll have to work on some of his own code that is old enough that he won't remember it /ubbthreads/images/graemlins/smile.gif
I've fired people for trying to convince me of that kind of garbage.
[/ QUOTE ]
Me, too, unfortunately always fired them too late. And there arguments were pretty the same ones as Wilmore's above .-)
Anyway, I rather want to know about the tint control:
[ QUOTE ]
coccolithophorid said:
- Next gen tint control reduces shift across power range
[/ QUOTE ]
[ QUOTE ]
Gransee said:
LEDs shift their tint as the power input and tempurature changes. This can be managed by a microprocessor to minimize the amount of shift for a given output.
[/ QUOTE ]
As much as I understood it, this is exactly what the Arc4 does now. So what will be different with the next generation (not how it is done, which you will not tell us anyway)?
NewBie
*Retired*
Re: Next gen tint control...what the?
Hitting the LED die with higher current pulses (but shorter) causes the light output to shift a few nanometers, for starters... There is also the play between the light output of the die and the light output of the phosphor.
Hitting the LED die with higher current pulses (but shorter) causes the light output to shift a few nanometers, for starters... There is also the play between the light output of the die and the light output of the phosphor.
Willmore
Enlightened
Re: Next gen tint control...what the?
That and the phosphor is not linear under high flux conditions, so the red/yellow/green output shifts vs the blue output with changing current.
So, if the peak current is held constant, the tint will hold constant as well. Brightness is varied by varying the width of the current pulse.
That and the phosphor is not linear under high flux conditions, so the red/yellow/green output shifts vs the blue output with changing current.
So, if the peak current is held constant, the tint will hold constant as well. Brightness is varied by varying the width of the current pulse.
PeLu
Flashlight Enthusiast
Re: Next gen tint control...what the?
Actually I was not so interested about how to do it, more what will be different in the next generation for the end user?
Actually I was not so interested about how to do it, more what will be different in the next generation for the end user?
NewBie
*Retired*
Re: Next gen tint control...what the?
[ QUOTE ]
PeLu said:
Actually I was not so interested about how to do it, more what will be different in the next generation for the end user?
[/ QUOTE ]
Oh, my bust, sorry PeLu.
[ QUOTE ]
PeLu said:
Actually I was not so interested about how to do it, more what will be different in the next generation for the end user?
[/ QUOTE ]
Oh, my bust, sorry PeLu.
Likebright
Enlightened
Re: Next gen tint control...what the?
/ubbthreads/images/graemlins/ooo.gif
/ubbthreads/images/graemlins/ooo.gif
Hallis
Flashlight Enthusiast
about the possable design, i dont think it want it to be shorter than the 4+, i mean i have a fairly small hand, and my hand swallows an Arc4+ up.
Hammerhead
Newly Enlightened
Peter, you made an interesting comment regarding the "mistake" of dimensions on the ARC 4. Would you expand on that a bit? As a part-time designer of sorts, I'd sure like to hear your views and understand your thought process.
Also, I realize this is probably a moving target, but can you give us an idea of dimensional differences between the 4 and 5 in terms of diameter and length? Also, what are your plans for shape - that can affect usability very much.
I guess what I'm asking is what lessons you've learned from the 4 and how they'll impact the new unit.
Also, I realize this is probably a moving target, but can you give us an idea of dimensional differences between the 4 and 5 in terms of diameter and length? Also, what are your plans for shape - that can affect usability very much.
I guess what I'm asking is what lessons you've learned from the 4 and how they'll impact the new unit.
Gransee
Flashlight Enthusiast
Hammerhead,
The diameter of a light is very important to me. This is in keeping with our motto, "lights that matter". A light is more likely to "matter" if it is easy to carry.
Diameter is one of the first things I specify with a new design. If I need to add volume, I would prefer to add it in length. The problem usually with a minimum diameter is the optics. If the optics are too small, efficiency and beam characteristics suffer.
The original design for the Arc4 (called the LS2, LSX and LS4 during development) was to be at least the same diameter of the LSH, which is 0.950" or smaller if possible. It is surprising what a mere 50 thousandths of an inch can do the "slimness" of a light.
Later in the design process however, I was persuaded to increase the diameter to increase the optical efficiency, allow more room for the electronics and have compatibility with all the 1 inch accessories on the market.
However in hindsight, those reasons didn't really pan out that big. In future designs therefore, I am more compelled to reduce diameter. I am upset that I didn't realize this sooner and that is the regret I referred to.
As far as a flashlight with a 5w emitter (Arc5?), I have yet to see an optics package that can smoothly and tightly focus a 5w emitter, efficiently and have a case diameter of less than 0.950". An EDC light must have range to its beam. I consulted with company here in Arizona that does optics for military and aerospace contracts. They told me the optics I wanted violated several laws of light propagation. /ubbthreads/images/graemlins/smile.gif
The Arc5 design is still in flux. My goal is to make it the best EDC available. This takes some effort though and I currently considering working my way to up it with some intermediate designs. That means the Arc5 may actually be called the Arc7 with the Arc5 and Arc6 being more powerful medium die models.
Small die
Arc-AAA
Arc-AA
Medium die
Arc-LS
Arc-LSL/H
Arc4
Arc5?
Arc6?
Large die
Arc7?
This is just an idea at this stage.. /ubbthreads/images/graemlins/smile.gif
One of the things that precipitated the possibility of intermediate designs is the realization that the medium dies designs still have some headroom to them. I came to realize that the electronics in the Arc4 are not nearly as efficient as they could be. Combine this with the problems in getting the large die optics into a small package and a 50+lumen medium die unit with a slim profile is look mighty Arc-like.
It would really help you to understand my design philosophy by ridding yourself the notion that the best light is the brightest. The best light is the one you have with you when you need it and it works well. As a result, building a big 5w flashlight is foreign to me. The only value I saw in the 5w emitter was making my single 123 cell designs brighter without making them larger. In fact, I was hoping the larger die would allow me to make an even smaller light because of the reduced heat produced. But because of the problems with the optics, EDC nirvana may be in the medium dies.
Also please understand what makes a small EDC brighter is not the wattage, it is the efficiency. This assumes the same battery and housing size and no laws of physics are broken. If you figured that out, my design goals will make a lot more sense.
--
Why these intermediate models?
I thought the Arc4 has pushed the limits of light output for a single cell, sub 1 inch, medium die product. That is why I had originally planned to make my next EDC use a 5w emitter. The contractor I hired to design the power supply for the Arc4 told me that the kind of increased power I wanted was "impractical".
We now know of course that a more powerful and more efficient power supply will fit into this size package. We are now back to where we were 2 years ago. I am working on a single cell, medium die, high power EDC. The efficiency of this design is intended to be one of the best for its design parameters.
Now I would skip straight to the 5w emitter but I don't think everyone can afford such an expensive light and I am just not happy with the optics solutions we have seen to date. The 5w emitter may never produce the beam I want out of an EDC.
The test of time seems to indicate that my original design goals are probably the best EDC for Arc to produce. This platform will have the capability of using the more efficient LEDs coming down the pipe. Lumen output will steadily climb.
Peter
The diameter of a light is very important to me. This is in keeping with our motto, "lights that matter". A light is more likely to "matter" if it is easy to carry.
Diameter is one of the first things I specify with a new design. If I need to add volume, I would prefer to add it in length. The problem usually with a minimum diameter is the optics. If the optics are too small, efficiency and beam characteristics suffer.
The original design for the Arc4 (called the LS2, LSX and LS4 during development) was to be at least the same diameter of the LSH, which is 0.950" or smaller if possible. It is surprising what a mere 50 thousandths of an inch can do the "slimness" of a light.
Later in the design process however, I was persuaded to increase the diameter to increase the optical efficiency, allow more room for the electronics and have compatibility with all the 1 inch accessories on the market.
However in hindsight, those reasons didn't really pan out that big. In future designs therefore, I am more compelled to reduce diameter. I am upset that I didn't realize this sooner and that is the regret I referred to.
As far as a flashlight with a 5w emitter (Arc5?), I have yet to see an optics package that can smoothly and tightly focus a 5w emitter, efficiently and have a case diameter of less than 0.950". An EDC light must have range to its beam. I consulted with company here in Arizona that does optics for military and aerospace contracts. They told me the optics I wanted violated several laws of light propagation. /ubbthreads/images/graemlins/smile.gif
The Arc5 design is still in flux. My goal is to make it the best EDC available. This takes some effort though and I currently considering working my way to up it with some intermediate designs. That means the Arc5 may actually be called the Arc7 with the Arc5 and Arc6 being more powerful medium die models.
Small die
Arc-AAA
Arc-AA
Medium die
Arc-LS
Arc-LSL/H
Arc4
Arc5?
Arc6?
Large die
Arc7?
This is just an idea at this stage.. /ubbthreads/images/graemlins/smile.gif
One of the things that precipitated the possibility of intermediate designs is the realization that the medium dies designs still have some headroom to them. I came to realize that the electronics in the Arc4 are not nearly as efficient as they could be. Combine this with the problems in getting the large die optics into a small package and a 50+lumen medium die unit with a slim profile is look mighty Arc-like.
It would really help you to understand my design philosophy by ridding yourself the notion that the best light is the brightest. The best light is the one you have with you when you need it and it works well. As a result, building a big 5w flashlight is foreign to me. The only value I saw in the 5w emitter was making my single 123 cell designs brighter without making them larger. In fact, I was hoping the larger die would allow me to make an even smaller light because of the reduced heat produced. But because of the problems with the optics, EDC nirvana may be in the medium dies.
Also please understand what makes a small EDC brighter is not the wattage, it is the efficiency. This assumes the same battery and housing size and no laws of physics are broken. If you figured that out, my design goals will make a lot more sense.
--
Why these intermediate models?
I thought the Arc4 has pushed the limits of light output for a single cell, sub 1 inch, medium die product. That is why I had originally planned to make my next EDC use a 5w emitter. The contractor I hired to design the power supply for the Arc4 told me that the kind of increased power I wanted was "impractical".
We now know of course that a more powerful and more efficient power supply will fit into this size package. We are now back to where we were 2 years ago. I am working on a single cell, medium die, high power EDC. The efficiency of this design is intended to be one of the best for its design parameters.
Now I would skip straight to the 5w emitter but I don't think everyone can afford such an expensive light and I am just not happy with the optics solutions we have seen to date. The 5w emitter may never produce the beam I want out of an EDC.
The test of time seems to indicate that my original design goals are probably the best EDC for Arc to produce. This platform will have the capability of using the more efficient LEDs coming down the pipe. Lumen output will steadily climb.
Peter
Hallis
Flashlight Enthusiast
Looks pretty tasety so far. If you're forced to focus on such a small die for the Arc5, why not make it a 3watter? with the Arc7 a 5-watt model since it will be a little larger and give you a little more latitude in optics/reflector.
Oh Peter i sent you an email to the Support email addy.
Shane
Oh Peter i sent you an email to the Support email addy.
Shane
Peter, in full agreement with where your headed.
I've been experimenting the most with CNC 123 as a test mule. this is due to ease of changing out configurations. Everything from single AA to 4X 123 packs.
For the optics. I've been dropping in everything from NX-01, carlo 6 degree, NX-05, Fraen, SO17 and others.
drivers have been a veriety of sammies. From MM+ R2H, BB500 R2H, BB650 Tbin, MM+ Tbin, ill pill, etc.
Two combinations comes out on tops for performance. Beats ARC4X in throw and output.
1. SO17 reflector, MM+ Tbin, R123 li-ion
2. SO17 reflector, BB650 Tbin, 14500 li-ion
Knowing that ARC4X has been certified by an integrated sphere to 46 lumens deflates a lot of output claims. I've been using that as a reference point.
Using Li-ion, Tbin and a 17mm reflector shows performance possible with a 20mm or less overall diameter.
Beamshots: ARC4x left, CNC 123, R123, MM+ Tbin, so17
I've been experimenting the most with CNC 123 as a test mule. this is due to ease of changing out configurations. Everything from single AA to 4X 123 packs.
For the optics. I've been dropping in everything from NX-01, carlo 6 degree, NX-05, Fraen, SO17 and others.
drivers have been a veriety of sammies. From MM+ R2H, BB500 R2H, BB650 Tbin, MM+ Tbin, ill pill, etc.
Two combinations comes out on tops for performance. Beats ARC4X in throw and output.
1. SO17 reflector, MM+ Tbin, R123 li-ion
2. SO17 reflector, BB650 Tbin, 14500 li-ion
Knowing that ARC4X has been certified by an integrated sphere to 46 lumens deflates a lot of output claims. I've been using that as a reference point.
Using Li-ion, Tbin and a 17mm reflector shows performance possible with a 20mm or less overall diameter.
Beamshots: ARC4x left, CNC 123, R123, MM+ Tbin, so17
- Status
Similar threads
Latest posts
-
-
-
Old, used, and/or abused Surefire Lights…lets see ‘em!- Latest: desert.snake
-
CPF UK - AND NOW THE 2018 PARTY STARTS!- Latest: Nyctophiliac
-
-
-
-
