When I first started experimenting with audio around the Gene Café CBR-301, the objective seemed fairly obvious.

Could I detect first crack more reliably?

The Gene Café is not a quiet machine. There is a fan, a rotating chamber, beans moving against glass and metal, airflow, motors and assorted mechanical noises all competing with what can sometimes be a surprisingly quiet first crack.

Some coffees make life easy. Others absolutely do not.

That was really where this started. If I could put a decent microphone beside the roaster, perhaps some fairly simple audio analysis could pick out the cracks that my ears were struggling with.

Several months later, I think that was probably the wrong place to start.

The more interesting question has become:

What does the Gene Café itself sound like?

Because until I understand that, asking software to recognise coffee inside all that noise is asking it to solve the problem backwards.

Putting a better ear beside the roaster

The current setup uses a miniDSP UMIK-1 measurement microphone, recording mono audio at 48 kHz.

That is rather more microphone than you need simply to record someone making coffee, but that is not really what I wanted.

The aim is consistency.

I want to capture enough of the frequency range cleanly that I can compare one roast with another and eventually give RoastAid some idea of what constitutes normal CBR-301 behaviour.

Microphone position has already turned out to matter, so a repeatable mounting position is becoming part of the experiment too. If the microphone moves significantly between roasts, I may end up measuring the room and the microphone position as much as the roaster.

And once I started looking closely at those recordings, something became difficult to ignore.

The machine has a rhythm.

The approximately 2.6-second rhythm

Across the recordings there is recurring activity roughly every 2.6 seconds.

Once you see it, you start finding it everywhere.

That immediately makes it interesting — and rather inconvenient if your original ambition was simply to search the waveform for sharp little noises and call them coffee cracks.

A repeating event every couple of seconds is much more likely to belong to the machine than to hundreds of individual coffee beans conveniently deciding to behave like a metronome.

That does not mean every event following that rhythm has the same mechanical source. I have not dismantled the machine and instrumented the individual components.

But it gives RoastAid something extremely useful:

a piece of the machine’s acoustic fingerprint.

If I know that a certain repeating pattern normally belongs to the roaster, I can stop treating it as interesting coffee activity.

That is quite a big change in approach.

Instead of asking:

Is that a crack?

I can begin by asking:

Is that something the Gene Café normally does?

Only after that question has been answered does the unexplained sound become particularly interesting.

R165 and a useful blind test

Roast 165 provided a nice little reality check.

Rather than looking at the graphs first and then deciding what I thought I could hear, I listened to short clips without knowing what each one represented.

Most of the control clips sounded like the machine.

There were mechanical noises, repeating activity and plenty of things that could probably fool an algorithm if it had been trained simply to search for short transients.

The R165 candidate clip was different.

Listening blind, I described it as definitely crack-like.

A section roughly 25 seconds earlier contained a few very light sounds that might have been pops, but nothing like the later activity.

That result does not prove that the marker in R165 represents the precise start of first crack.

That distinction matters.

What it showed was something slightly more modest, but still useful: when genuine-looking coffee-like activity becomes strong enough, it can sound recognisably different from several examples of the machine operating normally.

So there is signal in there.

The problem is learning enough about the noise first.

RoastPower added another layer

The next useful piece came from electrical power monitoring.

RoastPower lets me watch what the roaster is actually drawing from the mains.

When the heater is operating, I see roughly 1.4–1.47 kW.

When it switches out, consumption falls dramatically, typically into the tens of watts while the rest of the machine continues operating.

Near the upper temperature region there is quite obvious heater regulation. The heater switches on and off, including short OFF periods appearing at fairly regular intervals.

That matters for audio analysis because electrical state can alter what the machine sounds like.

A change in acoustic energy does not automatically mean that a bean has cracked.

It might mean the heater changed state.

It might reflect airflow.

It might be the motor or rotating chamber loading differently.

It might be beans moving differently as they lose moisture and density.

Or several of those things could be happening together.

RoastPower therefore gives RoastAid another useful reference channel.

Rather than analysing audio in isolation, I can begin asking whether a sound change coincides with something we already know the machine is doing.

Then 202°C became interesting

The most intriguing result so far came from comparing the eight recent roasts, R161 through R168.

There appears to be a repeatable change in the acoustic character of the CBR-301 at around 202°C displayed temperature.

This wasn’t simply the microphone becoming quieter.

Across all eight roasts, the balance of the sound shifted.

Broadly speaking, energy in the higher frequencies fell while the lower-frequency region became relatively stronger.

Different measurements told much the same story, and the 202°C comparison was the strongest common temperature anchor found in that analysis.

Eight out of eight is enough to make me pay attention.

It is not enough to tell me what caused it.

And this is where some history becomes particularly interesting.

The old fan-speed observations

Long before RoastAid existed, I was recording Gene Café roasts using the app and making fairly ordinary notes about what the machine was doing.

One recurring event was the fan changing automatically from speed 2 to speed 3.

In my early notes I often described this as the machine detecting an overheat condition. Roast 5, for example, contains exactly that interpretation, while later roasts record the same fan behaviour as something that had become quite familiar.

Looking back across normal-sized roasts, those fan transitions tended to occur in roughly the 194–209°C region, with the centre of the observations around 204°C.

That is remarkably close to the new acoustic change centred around 202°C.

The CBR-301 manual does confirm that the machine has internal overheat protection and electronic temperature control.

But that still does not allow me to join the dots and say:

“RoastAid can hear the overheat system operating at 202°C.”

We simply do not have that evidence.

In fact, some of my tiny 52.5 g sample roasts showed the fan transition at substantially higher displayed temperatures, around the low 230s.

That alone suggests that displayed temperature is unlikely to be a universal switch point.

The internal logic may be responding to an exhaust temperature, internal component temperature, rate of heating, airflow condition or some combination that I cannot directly see.

So, for now, the careful description is:

There is a strong candidate machine-state acoustic transition around 202°C in the recent R161–R168 data, and its temperature region overlaps interestingly with historical fan 2→3 behaviour.

That is evidence worth following.

It is not confirmed overheat detection.

Why the distinction matters

This might sound like excessive caution over a fairly small piece of home-roaster experimentation.

But it is exactly the distinction I want RoastAid to preserve.

If the software starts labelling things too early, it stops being an observational tool and starts creating its own reality.

A sound near 202°C becomes “overheat.”

A sharp transient near 240°C becomes “first crack.”

A cluster of transients becomes “development.”

Before long the screen is telling me a wonderfully precise story that the underlying evidence never actually established.

That is not what I want.

I would rather RoastAid say:

machine-state change detected

or:

candidate coffee-like activity

and let accumulating evidence determine what those observations actually mean.

It is less exciting than having FIRST CRACK flash confidently on a touchscreen.

It is also much more useful.

Explain the machine first

So the working model for RoastAid has changed.

Originally, the audio problem looked something like this:

Listen to everything → find crack sounds → identify first crack.

The future approach is closer to:

Learn the normal machine → explain known machine activity → examine what remains.

That means building up a CBR-301 acoustic profile.

The repeating approximately 2.6-second rhythm belongs in it.

Heater cycling detected through RoastPower belongs in it.

Temperature-dependent acoustic changes belong in it.

Known fan and motor states belong in it.

The BLE temperature trace belongs in it.

And over enough roasts, other repeatable machine behaviours will probably emerge too.

Once those are accounted for, the unexplained activity becomes far more valuable.

A random transient in a noisy recording is not particularly interesting.

A transient that does not resemble the machine’s normal rhythm, appears in an appropriate part of the roast, begins occurring more frequently and develops into the sort of activity that a blind listener also describes as crack-like?

Now we have something worth paying attention to.

Still a candidate.

But a much better candidate.

A different experiment from the one I started

I still want to know whether RoastAid can help with first crack.

That problem hasn’t gone away.

If anything, R165 made me more confident that useful coffee information really is hiding inside the Gene Café’s rather enthusiastic soundtrack.

But I no longer think the best way to find it is to teach a Raspberry Pi what first crack sounds like and hope for the best.

First, I need to teach it what the Gene Café sounds like when it isn’t first crack.

That may turn out to be the more useful experiment anyway.

Because if RoastAid can gradually build a reliable picture of machine state — without pretending we know more than the sensors actually tell us — first crack becomes only one of several things we might eventually learn from the sound.

And that feels much closer to what this whole project has become.

Not trying to make the Gene Café pretend to be a laboratory roaster.

Just listening carefully enough to understand the machine we actually have.

Explain the machine first. Then investigate what the machine doesn’t explain.