EEVblog Electronics Community Forum
Electronics => Beginners => Topic started by: Whiteowl on June 26, 2013, 07:28:26 am
-
Hi,
I'm an electronics beginner with very basic knowledge. I'm going to try and build a small circuit that will light an LED when the temperature goes above a certain value. This is for a cheap-o wine fridge that is very quiet, so I can know if it somehow dies on me.
The circuit idea is to use a 9V battery, split the V in half by using two 470 resistors, drive the 4.5V through a TMP36 and use the output voltage, along with a trimpot to calibrate input into an P2N2222A that will allow enough current to flow through into the LED (backed by a small resistor). The schematic is attached.
I guess I'd like help to make sure that this is even the right way of approaching this problem. I'm concerned that I won't be able to properly adjust the output of the TMP36 into the P2N2222A to make it work properly. Also, I don't know if using 2x470 to split the 9V into 4.5 is the right way. Would using larger value resistors save battery life?
Thanks in advance.
-
I don't know about that temp sensor, but what ever happen your led won't light.
-
As drawn, I think the schematic needs some work. The led is connected to the emitter of the npn but in parallel, it is shorted to ground so you won't really have any current flowing through the led ever.
Regardless, I would start over with the architecture, really it's a great idea for a little widget but the current design will not be very power efficient so you will be chewing through A LOT if 9v batteries for a circuit that could probably last an entire year on a single AAA.
So a few suggestions on what I would do to change. First thing would to lower the voltage, personally I'm a fan of a single alkaline cell and the using a small , low Iq boost converter to boost to something like 3 volts. Then I would look for the lowest power temperature sensor that you can find. Finally I would find a micro power comparitor with an open drain output. Attach the led to the output of the comparitor with the and anode pulled to 3v.
Touchstone has an impressive low Iq boost reg (ts8800) be doesn't look like the most simple part especially for hobbyists. I've used Semtech SC120 before with Iq of 40uA. It's been powering a sensor from a AAA since march with no sign of quitting anytime soon.
I guess one other suggestion would be that you will need a monitor to tell you when you battery is low otherwise you'll have another problem.
Other option is to use a old cell phone charger as a power supply, regulate it Down with a Ldo and go from there.
-
First of all these chips wont work above 5.5 volt....
I would work off 3 aa cells.
Youll need a comparator. The simplest thing is to power the tmp36 with the 4.5 volt. As well as power the comparator with 4.5 volt.
A trimpot sets the trip level. The output of the comparator can drive the led directly.
-
Another option would be to power a ultra low voltage comparitor directly from the battery then use two voltage dividers at the inputs, one with a trimly to set the alarm voltage and another with a thermistor to sense the temperature. Then when the voltage dividers cross over, use the output to drive an enable of a boost converter to drive the led. Then you just need a very low sleep current regulator. You could probably do the whole circuit for around 10 or 15 uA!
-
Back a few years ago, there were these wine fridges, that were sold by a big box store. They had the nasty habit of thermostat failing short. This froze the wine, and ejected the cork, or broke the bottles. Think a fail safe of shutting the power off, not just overtemp indication.
-
Thanks for the help guys. I think I need some time to digest these new ideas, as I didn't even know there were such things as low voltage boost converters and voltage comparators. I think I get the gist of it, so I'll try and read a bit and post another schematic.
Ignator: at this stage, I'm not even thinking of going anywhere near AC, which I think I would have to if I were to be able to shut the power off. Actually I am more concerned about the fridge just dying and me not noticing. It's very quiet when working, and it can get pretty hot here in Sydney during the summer. Mostly though, I'm doing this to learn, and this is something that might be useful, so more interesting to learn with.
Thanks again!
-
For the comparator I'd suggest a TLV3011 or a MAX931, both are ultra low power types. If you like MCUs you could use an ATtiny or a small PIC, check the temperature, enter sleep mode for some seconds and repeat. Or use the integrated analog comparator of the ATtiny to trigger an interrupt to wake up the MCU. There are tons of possible low power solutions.
-
Ignator: at this stage, I'm not even thinking of going anywhere near AC, which I think I would have to if I were to be able to shut the power off. Actually I am more concerned about the fridge just dying and me not noticing. It's very quiet when working, and it can get pretty hot here in Sydney during the summer. Mostly though, I'm doing this to learn, and this is something that might be useful, so more interesting to learn with.
If it's a thermoelectric cooler it can't freeze unless you put the whole thing in a freezer. Most folks don't understand COP, but for thermo electrics your lucky if 0.1 COP is had with 25c ambient. If it has a compressor (COP ~3), you need to worry. But it depends on the controller. Mechanical thermostats are much more reliable then solid state. It was solid state with digital display that was a problem.
This is a perfect learning project. There are many temp control circuits. Analog Devices has the AD590/592 family. And TMP-01 (I may have this remembered wrong as that was on the schematic, and may not be a vendor designator). This part may be too simple for you. As 3 programing resistors is all that's needed, and has over temp, and under temp output.
Find and read through application notes for a part of interest. They give interesting insight to many other uses of the part. And have schematics that you will gain much electronic training from.
-
You could use a 9v battery, a voltage regulator, a micro controller with a temp sensor, an LED and a resistor. Since this is a learning exercise for you you may choose to do it that hard way.
Use an ATtiny45 (http://canada.newark.com/atmel/attiny45-20pu/ic-8bit-mcu-avr-tiny-20mhz-8-pdip/dp/68T3729) which you can load an Arduino sketch on and cost less than a dollar. The voltage reg gets you the 5V you need independent of the battery voltage. LDO options are available. Use a fixed value or do what I did and buy a whole tube of LM2950's and use them for anything and everything you build. With an LM2950 you can drive the microcontroller at 3V and make the battery last longer.
The ATtiny45 has a built in temperature sensor.
-
This could also be done with a cheap microcontroller, like the ATtiny13A which has enough peripherals build-in like ADC, timers, PWM etc.:
+ Lower power consumption (deep sleep mode, PWM rather than resistor for LED and blinking rather than always-on)
+ It requires fewer discrete components (MCU, sensor and LED)
+ You can do much more (intensity, blinking, multi-color, low-battery warning, etc.) and update software gradually
- Requires programming
- Max 5.5Vcc (use 2xAAA instead)
If you're up for that kind of stuff, I have to say I'm having an awful lot of fun playing with the ATtiny13A for these kind of hobby projects, trying to squeeze in more features through intelligent use as I learn more (i.e. use the LED to measure ambient light level between pulses, and use this info to change brightness dynamically and save battery at night).
-
I honestly think it is overkill to use a mcu but that's just me. It's probably overkill to use the 10 or 15 uA approach too but I'd prefer a simple solution that teaches basics and gets great battery life.
-
I honestly think it is overkill to use a mcu but that's just me. It's probably overkill to use the 10 or 15 uA approach too but I'd prefer a simple solution that teaches basics and gets great battery life.
Simplicity is a matter of perspective and I am just an electronics amateur. However, not sure if I agree that a comparator, two voltage dividers, a trimmer, a LED, a thermistor, boost converter and a current regulator is simpler than an ATtiny, LM35 and LED. This is how much is needed compared to my index finder, costing roughly $2. And btw. the circuit idles at 90nA.
-
If good precision is not needed, one could also use the big brother attiny25 which has an internal sensor, though its sleep state draws more power than attiny13a. For even more optimization fun, and if precition is really not so important (as I think is the case here) one might try to cut the sensor altogether and use the attiny13a's internal (temperature unstable) oscillator to deduce temperature, like this german guy demonstrates:
http://www.elektronik-labor.de/AVR/T13contest/Temperatur.html (http://www.elektronik-labor.de/AVR/T13contest/Temperatur.html)
-
I honestly think it is overkill to use a mcu but that's just me. It's probably overkill to use the 10 or 15 uA approach too but I'd prefer a simple solution that teaches basics and gets great battery life.
Simplicity is a matter of perspective and I am just an electronics amateur. However, not sure if I agree that a comparator, two voltage dividers, a trimmer, a LED, a thermistor, boost converter and a current regulator is simpler than an ATtiny, LM35 and LED. This is how much is needed compared to my index finder, costing roughly $2. And btw. the circuit idles at 90nA.
Not bad at all, could be a good option however to make this apples to apples you would have to average that 90nA with the current consumed when the micro wakes up and samples the temp sensors. This is also dependent of you sample time which causes latency in detection but I know that doesn't matter in this case... Also the LM35 temp sense will consume about 56uA. The other challenge is like free_electron said, LM35 is not spec'ed to run lower than 4V however, even with 3 alkaline cells, you won't be able to fully discharge them before the circuit drops out.
Using the comparitor method, if two alkalines were used in series, the boost converter could likely be omitted but there might be some led brightness issues when the batteries are close to dead. (Assuming red led)
Like you say It's mostly a a matter of preference and what you are comfortable with working with. Hopefully the two suggestions provide an example of how many different ways a design can be approached, that's a good thing.
-
Whiteowl whatever route you decide to take when designing your circuit (and its enclosure) just remember water conducts electricity and fridges can produce condensation.
-
You can fit a single AAA cell, battery holder and pcb into hm1144-nd from digikey. It's translucent blue so put a blue led inside and you have it fully enclosed. Possibly an enclosure would be worse because it would capture humid air to condense and be trapped inside...
I did a little searching, to me I think Semtech SC120SKTRT is still a great fit for the boost converter and touchstone semi TS12011 looks really good for a comparitor, it has a reference and built in opamp too so even better... BC2583CT-ND looks like a good thermistor from digikey.
The one other thing that I will say on the micro controller side is that with that approach, you would be able to strobe the led after the fault was detected so that would extend battery life when the led is on...
-
Whiteowl whatever route you decide to take when designing your circuit (and its enclosure) just remember water conducts electricity and fridges can produce condensation.
Wrap it all in a big wad of Sugru. Problem solved, no case necessary. I haven't tried but you might be able to see the LED glowing through the rubber coating but if not then just leave the plastic of the LED sticking out. Should be mosty waterproof, shock proof and fully insulating.
http://sugru.com (http://sugru.com)
-
The one other thing that I will say on the micro controller side is that with that approach, you would be able to strobe the led after the fault was detected so that would extend battery life when the led is on...
Exactly, the battery-life of such a device would essentially last for 10+ years (assuming 99% of the time the device is in monitoring/sleep mode rather than alert mode) so an enclosure is probably overkill, just dip the circuit+battery+magnet in hot glue. A rev. 2 version could blink faster (or another color) depending on the temperature. A rev. 3 could include a micro-switch/reed to let the device known when the fridge has been opened and discard monitoring for the next 5 min. A rev. 4 version could also have its battery-life optimized by using the internal ADC and adjusting brightness (through PWM) according to voltage supply level. A rev. 5 version could measure the ambient light via the LED and the ADC, requiring less power when blinking at night. Lots of evolutionary options while learning MCU basics.
-
maybe this:
(https://lh4.googleusercontent.com/-97BDFgUngic/UcvtfqRNkQI/AAAAAAAAC2M/wq3VP42zc9I/w351-h331-no/temp.jpg)
-
Well, I've decided that as this is really about learning, I'll do both :) So I'm going to try the no MCU route first and then do the ATTiny version. I guess I'm attracted to the no-MCU route because I'm fairly confident about my programming abilities, but I don't know much about electronics, being a software programmer.
Cheers everyone for your help, I'll update when I've got something going. This is a great community, glad I joined!
-
I guess I'm attracted to the no-MCU route because I'm fairly confident about my programming abilities, but I don't know much about electronics, being a software programmer.
Just for the record (having a similar background as you); writing low-level C/assembly for a 1K device, interpreting datasheets, setting up interrupts etc. is a very different programming model than writing high-level Java/C# for 32-core, 64GB servers revolving around MVC pattern, ORM framework, CAP theorem, SaaS etc.
Originally I thought I'd find my way back into electronics using mostly discrete parts and TTL/CMOS logic gates, but quickly realized the amount of freedom and possibilities a low-cost MCU provides in this day and age - especially to those not scared off by a compiler tool-chain (software devs).
Anyway, have fun and lets hear what you come up with. :)
-
Just for the record (having a similar background as you); writing low-level C/assembly for a 1K device, interpreting datasheets, setting up interrupts etc. is a very different programming model than writing high-level Java/C# for 32-core, 64GB servers revolving around MVC pattern, ORM framework, CAP theorem, SaaS etc.
Very nicely put! :-) Do CS students learn how a CPU works in detail nowadays?
Originally I thought I'd find my way back into electronics using mostly discrete parts and TTL/CMOS logic gates, but quickly realized the amount of freedom and possibilities a low-cost MCU provides in this day and age - especially to those not scared off by a compiler tool-chain (software devs).
The logic gates aren't obsolete, but the TTL graveyards were replaced first by PALs, then GALs and today we got 50cent MCUs with internal ADCs.
-
We all seem to be software->hardware crossovers!
Good choice doing it as you are, I would do (and have done) the same. Chances are you'll just do it the analog way and then get bored having solved it but it's always good to know there are many ways to skin a cat.
-
Very nicely put! :-) Do CS students learn how a CPU works in detail nowadays?
Not in my experience. They all learn Java and have no idea about things like memory management, let alone what the cpu is actually doing.
CS students doing programming should all have to do a module in assembly language, IMO.
-
As drawn, I think the schematic needs some work. The led is connected to the emitter of the npn but in parallel, it is shorted to ground so you won't really have any current flowing through the led ever.
Even if he sorts out the LED circuit,there is no voltage on T1 collector ,as it is connected to the wrong end of R2.
Reading the answers on this thread reminds me of the story about a Technician,an Engineer,& an Accountant.
They all had a cat & a dog,& wanted to allow the animals to go in & out of the house when the door was closed.
The Tech bought & fitted a "doggy door" which was light enough for the cat to also use.
Both animals are happy.
The Engineer couldn't stand the idea of a big door being wasted on the cat,so cut two doors,large & small,with interlocks to prevent the cat using the dog's door,or the dog trying to use the cat's door & getting stuck.------he is up to version 3.2 now.
Both animals are confused.
The Accountant cut out a cat sized door & tried to push the dog through it! ;D
-
Reading the answers on this thread reminds me of the story about a Technician,an Engineer,& an Accountant.
They all had a cat & a dog,& wanted to allow the animals to go in & out of the house when the door was closed.
The Tech bought & fitted a "doggy door" which was light enough for the cat to also use.
Both animals are happy.
The Engineer couldn't stand the idea of a big door being wasted on the cat,so cut two doors,large & small,with interlocks to prevent the cat using the dog's door,or the dog trying to use the cat's door & getting stuck.------he is up to version 3.2 now.
Both animals are confused.
The Accountant cut out a cat sized door & tried to push the dog through it! ;D
Point taken. Can we agree though, that a temperature alarm is not much worth if it runs out of battery after 14 days and fails silently?!
6 months ago I did a mailbox notifier using various combinations of low-power CMOS flip-flops and 555 timers, but it would run out of power far too quickly and lay dormant until I realized the mailbox was full and that I needed to change batteries. I then rebuilt it with a cheapo MCU and now it should have battery for a couple of years, with fewer components and more features. The extra features is kind of a free lunch; would be silly not to take advantage of it.
-
Very nicely put! :-) Do CS students learn how a CPU works in detail nowadays?
Not in my experience. They all learn Java and have no idea about things like memory management, let alone what the cpu is actually doing.
CS students doing programming should all have to do a module in assembly language, IMO.
It's worse than I thought. More bloatware ahead :-( I second your suggestion to have them doing assembler for one CPU/MCU at least. Otherwise they'll learn how to write code vs. the CPU and not for it. Unfortunately throwing more GBytes and GHz at the problem is inexpensive these days.
-
The Accountant cut out a cat sized door & tried to push the dog through it! ;D
That would be the hungry-for-power circuit powered by a battery ;D
-
As drawn, I think the schematic needs some work. The led is connected to the emitter of the npn but in parallel, it is shorted to ground so you won't really have any current flowing through the led ever.
Even if he sorts out the LED circuit,there is no voltage on T1 collector ,as it is connected to the wrong end of R2.
Reading the answers on this thread reminds me of the story about a Technician,an Engineer,& an Accountant.
They all had a cat & a dog,& wanted to allow the animals to go in & out of the house when the door was closed.
The Tech bought & fitted a "doggy door" which was light enough for the cat to also use.
Both animals are happy.
The Engineer couldn't stand the idea of a big door being wasted on the cat,so cut two doors,large & small,with interlocks to prevent the cat using the dog's door,or the dog trying to use the cat's door & getting stuck.------he is up to version 3.2 now.
Both animals are confused.
The Accountant cut out a cat sized door & tried to push the dog through it! ;D
Love it! :-DD
-
Very nicely put! :-) Do CS students learn how a CPU works in detail nowadays?
Not in my experience. They all learn Java and have no idea about things like memory management, let alone what the cpu is actually doing.
CS students doing programming should all have to do a module in assembly language, IMO.
It's worse than I thought. More bloatware ahead :-( I second your suggestion to have them doing assembler for one CPU/MCU at least. Otherwise they'll learn how to write code vs. the CPU and not for it. Unfortunately throwing more GBytes and GHz at the problem is inexpensive these days.
IMHO if you can't write C code then you can't program. Everything else is just compiler semantics.
-
IMHO if you can't write C code then you can't program. Everything else is just compiler semantics.
That's a black-n-white sweeping statement that's very common to see among engineers who tends to think in absolutes. The truth is far more nuanced though, since it depends on what you need to do; don't tear down your garrage with a box-cutter and don't open your packages with a circular saw. Pick the right tool for the job!
Some of the worst code I've read over the years, are by embedded engineers who are so stuck in their old bit-twiddling C world that they lack all other elements of what I would consider to be professional software construction (i.e. no logging, no unit tests, homemade data structures use rather than tried-n-tested library versions, inability to make the code easy to read, silly optimizations which the compiler can do better etc.). When we write software today, we're writing as much to our colleagues as we are writing to the compiler, and C is just not very good at expressing intent (i.e. no type-safety, const can be cast away etc.).
I understand what you mean, C as a (very lightweight) abstraction fits well in the embedded and systems world, with strong ties to fundamental CS topics such as Turing machines etc. However, as program complexity and size increases, you quickly run out of abstractions. Sure you can roll your own VTABLE to achive polomorfism and mark-and-sweep to get garbage collection in parts of your system, but that makes you more of a fool than anything else - people smarter than you already came up with these abstractions in a cohesive language.
The latest iteration of polyglot language hybrids like Scala, Go, Clojure and even C# attack the concurrency behemoth head-on, something that will always remain a nightmare to do in C. At the end of the day, you'll want to make software that solves your problem rather than spending your time hunting down memory leaks and deadlocks.
-
I'm aware of the nature of the assertion but I didn't say you should always use C or that abstraction to a higher level isn't useful or even necessary. What I'm saying is if all you know is php or java then you aren't a complete programmer just as someone that who can use a nail gun but not drive a nail with a hammer isn't a real carpenter.
The Java VM is written in C. The operating system which runs the Java VM is written in C. C is where the rubber meets the road and a pro must know it. C is the software equivalent of Ohms law. If CS graduates come out of school not knowing it backwards and forwards then they are not graduating ready to be professional programmers. That is a huge problem.
I've been a professional programmer and software engineer for over 25 years. I became a journeyman when I learned to program in C. I became a master when I mastered it. I hardly ever use it. I do all my real work in ObjectiveC, ruby and python but without it I couldn't call myself a pro.
-
I guess I'm attracted to the no-MCU route because I'm fairly confident about my programming abilities, but I don't know much about electronics, being a software programmer.
Just for the record (having a similar background as you); writing low-level C/assembly for a 1K device, interpreting datasheets, setting up interrupts etc. is a very different programming model than writing high-level Java/C# for 32-core, 64GB servers revolving around MVC pattern, ORM framework, CAP theorem, SaaS etc.
Originally I thought I'd find my way back into electronics using mostly discrete parts and TTL/CMOS logic gates, but quickly realized the amount of freedom and possibilities a low-cost MCU provides in this day and age - especially to those not scared off by a compiler tool-chain (software devs).
Anyway, have fun and lets hear what you come up with. :)
Well, I'm no spring chicken, and I've been programming since I was a kid, so I've done lots of assembly, C and pascal along the way. I guess the way I see it is that if I were to use say, an AVR chip (I only have an arduino uno, but as I understand it, the programming is the same across the line), then it's simply reading an analog input pin, then deciding about writing an output pin, so not much of a challenge, and not that much electronics apart from a resistor on the LED. In that scenario, the real challenge would be to figure out how to program the ATTiny or whatever MCU, set it up with its power, and basically replicate the parts of the arduino that I need. Comparing this to the non-MCU solution, it just seems less satisfying. Anyway, once I get the components and build something, I'll post it up here so I can get some feedback on the solution.
-
...it's simply reading an analog input pin, then deciding about writing an output pin, so not much of a challenge, and not that much electronics apart from a resistor on the LED.
Oh well, I see it differently - just another skill-set. Btw. why the resistor? It just transforms useful electric power into rather useless heat.
-
Well, I'm no spring chicken, and I've been programming since I was a kid, so I've done lots of assembly, C and pascal along the way. I guess the way I see it is that if I were to use say, an AVR chip (I only have an arduino uno, but as I understand it, the programming is the same across the line), then it's simply reading an analog input pin, then deciding about writing an output pin, so not much of a challenge, and not that much electronics apart from a resistor on the LED. In that scenario, the real challenge would be to figure out how to program the ATTiny or whatever MCU, set it up with its power, and basically replicate the parts of the arduino that I need. Comparing this to the non-MCU solution, it just seems less satisfying. Anyway, once I get the components and build something, I'll post it up here so I can get some feedback on the solution.
The Arduino hides a lot of low level stuff inside libs already. If you start with a barebone AVR you'll need to setup a few registers and deal with interrupts or register flags for reading a value from the ADC.
-
This discussion took an interesting turn :) ...
Kudos to whiteowl for trying the non-MCU route first because it is very much the same argument in circuits. MCUs are great devices and very often the best solution. However they can be an injustice to learning circuit fundamentals just like Java or C# is to C.
I am only a programmer as a means to an end. I have however worked with a lot of career programmers on embedded projects. Some who have also wrote huge PC applications. I find it irritating when they dwell so long on how to abstract every single thing into a neat little C++ object when the desired function can be implemented in an hour with 15 lines of straight C code to simply modify some register value. If I wanted some test code to run in the lab (not even production code) they usually have to modify the abstraction layers which takes weeks! Doesn't make either of us very happy.
In embedded, it also drives simple solutions into overpowered processors with mega memory.
I think it all ends with my realization that I'm a hardware guy through and through... I will say on the PC side, I really enjoy python, it's a great tool.
-
How is the project going?
Sent from my iPhone using Tapatalk 2
-
I would have probably used a simple IC like MCP9700 : http://uk.farnell.com/microchip/mcp9700t-e-lt/thermistor-linear-active-smd-9700/dp/1084621 (http://uk.farnell.com/microchip/mcp9700t-e-lt/thermistor-linear-active-smd-9700/dp/1084621)
It gives you temperature from -40 to 125c with about +/-2c accuracy, works from about 2.5v so you can run it from 2aa batteries... and outputs a simple voltage which you can read with a comparator or the adc of a microcontroller.