A cautious update on my ongoing experiment to use audio, roast data, and manual notes to better understand first crack on the Gene Café CBR-301.

It has been a little while since I last posted a project update here. The last proper update was around 25 May, and since then the crack-monitoring experiment has moved on quite a bit.

Not finished. Not productised. Not magic.

But definitely moving.

For anyone new to this part of the project, I have been experimenting with a passive audio-based roast companion for the Gene Café CBR-301. The basic idea is simple enough: the machine is roasting, I am listening, the Gene Café app is logging, and a separate recorder or Raspberry Pi setup is capturing the sound around the roast.

The aim is not to automate the roaster.

The aim is to better understand what is happening.

Why first crack is awkward on the Gene Café

First crack is one of those things that sounds simple until you actually try to use it consistently.

In books and videos, first crack can sound like a clear event. In real home roasting, especially on a machine like the Gene Café, it can be much less obvious.

Sometimes it is clear. Sometimes it is scattered. Sometimes the fan, motor, glass chamber, and general roast noise make it hard to separate real cracks from everything else going on. Different coffees behave differently too. Some crack loudly. Some are quiet. Some seem to produce a few isolated pops and then a more obvious burst later.

That matters because it is very easy to overreact.

You hear one pop and panic.
Or you hear nothing and assume the roast has failed.
Or the coffee is cracking, but the machine noise masks it.
Or you wait too long because you are still chasing certainty.

My growing view is that first crack is useful, but it should not be treated as the only truth in the roast.

What I am testing

The current experiment combines several signals:

• Audio recorded during the roast
• Gene Café app temperature data
• Fan and stirring state
• Manual observations
• App crack markers where I press them
• Cooling time
• Weight loss
• Later cup results

The important word there is combines.

I am not trying to build a system that simply says “crack detected, cool now.” That would be too crude and, honestly, probably misleading.

A more useful system would say something like:

There is credible crack-like activity here.
The roast is in the right part of the curve for that to matter.
The confidence is rising.
The finish window may now be opening.
Use your judgement.

That is the direction I am interested in.

The latest three-roast test

This evening I ran three personal roasts using the same Kenyan coffee, each at 250 g, aimed more towards espresso and cafetière use rather than a brighter filter style.

That gave me a useful set of contrasts:

• One colder-start roast that went quite full
• One warm roast that looked and measured lighter
• One warm roast that clearly had earlier crack activity and also finished fuller

The interesting part is that the audio did not simply map to “more cracking equals more developed coffee.”

One roast showed strong candidate crack activity but still finished lighter by weight loss. Another showed clear early crack activity and finished much fuller. That is exactly the kind of result that makes this project worth doing.

It suggests the audio is useful, but only when interpreted alongside the thermal behaviour of the roast and the final weight loss.

That is important.

A crack-monitoring tool that ignores machine momentum, batch size, roast time, and weight loss would be a noisy toy. A tool that combines those signals could become genuinely helpful.

Candidate crack activity, not certainty

I am deliberately using careful language here.

I am not calling this “automatic first crack detection.”

At this stage, the better phrase is:

candidate crack activity

That means the audio shows sound events that look interesting and crack-like in the right part of the roast. Sometimes they align very well with what I heard and with the app marker. Sometimes they raise questions. Sometimes they are useful for review rather than live decision-making.

That distinction matters.

The goal is not to replace the person roasting. The goal is to help the person roasting notice things more clearly.

The Raspberry Pi direction

The hardware side is also becoming clearer.

The current direction is a small passive companion device using a Raspberry Pi, a microphone, a small OLED display, and eventually a few buttons and LEDs.

The device would not control the Gene Café. It would not connect to the roaster or switch anything on or off. It would simply listen, log, and display useful roast-side information.

A small screen could show things like:

• Roast time
• Recording status
• Milestones
• Candidate crack confidence
• Time since credible crack-like activity
• Cooling marked
• General “watch” guidance

That is enough. I do not want a tiny screen pretending to be a full roasting dashboard. The useful thing during a roast is not more clutter. It is a calm prompt at the right time.

What I am not claiming

This project does not make roasting automatic.

It does not guarantee repeatability.

It does not remove judgement.

It does not know whether a coffee tastes good.

And it definitely does not turn the Gene Café into a commercial profile roaster.

Coffee is a fresh agricultural product. Every batch has some variation. Every roast has context. The machine has its own behaviour. The room, the starting temperature, the batch size, the coffee, the process, and even the user’s attention all matter.

That is part of what keeps roasting interesting.

If roasting became “press button, receive identical coffee,” I think I would enjoy it less. And I am not convinced that promise is realistic anyway.

Where the project is now

Right now, I would describe the crack-monitoring work as:

promising, useful, but still experimental.

The latest tests suggest that audio can help identify interesting crack-like activity, especially when it lines up with what I heard during the roast. But the bigger lesson is that crack activity is only one part of the decision.

For the Gene Café CBR-301, I am increasingly interested in a broader question:

Can a passive companion help a home roaster make calmer, better-informed decisions during a roast?

That feels more useful than trying to build a gadget that pretends to know everything.

What comes next

The next steps are fairly practical:

• Keep recording more roasts
• Compare audio activity with app data and manual notes
• Check results against weight loss
• Add cup feedback
• Improve the live display idea
• Keep the language cautious
• Avoid pretending the system is smarter than it is

The project is still very much in the workshop stage. Wires, files, logs, odd noises, and the occasional goblin.

But it is starting to become useful.

And for me, that is the interesting bit.