Risking totally going off-topic but analog thermistors are so old-school!
;-)

Check out the DS18B20. Same size as transistor (TO-220) but is digitally
(one-wire serial) connected. No need for all that analog stuff and
curve-fitting. These are uniquely address, thus polled if need be (dozens on
the one bus) and can be metres from the microcontroller. (Well I have one on
the end of 30 metre roll of alarm cable). Sure a few bucks versus a few
cents, but wow.

Regards, Martin

[email protected]


On Wed, May 26, 2010 at 11:08 PM, Nick Andrew <[email protected]> wrote:

> On Wed, May 26, 2010 at 05:52:59PM +1000, Martin Visser wrote:
> > Pretty much based on the knowledge that the MCU program counter is
> clocked
> > on a 16MHz crystal (according to
> http://en.wikipedia.org/wiki/Quartz_clock they
> > are generally good for 6 parts per million for standard grade crystals,
> > whatever that is).
>
> Ok, that's reasonably accurate.
>
> > If you program it using a standard loop to read inputs, calculate and
> write
> > out to say a LCD display, you should have a loop-length of known number
> of
> > CPU cycles. (This is quite possible with a microcontroller as everything
> is
> > in memory and as long you aren't waiting for random DMA interrupts should
> be
> > quite feasible. A general purpose CPU running a mega operating system
> with
> > lots of peripherals would make this task pretty much impossible).
>
> That's what I was thinking - apart from wanting to be sure that the
> timebase
> is sufficiently accurate.
>
> > Another option is to use the built-in timer/counters (one 8 bit and one
> 16
> > bit are available) on the AVR ATmega MCU. Again clocked against the same
> > crystal, and using a configurable frequency divider mechanism.
>
> The arduino language/library includes a millis() function which returns the
> number of msec of uptime; it's a 32-bit unsigned counter so it overflows
> after 49.7 days. There's also a microsecond counter with a 4 or 8 uS
> resolution depending on the CPU clock speed.
>
> > And finally there are various dedicated real-time chips, such as DS1307,
> > which combined with a crystal (usually 32.768KHz) can be easily
> interfaced
> > if needed. These chips tend to be human-scale timers so you might have to
> > count lots of repetitions of your loop under test and do the maths to get
> an
> > average loop time (possibly limiting its usefulness).
>
> Depending of course on the timescales being measured either the milli- or
> microsecond counter should be adequate. Reasons for looping several times
> would be "the counter resolution isn't high enough" and "the program being
> tested takes a varying time to run". If run on a desktop operating
> system, there's a lot of activity going on in the background so looping
> many times and taking an average is, I think, a necessity.
>
> I have an Arduino which I'll be using for temperature monitoring among
> other things. While running the Thermistor2 program I noticed the reported
> temperature jumped around almost at random. I did some analysis and a lot
> of that "noise" is coming from the ADC itself: I wired it up to fixed value
> resistor dividers (instead of a resistor and thermistor) and monitored
> the ADC value twice a second for several days.
>
> It turns out the ADC value is approximately Normally distributed with a
> standard deviation of about 0.7 x LSB. From what I have read this is out
> of spec and it may be due to noise in the input voltage (USB powered)
> and can also be reduced by adding a capacitor to the circuit (which I
> haven't done).
>
> I modified the code to take 10 readings at a time and average them; this
> reduces the standard deviation considerably. So I'm looking forward to
> hooking it back up to the thermistor and running the revised temperature
> program. It should show better than 0.1 degree C precision, however it
> will still need to be calibrated to be at all accurate.
>
> Nick.
> --
> PGP Key ID = 0x418487E7                      http://www.nick-andrew.net/
> PGP Key fingerprint = B3ED 6894 8E49 1770 C24A  67E3 6266 6EB9 4184 87E7
>
-- 
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Reply via email to