Monday, May 20, 2013

Fighting Spikes

You might be one of the lucky roasters who gets perfect readings from your meter. However, some don't. Mostly spikes are caused by some electrical interferences between the temperature probe, meter or Computer. In the ideal word those should be resolved by an improved hardware setup. A nice description of the issue and a documentation towards its solution was recently posted to the HomeBarista forum and also a newer post details on a solution. However, in some cases a physical solution is not possible for various reasons. In those cases the new spike removal features of Artisan might help you out.

Artisan's Processing Flow

Let's start with reflecting on how Artisans turns the readings it receives from the external devices into curves on the screen (see the picture below). Initially the symbolic mathematical functions are applied as defined by the user per channel to the values received from the connected devices. Then the resulting values are processed by the input filters. For now there is the ET-BT-swap filter, a min-max-limit filter as well as a drop-spikes filter (details of those input filters are given below). The second step is the internal processing of values in the core of Artisan. This step includes the CHARGE/DROP-recognizer. The values resulting from this processing are stored in the roast profile files on save. Note that the original readings initially received from the devices are potentially lost or modified if input filters were applied. In that sense, input filters are distructive. Finally, the readings are prepared in the third and last step to be rendered on screen by the application of smoothing filters. Those are not distructive, as the original values (as available before smoothing) are kept. 

0 Symbolic Assignments

Here the value, bound to the variable x, as received from the device are passed to the corresponding symbolic math formula that was defined for that channel, if any, together with the previously internally recorded values of all other channels bound to the corresponding Yn variables. After the result of applying the formula to those values is computed, the resulting value is forwarded to the input filters.

1 Input Filters

Currently, there are 3 (destructive) input filters implemented.
  • ET <-> BT swap: this rather specific input filter routes the ET readings to the BT port and vice versa. This is useful to "control BT" via a PID instead of the "control ET" that Artisan offers by default. Just connect your BT probe to the control pid. Select this one as "control ET" device, but flag the "ET <-> BT" input filter. The consequence is that the control PID receives BT values and its process values are drawn as BT curve. Confusing?
  • min-max filter: this one limits the readings accepted by Artisan to the specified range. Selecting the standard range of expected temperatures expected during a roast often already eliminates most of the spikes, because meters experiencing electric noise often return very high or very low readings.
  • drop spikes filter: this filter removes all readings that would result in a delta value that is either very high or very low compared to the previous deltas. This filter is able to catch spikes that happen in the standard range temperature values and can therefore not be caught by the min-max filter.
NOTE: Input Filters are also applied to virtual devices!

2 Artisan Core Processing

The values forwarded by the input filters are still further processed by some internal processes before recorded internally. For example, the CHARGE/DROP recognizer constantly observes the latest internally recorded BT values and checks if a CHARGE or DROP pattern can be recognized.

3 Smoothing

Smoothing is applied only for rendering the internal readings on the screen. There are three filters that can be configured separately (menu Tools/Extras, HUD tab). The curve and spike smoothing is applied to the temperature curves and the delta smoothing to the DeltaET/DeltaBT curves only. The curve and the delta smoothing filters can be turned off by setting the corresponding smoothing factor to 0. A higher smoothing factor results in smoother curves, but removes also smaller details. The smoothing applied to the ET and BT curves has also a positive effect on the DeltaET/DeltaBT curves, removing already much of the jitter. The curve smoothing is also able to reduce the size of spikes, but the spike filter often can remove spikes completely as illustrated by the following figures. The first one is a recording with all filtering and smoothing turned off. The second is the same recording with the spike smoothing filter turned on.


  1. greetings. first of all, thank you for the effort you have made in writing and maintaining this software as well as the articles to address some of these issues. it seems to have a number of very valuable features.

    I have recently been trying to get the software to work with an ampprobe TMD56 under windows. the readings on the ampprobe are correct, but the results in the Artisan HUD for the BT and ET temperatures are not stable. to eliminate electrical interference i tried using the battery power only on may laptop. this appeared to eliminate some of the issues but not all of them. note that i have not been able to roast a single profile successfully. sometimes, i get very normal reasds for awhile then they get unstable.

    a curious thing currently making the software unusable with the ampprobe TMD56:
    it seems once it gets a bad value, it continues to remain in this 'bad value state' for some time, continually giving me garbage readings. sometimes this stabilized after 30 seconds and sometimes it does not ever stabilize and it must be reset.

    i am wondering if there is some sort of buffer read error that happens? for example, if a buffer read from the USB takes 15 bytes when it was supposed to get 16, then every subsequent read is the wrong offset so it just keeps getting bad values. the 'bad values' are generally a number around 411 fahrenheit or ~51 degrees, and it just keeps giving me these values, or 1.1.

    i wonder if there is might be a USB interface issue and a different laptop would give reliable values? can anyone verify a single laptop config that works for them successfully? does MAC work better than Windows or vice versa?

    also, i wonder if its possible that there is an escape sequence character embedded in string or otherwise that is getting pushed through an ascii to integer conversion or vice versa in the code and an internal array or data structure ends up unstable...are we checking alignment on buffer reads and/or writes?

    i am not an expert at reading data from a USB device, but the notion that it is giving noisy values seems suprising, i think the protocol has the capability to handle this correctly.

    any explanation or ideas to help debug?

    i found this forum and the conclusion in the last message interesting, i wonder if it helps?



    ps. i am willing to test out any beta versions or potential fixes.

    1. The ampprobe is known to output raw values via its serial connection that might differ from the computed values shown on its display. The HUD computation is based on the RoR/Delta values computed by Artian. The effects you describe are based on either ground loops or electro-magnetic influences of your measuring system (probe, meter and/or communication link). If you turn off all smoothing and all input filters you see the raw values received by Artisan from the meter (check menu Roast >> Properties; tab Data).

      Artisan is not communicating via USB, but the serial protocol and flushes the input and output queues before/after each transaction. So on the Artisan side there is unlikely a way to fix your issues (it runs smooth with the Amprobe of a lot users). However, as Artisan is open-source you can try to hack it yourself.

      My advice is to fix your hardware setup as this migh be the only way to achieve useful measurements. Run all devices from battery, add ferits, and use an optical USB isolator (as standard with the more expensive meters). Further you might consider ungrounded probes that are somewhat slower than grounded ones, but produce less interferences. Slower probes helps also in smoothing out the signal very early in the chain, which is good.

  2. thank you for your suggestion, i'll do some more experimentation and get back with results. i did indeed move to 'all battery' before posting, and it did make the results better/less noisy, but not completely resolving the issues, so the scenario described above is a 'battery in laptop, battery in ampprobe' scenario.

    1. Check out also the new post on the Cropster blog on probe selection:


Note: Only a member of this blog may post a comment.