dph1nm

Velocity is a relative quantity, it has no absolute value - so to answer the original question you have to ask the question moving relative to what? These days it can be popular to use the cosmic microwave background, especially in cosmology, but is that useful for stars in our galaxy? I think one might consider motion relative to the centre of the galaxy to be more useful.

NigelM

I had the same problem earlier in the year. Tried to go to the other side of the meridian with ekos/indi and the pointing went pear shaped (astrometry wouldn't solve). Tried to re-home , then park + rehome, but still couldn't get it to work out where it was. Gave up in the end and went out to the observatory to find the telescope pointing at the ground, with one of the cables jammed tight round the mount. Now whether the cable problem was a consequence or the reason it is impossible to say, but it seems likely that the cable jamming causing the mount to lose its position (and its inability to go home).

NigelM

B&Q seem to be selling a Bluetti PS54 537Wh for £249, which seems pretty good for the Wh rating.

NigelM

23 hours ago, Rallemikken said:

In many ways. they are the same. No problem running a Canon DSLR on  indi_gphoto_ccd driver, but the specific indi_canon_ccd offers some advantages.

The problem I had was it with replacing the 1000D battery during the observing session. The indi_canon_ccd driver would never recover from powering down the camera to replace the battery, to the extent that it required a reboot of the pi to get the system back. No such problem with indi_gphoto_ccd. I believe it was related to the fact that the canon driver allows for multiple cameras. This was a year ago or so, and I now have external power for the camera, so this is no longer an issue for me. So it maybe that the latest canon driver has been fixed.

NigelM

If there is little or no background sky signal, then it could be the effect of the dark subtraction (which will essentially leave the mean background near 0).

NigelM

My 1000D works fine with the indi gphoto_ccd driver. It never played well with the specific canon_ccd driver though (messed up the pi usb ports)

NigelM

I think this is unavoidable with short exposures or with narrow band filters. I get this in the red channel when subtracting darks from my 1000D 120s exposures taken through an L-enhance. There is virtually no sky signal, so subtracting the dark+bias has to lead to some -ve pixels. One might hope that the software could cope with this!

NigelM

If you are on a mac you might take a look at indigo, https://www.indigo-astronomy.org/for-users.html, which appears to be a fork of indi, but seems more macos oriented.

NigelM

One should really think of short F-ratio telescopes as a way of covering more area of sky to the same depth in a given exposure time than a scope of the same aperture with a large F-ratio. So an 8" RASA will not get you any deeper than e.g. an  8" F6 Newt, but it will be much faster at covering a large area of sky.

NigelM

14 hours ago, andrew s said:

Sky background noise can be reduced by by using a good sized annulus. 

Well yes and no - using a larger annulus for the sky can produce a better estimate of the mean sky under the star  (assuming the sky is flat, otherwise you are in trouble), which is important to avoid systematic photometry errors, but the photon noise from the sky, which is the dominant source of noise for faint photometry, is determined by the aperture used for the star, and so is unaffected by the size of the sky annulus. I seem to remember that an aperture of diameter ~1.4x full width half maximum is optimal in terms of s/n.

NigelM

Note that DSS requires a minimum of 8 stars in common between images for it to be able to stack. Don't think the example given meets that criteria.

NigelM

I have the quattro - works very well with the skywatcher aplanatic coma corrector. I would certainly recommend it if you are into faint galaxies. It is not what you would call a portable scope though!

NigelM

If you haven't already, take a look at dobsonianpower.com - he images dso live on youtube with a 12" dob.

NigelM

Probably depends how long your flats are! I only ever take flats in the region of 1 sec or so.  I would be very surprised if a flat-dark that length on a DSLR is in any significant way distinguishable from a 'bias' (basically a 1/4000 sec exposure on my Canon). You should subtract something though, be it flat-dark, bias or constant, otherwise the flats won't work correctly.

NigelM

There is always Celestia

NigelM

The 585 has 2.9um pixels, so about 0.6". A touch over-sampled unless you have very good seeing. The 533 is a bit better at 3.76um, but there really aren't many (cheap) cameras matched in pixel size to >=1000mm FL imaging, so you are always going to have to compromise.

NigelM

At 1200mm focal length most modern cameras (both DSLR and astro cams) are going to give you rather small pixels. I have tried the Altair 224C on my 12" f4 as an experiment - pixels are about 0.8 arcsec. It works OK for *small* DSOs, if you can track well enough (its my guide cam, so I can only use it as the main cam unguided) - I don't mind the amp glow.  In fact I have been quite impressed with it, although it is a better match to my 4" SLT.

NigelM

So I have a little Altair 224C guide cam on my main telescope, so I thought I would try it out as an imager on my venerable Nexstar 102 SLT. The FOV is tiny, which makes it almost impossible to find anything with the GOTOs on the SLT mount, and the small pixels are, lets say, a challenge for the tracking. So these are stacks of 8 or 15 sec subs. Clockwise from top left: M16, 622 secs; M14, 495 secs; M26, 328 secs; M27, 280 secs. All stacked with DSS and played with in GIMP, and taken low down in my very light polluted skies.

I am pleased to report that they are an improvement over the Canon 1000D which I have previously used on this telescope (to be fair, the Canon suffers as the short exposures you are restricted to on this AltAz mount are not long enough to overcome the read noise)!

NigelM

There is a site https://www.nightskiesnetwork.com/#about where people broadcast live imaging from their telescopes. I think you have to sign up for it - there was a time it was just open for anyone to view. Used to be mostly US, so the timings were a bit odd for the UK.

NigelM

The washed out DSS image is perfectly normal and correct.  If you put a faint object such as a nebula or galaxy on top of a bright sky then the intrinsic colour of the object will not be obvious. You need to post-process the image to remove the sky, and maybe up the colour saturation. The DSS image settings can do this, but you will have more control in dedicated photo-editing software.

NigelM

MKIDs? No need for filters or bayer matrices as these are photon counting devices which measure the wavelength of each photon. There are those who think these are the future of imaging at professional observatories. Need to be kept very cold at the moment, but technology moves fast ...

NigelM

Those files contain the registration, flat, dark, bias info etc used when processing the image frames. I keep them in case I ever want to stack the data again. Not sure what you mean by in the options tab - the file selection tab doesn't show them if you tell it to look only for e.g. raw files.

NigelM

There is a part-time job as well as the full-time one ...

NIgelM

There is a set of scripts here

http://www.hennigbuam.de/georg/gimp.html

NigelM

I have had a similar problem immediately after a meridian flip (this with an EQ8). Solver finds the offset, says it is moving the scope but it doesn't. So the next solve finds exactly the same offset (and so on).  Weirdly, choosing another target just a few arcminutes away solves and centres OK, but if you then return to the original target is still won't move the scope.  I put it down to a bug in ekos/indi and moved on to another target. It isn't the only problem I have found with the solver, but, hey, its free!

NigelM