MikeeJC

23 hours ago, Budgie1 said:

I think it assumes you start & finish a session in a known position, like the Home or Park positions.

I mark my mount with a Sharpie on the RA & DEC, so I can release the clutches for balancing etc, then put the axis back to where I parked it. Never had any dramas and it also means if you do need to reset the position (a cable got caught or something) then you just tell the mount to go to the Home Position and reset the axis with the clutches released.  

Like Ivor, I tried using the EQMOD PPEC on my HEQ5 but it actually seemed to make the guiding worse when it was switched on, so I don't use it now. 

Thanks Martin

I suppose the only way is to send the curve to the mount and see what happens... or run another session (if I get a long enough stretch of clear sky) and then send it to the mount straight after.

1 hour ago, Aramcheck said:

Astrobloke shows how to record the PPEC on his youtube video: https://youtu.be/PfvWhx7ozi0?si=7EEuao1nvAxTY1Ni&t=942 

I've only tried it couple of times & didn't see any noticeable benefit, but that could be down to other factors in my mount...

Cheers
Ivor

 

Thanks Ivor

I've watched Astrobloke's video and a couple of others but although they say the PEC can be written to the mount during the day, there's no mention of what happens if the mount has been moved and put away i.e. clutches released etc.

 

2 hours ago, ONIKKINEN said:

I think the mount is aware of the RA worm gear position, there is a small notch in a washer attached to the end of the worm gear, which is read by a sensor when the notch rotates over it. I have not used EQMODs PPEC, but from a mechanical point of view i think this is how the mount knows what part of the cycle the gear is in. So as long as you dont go and rotate this system manually somehow (impossible without dismantling the mount) it should be ok. Could be wrong though, someone who uses PPEC might have more info on that.

There is another option to periodic error correction, and one that will require no extra work or recording of the error. That would be the Predictive PEC algorithm in PHD2. This will record the periodic error as you guide, and gets increasingly more accurate the more you run the mount. This data is gathered directly from guiding performance, so i think has a chance to be more accurate, and i can confirm it works really well with my AZ-EQ6 that has a very aggressive peak twice per worm cycle. It does take a while to get accurate, about a few cycles worth of guiding per night. But chances are your early night data is not perfect anyway due to the scope still cooling down (if you set up fresh with the scope indoors before use), so there are no practical losses per night when using this. Not sure if the prediction data stays between nights when using the same calibration, as i recalibrate each night.

Thanks.

Haven't tried PHD2's predictive PEC algorithm as yet, maybe worth a try.

I've always used EQMOD's AutoPec when guiding but now wanting to use PPEC instead (although not sure if it's a major advantage or not).

I've created a PEC curve over 9 cycles and know to go into the developer area of EQMOD and record this to the mount.  My question is, I've heard this can be done during the day but how does the mount know when to sync with the curve?  Does the mount have to be in exactly the same position as when recording the curve?  As I have to set up each night I've already taken the scope off and moved the tripod into the shed.  Is it now too late to load the curve and send it to the mount or can I just make sure it's in the home position before sending it?

Thanks
Mike

Does it matter where the scope is pointing when recording a PEC curve using EQMOD?

I can't get my head around why it would make any difference as the periodic error in the worm drive would be the same wherever it's pointing..... or am I wrong?

My mount is the EQ6R-Pro.

Thanks, Mike.

Apologies if this is in the wrong group.

Is there a comparison review between the Antlia ALP-T 5nm and the newer Altair 4nm dual narrowband filters anywhere?  I've been looking but as yet no luck.

I had set my mind on getting the Antlia ALP-T but now Altair has brought one out it's made me think I should hold off until I see a comparison between both.

Thanks, Mike

Another M51 Whirlpool galaxy here.

Taken over 3 nights in April (after waiting ages for a clear night, managed to get get 3 over the month).  Total of 11 hours, 46 minutes integration time.  Plus 50 dark frames, 40 flats and 20 dark flats.

Taken with a RisingCam IMX571 OSC, Esprit 120ED on a EQ6R-Pro mount.

Stacked in DeepSkyStacker, processed in Siril, Adobe Lightroom and GIMP.

1 hour ago, Elp said:

Looks like something moving across the field of view and it's pulsing brighter and dimmer, wasn't a drone around?

Not that I'm aware of although I left it running and came in before this occurred. The way the light bars radiate out in increasing radius looks like some sort of shockwave effect.

Think I deserve an APOD for this one 😂

11 hours ago, Fegato said:

Interesting! But no idea I'm afraid. What direction is it coming from relative to the horizon?

That is a good point.  Looking at Stellarium, back to the exact time it happened (and taking into account the image is reversed) the 'flash' appears to have come from the South West direction.  My target was North North East relative to my position.  It looks more likely it's either come from my shed next to the left of the scope or maybe neighbour's garden.  Still very strange though, never seen a pattern like it.

I have just got around to checking my individual subs from the 14th February where I left the scope out overnight getting data on the Cat's Eye Nebula.

On one of the 3 minute subs there is this very odd 'firey' pattern which has appeared but all the others, before and after, are exactly fine and how they should be.  Has anyone ever seen anything like this?  I've absolutely no idea what it could be.  Almost looks like an explosion with the shockwaves coming out from it.

The more bluey image is exactly how it looks from the FITs sub and the more orangery one has been run through DSS by itself without any calibration frames.

Clear skies!

Another M45 Pleiades aka Seven Sisters star cluster here in the constellation of Taurus.

Taken over 3 nights.  Total integration of 10 hours, 51 minutes.  15 x 240secs & 197 x 180secs.

Equipment:  Sky Watcher Esprit 120ED APO refractor, Sky Watcher EQ6-Pro mount, ZWO ASI120mm mini guide camera & 30mm guide scope.
Capture Software:  NINA, PHD2 & Stellarium
Processing Software:  DeepSkyStacker, Siril, GIMP, Adobe Lightroom.

Clear skies!
Mike

49 minutes ago, ONIKKINEN said:

20 is way too low, stick to the default 768 offset to make sure no pixels are at 0. There are no real world downsides to having that extra offset as you can afford to lose that few hundred ADUs from the 65k the camera has to work with. Assuming you are using HCG mode too? If not, maybe better to, as LCG mode has limited benefit compared to HCG and only in some very specific situations (if you dont know you need it, you will not need it or benefit from it). It doesnt really matter if the images come out good or not, 0 value pixels are physically impossible to calibrate properly and you will have problems with flats and darks calibration if you have them (cant divide or multiply by 0 so software used for calibration uses a very small number, like 0.0001 or something, but not 0. Its a problem because the real pixel value could be -100 or -200 but there is no way to know since it was clipped).

I would still recommend taking all darks indoors with the camera off the scope and completely covered as just a few photons creeping in somewhere will ruin them. As for why this happened, not sure. I have noticed that sometimes immediately after shining something bright down the tube, like a flat panel, the next frame will have some ghosting of signal as if the light was still partially there. This is always the first shot after, so was your failed one the first darkflat after taking the flats? Dont know of a solution to this, other than checking each first shot of a sequence when taking darks but for what its worth this happens quite rarely.

Hi Onikkinen.

Thanks for the info.  Yes, I always use HCG mode.  I haven't tried LCG despite the sensor analysis stating you get a much higher full well depth in LCG at the expense of much higher read noise.

My dark frames have been taken indoors completely covered as you mention and all look good (apart from min=0 also) but the dark flats are taken outside as they are straight after the flats, which I take just before a session as this is more convenient than after as I usually leave it running overnight while I'm in bed.  As you mention, it is always the first dark flat frame taken directly after the flats which has these elevated values.

I'm a little dubious of the figures ASIFitsView histogram is giving compared to the visual histogram, although that could be me just not understanding them correctly.  I've attached a couple of screenshots of a light and flat frame showing FitsView histogram.

On 05/12/2022 at 14:01, The Lazy Astronomer said:

I'm not sure what's going on here, it could be a NINA or driver problem, but your second image has average and minimum values of 0, which implies your offset is too low. There should not be 0 value pixels even in a dark frame.

Hi.  I run the gain at 100 with an offset of 20 which seems to be popular for the IMX571 sensor and the images come out pretty good.  I will have a play at changing them a bit and see how the average and minimum values change.  Thanks.

On 05/12/2022 at 14:11, Gary Clayton said:

Are you using the native or the ASCOM driver, try swapping them to eliminate driver issue. 

Hi Gary.  I'm using the native driver as from what I can remember (it's been a while) it had better functionality and control compared to the ASCOM driver.  That said, I'll try changing to the ASCOM driver and see if I get the same result.  Thanks.

I'm experiencing a strange issue when starting to take dark flats in NINA's flat wizard.  Having looked back I realise it's always happened but only just noticed after switching to ASIFitsView to check the images prior to stacking.

The first dark flat taken always has a green bayer matrix visible when stretched which the other frames don't.  Also the histgram is showing elevated figures suggesting there's some light present.  Although the scope is covered with its lens cap and a folded dust sheet, also taken at night so there's no light entering the OTA.  If there were light leaking in then all the darks would be the same.

I'm using a RisingCam IMX571 OSC camera which appears to working well.

I know I can just delete this single 'incorrect' dark flat frame but it would be nice to figure out why this is happening.  Any ideas greatly appreciated.  Not sure if it's a NINA or camera issue.

I've attached an image of the first flat dark and also the subsequent one to illustrate.

Clear skies!
Mike

Also worth checking, quite often the EQ6R arrives with the RA and DEC axis too tight. This happened with mine. Without the scope on it, do both axis' rotate freely without any play with the clutches released? If they tend to stick and stay in one position then they'll need loosening off a bit. I've included a link below. As others have said though, give it half a dozen or so goes first to break it in.

Hi all!

I'm running a EQ6R-Pro mount and am getting a strange EQMOD PEC curve all of a sudden (see image below).  Does anyone know what could cause this?

Previously I've been getting a smooth Sine wave curve, equal top and bottom.  The only thing I've done recently is to remove a bit of play in the dec axis, being very careful not to overtighten.  After the adjustment I re-ran PEC training which then gave me this strange shaped curve.  Although I was sure at the time there was no stiction I will double check this.

Also, this may be a daft question, but how do I ensure EQMOD's PEC is properly sync'd to the mount so it's not running out of phase?  Or do I not need to worry about this?

Many thanks!

My first moon image with my Sky Watcher Esprit 120ED on a EQ6R-Pro mount. Camera is a RisingCam IMX571 OSC.  This was taken at 8.30pm BST while it was still daylight.  I did take several images to stack but struggled so this is a single image.

My first image of the Horsehead & Flame nebulae taken with my new equipment.... Sky Watcher Esprit 120ED & RisingCam IMX571 OSC camera on a EQ6R-Pro mount.

94 x 90 second lights (2 hours, 21 mins), 50 darks, 50 flats, 50 dark flats.  Stacked in Deep Sky Stacker and processed using GIMP and Adode Lightroom.  Apologies for the elongated stars, it was windy and my guiding was off.

I'm having a real problem removing or getting around a multicoloured artifact left behind by Starnet++ V2 (worse if I use V1) when it removes the bright star Alnitak.  I've attached a partly stretched image straight out of Starnet++   I've tried stretching both less and more prior to star removal but makes no difference.

If anyone has any ideas how to stop this happening or process out before processing the image properly it'll VERY much appreciated.

Taken using a RisingCam IMX571 OSC camera attached to a Sky Watcher Esprit 120ED APO.  Stacked through Deep Sky Stacker and processed with GIMP, Starnet++ version 2 and Adobe Lightroom.

Clear skies!

Hi.

I've just started getting into taking photos of the night sky using a DSLR.  I'm currently having issues with the camera 'dipping' slightly once I've framed the star/planet, locked the head and then gently let go of the camera body.  It usually goes out of frame if I use a long focal length.  I used to use a cheap pan & tilt head but have just upgraded to a Sirui K-30X ball head.  The issue isn't quite as bad now but hasn't gone away completely.  Is this normal and is there a way to stop it from happening?

Any help appreciated.
Thanks, Mike