-
Posts
1,038 -
Joined
-
Last visited
Content Type
Profiles
Forums
Gallery
Events
Blogs
Posts posted by BrendanC
-
-
Hi all,
I'm building a spreadsheet to help me with planning sessions, and I'm incorporating moon phases as part of this.
I reasoned that, to calculate the phase, it basically follows a sine wave, the period of which is the lunar month ie 29.53059 days.
After a bit of jiggery-pokery involving PI, sine functions and offsets, it worked. Mostly.
All my new moons and full moons correspond with what I can see from sites online such as https://www.timeanddate.com/moon/uk/aylesbury
However, I just noticed something: the phases in between the maxima and minima don't quite match up.
This is what it looks like for December 2020:
As you can see, the actual phases in orange, aren't actually constant increments or decrements, because they don't quite match the calculated, constant phases in blue. They're not quite an exact sine wave.
They're a bit slower at the extreme end of each turning point and accelerate a little midway. There's something else going on here.
I'm kind of ok with what I have, as it's usually within 5% of actuality, but I'm intrigued as to why this should be.
Any takers? I'm just curious!
Thanks, Brendan
-
Really gives a great sense of the object's overall structure. Fab work.
- 1
-
I had a ton of problems trying to update an old hand controller. Reluctantly, I took the direct connection route via EQDirect and EQMOD, and never looked back.
-
I pretty quickly gave up on observing when I realised that most of the things worth seeing were only viewable when imaging. Planetary is possible, but so rare. given the suitable position of a planet and the weather in the UK. I like 'seeing what is unseeable', which is pretty much most of the sky, at any time of the year weather-willing, but only through imaging.
- 1
-
Thanks - I'll try and clear the points. Already set the mount to home and park several times!
I think I'll wait for Jim at the APT forum to have a look through the logs and see what transpires...
Thanks for all the suggestions.
- 2
-
On 04/09/2012 at 14:49, cotterless45 said:
Well said! I tend to follow a routine that involves tripping over everything , then losing my glasses,
Nick.
Sorry, I know this is a very old thread, but this quote made me giggle.
-
Hey, it worked! Dithering is no longer a problem. Ace.
- 1
-
Thanks all.
@Padraic M I did most of those things. How do you clear align points in EQMOD? Or is that done when you exit and restart it? Also, regarding one-star alignment, I generally just polar align, then crack on with plate solving my way around the sky. Do I need to go back to one-star alignment generally, or are you saying this would be a good 'back to basics' way to identify what's going on? Also, I hope Ivo is OK - Jim has responded on the APT forum and I've shared the log file with him so let's see what happens.
@andrew s That's an interesting theory. I must admit, cone error has been on my mind too of late, mainly because I've never checked it but do intend to use SharpCap's Conesharp utility at some point. There is a slight misalignment in before/after meridian flip frames which I assume indicates cone error, but seeing as I was doing fine, I never got around to fixing it. As you say, that would be quite some error though. By the time I'd given up trying to plate solve to NGC 7822, it must have been an hour past the meridian.
- 1
-
Completely understand the frustration. I'm just emerging from 'cloudageddon' after literally months of little to no opportunities at all.
The alarm would have to be REALLY loud for me to hear it from the garden! Laptop is outside, connected via Powerline to the network and then controlled from inside.
I'll still be going 'analogue' as a first check in future though ie employing eyeballs and looking upwards!
- 1
-
Ah, here you go - 176.401437 degrees.
Hmmm. Very suspiciously close to 180, don't you think?
Could it be something to do with the scope thinking it's the other way around?
I'm wondering whether this thread on the APT forum could be something to do with it? Although frankly I only just about grasp most of it: https://aptforum.com/phpbb/viewtopic.php?f=10&t=2794
- 1
-
Very interesting.
I did wonder whether the pixel value was something derived from my camera's resolution and arcminutes, played around with the figures for a bit but couldn't see anything obvious. I'll play around with the maths a bit more and see if I can pull anything out, esp regarding degrees.
Meanwhile, it does seem to be something to do with the meridian, as you say. I did the same, chose an object further away from it and everything was fine again. But I waited for quite some time before retrying NGC 7822, during which time it must have passed the meridian by quite some time, and it still wasn't having it, and when I tried again it was quite some way before the meridian.
I've posted about this on the APT forum too, so let's see if Ivo picks it up.
-
Yes, but it was sort of ok at the time! I think it was just on the cusp of being a viable image, but not sufficiently for PHD2 to maintain the star. I dunno. Only my second time, as I say, but in future I will most definitely check the image AND stick my head out of the window!
-
The other night I wanted to image NGC 7822, which is at RA 00:01:09, Dec 67:25:17
My location is in the UK, near Aylesbury.
When I did my first Goto++ in APT, for framing, it worked fine. I started the plan, it worked fine. When it reached meridian flip, I actually wanted to do something else with the laptop (calibrating PHD2) so I stopped the plan, thinking I could do the calibration, and then restart the plan post-meridian.
However, when I did, the scope slewed, took an image, plate solved it - and told me it was 319,091 pixels out and cancelled the Goto!
I tried to get it to work several times again, without PHD2 (which I think is a red herring here) but every time I got the same error, not with the precise same number of pixels but a similar figure of around 320 thousand-ish.
I tried again tonight, before meridian, and got the same error.
Everything else works fine, all Goto++ via plate solving. No problem with any other object.
Any ideas? It's really oddddddd!
-
So, second night of guiding. Everything going really nicely between APT and PHD2, thanks to great support on this forum. Suddenly dithering goes wrong - RA goes through the roof. Darn it. Start everything again. Everything goes wrong again - this time it's Dec.
I've just been fiddling a bit and thought that was why it was better. Maybe I was wrong. Can I reset everything and start again? I surely can. Unfortunately I didn't realise that also resets the calibration.
So, I try and calibrate (this is all indoors - controlling the laptop by remote - you can guess what's coming up can't you?)
I can't. Nothing is working. What on earth has gone wrong?
Stick my head out of the window. Cloud. Doh!
So, lesson for today is: don't just go by the data, stick your head out of the window and LOOK UP!
Now I have to get everything set up again just as it was before... Still, at least I 'learned' something, right?
- 1
-
-
Brilliant, thanks. I was just using the same settings as when I used APT Dither, didn't really consider the change in focal length, but that makes total sense because I'm now specifying the focal length of the guidescope, right? I'd already changed several settings which helped, but there are just so many variables it's difficult to know what to target next without a hint from the good people on this forum.
Post-edit: just spotted your signature 'Perennial cloud cover'. I sympathise...
-
Hey, thanks! Yes, I knew that was the reason for timing out at 3 mins, and considered extending that but it seemed pretty long already. I just didn't know why it was timing out. Great suggestions, I'll give them a try.
-
Hi all,
Last night was my first attempt at guiding with PHD2. I'm running APT, controlling an NEQ6 mount under EQMOD via a direct connection, and have pretty much got that all working nicely now.
I got everything working and it all looked great... until dithering.
At that point the PHD2 chart went bonkers, while APT just said 'Dithering', and after 3 mins (the time-out limit), it, well, timed out.
I think there was an error in PHD2 too, about not being able to make sufficient RA adjustments. I'm kicking myself for not taking a note of exactly what that message was.
I've searched online and looked through the forums and don't really know what the next step would be to fixing this.
Given that these are my settings in APT, PHD2 and EQMOD below, can anyone spot anything that is immediately wrong? Or is there anything else I should be checking?
APT
PHD2
EQMOD
Thanks
Brendan -
Top tip: you can replace the optical drive in that machine with a HDD (or even another SSD) in a caddy. Works very well and replaces something pretty much redundant nowadays with something useful ie more storage on board, particularly useful if taking large video captures for planetary imaging.
- 1
-
Does it use magic beans?
-
I completely sympathise. I've only been 'at it' for about two years but the weather has been truly shocking, and I'm still seriously contemplating whether I want to pursue/spend more on a hobby that I can only actively enjoy once a month at best. I used to have a classic soft-top car and only then did I realise how few times I could get about in it because of the amount of times it's too cold/wet. So, I sold it. Now I have a telescope, I've realised how few times I can use it because it's too wet/windy/cloudy.
-
Very interesting feedback, thanks all.
Regarding the time it takes, well to put together a darks library takes, what, a day or two, in which I wrap the camera up safely in a towel, put it in the fridge, and let it take many, many shots as it cools down. Then I take it out, and let it continue as it warms up again. Then put it back. Then take it out. Etc. Think of it as the GBBO, but with a DSLR. Oh, and not actually baking. OK, so it's nothing like the GBBO, but the end result is, loads of darks at varying temperatures, or as close to those temperatures as I can estimate given the accuracy of the camera's sensor. So, next thing is, I just group them all by temperature and store them in my library. Same with dark flats, and biases (but they take a lot less time obviously). I aim for 50 biases and darks, and 25 dark flats, at every temperature I can manage. Then, of course, I take the light flats during the session, which again takes very little time. Then, in DSS, I group the lights, dark flats, darks and biases by temperature, and I use the same light flats across all of them in the main group (they wouldn't be temperature-matched because I would have to take loads throughout the session to get the right temperatures, plus it probably doesn't matter too much with such short, light exposures).
So, it's labour-intensive and time-consuming to build it, and then you have to store it all too, but once it's done, it's done. I was just wondering whether I needed to or not, given that I have a replacement camera.
The summary seems to be: yes, if I need to use darks; but I might not need to use darks.
I have experimented in the past without using darks. I couldn't see much difference, but then who knows whether it was just that particular image? Maybe a nebula with a lot of space around it would need darks? Maybe a cluster close-up wouldn't need darks? I'm certainly not going to try different combinations every time I process an image! And I'm minded not to do a load of experiments when I could just rebuild the library and have done with.
I'm tempted to rebuild it. It seems that, if I do it all 'properly', I've covered all the 'well, you could not use darks if A' or 'you could just use biases if B' contingencies.
Again, thanks for the input!
-
-
Ah, here we go again! I've done a ton of research on calibration files and what I've found is, there is no consensus! So here's a perfect example: I have a 'yes', a 'no', and a 'yes and no'! The perfect balanced sample...!
(Don't want to give the impression I'm ungrateful though, thanks for the replies all).
Totally understand the need for darks and flat darks to be at the same temperature, and that's why I referred to a library: with my previous camera I spent quite some time taking loads of darks and dark flats by cooling the camera, letting it heat up, cooling again etc until I could bring sufficient numbers of them all together at each temperature (according to what the camera's sensor told me). I did this because I thought I was supposed to! Also because packages like DSS and APP tell you to, and have specific features for these calibration files such as matching them via groups etc. I just thought it was best practice. They were all shot at ISO800 because that's what I use for everything, with the darks matching the lights for duration too.
I've also come across the argument that darks aren't needed at all. This would be more convenient, but I did find a web page (can't find it again) that outlined why you need both. So, given that there was no consensus, and some people argued that all calibration files are needed given different circumstances, I did both, figuring that it was a bit of a pain to begin with but once done, it was done.
So, if I just use biases, and a large dither (which I do anyway), is it definitely the case that I don't need darks or flat darks (or even dark flats - yes, I've read the thread that goes on and on where people even discuss which phrase to use)?
And if so, another question: do the bias frames have to be at the same temperature too? Again, research yields varying takes on this.
[Post-edit - I think it was this page, which did my head in, not least the comment that 'a good way to think about it' was Pre-processed Image = (Light - Dark) / (Flat - Dark Flat), which someone then elaborated on by clarifying it as Subcalibrated = (Subraw - Bias - (Darks - Bias)scaled ) / (Flats - FlatDarks): https://www.cloudynights.com/topic/658692-why-do-you-need-bias-frames-if-you-do-darks/]
Something I don't understand about Moon phases
in The Astro Lounge
Posted · Edited by BrendanC
Ah, nice one! Very good. That's probably it. Thanks! Very good insight there.
So, I need to include the eccentricity of the lunar orbit to calculate this more accurately. Hmmmm.... strokes chin...