rockinrome

Hi Pier

Looks like a problem (bug?) in the ASCOM driver software and not NINA itself. Have you the latest ASCOM platform and drivers for your equipment.

If i'm reading it correctly the error works from bottom to top.... meaning the error appears from ASCOM.iOptron2017.Telescope BUT fails further down with the move in NINA.

Regards

Hi Albir

For what it's worth I use the white t-shirt method over the objective. I've used NINA and APT with their Flat Wizard in the past with good results in the range of 0.001s - 1s exposure.

Hi JB

I agree with Kon re. binning, but I would ONLY be referring to colour CMOS here. There is just no point.
I know you need to get to the pixel scale required though and it is a pain!

6 minutes ago, adyj1 said:

This is also my experience. It isn't NINA causing this, but EQMOD and your mount. If you power off everything between sessions, then when you start EQMOD it will revert to its default start position - and assumes the scope is weights-down, pointing North. As far as I know there isn't a setting to get EQMOD to change this power-on default (although I have no experience of encoder-equipped mounts).

I am lucky enough to have an observatory, and as long as I maintain power EQMOD 'remembers' the custom park position. However, just to be on the safe side when I start a new session after any kit has been powered off, I run my planetarium software (CdC) and sync position with the mount before carrying out any slews. I can then see on the screen where my mount 'thinks' it is pointing, and if it is North rather than 'sideways-parked' I open the roof and manually point the scope north before then carrying on with my session...

HTH Ady    

Thanks for the info Ady - all the info helps.

Matthew

9 minutes ago, Varavall said:

Hi

I have the same mount and use NINA and park to a custom position so I can close the cover. What I have found is that once the custom park is set in NINA at the end of the imaging session the telescope duly parks where I want it. However, on start up when the telescope is unparked NINA assumes the telescope is at the home position so all goto slews go wrong. So what I do when I start up is to unpark and then park to home position, telescope goes pointing north and then everything works as it should. Guess that's a "bug" in NINA, but nothing major once known abut the foible. Hope that's useful.

Thanks for the insight Varavall. These are the little things that trip us all up!

Matthew

Thanks again all that have replied here.

This forum is ace and you guys always come up with the goods and give plenty of food for thought.

All the best
Matthew

7 hours ago, Budgie1 said:

If you're using NINA, then are you also using EQMOD?

If so, then expand the EQMOD GUI (Fig 1 in the image below) and in the central column, at the bottom, are the Park controls. In the drop-down you get the choice of Park to Home Position or Park to a custom position (I can't remember the exact wording on the drop down menu ).

You'll find details on page 88 of the EQMOD Manual.

I have this set for my HEQ5 in my ROR Obsy, so the scope is laying horizontal when parked, to allow the roof to roll over it.

Thanks Budgie1 - just the kind of "automation" I was after.

Kind regards
Matthew
 

2 hours ago, StevieDvd said:

By mix up it was the linking of NCP to home position by where the scope is pointing.  NCP can be set without a scope mounted.

But of course if you setup your mount & scope for each session, and/or need to polar align then you will likely move the mount from whatever saved position or home to do so.  If you are in an observatory and have PA sorted you can do a restart more easily, but in that case I doubt the original question would have asked. 

Can you let us know what software you are using and someone will point out where you can store your preferred start position?

If you are not leaving the mount in the close down position for next time even the saved position is effectively lost.  Plate-solving can be the answer you need as it can update the mount position for you as long as it can solve the image seen by the controlling software. 

Thank you.

I currently use NINA.

Thanks again
Matthew

My entry here is taken over Aldeburgh beach in Suffolk with a lovely Belt of Venus.

Thank you.
Matthew.

I may have the answer but looks like it will involve the hand controller. Not really a problem though at this stage.

The attachment is from the SynScan guide and says you can call any position (I assume moved by the hand controller or software controlling the mount) the home position and then recall that the next time you power on.

So - with gudie in mind I would do:

(1) First time move scope under control to my park position
(2) Function > Park to... Current Pos
(3) Then next session use Start from Park "Yes"
(4) Second and further times, Function > Park Position (park to last park position)

Thanks again all for your help/comments.

Matthew

7 minutes ago, vlaiv said:

Park position should be position where the scope is "parked" between sessions.

It is mostly important for two reasons:

1. having dome or otherwise closing observatory so that telescope can't be left in normal home position (for newtonian telescopes it is better to leave scope with mirror on its side so that dust does not settle down on the mirror).

2. When using periodic error correction and not having encoders. Here - software that controls the telescope assumes that telescope is at its park position when powered on - meaning stepper motors are oriented the certain way and haven't been moved. If steppers have been moved (not to be confused with manually moving the scope when clutches are undone) without software not knowing about it - then synchronization information between software and hardware is lost and periodic error correction will be wrong.

Home position is just "start" position for goto moves. It is usually defined as scope pointing to Polaris and counterweights down (that is RA 6h and DEC 90 degrees).

Most people don't bother and do not use two different positions - they use the same position for both of these uses - it does not matter if it is usual home or sideways parked.

In any case - home should be thought as scope orientation between moves / gotos / trackings and park should be thought of as permanent home between power cycles and is more related to internal gearing and motor positions.

Thanks for the reply vlaiv.

So, yeh, I get what's said here - the power-cycling bit is key to me here.

Matthew

5 minutes ago, Albir phil said:

Hi as far as I know if you set mount to current position you can begin next session from there, however I always return to home position,never tried current position. When you use home position it tells you it is saving data,not sure if current dose🤔

Thanks for the confirmation - that's what I've read and make sense.

Matthew

5 minutes ago, StevieDvd said:

You are mixing up Polar Alignment and mount position.  Home position is a useful starting point for most mounts, some do have an automated park/start position - the HEQ5 does not.

NCP alignment is the mount not the scope and is needed for accuracy of goto's on eq driven mounts.

Using your example of a perfect NCP alignment, what is needed on startup is to tell the mount where the scope is currently pointing. If it thinks it is at the standard home position but it's not, then the gotos will be wrong, though a bad date/time/location can have the same effect.

A lot of astro software will let you save a start position, that is effectively your home position now. You would not need to go to the old weights down/scope north home position.

When I had an HEQ5 mount and was polar aligned I would start at my home position, marked on my mount. Then do a goto to a bright star and if not centred I;d release my clutches and centre it, then do a goto home to check it was at my home marked on the mount. All gotos were then OK for me.  The current equivalent can be done my plate-solving and re-centering.

Star alignments are for letting the mount know of any inaccuracies in your Polar alignment and in where the mount is pointing (if not correct) it can then run taking these into account.

HTH

Steve

Thanks for the quick reply Steve.

With respect though - I am not mixing anything up (may have not explained properly of course?), I was very careful to say Home and Park as I know these are interchangeable sometimes.

I guess the escence of what I am saying is that I would like to simply return to where I left off or at least back to Home when I switch on again without any start alignment etc. BUT I do need to move the scope to a suitable "parking" place before I close the obs.
You said "A lot of astro software will let you save a start position, that is effectively your home position now. You would not need to go to the old weights down/scope north home position." - I *think* this what I am after - a software solution (or handset at a push!)

Best regards
Matthew

Hello all

I know there have been some threads on this, but not one *I think* has answered this question....

Let's assume that we have a perfectly polar aligned system and we all know that Home position is when scope is pointing at the NCP and that's all good. (There are loads of articles about how to achieve this - all good, sorted.)

BUT..... Is there a way to have an automated park position at the end of a session - like counter-weights left, scope to the right. Then when we come to another session, do an "un-park" and it moves to the home position, ready for use?
So when we switch on in this case the mount knows it's parked and not at home position as this would be incorrect to start from.

I know that you can specify "Home at current position". Is this the answer?, i.e. move scope with handset to best position for me and then use that as the "park". 

What I am trying to achieve here is a non-manual (which is error prone) solution.

Thanks for reading.
Matthew
 

Taken looking over Brackenfield, Derbyshire.
Canon EOS 5D Mk2. ISO640 f/7.1 8sec 135mm. 2 panes stitched and processed in Affinity Photo.

5 minutes ago, ollypenrice said:

It's paradoxical, but I usually have two or three focal lengths on the go and find the following to be true of what I actually do with each:

Super-wide field (short FL) - usually make mosaics.

Medium field (medium FL) - sometimes make mosaics.

Narrow FOV (long FL) - never make mosaics and usually crop out the object of interest before posting.

This is not based on what the gear can do, it is not a recommendation, it is simply an observation of what I end up doing. With a wide field I want wider, with a medium field I sometimes want wider and with a narrower field I want narrower.

I only post this observation because you might, quite possibly, find the same - in which case you might prefer binning over a reducer. I wouldn't buy any reducer which has not been shown to work with your scope.

Olly

Thanks Olly, sound advice.
That certainly gives me food for thought before I start spending (or not).
 

3 minutes ago, vlaiv said:

Reducer is worth using if you want to widen the FOV somewhat. However - you can't really go to arbitrary reduction factor with it.

Maybe best way to think about it in first iteration would be not in terms of focal length reduction but rather as "sensor size increase".

Say you want to use x0.6 reducer on your scope. Your sensor is 16mm diagonal as is. With x0.6 reducer - you will have 16mm / 0.6 = 26.666mm sensor size. Almost APS-C size, and at that size - several things start to happen. First - edge of the field astigmatism starts to show, second - depending on type of reducer - you will start to get vignetting. Pretty much all the things that you already noticed.

You can certainly use x0.5 reducer on this scope - but in that case, I'd look into sensor below 10mm in diagonal. In fact - for best results, stick to 4/3 sensor size - approximately 22-23mm in diagonal. This would mean 16/22 = ~0.72 in your case.

 

 

That is great information - thank you very much for your time.

2 minutes ago, vlaiv said:

Why don't you just bin the data? That will act as x2 reducer as far as arc seconds per pixel is concerned.

It won't widen you field of view though, but not sure if you are interested in that

Yeh. I have tried that route and that is great, but as you point out does not widen my view (not that that is a problem) ..... but yeh, deffo a route to think about.... Thanks.

9 minutes ago, Elp said:

To be honest, from my experience, reducers only help so much with regard to speed. Aperture makes more of a difference. And you have to change your train of thought that regardless, for a good image you'll be imaging for 10-20 hours at least.

Thank you for the information. Appreciated.

1 minute ago, vlaiv said:

Better match in which way?

My arc seconds per pixel.

3 minutes ago, Elp said:

Does your existing reducer introduce coma/elongated stars at the outer field of view? It's a general consensus you shouldn't reduce more than around 0.8, there's a reason most good reducers do not exceed 0.75x.

What are you trying to achieve? You ask is it okay, only you can decide this depending on what your intended use is.

Vignette is due to the illuminated imaging circle on the sensor of the camera, if it's close to your sensor size diagonal length it'll be more apparent, lenses due to their shape and construction generally all suffer from some sort of vignette at the edges, it's easily corrected with flats or via post processing software.

Hi Elp, thanks for the reply.

Yes, I do get slightly elongated stars with the 0.6x.
My goal was to get a faster system to reduce exposure times and to get a better match for my camera (533C).

Thank you.

Hello all and thanks for looking - not posted for a while...

Hopefully a quick question to answer.

I have a 6" Ritchey Chrétien and wish to focally reduce at most 0.5x.

I already have a 0.6x reducer/flattener and tried this. All OK, but has some vignetting on the edges. So my question is two-fold I guess:
(1) Is that reducer OK seen as it is also a flattener?
(2) Is the vignetting due to (1) or simply just the way the light falls on the sensor?

I did looke into a simple 0.5x reducer - would that work (https://www.firstlightoptics.com/astro-essentials-eyepieces/astro-essentials-05x-2-focal-reducer.html?gclid=CjwKCAjw-vmkBhBMEiwAlrMeF1d9yhWga3xDRvB1zOQlknp0PMXz5nsb-AP9kOOHMpqVeunYdsX6LBoCbeQQAvD_BwE)
Or do I need more like this: https://www.firstlightoptics.com/reducersflatteners/astro-essentials-075x-reducer-for-stellalyra-gso-ritchey-chretien-ota.html

Thanks again.

Clear skies.
Matthew

Hello all, this is going back some years, but I think it has legs!

Rosette Nebula in Monoceros.

Altair Astro 72ED-R and field flattener with Canon 600D stock at prime focus with SkyTech CLS clip-in filter. Total 1hr 40min @ ISO1600.

Hello, I would recommend the Jackery units (I have the 250). Have used one for around a year now with no issues. Similar power requirements to yourself, lasts about 3 hours.

All the best.

On 25/11/2022 at 10:21, sinbad40 said:

Hi All,

I want to be able to get a wider field, and want to know if the 533 is alright to fit onto the 50ED or would i be better to get a reducer for the 80ED (more light etc).  Skywatcher do a .85 reducer/flattener, but it doesn't give that much more fov.  Any recommendations or pointers are more than welcome.

 

Another quick on, the HEQ5 rowan mod, did anyone do any testing before and after, been looking at sorting that but wanted to know from others if they found it to be a good investment.  I am not bothered about the noise decrease, just the tracking improvement.

 

Hi Sinbad40

I have done the Rowan Mod on the HEQ5PRO and can confirm much better quiding (less corrections) with no (very, very little?) backlash.
Well worth the investmant.

All the best
Matthew