Public Lab Research note


Two Ways Around a Faster, More Precise Thermister

by kh_machine | June 12, 2015 21:24 | 32 views | 1 comments | #11977 | 32 views | 1 comments | #11977 12 Jun 21:24

Read more: i.publiclab.org/n/11977


Potential Problems

During the recent Thermal Fishing Bob Workshop (Northeastern U), two potential problems were discussed: * The thermister is slow to update. * The LED color system for the bob is too granular.

Suggestions

  • Instead of creating a faster update on the thermister, multiple thermisters could register the termperature at different times. For example, if the current thermister updates every five seconds and you need an update every second, you can use five thermisters, and have them update in serial fashion.
  • At the workshop, one person mentioned that having the LED color change when the water got cold or hot did not provide detailed enough information for rigorous water quality data. However, if you set the threshold points (where there are color changes) to numbers that represent temperatures that are acknowledged as dangerously high or low (given the other information about the water source), you can still gather really useful data without the added precision.

Questions and next steps

  • The obvious issue/concern about multiple thermisters is the potential high costs. However, a potential benefit is the redundancy, in the case of the failure of one (or more) of the thermisters. The next step here would be an analysis of tradeoff costs between a faster thermister and multiple slow thermisters.
  • If you use a threshold model, it is important to pick the appropriate numbers given the water source. What would be alarming low temperatures in one body of water would be normal in another. This adds a cost, both for the information required to determine those numbers and to program the sensor accordingly. Again the question is one of cost comparison between more precise data (that can be used in multiple ways) and more granular data that requires local information and a bit of programming.

1 Comments

have them update in serial fashion

Hi - just wanted to connect the dots here between @kh_machine, @neilhendrick, @kgrevera, and @lperovich -

We discussed this a little bit in this comment thread, but the issue with this approach is that it's not that the timer takes a certain number of seconds to update -- like, you start it and then at the end of a 6 second wait, it's done -- but that the mass of the sensor (and whatever it's touching) means that it "stays warm" or "stays cold" for a little while, even as you pass it through a different temperature water. So having multiple thermistors won't improve your latency -- they'll all take that long, and they'll likely all be the same temperature.

The discussion I linked to suggested either:

  1. reducing the mass of the thermistor and whatever it's attached to
  2. increasing the thermal conductivity (via higher surface area, like a radiator, or choosing a heat-conductive material, like metal)

...in order to reduce how long it takes for it to reach the ambient temperature.

That said, multiple thermistors at different depths would still be useful for measuring temperature at different depths. It just won't get you a faster temperature reading. Does that make sense?

Is this a question? Click here to post it to the Questions page.

Reply to this comment...


Login to comment.

Public Lab is open for anyone and will always be free. By signing up you'll join a diverse group of community researchers and tap into a lot of grassroots expertise.

Sign up