Using CRUCS at CRG Retreat

A couple days after the initial public release of CRUCS I was on my way to the Coffee Roasters Guild Retreat. This is reliably my favorite coffee event of the year. A couple hundred people who all roast coffee take over a chunk of a scenic resort, have good conversations, roast some coffee, do some educational stuff, and drink perhaps a bit too much. This year nobody asked me to help with developing materials or teaching classes so it's the first in a long time that I had no official responsibilities and could participate as a normal attendee.

One of the highlights of this event is the roasting tent in which several different coffee roasting machines are set up and ready for attendees to use. I got a bit of time on a couple machines that I haven't used previously, which is always fun. These days, the machines all have computers connected to them (sadly none running Typica as usual) and most of the time whatever software they're using even works, but nothing is set up in a way that makes it easy for attendees to take their roasting data with them for later reference. Ignore the irony that supposed ease of data sharing was one of the early selling points of cloud based roasting software. If you want to have your roasting data at an event like this, you should be prepared to manually record your roasts. It turns out, CRUCS on an iPad makes a decent manual roast logger. I might add some features to make that use case a little more convenient, but it's certainly usable for that as is.

This year's team challenge involved taking one coffee and creating a blend combining the current crop of that with at least 75% of the past crop version. There's not really time to go through the rigorous product development approach I take in my own shop and everybody does a blind cupping with all of the submissions. Winning mostly comes down to luck (I say this as someone already on the trophy as a past winner) but the range of submissions on the table was a clear indication that roasters can use their creativity to mask this sort of issue and while they may not be able to sell a past crop coffee with the flavor characteristics they originally bought that coffee for, it's still possible to produce a pleasant result.

The team I was on came in 2nd place. Once the sample coding was announced I was able to see that I scored my team's coffee highest, though I only scored the coffee of the winning team 1 point lower so I can't say that the results are unfair. We roasted on one of the San Franciscan machines which seemed to handle nicely during our roasting time, knocked out four batches: three with the coffee having had some hand sorting, one without, though I only have data on the first three batches.

Of the four batches, the 2nd one was clearly the most interesting on the table, but combining it with the 4th batch improved the body. Measurements were logged approximately every 30 seconds here, which is more than is generally needed when using CRUCS for logging (for these the data was transcribed into CRUCS after initially writing things down on paper). If this were being used as the basis of a future production plan, the number of data points would be significantly reduced to further smooth out that rate of change series and make this a bit easier to match. The data file above also has the unused first and third batches.

For one of the roasting workshops, I decided to use CRUCS directly at the roaster. This was on a little Probat, different people roasting each batch (I did one of them) following the same control parameters (fuel settings at designated events) with different starting temperatures. Only 3 batches were needed, but the group I was in knocked these out efficiently and we got in 5 roasts, letting more people get time on the machine.

Here I dropped the rate at which I was recording measurements down to only 1 per minute, which on a paper log generally isn't good enough, but with CRUCS that turns out to be quite reasonable if perhaps still a bit too frequent later in the roast. This was the first time that I was able to see other people seeing me using CRUCS and the reception to that seemed pretty positive, though I got the impression that some people had no idea what exactly it was that they were looking at.

Here are some quick tips if you want to use CRUCS as a logger at your machine.

• The time field doesn't require a full minutes and seconds form. If you don't put in a : character, it gets interpreted as seconds, so 0 for the starting time works fine. If you do put in a : character, everything to the left gets interpreted as minutes and everything to the right gets interpreted as seconds, but you don't need to have anything to the right. One minute can be written as 1: and it'll be interpreted correctly.
• You can probably get away with recording fewer points of data than you might otherwise be tempted to. Once you're a little past turnaround, consider only noting where you've made control adjustments, events of interest, and where you've stopped the roast. Excess detail with poor precision tends to show up as extra waviness in the rate of change that isn't real.
• You can record any number of batches without clearing your data. Layer settings can be used to name each data series in a way that you'll understand and you can hide layers you don't need to reference at the moment while still being able to bring those back later.
• Save your work. Prefer to export in Typica XML format as this will save the exact points you've entered as well as per layer settings (including hidden layers). If you need CSV later, just open the XML file and then export the CSV, possibly after adjusting layer settings to get exactly the data series you want with the column headers as you want them.