2.8.4 and lag at the DROP moment

[procent85]

Describe the bug
Hello. In 2.8.4 I am experiencing a lag at the DROP moment, similar as here #859

To Reproduce
Steps to reproduce the behavior:
The earlier stages of roasting the coffee are fine, but at the end when I open the lid and throw the beans into the cooling tray, the DROP temperature and time are marked with a delay. For example: I dropped my coffee at 21.5% DEV, 11:37 min. and 203.0 C but Artisan marked DROP as 21.7%, 11:38 and temp. 202.4 C. I attached a high resolution screenshot. Please zoom in to the end of the graph, you can see the delay with which Artisan "marked" the drop. This happens almost every time I roast coffee.

Expected behavior
Marking DROP without lag as in previous version - v2.8.2.

Screenshots
Please see the attachment.

Setup (please complete the following information):

Artisan 2.8.4
Platform Windows-10
Connected devices or roasting machine: Coffed SR5 manual

MARISA 2.5KG 22 I 203.0 ST - MAI 3_44 - CH 160 G 0_50 - TP 72 DE 5_22 - PIERWSZE - DEV 2_32 - 11_38.txt

[procent85]

Hello. I would also like to add that micro lag occurs when marking FC. When I mark FC at 193.0 C Artisan shows 192.7 C.
I have attached my latest profile.
This problem did not exist in the previous version.
If it helps, my laptop is i5 4200H 2.8GHz, 8GB of RAM and SSD drive, with updated Windows 10 Pro.

KOL.txt

[Terracotta-62]

The guess error is related to the adoption frequency 'sampling' you use.

[roasterdave]

The calculation of autoDROP is sensitive to a number of things including the shape and flattness of the BT curve, how quickly the BT changes at DROP time, how much noise there is in the BT signal and the resolution of the BT signal received by Artisan. I examined the profile you supplied, MARISA 2.5KG...23-07-13_2338_.alog. Please see the screenshot below. Notice that the delta temp for the first decrease in BT is only -0.6C. This is not large enough to trigger autoDROP. It is just under the threshold that is there to prevent false triggers caused by noise that exists in many systems. Is it possible the door opened late in the sample period? That could make the temperature change between samples small, thus DROP was not marked until the following sample. These subtleties of timing can affect where marks happen by one sample.

I looked at your other profiles too. KOL...23-07-16_2348.alog shows DROP marked as expected. From issue 859 KOL...22-03-30_0108.alog, I recalculated the autoDROP mark using v2.8.4 (it was originally recorded with v2.6.0). The screenshot shows where autoDROP in v2.8.4 and v2.6.0 mark DROP. Here v2.8.4 detects the DROP time as expected.

For these three profiles autoDROP is working as expected (by me). There is not a single perfect way to calculate it for all setups so we are investigating how to allow users to easily tune the autoDROP calculation for their specific setup. This work is just starting so please be patient.

[roasterdave]

Hello. I would also like to add that micro lag occurs when marking FC. When I mark FC at 193.0 C Artisan shows 192.7 C.

Are you marking FCs manually? Artisan marks FC in the sample where FCs is pressed. Your description sounds like Artisan is not lagging but instead marking early, so some additional context for how you are marking FCs will help to understand what is happening.

This is not related to autoDROP. For clearer tracking will you please open a new issue for this item. It will help it you also attach your settings file (Help>> Save settings, rename the file to have a .txt suffix then drag and drop it here on the website. It will not work attached to an email.) Thanks.

[MAKOMO]

The autoDROP heuristic has been revised to make it more accurate for more setups (Commit e3bb21c).

Please test this revised algorithm available now with the Continuous Builds.