Syksyiset pimeät saapuivat taas, valitettavasti syksyn matalapaineetkin tulivat samalla pilviverhoineen. Afrikan tropiikissa alkunsa saaneiden myrskyjen jäänteet kulkevat pitkän kiertoreitin Karibian kautta päätyäkseen Siperian aroille. Siinä missä isot matalapaineet kulkevat parissa päivässä koko USAn itärannikon korkeuden, kestää niillä yhtä kauan ohittaa kapea Suomi, seuraavan rintaman hönkiessä jo niskaan Atlantilla. Tästä seurauksena Suomessa ei syksyllä ole kovinkaan montaa kirkasta yötä, peräkkäisistä kirkkaista öistä puhumattakaan. Matalapaineet tuovat myös mukanaan runsaasti sadetta ja ne harvat kirkkaat, kuulaat päivät päätyvätkin usein sumuisiin öihin, jolloin kaikki peittyy kasteeseen.
Tähtikuvauksen kannalta sumu on ilkeää, sillä sen läpi ei näe kovin hyvin. Kasteen kanssa on opittu elämään lämmittämällä kohti taivaita osoittavaa optiikkaa niin, että sen lämpötila pysyy kastepisteen yläpuolella. Ilman lämmitystä kirkaalla säällä optiikan pinta jäähtyy alle ympäröivän ilman lämpötilan säteilyjäähtymisestä johtuen, täten kosteassa ilmassa jäähtyminen jatkuu alle kastepisteen. Pahimmillaan kosteutta voi kertyä niin paljon, että linssi voi peittyä kokonaan veteen. Veden suuresta ominaislämmöstä johtuen kertyneen veden poistaminen vaatii paljon energiaa, mutta jo melko pienellä lämmityksellä voidaan pitää optiikan pinta kastepistelämpötilan yläpuolella. Liian suurta määrää lämpöä puolestaan ei kannata käyttää, koska tällöin optiikan sisäiset lämpötilaerot voivat aiheuttaa kuvanlaatuoa merkittävästi huonontavia konvektiovirtauksia putken sisään tai pahimmillaan jopa linssin ulkopuolisen ilman pyörteilyä.
Näitä optiikan etuelementtien lämmittimiä kutsutaan huurrepannoiksi, ja markkinoilla on useita erilaisia ja erihintaisia ratkaisuja. Lisäksi liiallisen lämmöntuoton estämiseksi usein käytetään säädettävää ohjainta, jolla vallitsevan ilmankosteuden perusteella säädetään lämmitystehoa juuri ja juuri riittäväksi. Nykyään kaupalliset ratkaisut perustuvat lähes yksinomaan paksukalvovastuksesta, jonka käyttäminen kotikonstein on turhan hankalaa, ja saatavuus pienissä erissä lähes nolla. Tee-itse -henkisille on kuitenkin kaksi muuta toimivaa tekniikkaa, yleisin ratkaisu on juottaa suuri määrä vastuksia rinnan tai sarjaan ja toinen tapa on käyttää vastuslankaa. Sopivan tehontarpeen (ja siten vastuksen) laskemiseen löytyy helppo kaava, P = 0.0606 x D +1.18, jossa D on lämmitettävän elementin halkaisija millimetreinä ja lopputulos on watteja. Tarvittavien vastusten laskemista varten on tehty myös kätevä taulukkolaskentapohja. Suomen oloissa kannattaa tehdä hieman ylitehokas lämmitin (kosteimpina kevättalven öinä sulavasta hangesta vapautuva vesihöyry tuottaa helposti kaiken jäähän kuorruttavat olosuhteet), sillä tehoa on helpompi säätää pienemmäksi kuin suuremmaksi.
Huurrepantojen säätöelektroniikkaa on saatavilla vaihtelevin hinnoin, kalleimpien ollessa useita satoja euroja. Tee-itse ohjaimen saa tehtyä helpoimmillaan muutamalla analogisella komponentilla 555-piiristä PWM-kytkennässä, jolla ohjataan tehotransistoria tai FETtiä, pulssinleveyttä säätämällä voidaan rajoittaa huurrepannan keskimääräistä lämmöntuottoa lähes nollasta täyteen tehoon. PWM-taajuus kannattaa pitää joko hyvin matalana (alle puoli hertsiä) tai kohtuullisen korkeana (muutama kHz), tällöin kuorman kytkennästä aiheutuvat virtapiikit on helpompi suodattaa pois häiritsemästä herkkiä kuvausinstrumentteja. Toinen harrastajan helposti saavutettavissa oleva säätötapa on tuottaa PWM-signaalia mikrokontrollerilla, etuna tällöin on kohtuullisen helppo lisätoimintojen saaminen, esimerkiksi lämpötilan ja ilmankosteuden mukaan automaattisesti säätyvä teho tai tietokoneohjaus USBn kautta. Moderneilla mikrokontrollereilla ulkoisten komponenttien tarve on varsin pieni ja nykyään löytyy myös hyviä TTL-tasoilla ohjattavia FETtejä, jolloin erillistä FET-ohjainpiiriä ei edes välttämättä tarvita.
Oma automaatioprojektini käyttää USB-ohjattua mikrokontrolleria tuottamaan useita PWM-ohjattuja signaaleja, kaksi on varattu huurrepannoille (toinen kuvausoptiikalle, toinen ohjausoptiikalle), yksi valopaneelille ja kolme on varalla. Lisäksi voin kytkeä mikrokontrolleriin 1-wire -protokollaan käyttäviä antureita mittaamaan kosteutta ja lämpötilaa, sekä erilaisia mekaanisia käyttöliittymäkomponentteja tietokoneettoman käytön säätimiksi. Taloudellisesti mikrokontrolleripohjaiset projektit eivät kannata, jos laskee omalle ajalleen minkäänlaista hintaa, mutta harrastuksena ne tuovat mukavan lisän kuvausöiden kokemukseen.
2011-09-26
2011-09-21
William Optics Flattener comparison
I recently acquired the William Optics Adjustable Flattener Reducer 4 as I wasn't too happy with the image quality I was getting from the local astro-club's William Optics FLT-110 telescope with the William Optics Focal Reducer/Field Flattener III.
Although I had used the WO FR/FF III the last season while using the FLT-110, I noticed my star shapes were way off considering how good the scope was supposed to be. I had put the blame on the less than stellar polar alignment of the mount, especially since the mount was secured to the pier and aluminum base plate only by the central bolt. Needless to say, as the temperature during the imaging season fluctuates between +15 C and -35 C, the bolt comes loose due to thermal effects and the mount starts to drift off. During the summer I built a new observatory for a new EQ6 our club had purchased and I made sure the polar alignment won't move. With the mount aligned I discovered that the horrible looking stars were not caused by polar alignment but an optical issue instead. I played around with the flattener to sensor distance and the star images improved a bit, but the stars near border turned from warp effect to cross shapes. Reading thru forums I found out I'm not the only one faced with the same issue on the FLT-110.
After a bit of research I placed an order for the William Optics AFR-4, as it had a reasonably long back focal distance, and more importantly, the flattener lens group location can be moved for 20mm by rotating the lockable adjustment ring. The various posts on forums recommended a distance of 73.5mm for the FLT-110, so I made a rough estimate and started waiting for a break in the clouds. A week later I took another set of frames of the Sh2-101 () so I could make a direct comparison on the images produced by the flatteners using the same equipment. Incidentally the sensor distance was quite good with my first guess and now the sensor tilt is the prominent image quality reducing factor. I was able to reach 1.05px HFR stars at center with the stars in corners were around 1.08 pixels HFR. The image scale is a bit tighter than with FR/FF3, the field of view is 2 arcmin narrower at 97.2 arcmin with the AFR-4 compared to 99.0 arcmin with the best star shapes on FR/FF-III. Of course the field of view with reducers depends on the sensor distance, so the final figure after more adjustments is subject to change.
So far the only negative aspect has been a bit of flare around brightest star in the field, but it could be partly caused by the humidity, as the air was far from clean on the test night. Hopefully more to follow on the experience with AFR-4 as the imaging season 2011-2012 progresses and I reach a better optical alignment.
Although I had used the WO FR/FF III the last season while using the FLT-110, I noticed my star shapes were way off considering how good the scope was supposed to be. I had put the blame on the less than stellar polar alignment of the mount, especially since the mount was secured to the pier and aluminum base plate only by the central bolt. Needless to say, as the temperature during the imaging season fluctuates between +15 C and -35 C, the bolt comes loose due to thermal effects and the mount starts to drift off. During the summer I built a new observatory for a new EQ6 our club had purchased and I made sure the polar alignment won't move. With the mount aligned I discovered that the horrible looking stars were not caused by polar alignment but an optical issue instead. I played around with the flattener to sensor distance and the star images improved a bit, but the stars near border turned from warp effect to cross shapes. Reading thru forums I found out I'm not the only one faced with the same issue on the FLT-110.
After a bit of research I placed an order for the William Optics AFR-4, as it had a reasonably long back focal distance, and more importantly, the flattener lens group location can be moved for 20mm by rotating the lockable adjustment ring. The various posts on forums recommended a distance of 73.5mm for the FLT-110, so I made a rough estimate and started waiting for a break in the clouds. A week later I took another set of frames of the Sh2-101 () so I could make a direct comparison on the images produced by the flatteners using the same equipment. Incidentally the sensor distance was quite good with my first guess and now the sensor tilt is the prominent image quality reducing factor. I was able to reach 1.05px HFR stars at center with the stars in corners were around 1.08 pixels HFR. The image scale is a bit tighter than with FR/FF3, the field of view is 2 arcmin narrower at 97.2 arcmin with the AFR-4 compared to 99.0 arcmin with the best star shapes on FR/FF-III. Of course the field of view with reducers depends on the sensor distance, so the final figure after more adjustments is subject to change.
So far the only negative aspect has been a bit of flare around brightest star in the field, but it could be partly caused by the humidity, as the air was far from clean on the test night. Hopefully more to follow on the experience with AFR-4 as the imaging season 2011-2012 progresses and I reach a better optical alignment.
2011-09-17
But what to call it?
My automation project for tedious astrophotography tasks reached a new milestone today as I assemebled my new control board for functionality tests. The board has two main duties, one is to control the dew-heater bands and the other, main reason for this, is to control the EL-foil luminosity while taking flat frames. My astro-camera has a mechanical shutter with a limited speed, so the flat frame exposures have to be at least 2.5 seconds to eliminate the shutter movement below a few ADUs. As the LRGB filters pass a lot of light, the light has to be fairly dim to reach such a long exposure with a sensitive camera. Unfortunately, the narrow-band filters are just that: narrow. Using the same low setting on a 7nm SII filter (deep red near infrared) the not-so-warm light of the EL foil is diminished to extinction resulting in almost one minute flat frame exposures. Taking 30-60 exposures at one minute each doesn't sound like something I want to do at 6am, I can now make the light brighter for the narrow band filters keeping the exposure shorter, and brightening the light for wideband filter for extending the exposure.
I drew the board in KiCad a while ago, and kept upgrading new features, most notably the extra IO-lines were added when I noticed I had an extra ATMega644. A bit of an overlook at the datasheets left me with a grave error in the schema, I had connected the VCCIO pin of the FT232RL to the VUSB instead of VCC network, so I had to cut the trace on the board and jump the SOIC-28 leg to VCC on the ICSP header. Unfortunately I realized this only after my order had already been sent back from iTead Studios, so hacking was necessary.
This would have been relatively easy, but I had found out that the ATMega644 can run an Arduino compatible bootloader called Sanguino and all I needed was a way to reset the board while programming. I had forgotten the reset switch completely, although one can pull down the reset pin on the ICSP just the same. The Arduino also supports auto-reset over FT232RL by connecting the DTR# -pin to ATMega reset thru a series capacitor (pulsing the reset). Not so fortunately the DTR# -pin is one pin over from the VCCIO and in between there's RST# pin that I don't want to touch at all. Plenty of light, magnification and a narrower soldering tip was used to make the bits of wire go to the right spots without solder bridges.
The auto-reset isn't fully reliable, I might have used a wrong value cap in the series. The Sanguino bootloader installation made almost miss a heart beat, as it didn't say what it was doing while writing the bootloader. As you can see, my board relias on the internal clock source of the ATMega, and the first thing Arduino IDE does when flashing the bootloader is setting the fuses to use an external clock source. This caused a few minutes of frustration wondering why nothing works, until I realised my ATMega needed a temporary heart transplant. With a 12MHz oscillator I was able to reset the fuses and then it was time to adjust the Sanguino bootloader code and flashing settings to match my setup. Now I'm able to upload Arduino sketches onto my board and they run jst fine, serial data receive excluded (this seems to be a known bug in Sanguino).
My actual test-code is just basic C-code with avr-libc and avr-gcc. Being able to upload the code thru the Arduino bootloader makes field-upgrades easier, though, since now there's no need to carry the programmer device along. The test-code sets the PWM channels at 50% duty cycle, the fast channels at 4kHz, slow channels at 13Hz and the servo channels at 50Hz with 16bit OCR1 registers for accurate positional control (ICR is set at 19999). The board takes around 10-20mA when operating without load, the possible servos are the only external load on the VCC line keeping the LM7805 from heating up too much. The FETs are N-channel IRF540N, saturating at 4.7 volts, so I can drive them directly with the uC outputs with minimal protective circuitry around the FET. Possible flywheel diodes for inductive loads are omitted, they can be added closer to load if necessary. A bit of probing and coding proved that the circuit works now pretty much as planned, I was able to connect over USB-serial to the uC and change the PWM duty cycle from my computer, and the EL-foil changed its brightness just as expected (non-linearly). For the EL-foil I'm also using a current limiting resistor inline with the load, the 2.2ohm 50W resistor heats up to around 20C above ambient, very close to my estimates on theoretical power dissipation.
Now it's time to call it a day/night, start thinking about those free IO-lines on the side and plan the firmware and PC-side code a bit further into reality.
Oh, what to call it? The ability to use the Arduino IDE after all (when the Sanguino UART bugs are fixed) kind of necessitates something Arduinoish and the astrophotography background should somehow be present in the name as well. Thusfar the best name I've been able to come up with is Astruino, and that's what I shall call it from now on.
I drew the board in KiCad a while ago, and kept upgrading new features, most notably the extra IO-lines were added when I noticed I had an extra ATMega644. A bit of an overlook at the datasheets left me with a grave error in the schema, I had connected the VCCIO pin of the FT232RL to the VUSB instead of VCC network, so I had to cut the trace on the board and jump the SOIC-28 leg to VCC on the ICSP header. Unfortunately I realized this only after my order had already been sent back from iTead Studios, so hacking was necessary.
This would have been relatively easy, but I had found out that the ATMega644 can run an Arduino compatible bootloader called Sanguino and all I needed was a way to reset the board while programming. I had forgotten the reset switch completely, although one can pull down the reset pin on the ICSP just the same. The Arduino also supports auto-reset over FT232RL by connecting the DTR# -pin to ATMega reset thru a series capacitor (pulsing the reset). Not so fortunately the DTR# -pin is one pin over from the VCCIO and in between there's RST# pin that I don't want to touch at all. Plenty of light, magnification and a narrower soldering tip was used to make the bits of wire go to the right spots without solder bridges.
The auto-reset isn't fully reliable, I might have used a wrong value cap in the series. The Sanguino bootloader installation made almost miss a heart beat, as it didn't say what it was doing while writing the bootloader. As you can see, my board relias on the internal clock source of the ATMega, and the first thing Arduino IDE does when flashing the bootloader is setting the fuses to use an external clock source. This caused a few minutes of frustration wondering why nothing works, until I realised my ATMega needed a temporary heart transplant. With a 12MHz oscillator I was able to reset the fuses and then it was time to adjust the Sanguino bootloader code and flashing settings to match my setup. Now I'm able to upload Arduino sketches onto my board and they run jst fine, serial data receive excluded (this seems to be a known bug in Sanguino).
My actual test-code is just basic C-code with avr-libc and avr-gcc. Being able to upload the code thru the Arduino bootloader makes field-upgrades easier, though, since now there's no need to carry the programmer device along. The test-code sets the PWM channels at 50% duty cycle, the fast channels at 4kHz, slow channels at 13Hz and the servo channels at 50Hz with 16bit OCR1 registers for accurate positional control (ICR is set at 19999). The board takes around 10-20mA when operating without load, the possible servos are the only external load on the VCC line keeping the LM7805 from heating up too much. The FETs are N-channel IRF540N, saturating at 4.7 volts, so I can drive them directly with the uC outputs with minimal protective circuitry around the FET. Possible flywheel diodes for inductive loads are omitted, they can be added closer to load if necessary. A bit of probing and coding proved that the circuit works now pretty much as planned, I was able to connect over USB-serial to the uC and change the PWM duty cycle from my computer, and the EL-foil changed its brightness just as expected (non-linearly). For the EL-foil I'm also using a current limiting resistor inline with the load, the 2.2ohm 50W resistor heats up to around 20C above ambient, very close to my estimates on theoretical power dissipation.
Now it's time to call it a day/night, start thinking about those free IO-lines on the side and plan the firmware and PC-side code a bit further into reality.
Oh, what to call it? The ability to use the Arduino IDE after all (when the Sanguino UART bugs are fixed) kind of necessitates something Arduinoish and the astrophotography background should somehow be present in the name as well. Thusfar the best name I've been able to come up with is Astruino, and that's what I shall call it from now on.
2011-09-07
Pelican Nebula (IC 5067/5070)
The Pelican Nebula is located in Cygnus right next to North America Nebula, and it is in fact the same cloud of glowing hydrogen gas. From our point of view the cloud is split in two forming the more photographed N-A nebula and the Pelican nebula by the dark dust between the Earth and the gas cloud.
The dark dust has a lot of intricate detail I wanted to bring forward by increasing the local contrast using a contrast mapping algorithm.
Via Flickr:
The Pelican nebula in Hydrogen alpha.
Tone-mapped to show the rich low-contrast details, although the "pelicanness" is reduced a bit in the process.
Total exposure: 1h30m.
The dark dust has a lot of intricate detail I wanted to bring forward by increasing the local contrast using a contrast mapping algorithm.
Via Flickr:
The Pelican nebula in Hydrogen alpha.
Tone-mapped to show the rich low-contrast details, although the "pelicanness" is reduced a bit in the process.
Total exposure: 1h30m.
Subscribe to:
Posts (Atom)