Rainfrog Inc.

Month: May 2011

  • Calling All Thermocouples

    Calling All Thermocouples

    OK, so I’ll admit it… I love the nostalgia of analog devices.  As a kid I assembled a rolling ball clock – the kind that resembles an intricate, miniature roller coaster, where time is measured by the number of balls on each “track”. I loved it! Unfortunately, it woke the whole house up at midnight, so I, alone, was unanimous in that, but to me it was the most wonderful invention I had ever seen.

    The programming side of my brain, though, makes me a fair-weather friend to analog devices. For all their nostalgia, sometimes digital is just plain easier… and better. Such is the case for me with my roasting thermometer. There’s absolutely nothing charming about craning my neck upside down to read the accurate bean temp at regular intervals throughout a roast. And, though Roastmaster makes it easy to input temps with the keyboard, an automated solution would be much better.

    For some time now, I’ve been wanting to make the jump to something digital. I’ve held off, hoping I could find a device that I could integrate with Roastmaster to accommodate the automated readings. There are endless USB data loggers out there, but without a USB port on any iOS device, they may as well be turkey probes. I did find a high-end Bluetooth thermocouple as well, but any price that is listed as “Call for quote” is usually just too ridiculous to display. I did, by the way… and it was.

    I was hopeful when the iGrill bluetooth thermometer was introduced. It’s basic, but it’s an all-in-one package that looks great, and would do the trick, as long as the makers would release the SDK for other apps. Or, so I thought – turns out it’s not capable of reading temps high enough for coffee roasting. I’d like to talk to the manufacturer and see if this is hardcoded in the electronics, or simply a limitation of the probe supplied with the unit. For the moment, though, mine is sitting quietly and sadly, unused.

    I’m aware that there are build-it-yourself open source Arduino solutions out there. I’ve researched one, and it is feasible from what I can read. I had hoped for a prepackaged solution, since we’re coffee roasters, not electronic engineers. But, being in this community for quite some time has taught me that often they do overlap. I’m thinking I may just take the plunge. Being open source – I anticipate it will work well, but probably won’t win any beauty contests. Still, though, it will give me a tool to at least construct the framework Roastmaster will need to work with these devices, and as new solutions come to market, those will be as easy to add as creating a device description for them, or so I’m hoping.

    In the mean time, if anyone knows of a Bluetooth, LAN or, dare I ask for it – an iPhone dock-style thermocouple – available for a reasonable price, with a public SDK, please let me know.

    Cheers and Happy Roasting,
    Danny

  • When 2 + 2 = 4.0001

    When 2 + 2 = 4.0001

    If you use the imperial system to record weights in Roastmaster, and you roast in even measurements of, say 8oz, or 4oz, you may have noticed that as you near the end of your inventory for a particular bean, the number that Roastmaster displays as your inventory becomes a decimal that is very close to your actual inventory, but is sometimes off by hundredths of an oz (or a few grams).

    What is happening?

    Whenever your database is saved, the inventory in memory is being saved as gram integers to the database. This is effectively stripping off the decimal portions of a gram. Now, before you worry – a gram is roughly 6 beans, give or take – so it’s not serious, but it is definitely an annoyance that I plan to address in the next update.

    Why is this happening?

    Well, that takes a bit of explanation…

    Computers are amazing things. In and of themselves, they are perfectly accurate machines – capable of crunching any number thrown at them. Unfortunately, though – storing those numbers in memory, or to a database, can be a problem.

    Think back to the days of high school math, and everyone’s favorites… long division, and yes… fractions. Some are easy. For instance 1/4 = .25. Simple, right? Well, what about 1/3? .33 may come to mind, but the actual number is 0.33333333333333333… with the 3’s going on forever. That is the venerable repeating decimal – a number that can never be exactly represented in decimal notation. Now, once you’ve worked out about 4 or 5 decimal places, most of us (math teachers included) would say “close enough”. And that is exactly what computers have to do – otherwise those numbers would overflow all of the available RAM, and the extra precision wouldn’t do anyone any good.

    So what does this have to do with coffee?

    Well, Roastmaster users are located all over the world, and from what I know, the US is the last major holdout on the imperial measurement system. Yes… pounds and ounces – where nothing divides evenly, and conversions back and forth are impossible to do in your head, so we’ve added all of these auxiliary helper units like cups and pints. Our global friends though, using the metric system, are at an advantage here. Everything is even – everything converts – and computers have a much easier time working with it. Now – providing support for both at the same time is the dilemma that Roastmaster faces – every number ends up being a nasty looking decimal in the end when the imperial system is involved.

    Unfortunately, SQLite databases in iOS are tricky when working with decimal numbers. The decimal number you save in is NOT guaranteed to be the number given back to you the next time you read the database. It will be close, but not always exact. The accuracy varies, but when dealing with larger numbers, it diminishes fairly quickly, so what starts out as accurate to the millionth place, can sometimes quickly dwindle to the point of only being accurate to the hundredth place.

    I knew from the beginning of Roastmaster’s development there would always be tiny inventory drifts when roasting if the imperial system was involved, due to floating point decimal approximations. The design decision I faced in the very beginning was how to minimize this for the largest number of users. In the end, I opted to use the metric system internally for Roastmaster, and to store the inventory as gram integers. I thought this would yield the least overall drift, (and best precision) as it would eliminate the small inconsistencies that could creep in when dealing with decimals – especially for larger inventories like roasting shops would have.

    I thought it was a good decision for a few reasons. One, I believe the metric system is superior to the Imperial system, and certainly easier to use. Two, I feel that even here in the states, for home coffee roasting, most people use metric as well – it offers more precision that trying to deal with quarters of an ounce. Even those that own roasters with half and quarter pound settings, usually whittle those numbers down to a lesser amount of grams until they find the sweet spot of the roaster. Three, shop roasters would have larger inventory and never notice, or care, about drifts of a fraction of a gram. Finally, and most importantly, the vast majority of the world are metric users, and would never even see an inventory drift at all, because that kind of thing just doesn’t occur in a system that converts evenly.

    Now, as Roastmaster is being put through its paces, it turns out the drift for imperial users was a little more than I anticipated. In just 5 – 10 roasts, those gram fractions can add up quickly and amount to 1/10 to 3/10 of an oz, so users are left seeing, say, 15.86 oz of inventory instead of an even 16 oz.

    What else does this affect in Roastmaster?

    Absolutely nothing. All of Roastmaster’s internal calculations dealing with storage in the database operate on decimal numbers, and at much smaller amounts, which is safer for decimal precision. So, whatever number you put in for roasted weight, cupped weight or volume, or blended amounts, etc. is exactly the same number that is saved in the database – with all of its decimals intact. In addition, all of Roastmaster’s internal conversion algorithms operate with 6 decimal place accuracy, so this problem should only be seen in numbers that are reported directly from the transient inventory measurements.

    If you’ve noticed this issue, I hope this has shed a little light on what is happening. Be on the lookout for a fix in the next update, and sorry if this has caused anyone trouble or confusion.

    Cheers, Danny