TL;DR I think the IBTS reading fluctuations, described in an older thread Erratic IBTS RoR on First Roast are a problem with an algorithm used to discard the temperature reading of drum vanes, and could be fixed with a firmware update. Until the fix is released, it should be possible for users to make the job of the algorithm a little easier by changing the drum speed, which could improve IBTS temperature reporting.
I think IBTS is an awesome invention and am trying to use it for my roast recipes, but it’s challenging. The problem is that my Bullet R2 Pro is showing the same fluctuations as described in an old thread Erratic IBTS RoR on First Roast.
Here are some of my roasts where the IBTS curve clearly makes no sense.
“Makes no sense" might be a strong phrase, but I think you will agree that it is unusual to see an apparent drop in the surface bean temperature (red line) at the very start of the roast, when the beans cannot possibly be losing heat. There is also another, less striking pattern in I-RoR (orange line) on all three graphs: just before the 6-minute mark in “El Cedro” (IBTS ~175°C), at 4 minutes in “El Limon, San Ramon” (IBTS ~155°C), and at 5 minutes in “Martin Chirino, Caturra” (IBTS~175°C), there is a break in the I-RoR. In these spots, the I-RoR either stabilizes for a short time (first two graphs) or moves unusually wide (last graph).
Trying to understand what is going on, I’ve carefully read The Start of Something …, and in particular paid attention to the raw IBTS readings graph (below is a copy from the article)
The article explains that the wild jumps are caused by the IBTS “picking up the temperature of the drum vanes,” and that Aillio is developing a “smarter filtering algorithm to reduce the noise.” You will notice that on this graph, the “peaks” (which I understand are vanes temperature readings) slowly change into “troughs” sometime between 160 and 175 IBTS reading.
Now, a little about my background: I am a software engineer with more than 30 years experience, and in the past 20 years I’ve done some work filtering useful data from noise (in my case, financial markets). I also have some musical experience and am familiar with the effect of two close frequencies interfering with each other, producing a much lower frequency (examples: Wolf Tone and Superposition of Waves).
As a programmer, I would typically use the words “smart algorithm” when discussing a heuristic that is trying to guess something from incomplete data. In the case of filtering vanes temperature readings, the Bullet firmware most likely does not “know” that it is reading vanes and not beans, because it does not “know” where the vanes are at any particular moment (i.e. outside or inside the IBTS field of vision). So it needs to make a guess, and one possible way of making that guess is by timing the IBTS readings based on the drum speed. But does the firmware actually know the drum speed? After all, the programmed drum speed might not be exactly the same as the actual speed due to various reasons (e.g. mechanical slippage, voltage inaccuracy, clock inaccuracy, etc.). If there’s a small discrepancy between the expected (by the filtering algorithm in firmware) drum speed and the actual speed, a superposition of frequencies (in this case, the frequency of IBTS reads and the frequency of actual vane positions) would develop, resulting in a very low superposition frequency in the filtered results. In addition, that superposition frequency would show abnormality around the temperature range where the vanes’ temperature meets the beans’ temperature - and the graphs above show exactly this kind of behavior!
I am not saying “I know exactly what’s going on.” I do not actually know how the “smart algorithm” really works. I have implemented similar types of heuristics in the past, but none of them related to temperature readings of a physical system. Also, I do not know how often IBTS reads are performed or what other inputs are available for the algorithm to use. If I had more data, I could perhaps be able to help develop a better algorithm. However, at this time I think that, for some running conditions and certain drum speeds, the smart algorithm is not doing great work removing the temperature readings of the drum vanes, and one way around it is for the user to switch to a different drum speed.