Thermocouple Noise When Using 2.4G Wifi


 
Brian,
For me I see no difference between the 2.4 and 5Ghz readings on the noise graph. This graph was made using a corded power source instead of the usual battery setup since digging battery out of garage right now is not safe. The last graphs I posted were made with same corded power source, not the battery. Windstorm decided to drop huge pines on house and garage. Grills never got touched. Will continue to look for my battery once I have things temporally secured. The one thing I had before was when in office and I would switch from the main configuration screen to the WiFi page, I would get a huge step that would actually change pit temp, thermocouple reading, and then would run servo open and back to what it was prior to switching tabs. The heatermeter was about 4' from router and computer. I just set it up in basement to see what would happen when I toggle from config to WiFi page. Nothing. Attaching current graph from basement location.
5Ghz graph.png
 
The noise graph only updates every 10 seconds and is 26 milliseconds long, so it is unlikely you'll catch anything on it in client mode because it would have to overlap at the exact time you experienced the temperature jump. It is easier to see in AP mode because the Pi is transmitting like 5% of the time. I'm not sure I'm fully understanding what you're reporting though, you were still getting temperature jumps on 5GHz when switching pages?

Oof sucks to hear about the wind damage though, hope everyone is ok.
 
Comparison of 5GHz vs 2.4GHz impact on thermocouple noise using a shorted AD8495 (no probe, just ambient sensing)
5ghzdl.png
  • Section 1, connected to 5Ghz wifi, downloaded 150MB file in 19s. Temperature stable.
  • Section 2, wifi scan and switch to 2.4GHz.
  • Section 3, connected to 2.4GHz wifi, downloaded 150MB file in 27s. Temperature volatility 4 degrees F peak-to-peak
I think it is clear that 2.4GHz wifi causes interference with the thermocouple amplifier and 5GHz does not. I also tried turning on power_save on the adapter, as well as lowering the output power and all have no effect. There's just some sort of resonance or something that messes it up.

I'm going to try to switch out the capacitors and resistors for different values to see if there's some combination that attenuates the interference at all. I don't expect I'll have any success in that endeavor considering just how bad it is. It isn't interfering with the output, it is completely dropping it to zero so it's not like I'm looking for a better set of values, I'm looking for any sort of influence because right now we've got none.
 
Pretty interesting results. And credit you are amazingly tenacious trying to figure this out. Since you have the AD8495 shorted out, seems hard to believe it is input noise, is it worse with a probe? Wonder if this is the RFI rectification issue described by AD? Years ago when chasing a similar issue with a bridge amplifier, found that the input filter caps to ground surprisingly made things worse, even though they recommended by AD. Maybe try leaving them out, keeping just the middle one. Also noticed that while your filter cutoff is similar, the AD evaluation board circuit use only 100 ohm series resistors with much larger caps, so that may be worth a shot as well.
 
Yeah I was going to try the configuration they had in the application note, but the common mode filter cutoff remains exactly the same due to how the components are combined. The differential mode filter is one order of magnitude off but I don't think that's going to make any major difference because, again, it isn't like the performance is "not great" it is zero performance so even 10x better won't make things better. It should be noted that the Adafruit board has the exact same values we do, despite our board pre-dating theirs so we both based our designs on Analog Device's reference design at the time.

It is the same with a probe vs without, I just use no probe because that's one less giant wire going all over the desk as I try to work with it. I also suspected the thermocouple mini jack plug itself (both PCC-SMP-K and the probe's side), but the Adafruit board has screw terminals and it does the same thing.
 
Brian,
Looking at the data sheet I see that they recommend a 10uf cap in parallel with the .1 uf cap on the VS+/- chip supply. I see down in the data sheet that this can be a shared cap. They still look like they recommend it to be located closed to the chip. Also they show the Reference pin grounded in a lot of examples. Looking at the heatermeter schematic, it looks like it is open, not connected or grounded. If this correct, have you tried grounding to see if it helps and does not change linearity of chip? GSpinelli brought the input resistor's values. I am thinking maybe AD went with the lower values to reduce noise because a higher value would allow more voltage drop to occur across the higher resistance value and then get amplified. I am scratching head too. Why the noise with the input shorted. Mathematically this would negate the higher input resistance values. So with that said, I am wondering if the noise is getting into the amp another way. Power supply noise or the Reference pin.AD8495.png
 
Check the HeaterMeter schematic again, the reference pin is grounded. :D

Thursday I also tried putting a 10uF tantalum capacitor 2mm from the amplifier power input, then tried a 100uF low-ESR electrolytic capacitor. No change at all.

I've now also tried the CN-0271 filter values, 100ohm, 1uF, and 10nF and there's zero difference there too.

I'm out of ideas, I can't think of anything else to try on either the HeaterMeter board or the Adafruit version because the only thing that has had any effect was to switch from 2.4GHz to 5GHz. I found this post of someone else experiencing the exact same issue except with a cc3200 wifi module. Someone posted that a copper shield solved the issue for them but I don't think that copper would be *so* much more effective than aluminum foil that foil had zero effect and copper works perfectly. I do have some full copper PCBs I guess I can try.
 
Last edited:
I did think of something else to try!

I connected the Pi to a 5V USB power supply and the HeaterMeter to a separate 12V power supply. They were not connected to each other at all, which eliminates supply rail being involved at all. Still the same problem. I can move the two boards around and can hit a perfect spot where there's almost zero drop out, I can move it a couple centimeters away and it has a positive 100mV spike, or move it the other way and it goes back to a negative 100mV spike.

I took a piece of unetched 1oz copper PCB material and inserted it between the two and there was also not much change. Moving the PCB around I can kinda find a place where it sort of has an impact but I think that's hitting some sort of resonance point where the corners of the PCB material are just at the right place to absorb the wifi waveform and reduce it.

Unless anyone else has something to try, I'm done with this because it seems unsolvable apart from changing wifi bands.
 
Brian,
I saw the line coming out of the chip and thought that was the ref input when looking at schematic. Did you attach wire to pcb and connect it it Pi ground and then to the 12v ground to see if the shield grounding would make difference. Other than that, Sounds like if you want lower noise, switch to 5Ghz if you can. This is where it can get fun. 2.4Ghz radio waves travel better than the 5Ghz. I know when I go outside on a cool winter cook, 5Ghz signal strength is lower so connections can get tough. I usually use the 2.4Ghz and with battery power I do not run into many issues.
Still someone might want to make a streaming show about the mysterious heatermeter noise gremlin. I sure Science channel or Discovery might like it. They might find a blind frog causing problem.
 
I did try both with and without a wire soldered to the copper plate and the HeaterMeter ground, but not to the Pi. It made zero difference compared with not grounded. The PCB material is only 90mmx60mm so it doesn't cover the entire HeaterMeter or Pi, so maybe that would make a difference but of course that wouldn't be achievable for trying to stick them back together so it doesn't matter.
 
Why don't you try an off board thermocouple amp that you can shield better and move further away? This way you can get a better idea if this is caused by waves in the air or something coming through the circuits...
 
Brian,
I know this something that is not normally done with analog amps, but since we really are looking at a mv level change from the thermocouple, have you tried a .01uf cap across output to ground. I know this is not a standard practice, but if noise is amp generated, it should decouple noise to ground. At this point the linearity of the amp might change, but this might help eliminate if the source is thermocouple amp caused.
 
RalphTrimble said:
Why don't you try an off board thermocouple amp that you can shield better and move further away? This way you can get a better idea if this is caused by waves in the air or something coming through the circuits...
Click to expand...
We know it is caused by waves in the air because even when the Pi and HeaterMeter (or Adafruit breakout) are powered separately, the error still occurs. The error still exists so far away that there's no way to escape it, and the severity is related to where you hit the signal in its waveform. It just so happens that the way the HeaterMeter board mates to the Pi it is just about the worst position that exists.
Gary V said:
Brian,
I know this something that is not normally done with analog amps, but since we really are looking at a mv level change from the thermocouple, have you tried a .01uf cap across output to ground. I know this is not a standard practice, but if noise is amp generated, it should decouple noise to ground. At this point the linearity of the amp might change, but this might help eliminate if the source is thermocouple amp caused.
Click to expand...
There is a capacitor on the output already in the LC filter. That's the reason the temperature only drops a few degrees and not fully to 0C, which is what the amplifier is putting out when the wifi transmits. It isn't "a mv level change" of error, it around 100mV which is a lot. You could make that capacitor 10x the size and it would still see a drop, although it will be smaller.

I just tried 1.1uF (existing 0.1uF + 1uF SMD capacitor in parallel) and the temperature still drops 2.5F at the most, but now it takes 2-3 seconds when you plug or unplug a thermocouple for the temperature to settle. Plugging in you see like 400F, 100F, 78F. I also tried it with 10.1uF (existing+10uF electrolytic) and you see almost no change in temperature, around 0.3F, but now it takes 7-8 seconds to settle when you unplug or plug in a probe which messes up the graph pretty bad. It goes up to like 800F before dropping out which makes all the rest of the graph squish in scale.

So a larger capacitor is kinda a solution for folks who won't plug in / remove a thermocouple once up running, but it becomes a sliding scale of how much settling time you want vs how much rejection you get. You need like 47uF or higher to get it down around 0.1C. I feel like 1uF is kinda acceptable, but doesn't do enough to reduce the error. 10uF is pretty good error reduction but unacceptable insertion / removal performance.
 
Can you make the HM delay posting TC temp data until a few seconds after it goes from OFF to connected? This would keep the wonky part of the TC startup off the graph, I don't think anyone has a real need to see the TC temperature instantaneously after it is plugged in? I would accept the power-on delay for lower noise performance. Though I could see this making things more frustrating if you have a flakey TC situation, perhaps make a setting to turn on/off delay TC data posting?
I have no idea if this would be easy or a nightmare to code....
 
Brian,
Have you looked at the OKI-78sr as the source of noise. I say that because last summer when I was looking at the possible source of noise I saw in the data sheet that this regulator was a true switching device. I started looking at other 78series devices to see if I could find a replacement for a test to see if the switching noise was getting into the circuit. Looking at the data sheet, they show 19mv of noise from the device. Not unusually high, but never the less it is noise. Other than that, I am out of ideas and will continue to use my heatermeter when I get a few repairs done. This still is the best controller out there for BBQ in my opinion.
Keep up the good work.
 
I am fairly confident It is not a power problem. The two are on different power supplies and my test setup has an inductor between the 5V and 3.3V supply (LC filter), a high ripple rejection 3.3V linear regulator in place of the MCP1700, a ferrite bead adjacent to the AD8495, followed by a 0.1uF capacitor, a 1.0uF capacitor, and a 100uF capacitor within 2mm of the power input. It's the cleanest power we can practically get and it made absolutely zero difference in performance. The phenomenon also occurs when I'm using the Adafruit breakout, powered from a separate bench power supply than the Pi.

A dongle would probably work but I'm not sure how much work that will be to set up. The easy scripts I wrote for being able to configure the wifi without using the OpenWrt standard webui expect there to be only one wireless device present so there's nothing in it to configure a second adapter. A Pi B with an edimax dongle shows absolutely zero noise in the HeaterMeter diagnostics so there's either something about it being just the right distance from the amplifier, or the Pi3B+ does something weird on 2.4GHz in its driver that blasts too much power?

@RalphTrimble - I did consider expanding the rejection algorithm (we already look at the signal to try to determine if it is mid-insertion or removal and throw the value out). The problem is that it is somewhat easy to reject an insertion event because we know that we previously were unplugged, but on removal we can't tell a normal temperature rise from a removal event. I previously had much tighter limits on what was considered valid, but was convinced by users that they'd rather see the bad data than have me throw it out. We don't have the CPU power to do real statistical analysis on the data because new points are coming in every 0.1ms so telling noise from actual temperature changes and plug/unplug events has to be very basic.

That also is just a workaround that doesn't even solve it entirely so I am unlikely to pursue that.
 
This is still a problem obviously, but I've been doing some more research in ways to try to reduce wifi noise coming in on HeaterMeter from Pi3B+. I I recently came across the Pi3B+ FCC filing where it shows that the wifi emissions there were measured at 138mW and the PiZeroW which claims just 31mW. I believe these numbers are just wholly wrong, because the Pi4 claims to max out at just 30mW as well. I believe someone reported the dBm as mW because the wifi chip itself reports it is good up to 31dBm (although there is zero chance it will put out 1250mW). The ZeroW doesn't seem to have much of a problem with generating noise, even when I put the amplifier directly by the zero's antenna.

This got me thinking about if the wifi set power ioctl was actually implemented and it appears to be (reading the source). I used the following line and it seems to have changed the size of the dip of the output from the thermocouple amplifier, so it might be of use to some people
Code: 
# Set to max power (31dBm)
iw dev wlan0 set txpower fixed 3100
# Set to 100mW (20dBm / standard wifi power)
iw dev wlan0 set txpower fixed 2000
# Set to 10mW (10dBm)
iw dev wlan0 set txpower fixed 1000

I wouldn't try any lower than 10dBm because you'll have a hard time connecting probably. This also can help client mode if you're experiencing the weirdness where the temperature can jump when accessing the webui, although the easier solution to both is to use a 5.8GHz network.
 
Bryan,
Makes sense. So my next question is, did you make this change in through the HM scripts or would i need to get into the Pi directly. Would like to lower power. I have a mesh set-up so my grill area has good 2.4ghz coverage, by I am currently working on node positioning so I get better 5ghz. Large brick chimney is not helping, blocks radio waves well. Next question is, can the radio of the Pi be turned off and a an external WIFI device used instead. How easy is that to do. Would like to try turning radio off prior to next cook and use an external WIFI device plugged into usb jack. I will look on wiki page to find recommended WIFI device to use.
 
EDIT: Don't do this. You can just change the wifi power in Network -> Wireless -> Edit (Wireless Overview section) -> Transmit Power.

You can add the line to System -> Startup -> "Local Startup" box like so (just be sure to put it BEFORE exit 0)
1623074958972.png

As for adding a second wifi adapter and disabling the Pi, that's a bit more tricky. All the convenience scripts I've added to configure wifi assumes there is only one wifi adapter present, so it can't disable one and configure another. You can do it through the standard LuCI webui, but honestly it is so confusing that it is likely to be misconfigured and leave me networkless by mistake. I'm clicking through it right now and scratching my head about what to change to do it despite the fact that I wrote all the wifi configuration stuff we use (although the reason I did that was because this was so flippin' complicated).
 
Last edited:
You must log in or register to reply here.

 

Back
Top