Vargo Titanium Triad Alcohol Stove

Leave a comment

I have had the Vargo Titanium Stove for a little over a year now and as a back up to my wood burning stove it is proven its worth.  Small, light and efficient; it is everything that I have required when I go camping and pull into camp with no time or bad weather to be bothered with the wood stove.

There has been one nagging problem though, sometimes the stove seems to burn all of its fuel in record time without boiling the requisite 2 cups of water that I need for my meal so I decided to do some testing and came up with a few things of note:

Vargo Claims/Description:

  • Weight:    1.0 oz.    (28 grams)
  • Burner Diameter: 60mm
  • Diameter when pot support is open: 85mm
  • Fuel Capacity: 1.75 oz.
  • Collapsed height:    27mm

My Stove Specs:

  • Weight:    31 grams
  • Burner Diameter: 60mm
  • Diameter when pot support is open: 85mm
  • Fuel Capacity: 1.35 oz (40 ml), 1.5 oz (45 ml)
  • Collapsed height:    31mm

Overall, negligible except the fuel rating.  I specifically want to point this out since it might be technically possible for the stove to hold 1.75 fl oz of fuel, but after doing some testing this is unlikely to be possible in the field.  For the most part the likely capacity will be 1.35 fl oz, with a possible maximum of 1.5 fl oz.  The reason this is specifically a concern is that this directly impacts burn time and 45 ml of fuel will get you about 18:30 of burn time in ideal conditions.

In my testing I generally have been getting a boil time for 2 cups of water in about 8 – 8:30 including the 1:15 bloom time that happens during initial stove start up. I include this since I put the pot on the stove as soon as it is lit.  This however brings me back to the initial point of this post, why doesn’t the Triad always have a similar boil and burn time.  First off I did a series of fuel tests to see what the results would be and they were exactly as you would expect.

Fuel Blossom Boil Burn Time
30 ml 1:15 8:25 14:27
35 ml 1:07 8:30 16:15
40 ml 1:10 8:00 17:40
45 ml 1:10 7:30 18:42

Reasonably consistent especially considering that this isn’t any kind of scientific test.  However some initial thoughts that I had that the reduced efficiency of the might be related to over filling the stove with fuel were proven incorrect.

Next I decided to add the only other option that really comes into play and that is the wind screen. I refueled the stove with 30 ml and wrapped the wind screen as tightly as possible around my pot and stove after lighting it.  This time the results showed up right away.  All of the fuel was spent in 8:30 without even coming close to achieving the boil.  I did a little investigation about this and only found a few people commenting on it, however it is a pretty common problem with alcohol stoves.  Apparently if the alcohol stove overheats then it will over-consume the fuel without achieving the desired boil.  As such, proper use of your wind screen is extremely important since that is the common reason for overheating (the wind screen is trapping the heat around the stove).

Some other comments on this phenomenon:


What’s In a Version Number?

Leave a comment

Just saw a post that Firefox 7 was released today as part of the “rapid release” strategy and I thought it was worth a few minutes to type a little blog for this.

Firefox has basically adopted 2 things here.  One is the Google-sque version numbering convention for just updating it quickly for no apparent reason other than there is a new sprint, the other is  what essentially amounts to the agile software development cycle.

Realistically Firefox can call their browser what ever they want and give it what ever number they want…3.0, 3.5, 3.6, 4.0, etc, etc, etc.  However what people are basically losing sight of is what that number means to people.  As somebody in the industry when I see a major or minor version number change like the ones above, I am trained to expect is problems.  It means that somewhere in the system someone has made a change that might or might not affect my application.  This is where the Firefox strategy starts to fall down badly.  Arguably the changes are minor that are happening, but as this post explains “we might break something” so you need to test.  As a corporation running internal types of tooling, this just doesn’t work.  I have no real need to be updating everything every 6 weeks and retesting so that I ensure that everyone of my 100+ applications still work with the new version.  In reality, 99% of them will be fine, but that 1% creates havoc since now I can’t update the browser, which might mean I can’t update the OS and invariably at some point I will get a newer application that won’t work on the old version…havoc ensues.

What the browser companies need to do a much better job of is what MS actually does a pretty good job of and that is backwards compatibility.  It is fine to do releases every 6 weeks, it is fine to add features to those releases, but you need to achieve the goal of giving people a stable platform that won’t necessarily break every time you turn around.

Google is Evil

Leave a comment

Ah Marjory, my little pet nickname for Google.  It is still my favorite search engine although as I have blogged in the past it is starting to lose that standing.  However today the good article I read was about the Google business model.  Anybody around me will quickly note that I will say Google is Evil.

Why is this?

Well when it comes right down to it, it is the fact that what Google really does is gather information about you and sell it.  Realistically this isn’t that much different from likely several dozen other companies out there, but what truly separates Google from the pack is that they are good at it to a level that is down right scary.  From the way that Chrome stores all of the settings on the web to the google+ you must register as your campaign.  As consumers we think it is great that we are getting all of this great stuff for free, however there is an old Japanese saying; “Things that are free, cost the most”.

There is a great little summation Blog today that nicely sums all of this up.

And where Marjory comes from:

We Don’t Need One Until We Do

Leave a comment

I was reading a post this morning about the utilization of state machines in code and how most developers don’t use them.  The main comment that I noticed was the title above “We Don’t Need One Until We Do”.

I have definitely found this to be true however that comment has several implications that are worth noting that go well beyond state machines and is a commentary on development in general.

1. Requirements – In the ideal world we would have perfect requirements that would have foresight at least 5 years into the future, but the reality is that it isn’t normally that “we need one”, it is the business that needs it.  However the business doesn’t really know what technology they need to do anything and will never fully understand the implications of those decisions.  As such it can be invaluable to have a technology person the understands the basics of the business to at least be able to point out where something maybe much bigger than the requirements indicate.

2. We just don’t know – Similar to requirements regardless of the foresight and the business, you never really know what is going to happen, the economy takes a downturn, you suddenly have legal changes which impact your application, your company signs a big client which is different than anything in the past.  These all come together in ways that you can’t possibly foresee even a couple of years in advance, let alone a decade (gasp).  I only point this out since even making the perfect decision at the point in time it is made, there will still be things you would have done differently if you had to do it again.

3. Currency (Technological Debt) – Finally, both of the above points above lead to a day of reckoning where the customized component you have created with become so large and unwieldy that it is impacting everything around.  Once you reach this point it is already too late.  Development takes longer, testing takes longer, deployment takes longer, everything is taking so much effort that you have to replace it, however it is also so late that the endeavor to replace it will not be a trivial task.  Meaning, lots of time and lots of money invested in something with a fairly intangible business value. As often as not, people are comfortable with “the ways things are” and although might see a need to change, don’t think it is that bad.

Unfortunately the 3 items above tends to lead to “go big or stay home” syndrome.  Every little item gets wrapped up in a giant process and architectural exercise requiring review and signoffs and everything else under the sun.  Ultimately driving costs through the roof.  The real key for us all is to be able to understand the business needs enough to know whether or not you need to go for the gusto and buy that big enterprise component, or whether it is a small enough side line item that rolling your own is perfectly fine.

At my company we have a few poster children for these things like this as I am sure we all do, but the best example of one is a document generation engine we built 10 years ago.  Effectively it started as a “find and replace” string parser, however 10 years later it is a very complex custom piece of software that takes months if not years for new people to fully understand what is going on in there.  This would all be fine if our primary business was “document generation”, but in reality it is a service that simply supports the application.

In the beginning would I have done things differently?  In the beginning, maybe a little, but probably not much, the component served its purpose quite well for 5 years.  However, after that we started to add features to the document generation that culminated into the current issues, which is basically a very complex custom piece of code, which is buggy at best.  There are lots of reasons for that (some in our control, some not) that are worthy of a different post, but suffice to say that currency has finally caught up and things need to change.

In the end the key for all of us, is the understand when we need to go for the gusto and when we don’t.  And then when we didn’t go for the gusto the point at which we need to bite the bullet and move to the better model, rather than just bolting on more of the same.


Do you know your shortcuts?

Leave a comment

A somewhat funny one today.  I always find it interesting just how often somebody is doing something “the long way”.  Having used and been enamored by computers for a long time I know most of the basic keyboard shortcuts which have over the years become pretty ubiquitous in the Windows world at least.  However, as somebody who actually works in an IT department with other people who also work in IT it never fails to amaze me just how many of these people don’t use keyboard shortcuts.  There is little more annoying that watching an “IT professional” in a meeting on a projector shakily highlighting a word and then moving the mouse up to the “edit” menu and clicking “copy” then moving the mouse back down again and moving through the document with the little bar on the right with the shaky mouse to the right spot, then putting the mouse where the word would go, then moving the mouse back to the “edit” menu again and finally clicking “paste”.

While this is ultimately annoying with anybody, it is always especially annoying to me when it is somebody who should “know computers”.  There is very little reason everybody out there should not know ctrl + x, ctrl + c, and ctrl +v, but there are lots, way more than you think.  You may be surprised by this, but there are studies to prove it….seriously.

Negative Nelly

Leave a comment

Although I am on a spin these days to avoid the negative Nelly view of the world, it is good to read the articles sometimes as quite often it will be a much more realistic view of what is out there or what is to come.  So after a week or so of reading how HTML5 was going to save the world, it was interesting to see the opposite view.,0


Think outside the box

Leave a comment

Don’t you hate that term… A term normally thrown around by some management know it all (is that me??) in a lame attempt to try and get people to think about something in a different way.  As often as not we are trying to tackle an issue head on and we aren’t seeing things from another angle. 

So what does thinking outside the box mean?  Well, I find the best place to look for an example of something that is out of the ordinary is to look for people that are trying to do things erroniously.  Generally hackers or trojen writers since they are trying to use the tools at hand in a unique way to get a job done, that people may not done to them.

Anyway an interesting article this morning about how to create 2 files with the same name in windows.  As I am sure you will quickly way “that isn’t possible”, but just think outside the box 🙂


Older Entries