Random Musings of a Coffee Technologist
If you’ve been using Typica lately (this feature was introduced a few months ago) there’s a Help menu. It’s not terribly helpful at the moment but you can get an about box with copyright and license information and the like (on the Mac you don’t get a help menu and the about item is moved to the standard location on that platform), but for those of you who still use a proper email client, do you see the little blue envelope pictogram? If you click on that, Typica will open your default mail client and start a new email already addressed to me (actually sending the mail is, of course, still under your control). I read all of those and reply to most of them. There are also some social media links there so you can use those to find me on twitter, github, tumblr, and linkedin (sorry, I’m not in the face book). Give it a try.

If you’ve been using Typica lately (this feature was introduced a few months ago) there’s a Help menu. It’s not terribly helpful at the moment but you can get an about box with copyright and license information and the like (on the Mac you don’t get a help menu and the about item is moved to the standard location on that platform), but for those of you who still use a proper email client, do you see the little blue envelope pictogram? If you click on that, Typica will open your default mail client and start a new email already addressed to me (actually sending the mail is, of course, still under your control). I read all of those and reply to most of them. There are also some social media links there so you can use those to find me on twitter, github, tumblr, and linkedin (sorry, I’m not in the face book). Give it a try.

Punch card graph showing commits to Typica. Apparently I don’t make any between 8PM and 4AM.

Punch card graph showing commits to Typica. Apparently I don’t make any between 8PM and 4AM.

Typica 1.6 is now officially released. What’s different from 1.5 can be found in this blog post. Everybody using Typica should consider upgrading to the latest release.

Feature Freeze for Typica 1.6

The release-1.6 branch has been opened and no new features from this point on will be in the 1.6 release. Bugs that are noticed in testing will still be fixed, but at this point I expect that things are working rather well. Here are some of the new features you’ll see compared with version 1.5.

  • Windows support for the DATAQ DI-145 (some of the data acquisition devices that Diedrich Manufacturing has as an option on their roasters use this hardware).
  • Support for non-temperature measurements.
  • Ability to produce rate of temperature change data.
  • A vertical line in the graph showing current progress through the roast.
  • Support for taking measurements from Adam PGL series scales connected by serial port (or through a USB serial adapter).
  • A new window to simplify the work flow for sample roasting.
  • The ability to configure automated annotations based on the value of a control channel.
  • The ability to hide data series while still producing derived data series or annotations. This also allows for reordering the presentation of data series.
  • Minor modifications to some reports and windows to make them more useful or better looking.
  • Ability to cancel close events for certain windows if closing that window might result in inappropriate loss of data.
  • Cost of green coffee for roasted coffee report.
  • Several under the hood changes that improve the maintainability of Typica’s code base, fix bugs, or provide the foundations for future planned features.

Some of these things hint at plans for improvements in other areas of Typica. For example, the window for entering details on sample roasting batches suggests where I’d like to go with green coffee purchase data entry (basically getting rid of all the optional fields and letting you track whatever else you want to among other changes).

At this point it’s just getting the platform builds done, doing the deployment testing, and some additional testing before making that release available. As always, people who know how to compile the software themselves can get it early from github.

This is what setting up a channel on a DATAQ DI-145 looks like on the development branch of Typica at the moment. It looks rather intimidating, but I’m hoping that people don’t have too much trouble with it. The device measures signals over a ±10V range and you’ll usually want to do some calibration and map the values to what that signal represents. Here I’m mapping to temperature measurements. The stuff in the lower right is there to help pick appropriate values to enter on the left (you set the input to the device to a known stable value and see what the device reports). The output range can be open as above or you can close the range so that, for example, you can’t get values under 0 or over 100 on a channel representing a percentage on a control channel. You can also choose to limit the output within the range, so for example my air flow control channel will only ever output 0, 50, or 100 while the channel above outputs at its maximum available precision and fuel control settings are set to only output integers 0 through 100 inclusive.
What’s new here is a checkbox near the top: “Hide this channel”. That’s available on every channel for all device types and if it’s checked (it defaults to not) you don’t get an indicator showing the value, you don’t see it in your table view, you don’t see it on your graph, but Typica still sets up the channel and takes measurements from it. Why? So you can pipe the data through to other things. Here, for example, I’m taking the measured values and sending them to another mapping function that produces the values I would be measuring at my production roaster. I don’t need to see the input to that function, so I hide it. Similarly, with the airflow control channel I don’t need to see that on the graph. I’d rather just have an annotation telling me when the value changed and what the new setting is. So now that’s what I have. The result is that data that I don’t need to see isn’t shown and I can more easily focus on what I’m interested in.

This is what setting up a channel on a DATAQ DI-145 looks like on the development branch of Typica at the moment. It looks rather intimidating, but I’m hoping that people don’t have too much trouble with it. The device measures signals over a ±10V range and you’ll usually want to do some calibration and map the values to what that signal represents. Here I’m mapping to temperature measurements. The stuff in the lower right is there to help pick appropriate values to enter on the left (you set the input to the device to a known stable value and see what the device reports). The output range can be open as above or you can close the range so that, for example, you can’t get values under 0 or over 100 on a channel representing a percentage on a control channel. You can also choose to limit the output within the range, so for example my air flow control channel will only ever output 0, 50, or 100 while the channel above outputs at its maximum available precision and fuel control settings are set to only output integers 0 through 100 inclusive.

What’s new here is a checkbox near the top: “Hide this channel”. That’s available on every channel for all device types and if it’s checked (it defaults to not) you don’t get an indicator showing the value, you don’t see it in your table view, you don’t see it on your graph, but Typica still sets up the channel and takes measurements from it. Why? So you can pipe the data through to other things. Here, for example, I’m taking the measured values and sending them to another mapping function that produces the values I would be measuring at my production roaster. I don’t need to see the input to that function, so I hide it. Similarly, with the airflow control channel I don’t need to see that on the graph. I’d rather just have an annotation telling me when the value changed and what the new setting is. So now that’s what I have. The result is that data that I don’t need to see isn’t shown and I can more easily focus on what I’m interested in.

The development branch in Typica now has working integration with scales (or at least with the Adam PGL series of scales which is what I have to test with). Confirmed working on Linux and Windows, assumed to work on Mac but I will need to test that assumption before release. It’s a bit ugly and the full range of features on the scale are not supported, just enough that it’s useful. Drag and drop weights in the new batch window to eliminate typing (not a big deal if you have a keyboard, but a nice time saver if you’d otherwise be using the on screen keyboard on a touch screen). If the scale is set to a different unit than the new batch window, measurements are converted to what Typica expects so this is maybe good for eliminating errors if the scale is set for grams and Typica is set to expect kilograms and nobody notices the mis-match (not that I’ve ever done such a thing but I’m willing to bet that someone has). New weights can be displayed either by clicking a button in the New Batch window or by pressing the Print button on the scale. The code also supports taring the scale from Typica, but I have not put that into the New Batch window because I thought it would be too easy to fat finger it and accidentally tare the scale instead of taking a measurement. Maybe I’ll add it in as a menu option at some point if anybody really wants that, but I think that in general people would rather tare the scale when they’re at the scale anyway.

I really need to do something better with data series color selection.
The timing on introducing the rate of temperature change monitoring feature in Typica’s development branch was good. New coffees recently arrived so these have this information in their target profiles. I’m saving new target profiles for the rest of the coffees as I get to them and most of those now also have that data (I don’t want to auto-generate the data). Now that these new profiles are turning up and I’m using the extra information to better match roast profiles I can say that I’ll recommend turning this feature on. Note in particular the slow section at first crack. This was really easy to maintain a match on and around and combined with the profile translation feature (3 seconds in this case) I expect our already low inter-batch variation on QA metrics to get even lower. The use is similar to using air temperature monitoring to better gauge control adjustments but easier since it nicely abstracts out differences in batch size and retained heat. Thanks all who requested the feature. It’s more useful than I expected.
I still have a few other areas where I want to polish things a bit more before the 1.6 release, but that should be happening very soon. I’m also hoping that I’ll be able to get some time in to assemble a couple videos, in particular one going over how I have all of the new stuff set up at the lab roaster, but there again I’m not going to hold the release up for something like that.

I really need to do something better with data series color selection.

The timing on introducing the rate of temperature change monitoring feature in Typica’s development branch was good. New coffees recently arrived so these have this information in their target profiles. I’m saving new target profiles for the rest of the coffees as I get to them and most of those now also have that data (I don’t want to auto-generate the data). Now that these new profiles are turning up and I’m using the extra information to better match roast profiles I can say that I’ll recommend turning this feature on. Note in particular the slow section at first crack. This was really easy to maintain a match on and around and combined with the profile translation feature (3 seconds in this case) I expect our already low inter-batch variation on QA metrics to get even lower. The use is similar to using air temperature monitoring to better gauge control adjustments but easier since it nicely abstracts out differences in batch size and retained heat. Thanks all who requested the feature. It’s more useful than I expected.

I still have a few other areas where I want to polish things a bit more before the 1.6 release, but that should be happening very soon. I’m also hoping that I’ll be able to get some time in to assemble a couple videos, in particular one going over how I have all of the new stuff set up at the lab roaster, but there again I’m not going to hold the release up for something like that.

Cost of Green for Roasted Coffee Reporting

Today I spent some time working on a new report for Typica. This one calculates the cost of green coffee per unit of roasted coffee. Implementation is simple. First it acquires a list of the roasted coffee items you currently produce. This is the same as the list of roasted coffee items in the New Batch window so if you’ve been keeping that current there’s no extra data entry that needs to be done for this. If you haven’t been keeping that current you’ll just have some extra data in the report.

With that list of roasted coffees it then determines what proportion of which green coffees are used to produce that roasted coffee. In most cases this will be 1 green coffee that makes up 100% of the roasted coffee, but since Typica supports pre-roast blending the report needs to handle that. This set of current recipes is based on the most recent roast of each roasted coffee item.

Next we want to get some aggregate information on all batches of a particular roasted coffee item using a particular set of green coffees. Specifically, we want to calculate the minimum, maximum, and mean of the expression 1 / (-1 * ((G - R) / G) - 1) where G is the weight of green coffee and R is the weight of roasted coffee. That expression gets you how much green coffee is needed for 1 pound of roasted coffee. We limit that to batches where G > 0, R > 0, and the batch was approved. These aggregates are then multiplied by the sum of the proportional costs of the green coffees used to produce for each coffee a set of numbers that can be used to estimate the cost of green coffee for each current roasted coffee item. Generally you’ll want the mean value (median would be better and more reliable but I don’t think PostgreSQL has that built in, I might have Typica add a user defined aggregate function for that in a future release as that’s not hard to add), but the minimum and maximum are provided so that it’s easier to see if there’s something weird in the data that might throw that calculation off.

Note that this doesn’t attempt to capture all of the costs associated with roasted coffee production. It doesn’t capture fuel costs, electricity costs, labor costs, packaging costs, any fees such are warehousing or freight costs that are separate line items from the green coffee, or any kind of general overhead costs. All this captures is the cost of green coffee and weight loss for each of your roasted coffee items.

The report needs a little more clean up (I wanted to make sure that it worked properly before adding more features so right now it only reports cost per pound and it needs to also be able to report cost per kilogram if that is your preference and the ability to sort on anything other than the name of the roasted coffee item would also be nice) but it doesn’t currently make use of any features that are not already in the latest release version of Typica so if you want it early you can grab the file from github (look for the Raw button to get a file you can save), drop it in your reports folder, and start using that now.

An improvement over rate of change graphing compared with yesterday. Still a little noisy for my taste but I think I’ve reached the point of not awful. Anybody using something else for this care to weigh in on how this is relative to other programs?

An improvement over rate of change graphing compared with yesterday. Still a little noisy for my taste but I think I’ve reached the point of not awful. Anybody using something else for this care to weigh in on how this is relative to other programs?

Graphing rate of temperature change, first draft. There’s at least one bug that needs to be fixed and there’s some room for improvement generally.

The number of grid lines doesn’t need to match up with the primary axis and the color of the secondary axis can be changed to whatever you like (default is black for the grid lines, not the purple seen here). There are some hints to future plans in how I’ve left space for additional configuration options.

There’s a color picker available from the tool button so you don’t need to know that #aa00ff makes a nice purple. Which color picker you get depends on what OS you’re running on. I haven’t tested it but I think typing in a color name like aliceblue should also work.