Who is here? 1 guest(s)
 Print Thread
Smoothing Artisan/HT RoR curves
Barrie
After considerable hand-holding from Marko Luther, I have made changes in my Artisan configuration that lead to much-improved Delta curves. The underlying problem goes back to Artisan's property of catering to a variety of very different devices and, for want of a better phrase, excessive responsiveness in the case of the Hottop/Omega probe combination in use. Rapidly-responding probes feed into the problem! The solution lies in a combination of filtering, data averaging and sampling rate adjustments. Changes have been made in the aArtisan sketch, and in Artisan's Configuration components as follows.

The Artisan sketch
The sketch was edited and reinstalled.

1. User.h can be edited with Notepad or Notepad++. In this (Windows 7) computer, it is in the documents library: 200 files\aArtisan-REL-200\aArtisan\. There are seven files including user.h in that folder.
2. Change BT_FILTER and ET_FILTER to 90
3. Change baud speed to 115200
4. Using Arduino.exe, reinstall (overwrite) the sketch.

Artisan
1. Config/Serial Port: Change Baud rate to 115200
2. Config/Sampling Interval. Set to 5.0 sec.
3. Config/Oversampling. Check this.
4. There will be no change in Artisan?s basic MO of displaying real time curves during the roast and smoothing them by averaging once OFF is clicked.
Barrie attached the following image:
peaberry.png

Edited by Barrie on 01/22/2014 2:17 PM
Barrie (San Diego, CA)
"So much to learn, so little time."
Hottop 2K+., Artisan, Jura Capresso ENA 3 (i.e. espresso).
 
smico
I love when someone elso does a job and all I need to do follow the recipe.
Thank you Barrie. This is major improvement and someone should change the source. When JimG comes back, I guess.
Regards,
Miroslav
Hottop B2 + HTC, Cremina 83, OE Pharos, Brewtus IIIR, Baratza Vario
 
Barrie
Good morning, Miroslav. I have been concerned as to whether my "instructions" were adequate. At least they seem to be for a software professional. Hopefully someone less sophisticated than you at these things will post a message reporting success with the update.
I may even display Delta TE again. Grin
Did you notice the low temperatures recorded by my Omega probes? That still bugs me, although it is functionally unimportant. It arouses comment from time to time.
Edited by Barrie on 01/23/2014 10:15 AM
Barrie (San Diego, CA)
"So much to learn, so little time."
Hottop 2K+., Artisan, Jura Capresso ENA 3 (i.e. espresso).
 
MaKoMo

Quote

smico wrote:

I love when someone elso does a job and all I need to do follow the recipe.
Thank you Barrie. This is major improvement and someone should change the source. When JimG comes back, I guess.
Regards,
Miroslav


I do only partially agree. The code should/could be changed to adjust for the higher serial speed, but that is a minor win. Regarding the smoothing settings in the Arduino sketch, the optimal settings depend on the probes. Barry and myself have unshielded wire probes. I now consider them as being too fast. I also have shielded probes in another machine and the default smoothing values in the sketch work perfectly for those. Anyhow, it is quite simple to change those settings. You anyhow have to upload the sketch to your Arduino. Why not adjust those settings to your probes?
 
Barrie
MaKoMo,
I had thought that slowing down the Arduino signals, while being advantageous to those with rapidly-responding probes, would not be disadvantageous for the slower responders. You have made me reconsider and it may be worth discussing this here a little further in terms that lesser mortals like me can understand. Grin

As I understand it, the Arduino sends out too many signals per unit time for some of us, and rapidly-responding probes harness that characteristic. You have described elsewhere the compromise that Artisan must strike between reporting "the temperature of every bean bouncing off the probe" and an averaging of events. To some extent the "jaggedness" of the curves reflecting this can be blunted by increasing the sampling interval. While plotting in real time, only past values can be used for averaging, whereas once the roast is complete values can be recalculated based on averaging values before and after each point in time.

So there are three areas that one can make a change - the sketch, Artisan, and the probes. I had imagined that, in practice, decreasing the frequency with which aArtisan provides data to Artisan by increasing BT_FILTER and ET_FILTER would not impede the transfer of data points from slowly_responding probes? I guess we need to hear the experience of some slow-responding probe users. Those that do not have a problem will not want to make a change anyway?

Is there something wrong with this reasoning?
Barrie (San Diego, CA)
"So much to learn, so little time."
Hottop 2K+., Artisan, Jura Capresso ENA 3 (i.e. espresso).
 
MaKoMo

Quote

Barrie wrote:

MaKoMo,
I had thought that slowing down the Arduino signals, while being advantageous to those with rapidly-responding probes, would not be disadvantageous for the slower responders. You have made me reconsider and it may be worth discussing this here a little further in terms that lesser mortals like me can understand. Grin

As I understand it, the Arduino sends out too many signals per unit time for some of us, and rapidly-responding probes harness that characteristic. You have described elsewhere the compromise that Artisan must strike between reporting "the temperature of every bean bouncing off the probe" and an averaging of events. To some extent the "jaggedness" of the curves reflecting this can be blunted by increasing the sampling interval. While plotting in real time, only past values can be used for averaging, whereas once the roast is complete values can be recalculated based on averaging values before and after each point in time.


Correct.

Quote

Barrie wrote:
So there are three areas that one can make a change - the sketch, Artisan, and the probes. I had imagined that, in practice, decreasing the frequency with which aArtisan provides data to Artisan by increasing BT_FILTER and ET_FILTER would not impede the transfer of data points from slowly_responding probes? I guess we need to hear the experience of some slow-responding probe users. Those that do not have a problem will not want to make a change anyway?

Is there something wrong with this reasoning?


Berry, what is wrong in the above is the statement that the BT_FILTER and ET_FILTER do change the frequency in which data is supplied by aArtisan to Artisan. Artisan requests data from aArtisan at a fixed frequency which is controlled by the sampling interval setting. The BT_FILTER/ET_FILTER does modify the number of past samples taken into account as recorded by the TC4. The TC4 runs its own sampling frequency that is way higher than that of Artisan.

The more you smooth the more information is lost. Therefore, one should apply as much smoothing as needed, but not more. As there are quite diverse setups around (the aArtisan firmware is even used by some without Artisan), there is no sensible default that works for all. Now if the increased smoothing on the TC4 helps with your fast probes, it might result in a too large time lag for those with slower probes. Therefore this setting is customizable in the first place (well done Jim!).

I further argue in a new post on the Artisan blog

http://artisan-ro...te-of.html

that smoothing should be apply as early as possible in the chain.

Hope that finally resolves the confusions,
Marko
Edited by JackH on 06/18/2015 7:09 AM
 
Barrie
Very helpful.
Barrie (San Diego, CA)
"So much to learn, so little time."
Hottop 2K+., Artisan, Jura Capresso ENA 3 (i.e. espresso).
 
Jump to Forum: