Jump to content

Thermocouple bricklet readings "sticking"


zef
 Share

Recommended Posts

Hi all,

I've been working on a PID temperature controller and have been loving the Tinkerforge system overall.

The only issue I haven't been able to solve is an intermittent "sticking" of readings from my thermocouple bricklet V2 with a K-type probe. I'm using the thermocouple callback to give me a value every 1 second as reccomended by the docs, with 'value_has_to_change' set to False.

This works great 99% of the time. But occassionally and apparently randomly, the bricklet returns an identical reading for a short period of time. You can see in my attached image: the two little plateaus in the graph, even though the real temperature is steadily rising (the X-axis here is 1 second per point). In this example I was using 16-sample averaging, but the issue seems to persist for all averaging values. The data on the graph is processed obviously, but I've confirmed that the thermocouple callback itself is being called with identical values.

I haven't been able to pin down why this is happening. I'm using the Python bindings on a Hat Zero brick alongside a SSR and LCD bricklet. The only thing that seems to help is reducing the frequency of the callback, but I suspect it's just masking the problem. I'm fairly sure the probe and connections are fine: I don't experience the sticking with an external thermocouple reader, and the apparatus isn't moving around or subject to any other external interferrence that I can see.

Has anyone else experienced anything like this? Anything I could try? My next idea would be to try an isolator bricklet, but that would just be a guess! Other ideas: possible performance issues on my Pi Zero, causing the various callbacks in my script to compete with each other? Not sure. From what I can see the callback is firing on time, just with the same value over and over!

The thermocouple configuration section of my code is here, for reference: https://github.com/BenVosper/heated/blob/master/regulated.py#L238:L256

Let me know if you need any more info about my setup. Thanks!

IMG_20210503_152601.jpg

Link to comment
Share on other sites

@rtrbt Thanks for pointing that out, I should have seen that in the docs!

It does seem that's what's happening. I can see the open-circuit errors happening in sync with the little plateaus in the readings. That makes sense.

But what could be causing the open-circuit errors? Some interference in the system? I can see it happening with two different probes. Admittedly they're not particularly expensive or high quality probes, but I don't have any reason to suspect they're both faulty.

Nothing is moving when I see errors, so I'm not sure it's any physical connection at fault either.

Could it be some quirk of my wiring / enclosure? I've got 240VAC coming into the enclosure and being converted to 5v for the brick and bricklets via a high quality DC power supply with plenty of headroom, but could it be too electrically noisy within the enclosure?

Does that sound likely at all? I wonder if an isolator bricklet would help

Link to comment
Share on other sites

18 hours ago, zef said:

Does that sound likely at all?

Maybe. As a simple test, you could build a minimal setup with only the bricklet and the probe (attached to the HAT and Pi or, if you have one, a Master Brick) without an enclosure, connect to the Brick or Pi with Brick Viewer and see if the bricklet gets stuck again. Of course this depends on how often the errors happen.

Link to comment
Share on other sites

I've confirmed that running the brick and bricklets with an external 5V supply seemed to prevent the error states. So possibly some interferrence caused by the DC power supply within the enclosure.

I tried some rudimentary shielding around the thermocouple bricklet, but that didn't seem to help on its own.

So I think I'll try out an isolator bricklet to see if that will improve the stability. Worst case I'll just have to find a different power supply or change my enclosure around a little.

Thanks for pointing me in the right direction!

EDIT: Will the isolator bricklet be comptible with my HAT Zero if I connect it with a 7p-7p cable? The docs only mention it working with a 7p-10p to the brick

Edited by zef
Link to comment
Share on other sites

^ Thanks for clarifying.

I gave the isolator bricklet a go today. Unfortunately it didn't seemt to prevent the error states. I was getting the same intermittent dropouts with a variety of different probes / power supplies.

Maybe I'll try a slightly better probe. That or perhaps reshuffle things inside the enclosure a bit

Link to comment
Share on other sites

Had a breakthrough. Nothing wrong with the probes / setup. The probes I'm using have stainless-steel cladding on their leads, and for whatever reason connecting the cladding to DC ground totally eliminated the error states. This is without the isolator brick in the system.

I'm not entirely sure why this fixed it, but I haven't had a single error reported with the new grounding in place. I guess some kind of interference / ground loop in the cladding screwing up the thermocouple voltages?

Link to comment
Share on other sites

Hello zef,

I have also seen similar issues with the thermocouple bricklets I control for a setup and I suspect the cause might be similar. Would you mind posting a photo of your probe and what you mean by "cladding"? I have long suspected grounding problems but when I look at my probes I don't see what could be grounded.

Thanks in advance.

Link to comment
Share on other sites

@seismicvibrations Maybe "cladding" isn't the right word! The high-temperature probes I'm using came with stainless-steel braid on the outside of their leads, over the top of the ceramic / glass fibre insulation of the wires themselves. This is the one I'm currently using:

ceramic.thumb.jpg.fe6f1f4feee5a6e742ca5a8c61cd4a0a.jpg

I found that connecting this outer steel braiding to DC ground greatly reduced the error states. I did this simply with a crocodile clip clamping onto the lead at the connector end, close to the connector itself.

I also have probes like this which have a steel cover over the probe tip itself, also with the steel braiding over the lead:

steel.thumb.jpg.25e563e854d9b54ab88a0294b4084e47.jpg
Grounding the braid seemed to have the same effect for me on these. The steel tip cover is electrically connected to the braiding on the one I have, so perhaps if your probes don't have the braiding, you could try grounding the tip itself?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...