Better probes?


 
After reading through about everything I could find on probe types, could someone give me a warm fuzzy that these are the best option for the HM setup? I have a brief list of pros and cons from my reading.

Thermoworks pros
- better made probe that works with the HM
Thermoworks cons
- Probes don't stay in the jacks

Maverick pros
- tested and commonly used with the HM setup
Maverick cons
- moisture can easily ruin probe
 
My thermoworks probes are very erratic. They work great on all test runs in the house with freezing/boiling water, they'll read precise temperatures for hours. However once I get them out on the grill they go crazy. They'll be stable for a while, and then they seem to lose their mind and have 400+ degree spikes. They seem to be EXTREMELY sensitive to the amount of pressure thatis placed on the wire when the top/bottom of my kamado close down. I'll try to post a picture later. Has anyone else seen this?
 
I sometimes see that "going crazy" behavior too. Not sure what causes it. So far all probes have recovered but it is annoying.
 
AubreyW said:
I sometimes see that "going crazy" behavior too. Not sure what causes it. So far all probes have recovered but it is annoying.
Click to expand...

Just when I think I have it figured out or the erratic behavior accounted for, I get something that I just can't explain.

These are 2 screenshots of my cook yesterday. I ran out of charcoal faster than normal and didn't realize it. So, the graph looks much worse that it actually was. The pit temp was actually pretty well maintained for about the first 6 hours. After that, it was a comedy of errors on my part. Try to look past that ugliness and just focus on the 2 food probes.

I was cooking a turkey breast and had one probe in each breast. At first, there was a significant difference between the 2 probes. I assumed it was the placement of the probes. I just left them alone. Later, they evened out. But, if you look at one food probe, it's smooth (green) and the other is erratic as hell (blue). After the cook, the blue probe smoothed out. I can't figure this out. Any ideas? Why would it be so erratic and unpredictable during the cook, then instantly stabilize after the cook?

12052049976_a92fa1743e_b.jpg


Here it is zoomed in. After 6 hours, I was running out of charcoal in this one. That's faster than I've ever run out of charcoal. So, I didn't realize what was going on. But, you can see the 2 probes a little better in this shot.

12051248743_287251c374_b.jpg
 
Last edited:
I have two thermoworks probes and they seem to bounce in between a 4 degree window over and over again. Looks like a sine wave or something similar. My ET72s do not exhibit this behavior.
 
PaulFisher said:
I have two thermoworks probes and they seem to bounce in between a 4 degree window over and over again. Looks like a sine wave or something similar. My ET72s do not exhibit this behavior.
Click to expand...

Mine do the exact same thing. Posted about it a few pages back but never found a resolution
 
Geoff Parris said:
Mine do the exact same thing. Posted about it a few pages back but never found a resolution
Click to expand...

Can you see any correlation between changes in the blower speed or servo position and the cycle of temp?

EDIT: If you turn off the blower/servo (lid mode) does the temp line smooth out for the probe?
 
Last edited:
Because the v4.1 boards had possible noise issues, I've been looking a lot at quantifying what constitutes a normal amount of noise and what is "a hot mess". The ET-72/73 probes are pretty solid, the Thermoworks probes show more variation, and the ET-732 are pretty solid unless something touches their braid.

EDIT: Information below is probably not accurate. See next post

What I've found is that the thermoworks and the ET-732 both show benefit from adding some capacitance to their output. It doesn't completely remove the variation but it cuts it in half for the thermoworks and reduces the chances of the ET-732 dropping off completely. The ET-732 dropoff is caused a 120Hz (2x mains frequency) small spike that lasts about 1/1000000th of a second. When HeaterMeter samples and gets this, it throws out the whole second's worth of readings causing the probe to drop out. Adding the extra capacitance attenuates this spike, although the extra noise caused by the ungrounded ET-732 probe shield can still cause dropouts at room temperatures. The only way to eliminate this is to solder a ground wire to the braid itself.

So it is win-win right? Well not 100%, the capacitance can cause an erroneous reading when plugging or unplugging probes. That's not so terrible though so here's something to try if your Thermoworks probes show a lot of variance or your ET-732s just drop in and out. This is for both v4.0 and v4.1 HeaterMeter boards.
Faoztih.png

Simply solder a 0.1uF capacitor from one side of the probe jack to the other. Use a ceramic / mlc capacitor such as the same 0.1uF capacitor used in the rest of the build. The exact value isn't important but I've tested from 0.047uF (47nF) to 1.0uF and they all do alright. Even a low-ESR 10uF worked acceptably, but the chances of getting a bogus reading when plugging/unplugging go up the higher the capacitance.
 
Last edited:
Bryan Mayland said:
What I've found is that the thermoworks and the ET-732 both show benefit from adding some capacitance to their output.
Click to expand...
After more testing tonight it appears this only works when the oscilloscope is connected. When the oscilloscope isn't connected, I still get the same fluctuations when touching the braid. Probably no benefit to adding the extra capacitance, so don't waste your time.
 
Bryan Mayland said:
After more testing tonight it appears this only works when the oscilloscope is connected. When the oscilloscope isn't connected, I still get the same fluctuations when touching the braid. Probably no benefit to adding the extra capacitance, so don't waste your time.
Click to expand...

That's what I found when I experimented with the cap across the probes a while ago when I was developing the roto damper...
It would be nice to smooth this out somehow....
 
Bryan Mayland said:
After more testing tonight it appears this only works when the oscilloscope is connected. When the oscilloscope isn't connected, I still get the same fluctuations when touching the braid. Probably no benefit to adding the extra capacitance, so don't waste your time.
Click to expand...

Thanks for looking into this.

Do you think there's still hope for these probes? Would grounding them to the HM help, at least as a short term work around?
 
I completely rewrote the ADC sampler last night too thinking this could be fixed in software. Instead of sampling pseudo-randomly across the 1 second period, it samples continuously 256 times then averages/decimates the results. The papers I'd read said that to eliminate noise you have to sample continuously in order to apply algorithms that don't work on discrete samples like we had be doing. The higher sample count leads to a reduction in noise by one half by itself and removes the chance of randomly sampling just during the "bad time", the time when there's a spike. This way, I thought, you're guaranteed a spike but it will be averaged out with all the good data.



It works, although only marginally better than the original code. That's subjective too, now instead of dropping out entirely at low temperatures, they show a few degree variation. I don't know which is better, not having a value at all or just being in the ballpark (within ~5 degrees). Obviously they still couldn't be used for Pit probes with that level of variance. I'll keep working on it.

Soldering a ground wire to the probe does a pretty good job of fixing it though.
 
Steve_M said:
This is for the ThermoWorks probes?
Click to expand...
For all probes really, as they all some some degree of error. Primarily for the ET-732s, and to a lesser extent the Thermoworks. At least in my testing, these show the highest variance in readings.
Matt Birmingham said:
Bryan, just out of curiosity, what kind of average algorithm did you write? Was it a simple mean (or median or mode)?
Click to expand...
Simple averaging. There's a few reasons. Storing runs of 256 16-bit numbers takes 1/4 of the RAM of the device. I'd actually rather do 512 readings but I'm trying to keep the code as tight as possible. There's not that much CPU power that you can move a lot of data around, or work to much in floating point. Especially because it is working at 9600Hz so there's not a whole lot of clock cycles to use before you start ending up using all the CPU time to just keep track of the analog. I also need to oversample to increase the ADC resolution so what I really need to do is add up the 64 median samples and and divide by 16.

If I had all the CPU time and RAM in the world, I'd run through each block of data and discard any samples outside of 2 standard deviations then oversample on the resulting data. There's no chance that's going to happen though.
 
Last edited:
I've added a ground wire to the braid on the pit and first meat probe. The 2nd and 3rd meat probes are stock.

The braids are all touching since they're all grouped together for the test, so I don't know if the 2 stock probes will benefit from touching the 2 modded probes.

Tracking the progress here http://bbq.converged.ca
 
Last edited:
Bryan Mayland said:
If I had all the CPU time and RAM in the world, I'd run through each block of data and discard any samples outside of 2 standard deviations then oversample on the resulting data. There's no chance that's going to happen though.
Click to expand...

Agreed. I had hoped (and assumed) you had already thought of this. You also mentioned that you don't have cycles to move data around and issues w/ floating point. I'm guessing that eliminates mode averages since you'd need to round to a less-accurate number then (possibly) sort, then find the midway point?
 
Mode would require storing anywhere between 1 and 256 values along with its count to determine which value is seen most frequently. That's 37.5% of all RAM, so that's out.

Median would probably work, but again it's just so much data and the values would have to be sorted which could mean moving that all around. I'm not sure how fast read/write RAM access is, but when you're talking about moving up to 1/4 of system RAM it probably isn't super-quick. I also looked at doing 8x samples, doing a median on that, then doing it 64x and using that result. Problem is that some noise appears to last only a couple ADC ticks (ok!) but some noise can last at least 8 samples which would throw off the result.

I need to do some more data gathering so I can test different ideas without having to fully implement them in ATmega code before I find out they don't work.
 
You must log in or register to reply here.

 

Back
Top