NigeB

A bit rough but dodging moonlight and rain storms - here is M63. Details: Celestron Edge 14 with 0.72 reducer Atik 640ex + EFW2 Mesu 200 mount Processed in PixInsight L 10.2 hrs, R 3.2 hrs, G 3.5 hrs, B 2.5 hrs Second attempt at processing the data and still lots of work to do, I may update if I manage to fix all the problems before the challenge is up!

That's a really nice analysis @Xilman! Would be interested in knowing what level of detection is represented in this image (i.e. sigma), and what levels in the individual subs are. Just curious. Regardless, really nice work, you've inspired me to try something similar. Did you do this from your UK or La Palma site? Nigel

This is an interesting thread and a nice reflection on the nature of the SGL community - on a different astronomy forum, this discussion might have descended into acrimony and thread-locking within the first page. My own perspective as a Tak owner: I had a TOA-150 which I loved. Long before I got it, a Tak for me was an aspirational thing - my wife would say obsessional. I've have had many scopes in the 45+ years I've been actively into astronomy, but never a Tak. I knew it was something I wanted to try. I liked the reports of looking through them, the images taken with them, the perception that in terms of quality it didn't get much better (note, not "THE BEST" - which is subjective and impossible to determine - but at least, up there among the best, which I would argue is at least less debatable - but read on). And I liked the appearance and the engineering of the instruments - not necessarily because it was better than any other brand - it was just an aesthetic that appealed to me - and why not; this is a hobby - if some people enjoy looking at as well as through, then that's just fine. Some people spend serious money putting paintings on their wall, I find equal artistic merit in a well engineered and nicely designed telescope. So when I reached the time of life that provided some disposable income, I scratched the itch and bought a TOA-150. It didn't disappoint. Did I do a quality-per-£ analysis when it arrived? No, I just knew that I was happy with the views and images it gave me; it lived up to my expectations, and I did not regret the money I'd spent. But I was curious to see how it stacked against my other telescopes. After a couple of years of just enjoying the Tak, I decided it would be interesting to do some side-by-side comparisons with my other 'scopes, particularly a C11, Edge 14 and a Wave 80. In each case the TOA was mounted side-by-side with the other OTA so I could do simultaneous observations, with eyepieces selected to give similar image scales. On the whole I did this privately - I posted one comparison image, but this was really about satisfying my own curiosity - I had no interest in "proving" how good the Tak was, or by implication denigrating other makes. The outcome? As I explained to my wife, there was absolutely no way I could justify the cost of the Tak based on the performance I saw, from my site in the midlands of the UK. I could have bought all of my other scopes, for less than the price of the TOA. I'm not talking about the fundamental differences due to focal length, aperture or SCT vs refractor - those "3 inch Tak Beats 20" Plane Wave" posts are utterly pointless. I'm just talking about general experience. Yes, the Tak showed pin-sharp images - so did the Wave 80. Yes, the SCT showed fatter stars.... so did the Tak when I pushed the magnification up to the same level - but the SCT was brighter. Yes the deep sky images I obtained were somehow "more aesthetically pleasing" (to me) than the ones I got from my SCT. But so were the Wave 80 images - again, I think more to do with shorter focal length than optical quality. Was there a slight "edge" to the Tak? Possibly - and if I was observing from a world-class site with excellent seeing I might have managed to determine that more precisely. But that wasn't the point. If I was using rather than comparing then I would have been every bit as happy with the images coming from the other 'scopes, as I was from the Tak. So in a sense I did end up doing a cost-benefit analysis, and for me, the cost of the Tak could not be justified on performance grounds. As some on this forum will know, I sold my TOA-150 because of a coating issue that developed (much later). What did I do, knowing the outcome of that analysis? I replaced it with a TOA-150B - despite, and because of, all the points above. Once upon a time the gap between Tak (and similar "high end" makes such as AP), and other manufacturers was much wider, and the quality improvement that came with the price premium was much more distinct. But times have changed - the quality of optics coming from China is getting better and better. I've never looked through an Esprit 150, but looking at sites such as AstroBin - or posts from people here on SGL, suggests that the optical quality of the Esprit is in the same class, such that any noticeable differences are more likely due to seeing, processing, tracking, than intrinsic optical performance. I spoke to a professional optical expert who has worked on both makes (and on my first TOA), and his view of the optical quality of the Esprit seemed to be in agreement. Bottom line: I don't believe you will ever be able to justify a Tak on a cold, objective, cost-performance basis - not today. And perhaps as a consequence, the aspirational nature of the Takahashi brand is becoming less distinct and more challenged with time. You earn your money, and spend it on the things you want. If you decide to pay the premium for a Tak over similarly specified telescopes from other manufacturers, you should be clear that you do it for one reason only - because you want one. N

Hi Ed, Sure... Try this DropBox link: https://www.dropbox.com/sh/aaioncmahrge7fi/AACgmPbGzM8Csqus5qUmUP5Oa?dl=0 In there you should find the calibrated, corrected and co-added L,R,G,B and Ha files in FITS and PixInsight .XISF format. Best Regards Nigel

Agreed, this is an excellent discussion and I've just been reading the previous analysis of drizzle integration by @vlaiv. Bookmarked this one for future reference.

Hi Mike That's a really useful comparison. Clearly there's no substitute for a weather station right next to the observatory, but the general trend in the wind speed looks consistent, and I'd feel confident in using the API wind data on the basis of what you're showing. It makes sense that the gust data are different - those measurements must be strongly dependent on the local environment in which the sensors are mounted. (Aside: I speak as someone who, many years ago, received a text from a neighbour telling me how my home-made dome had just been seen floating across the fields. It was lifted clean off the walls and didn't touch the LX200 inside - despite there being about 30 cm clearance between dome and scope. The aluminium dome was dumped about 50 metres away. The cause was failure of the shutter, which flipped off, and allowed the wind to get inside the enclosure and lift it - but in any case, I regard wind measurement as essential now, along with some good clamps...). Where I'm less convinced about the API is the cloud monitoring. From what I've seen, the OpenWeather API can report >75% cloud, when what I see here is more like low altitude mist or very thin, high cirrus that I'd consider imaging through in some cases. I'd be very interested in seeing the comparison with your All Sky Camera, and perhaps implementing something similar if you find good results from it. I'm not yet convinced that I need to buy a physical weather station given how useful some of the API data seem to be - I see many good reviews of systems like AAG Cloudwatcher, but also plenty of discussions about sky clarity calibration etc, so it seems that neither solution is free of issues, but the API is at least free... I looked at the image-based approaches to cloud detection previously - I came across a solution from Tektite Skies that looked interesting: http://www.mcdougalltech.com/page1/page1.html Is this the approach you're taking? I'd be interested in hearing more about your system. Thanks Nigel

@Commanderfish Very nice! And don't worry about the heavy sustained cloud (which does seem to have arrived - thanks) - if you can't look through it, you can have almost as much fun looking at it...

Hi All, Many thanks for your comments ( @hughgilhespie that does look quite familiar!) @skybadger thanks for those suggestions. Interesting observation on the Hydreon - I went out yesterday when it was snowing and checked it - indeed, the telltale green light wasn't on, yet it's able to detect the slightest bit of rain. That makes some sense based on the detection method - a useful heads-up which I'll monitor carefully). Re: the battery, I've got the charge controller set so that the electronics are not powered between dawn and dusk, which improves the charge/discharge ratio somewhat. I've managed 5 open/close cycles of an evening so far but not tested how far I can go before it fails (the motor is drawing about 3 amps on average). Weather permitting I'll see how many times I can cycle this weekend during the day. Good point on the MPPT - I think the shutter charge controller is working well enough for the battery capacity, but I had hoped to run the 'scope, cameras and dome rotation from a 100 Ah battery, and the panel/charger really struggled to keep that battery topped up even with quite demand - the PWM charger could well be the weak point here so I'll try a MPPT unit - thanks for that pointer. One final point, what OpenWeather API are you using? I'm using the OneCall API and rain data is definitely included, and seems to track local conditions here pretty well. However, the "rain" keyword is not always present in the JSON structure - it's only there when there's a non-zero value for rain, at which point it appears in both the "Minutely" and "Hourly" sections of the JSON structure. So in the Python script, I use a "try" operator, and set the rain condition according to the value in the ["hourly"][0]["rain"]["1h"] field. Best Regards Nigel

Hi Alvin, That's a short question but the answer is perhaps a little longer... It's true that the central obstruction reduces the effective aperture, though there are other things in play that could have a bigger impact on performance. The amount of obstruction varies by telescope design, but ~30% reduction in area is fairly typical for a reflector. So in the case of the examples you give, a 90mm refractor has an area of pi*(90/2)^2=6362 square mm of unobstructed aperture , whereas the 114mm reflector has an aperture area of pi*(114/2)^2 = 10,207 square mm, but a 30% obstruction means that you only get 70% of that area - so that's 7144 square mm. It's still 12% more collecting area than the 90mm refractor, but all other things being equal I doubt you would see much difference (but read on...) There are a couple of other points to bear in mind. There may be a little bit more "loss" in the reflecting design than the refractor (mirror reflectivity tends to be a little lower than lens transmission), and that further narrows the gap between the refractor and reflector examples you chose if we're just considering how much light they collect. However there are other considerations. The angular resolution of the telescope goes as the diameter of the aperture as well, and in principle the 114mm reflector offers improved resolution over the refractor. The central obstruction does have some practical effect on that as well, but if the optical quality of the two telescopes is equal, and the reflector is well collimated, then the advantage is certainly real. My view is that based on the points above, then what the view through the eyepiece looks like (or the image, if you're using a camera) will be determined more by parameters such as the focal length of the telescope assuming that the optical quality of the two is comparable. And if the focal length is similar, then I would expect the views to be similar - again assuming optical quality is comparable in the two systems. If the reflector has a "spider" holding the secondary mirror, then it will produce diffraction spikes in the image, which the refractor won't do. Some people like the spikes, some don't - it's a personal choice, but the kind of thing that might persuade you to go with one over the other. So while I would not disagree with the statement you quote as a broad guideline, there are always other factors to consider, particularly when the two options are as closely matched as the ones you suggested. If there are specific models you're looking at, post the model numbers here - you'll get lots of advice from SGL members considering the specific details of the telescopes along with user experiences, and that is probably more useful in helping you to reach a decision. Best Regards Nigel

Hi All I've been into astronomy since I was a kid, but somehow I was oblivious to the existence of this fabulous place in Switzerland until earlier this month. It looks to me like the archetypal "fantasy observatory", teetering on a mountaintop. All that's missing from the image is the big refractor poking through the slit. The camera angle in these photos is carefully chosen - from other angles it's clear there is a significant building (and a substantial research facility) here, and it's not as precarious as it first seems. Still, it made me smile. I've hyperlinked the photos to their sources. Sphinx Observatory: http://www.hfsjg.ch/en/home/ Nigel

😂 Excellent choice... I see we're clangers in quite close proximity as well...

+1 for Baader fluid, but I also use Purosol, which is a bit pricey once you add shipping, but a couple of bottles will last most of a lifetime... One point on the Baader lens cloth - don't use fabric softener, and do use a non-bio powder/liquid. See this earlier SGL thread: N.

Hi All, After months of faffing about, I've finally got a reliable, working solution to full automation of my 2.7m Pulsar dome which I thought I'd share here. The automation of rotation using a timing belt and pulley is well documented elsewhere. In particular I made a lot of use of the detailed threads and discussions by Steve @sloz1664 (along with a few pm's - thanks Steve!). This uses the LesveDome driver and electronics scheme, based around a Velleman VM110N USB Experiment Interface Board (see http://www.dppobservatory.net/DomeAutomation/DomeDriver.php). I won't dwell on that part of the project - see Steve's posts, and others on SGL, for lots of details on that. The only modification I made was a different choice of motor - instead of a windscreen wiper motor which is commonly used, I ended up fitting a Planetary Gear Motor with 369:1 reduction gear sourced from Gimson Robotics (https://gimsonrobotics.co.uk/categories/dc-electric-motors/products/gr-ep-45e-medium-power-45mm-12v-planetary-gearmotor). Where things got really "interesting" is shutter automation. Looking at SGL and elsewhere, there's a wider range of solutions for this, and it seems to be the part of the project which causes the most issues. Initially I went for a timing belt + wiper motor approach, but this proved problematic. The 2.7m shutter is heavy, and the load on the motor changes significantly from fully closed, through mid-travel, to fully open. I had lots of problems with slippage, stalling and runaway, as I posted on September 10th 2020 on Steve's thread here: So I went for another 369:1 motor from Gimson, which has more than enough torque to deal with a shutter twice the weight, and fitted an 18 tooth pulley which engages with the AT10 timing belt strip that is secured to the inside of the shutter using "Sticks Like Turbo". Mounting the shutter motor assembly securely was a challenge - I wanted to avoid drilling holes in the dome. The central seam provides one possible anchor point, but the motor assembly needs to be supported at both ends to provide enough contact pressure on the belt to work properly. On my version of the dome, there's a convenient channel on the inside, approx. 2 cm tall and 2 cm deep, that runs all the way around the slit edge - a consequence of the shape of the recess which holds the shutter in place - as shown on the image below. I use this to route the power and signal cables feeding the shutter motor and "open" microswitch - but it also provides a mounting opportunity. So I exploited this by making a spring-loaded motor bracket which, on one end, bolts to a plate mounted on the central seam, and on the opposite end has a 1.9 x 1.9 x 5 cm aluminium block that fits snugly into this recess. The following photos show my bracket and the block (the white stuff on the block is adhesive which I used in a temporary fit check to mark up some screw holes). The spring is a 3.5mm diameter carbon steel spring, outside diameter 25.4mm, length 40mm. The hinge is a strong Eclipse fire door hinge. The length of the bracket is precisely cut so that, when one end is bolted to a plate on the central seam, the block at the other side fits firmly into the recess. I originally made this mounting bracket out of 3mm Al plate, but the contact pressure with the shutter needs to be very firm, and the 3mm plate wasn't stiff enough. So I changed to a plate made of 4mm aluminium angle (sides 100 mm x 50 mm), which solved the problem. The plate on the central seam is 3mm Al, and that's working fine. This plate was originally designed for the wiper motor, but I've re-purposed for the new approach. You can still see the wiper motor mounting points on the plate. It's not elegant and I may re-make at a later date, but it works. I was still getting a couple of slips near the extremes of travel, which I tracked down to shutter flexure - in the middle of the shutter there's plenty of rigidity, but at the extreme ends there's more flexure. I fixed this by fitting a 5mm thick Aluminium strip of width 50mm across each end of the shutter - you can see one of them at the end of the movie in this post (they're painted in white Hammerite). These strips remove flexure from the shutter, and the slippage is fixed. The shutter is controlled with the fantastic MagicWire system designed by @hughgilhespie , which works like a dream. It's powered by a 12V 9Ah battery which charges every day via a solar panel mounted on the lower shutter. There's a manual open/close switch on the control box, but for normal operation everything is controlled via Voyager. Microswitches provide open/close confirmation and power control. I wanted to provide a way of triggering the switches but allowing a few mm of extra travel just to bring everything to a standstill gently, so used some kitchen cupboard soft closing pistons as the "probe" to activate the microswitches. That seems to be working nicely. Here's a video of the whole thing in action. "Sequences shortened" as the adverts say; with the DC soft start unit in-line, shutter opening or closing takes around 100 seconds in this configuration. PulsarDomeAutomation.mp4 I was planning to fit an AAG Cloudwatcher for protection from weather conditions during robotic operation. But over the past few weeks I've been monitoring the data coming from https://openweathermap.org , and the current weather conditions reported are in excellent agreement with what I see at my site (there are clearly several reporting stations nearby which feed into openweathermap). So I've written a bit of Python code which calls OpenWeatherMap via an API to read the current conditions every 90 seconds, and generates a Boltwood-compatible file that Voyager reads and uses to trigger safe/suspend/shutdown signals in the event of cloud/rain/wind warnings. As a last resort safety measure there's a physical sensor - a Hydreon RG11 rain sensor on a post next to the observatory which overrides anything coming from the PC controller and uses MagicWire's safety sensor inputs to close the shutter in the event of rain being detected. On that same mast is a solar panel which charges a 12V battery for an uninterruptible power supply that ensures the system continues operate in the event of a mains failure, along with a long-range wifi access point that provides data link with my house about 50 m away. So far so good - remote operation is working well. There are a few improvements in the pipeline - I've repurposed brackets which were used for the original wiper motors, whose geometry is quite different (drive axis at 90° to the motor axis, unlike the planetary motors which are inline). The dome rotation bracket needs to be modified so that the hinge is rotated by 90° to give better rigidity on start/stop. I also plan to separate the dome rotation encoders from the drive pulley, onto an un-driven wheel in contact with the dome. This way the system measures dome rotation rather than motor rotation, which seems like a better solution. And I'm going to upgrade to heavier duty microswitches for the open/closed position signal - these ones work, but they feel a bit small and flimsy. I hope this helps anyone considering shutter automation on their observatory. I have to say that I started this project to save some money - the Pulsar off-the-shelf solution seemed to be very expensive for what it is. The solution above has achieved the same results, and I've certainly saved money. But I've also spent a lot of time, and in retrospect I no longer regard the Pulsar product as unreasonably expensive. That said, this approach has the advantage that if/when things go wrong, it's very easy to diagnose and fix yourself, and there's some satisfaction to be had in that. Thanks to @sloz1664 and @hughgilhespie for their advice during this project! Nigel