On my scope, a 10" LX200GPS, I have the dew heater just behind the corrector plate which appears to be the best location, and the idea is that the heat going into the tube and slightly heating the back of the corrector plate, (air), stops the dew from forming on the front. I've read also about too much heat as well might not be the best. As all scopes and setups and weather are different so lots of tweaking for optimal results.
At first before the dew sets in, the heater is off as no pwm needed As the temp drops, the code checks the dew point and gets a celsius value, (calculated from the DHT22), and compares this with the temp sensor + say 5 deg and a simple calculation, see code below and credit due to the other guy in the previous post link for that bit.
If the temp sensor reaches the start of the threshold, the pwm starts to turn on, but only enough to satisfy the temp/rules. As the dew point vs temp changes, the pwm keeps ramping up until it hits 100% duty cycle. There it stays until conditions change. Might be power savings as well in light dew.
Each channel is unique, as for my setup I have a guide scope as well, so tweaking can be done seperately on each channel.
The idea of putting the temp sensors under the dew straps, I picked up from lots of searches in astro sites looking for commons in temp sensor positions and under the dew heater seems to be the most intelligent things I read. Some mentioned to put thin rubber/foam as an insulator others not, so I'm about to fit it to the scope as the tests I've done so far have been on the bench and I'm thinking I'll try just heatshrink over the sensor at first and then under the dew heater.
So the real telescope tests are about to happen and I'm sure there will be tweaking of the code to get the optimum, and that's one thing I think the logged data/graphs can help with.
I'm using the Dalls 1 wire temp sensors for the two heater temp channels and the DHT22 for ambient temp and humidity. The humidity sensor is on the inside lid of the small box that sits on the tube, and has holes in the lid to pick up the dew.
void loop() {
delay(1000);
// Reading temperature or humidity from dht takes about 250 milliseconds
// Sensor readings may also be up to 2 seconds 'old' (its a very slow sensor)
float h = dht.readHumidity();
float t = dht.readTemperature();
float logEx;
float dew_point;
float valpercentpot1;
float valpercentpot2;
int qq;
I did something like this many years ago, and you will find it gets too complicated too quick, and too many cables go to one spot.
Have attached piccies of a unit i made up for fun that could
a) Have one DewHeater channel controlled via several means
including using dewpoint, defined PWM duty cycle or auto temp delta mode. It doesnt come on till you get within a set delta from the dewpoint.
b) Have 4 secondary PWM channels that could be manually controlled
c) Have regulated 8V and 12V outputs for my cameras
d) Have a focusser controller
e) Have a user settable menu system
It worked OK, but in the end, i split up the process and used dedicated units for each of the functions,
As per redbeard, i also put my primary dew heater wires behind the corrector, but my ( insulated) dewshield also goes right back over the OTA as far as possible to retain as much dewheater heat as possible in the OTA. I also use dallas 1 wire temp probes and the system works quite well with much lower current draw than exposed units.
Computers are really bad at math. That function has 11 floating point operations, and a logarithm. It doesn't look like much but it compiles to 1658kB of code (~20% of the 8kB available in my targeted microcontroller ) and it takes a whopping 4678 instructions to calculate.
There's a rule of thumb which gets you to within 1deg of the actual dewpoint providing humidity is above 50%, and gets more accurate the closer you get to 100%:
Code:
dew_point = t-(100-h)/5;
1 floating point operation (the divide by 5) 268 bytes, and 407 clock cycles.
And since I was bored:
Code:
dew_point = t-((100-h)*410>>11);
no floating point operations 68 bytes and 74 clock cycles. The answer still comes in to the nearest degree. So I'm going down that path.
(Don't you love it how a computer finds it hard to divide by 5 but can efficiently divide by 4.995121912 ).
Or maybe a hybrid solution, if running from the computer do the full calc, and if running independently from the micro only do the approximation complete with screwy division.
Quote:
Originally Posted by AndrewJ
Gday Chris
I did something like this many years ago, and you will find it gets too complicated too quick, and too many cables go to one spot.
Have attached piccies of a unit i made up for fun that could
a) Have one DewHeater channel controlled via several means
including using dewpoint, defined PWM duty cycle or auto temp delta mode. It doesnt come on till you get within a set delta from the dewpoint.
b) Have 4 secondary PWM channels that could be manually controlled
c) Have regulated 8V and 12V outputs for my cameras
d) Have a focusser controller
e) Have a user settable menu system
It worked OK, but in the end, i split up the process and used dedicated units for each of the functions
Looks quite neat. Ultimately I'm going to have a split between complicated units too, and I'm looking at maybe reduced functionality away from the computer so I can offload complicated stuff to software. Focus will be on it's own microcontroller too. I'm not sure what the problem is with cables going into one spot, that is exactly what I'm going for. 1 spot on the OTA so there's no risk on tangles when slewing. The only cables coming off my scope/mount will be primary and backup power.
Quote:
Originally Posted by AndrewJ
As per redbeard, i also put my primary dew heater wires behind the corrector, but my ( insulated) dewshield also goes right back over the OTA as far as possible to retain as much dewheater heat as possible in the OTA. I also use dallas 1 wire temp probes and the system works quite well with much lower current draw than exposed units.
I know the feeling. I DIY'd my dewstrap with some nichrome wire. Did the job well but at astrofest I couldn't get enough heat into my scope because it was literally wire held on the OTA by tape, like yours except a single wire. The wire was hot but my scope was cold. H0ughy lent me his dew strap but I didn't actually even have to turn it on. It just had to be there to prevent losing heat to the environment for my piece of wire to do it's job. Now it's insulated with a neoprene strip.
A double is still a float, just a double precision float is 64bits long instead of 32bits. Any floating point operation is very expensive on an Arduino or AVR as they don't have a floating point arithmetic unit unlike say the CPU in your computer. Simply adding 2 doubles takes around 230 instructions. The fact you find a double works where a float doesn't may point to a compiler issue.
For efficient code you want to as avoid using any floats single or double (which means no decimal places) and avoid performing any math which results in a division that has a decimal place. Hence in the above code the /5 is an expensive instruction however the *410>>11 is not (this is the same as *410/2048 which is divide by 4.99512 so in our application effectively the same).
What "noise" are you talking about? You talking about ringing from the FET overshooting? You talking about actual radio noise being emitted every time the FET switches?
To limit the power loss you need two things, 1) a FET with a low Rds_on value (the resistance when fully on), and 2) you need to move through the linear state as quickly as possible into saturation. The longer the FET takes to switch from off to saturated the more power is lost. This can be achieved by either reducing the switching frequency (MOSFET power-loss becomes a big issue at high frequencies), or by increasing the rise time of the MOSFET gate (using a fast push-pull driver at the output of the microcontroller). If they are covered there's a chance you're not saturating the MOSFET.
A double is still a float, just a double precision float is 64bits long instead of 32bits. Any floating point operation is very expensive on an Arduino or AVR as they don't have a floating point arithmetic unit unlike say the CPU in your computer. Simply adding 2 doubles takes around 230 instructions. The fact you find a double works where a float doesn't may point to a compiler issue.
For efficient code you want to as avoid using any floats single or double (which means no decimal places) and avoid performing any math which results in a division that has a decimal place. Hence in the above code the /5 is an expensive instruction however the *410>>11 is not (this is the same as *410/2048 which is divide by 4.99512 so in our application effectively the same).
What "noise" are you talking about? You talking about ringing from the FET overshooting? You talking about actual radio noise being emitted every time the FET switches?
To limit the power loss you need two things, 1) a FET with a low Rds_on value (the resistance when fully on), and 2) you need to move through the linear state as quickly as possible into saturation. The longer the FET takes to switch from off to saturated the more power is lost. This can be achieved by either reducing the switching frequency (MOSFET power-loss becomes a big issue at high frequencies), or by increasing the rise time of the MOSFET gate (using a fast push-pull driver at the output of the microcontroller). If they are covered there's a chance you're not saturating the MOSFET.
I think you've covered it. Definitely an Arduino compiler issue. Would not compile using float in some circumstances. My program isn't extensive so I'm happy to accept the additional bits, and because I'm dithering pwm either side of setpoint temperature the decimal places are handy.
Both types of noise. I think I've met the switching frequency and overshoot issues in that case with a snubber circuit and inductor, but perhaps I need to shield the TEC wires as well. FET is logic level Vgs 4.5v, rds on ~1.3 - 1.4 milliohms. I'm not using a gate driver. Nice to know I'm on the right heading with this stuff.
Overshoot and ringing are a side effect of a crazy fast switching response which is usually the result of wanting to waste as little power as possible in the MOSFET. To get that kind of noise you need some kind of reactance (capacitance or inductance) either from components, cables, or even the MOSFET itself.
A correct snubber can help. An incorrect snubber will simply make it worse.
How fast are you switching? Are we talking Hz or kHz? The other way around the issue is to slow everything down if the application permits. If you half the switching frequency then you half the powerloss in the MOSFET due to switching. With the new capacity you can slow the speed at which the MOSFET turns on which using a very gentle RC circuit at the gate of the MOSFET. This may eliminate the ringing even without a snubber.
Exactly what I learnt in my last lesson in Micros lecture only last week. I was amazed the amount of code required to do floating point calculation compared to integer based calculation.
One disadvantage I found which will have an affect more on Arduino platforms is the integer based calculation quickly use up 8, 16 and 32 bit integers. So the best platforms are high speed 32 bit processors now. Freescale have a function called umuldiv() that is specifically catered for integer based floating point calculations and just places two integers and a scaling factor.
I am steering away from Arduino platforms for more complex application and starting to other platforms like Freescale and dsPIC and PIC32.
Some of the development boards I have a super powerful and nice to program plus unusually cheaper than Arduino. The best I have for is the PIC EasyFusion v7 and the C compiler for great development, while the nice small platform solution is the Freescale KL25z which only cost $29.00 and has Arduino compatible headers.
I am sure there are plenty of development platforms out there that are just as good though, but i have too many including Beaglebone Black and other smaller stuff. I am not really interested in the Beaglbone though.
Another really really cool platform is the PSoc4 platform which as a brilliant IDE that is component based and I believe super easy to develop. I will consider this as a possible option after completing this semester.
Quote:
Originally Posted by Garbz
For efficient code you want to as avoid using any floats single or double (which means no decimal places) and avoid performing any math which results in a division that has a decimal place. Hence in the above code the /5 is an expensive instruction however the *410>>11 is not (this is the same as *410/2048 which is divide by 4.99512 so in our application effectively the same).
Another really really cool platform is the PSoc4 platform which as a brilliant IDE that is component based and I believe super easy to develop. I will consider this as a possible option after completing this semester.
ARM seems to be the way to go for bigger stuff. I've heard good things about Propeller too. I'm not using Arduinos for this stuff though. In terms of efficiency they have worse to worry about than floats. Did you know digitalWrite(1,HIGH) takes 55 clock cycles to complete? PORTD |= _BV(1); takes 2 cycles. If you're familiar with the internal workings of AVR chips then the Arduino platform adds needless overhead. I will however be using an AVR of some description because they are cheap as chips and I have the tools here to program them.
Oh I understand now! You're using it to control a TEC. For some reason I was still in dewstrap mode and was trying to figure out why on earth you're switching faster than about a couple of times per second. A telescope has an incredible amount of thermal mass so there's no reason to switch at a frequency above 1-2Hz.
That said a TEC should have considerable thermal mass so you shouldn't need to switch that fast. A few options are writing a subroutine with a series of delays, or using one of the pulse width modulators with a really slow clock cycle which can always be slowed down further by counting in a loop i.e. if (counter > 500) {change output and reset counter} else counter++; That can get you down to really slow frequencies
Looking at your circuit though you're running a MOSFET with 5V at the gate and 12V at the drain. To switch it on fully you need to be selective of your MOSFET. It could be you're never actually saturating the MOSFET if the Vgs threshold voltage of your chosen MOSFET is too high. This may cause a lot of heating. In your circuit for instance an IRF510 would dissipate 3W average, and an IRF1405 0.5W. You can verify this is happening by putting 5V at the gate (continuously) and measuring the voltage from Drain to Source. If it's not effective zero then you're not saturating the MOSFET and you're losing power across it. That MOSFET should not need a heatsink.
That said a TEC should have considerable thermal mass so you shouldn't need to switch that fast. A few options are writing a subroutine with a series of delays, or using one of the pulse width modulators with a really slow clock cycle which can always be slowed down further by counting in a loop i.e. if (counter > 500) {change output and reset counter} else counter++; That can get you down to really slow frequencies
I might get hold of a Teensy 3.0 to analog write the pwm frequency for my next project. In the meantime I'll look at a sub routine, as suggested and change pwm pin to 3 - 1khz instead of 3khz. Teensy's are intended to be programmed directly with C++. I am slowly working through the tutorials.
Looking at your circuit though you're running a MOSFET with 5V at the gate and 12V at the drain. To switch it on fully you need to be selective of your MOSFET. It could be you're never actually saturating the MOSFET if the Vgs threshold voltage of your chosen MOSFET is too high. This may cause a lot of heating. In your circuit for instance an IRF510 would dissipate 3W average, and an IRF1405 0.5W. You can verify this is happening by putting 5V at the gate (continuously) and measuring the voltage from Drain to Source. If it's not effective zero then you're not saturating the MOSFET and you're losing power across it. That MOSFET should not need a heatsink
.
The freetronics smd mosfet runs a little warmer than the IRF2804 I have, although freetronics advertise it as logic level Vgs 4.5v - I think the rds on is not as low as the IRF. The heatsink is a precaution more than being absolutely necessary. I will try the saturation test on all the MOSFETS I have lying around.
The freetronics smd mosfet runs a little warmer than the IRF2804 I have, although freetronics advertise it as logic level Vgs 4.5v - I think the rds on is not as low as the IRF.
Well I have another gotchya for you. Firstly remember the 100 and 750 ohm resistors mean you never actually produce the logic level voltages at the gate You get up to 4.41V at the gate. Secondly the spec in the datasheet for Vgs_thresh is usually specified under the condition of Vgs = Vds. I.e. the value for Rds_on is only true if you're above the threshold voltage and you're putting the same voltage through the gate as across the MOSFET.
The IRF2804 has a fairly well defined model. A spice simulation shows that when you put 5V into your circuit Rds = 0.075ohm when Vds=5V which is good, BUT Rds = 0.474ohm when Vds=12V as in your case. At steady state with your circuit if the MOSFET were IRF2804 you'd burn about 480mW into the MOSFET. If you removed the 100 ohm series resistor the power in the MOSFET drops to 170mW.
If you're aiming to reduce power consumption you may want to look for a MOSFET which saturates more easily. Or another option is switch the gate with 12V instead of 5V using a gate driver like the one I attached. That reduces your 470mW to 30mW (actually 70mW given the 3 other components which now dissipate power too). Just be aware if you do do something like this that it inverts your output (i.e. MOSFET is ON when Arduino output is OFF).
That is good stuff. I understand the issue more clearly, for sure. Shouldn't be too difficult to fit a gate driver circuit in the box. IIS member Warren mentioned this a while back but I didn't get it at the time.
I need to get to the bottom of pwm frequency - resolution seems self explanatory. I estimate it takes several seconds to indicate an increase in temperature of the cold finger.
I am guessing that 60hz is adequate, perhaps less. The strategy is to estimate the pwm value linearly for setpoint temperature and dither either side to maintain temperature. Changes in ambient air temperature are used to recalibrate pwm values - avoiding high, low switching.
EDIT:
Quote:
The TEC drive voltage, however, does not need to be DC—a suitably fast (kilohertz range) pulse-width modulated (PWM) signal will also work as long as the PWM frequency is faster than the TEC's thermal time constants. http://www.sensorsmag.com/electronic...ric-cooler-993
Huh why can't I edit my original post... I was hoping to use it to update progress. Oh well I guess not.
Anyway progress update:
Initial schematics completed
Parts on order
Presently testing DHT22 humidity sensor.
So far we are moving well. I still need to test the prox switches, dew controller, and relay drivers.
Have yet to come up with how to do a USB reset but right now I think I'm going to try holding the data pins low on the way to the USB hub. If the devices don't report in several times a second they drop off and may be forced to reconnect.
I've decided to try and drive the computer directly and switch to an ATMEGA32u4 chip with built in USB controllers. This may not work. I've no experience with how much overhead a USB library takes but I guess we'll find out soon enough.
Also I've decided to drive the relays via an I2C port expander. This will make designing the circuit board easier at the cost of about $2.00.
Hi Chris, most excellent work...one thing I noticed...DEW controllers using RCA connectors.
You have designed the system as a low side switch I'm not sure if you are controlling the TC4427 outputs with PWM (I suspect you are) or just switching the MOSFETs on/off.
If you are PWM controlling the FETs then...if applied power driving the mosfet is low, the outside shield of the RCA can approach +12V.
Touch this against any part of the mount (earth) then there is a short cct to earth.
Somewhere back in the dark ages someone used RCAs for DEW strap connectors and this became a pseudo standard...a poor standard at best, especially if the RCA plug is a metal one, like some used by Kendrick. Although I have seen some of these covered with heatshrink.
The best fix.... use a high side switch MOSFET (wire the RCA shield to grnd, thus will always be grnd) like AUIR3315 (or called IR3315), 3~30A programmable shutdown (via resistor) high side switch...even has rev polarity protection...no fuse needed!
I have tried them...they work a treat and impossible to destroy once I shutdown set. Specifically they are designed for Automotive work, thus ideal for +12V systems. There is a range of these FETS, IR3313 ~IR3317 that have varying properties specifically the IR3315 is best (~$3.9 in to220 format) due to the low on rds and I shtdwn can be as little as 3A. If a dew strap is using more than 3A...then well yikes!
Thanks Brendan. Great catch. I was working under the assumption of plastic RCA connectors and recessing the RCA plugs so once they've mated there wouldn't be any metal exposed. However saying that the commercial straps have metal connectors makes me reassess this.
The only reason I went lowside switching is due to the low RdsON, good switching characteristics of NMOS vs PMOS and low part count. Power dissipation is critical as I was targeting a SOT-23 package.
I'll reassess and see if I can switch the highside like you suggest with a suitably small package.
/EDIT: Actually that's not quite true, the advantages of lowside vs highside switching were mostly eliminated when I added the driver IC. Should be trivial to change :-)
Yeah low on Rds is vital this is why most people use N channel fets...as well as common and cheap
However, over that last few years some interesting P channel low on rds fets have become available. Specifically as these have the Ishutdown sense. Meant to say IRF also has application notes, AN-1118 or AN-1058 and design tip DT99-4/5/6 for this family of fets.
Since on rds is a function of current passed but I found 12V @4A absolutely no problem for the IR3315, doesn't get warm at all. While these are low on rds there are no small packages for this family. You might get some P channel low on rds capable for the current drain in the SO8 packages though, but you lose the intelligent fet I shutdown, all depends on what you want.
Of course this is a worst case fix and probably not generally necessary, but, some users do use RCA extensions or metal shield connectors, they will find out the hard way. Also some plastic RCA connectors have exposed parts of the shield.
Gawd...how this become the std for dew strap connectors .....beats me!
Last edited by wasyoungonce; 09-11-2013 at 03:33 PM.
It looks good but it's not available from my usual sources for components either. Given the costs I'm working here I'm expecting shipping will cost about half as much as the entire project so I'm trying to avoid multiple sources for components.
On the upside I have found a p-chan mosfet from NXP with low RdsON. Only problem is I'm at max ratings for gate switching voltage. That's the other issue going highside, it's relatively straight forward to control gate voltage with reference to ground but not so easy with reference to Vcc, not when using an off the shelf driver anyway.
It looks good but it's not available from my usual sources for components either. .......
On the upside I have found a p-chan mosfet from NXP with low RdsON. Only problem is I'm at max ratings for gate switching voltage. That's the other issue going highside, it's relatively straight forward to control gate voltage with reference to ground but not so easy with reference to Vcc, not when using an off the shelf driver anyway. More research needed :-)
Hi Chris...RS components has free shipping on parts....Element14 isn't that expensive to ship either and free over $45 order. Yes ordering from multiple sources is a pain and these intelligent fets are not cheap. Pity they are not logic level gates!
I control switched these fets using a BS170, small TO92 fet (it's gate ref to grnd) so easy to do and kept rev polarity protection. Your using Fet driver ICs...much better...keeps gate capacitance really low.
Sorry to throw a spanner into the works part selection and cct design trials can be quite expensive...this I do know!
What you have done is excellent and should be congratulated!
A bit beyond my skills. Shall follow with interest.
) and it takes a whopping 4678 instructions to calculate.
).
