wimvb

I don’t think you will get much/any response here, since most members are European/American. But you could contact a local astronomy club for advice.

Paper tape is old school. We use punch cards now.

The same way, I suppose, lieutenant. It's a quantum procedure, with only integer values: all or nothing, but never inbetween. That's my guess, at least, and the reason why I find Linux so much simpler.

If I understand your concern correctly, you can avoid the problem by just hanging the camera up side down. The oag prism will be on the bottom side of the camera.

If possible, align the camera with RA. This means that the long side of the sensor is parallell with RA, and the short side with DEC. This way, it's easier to reframe targets if you image over several nights, and it's also easier to trouble shoot any guiding/tracking issues. To align with RA, take a 30 second exposure. 5 seconds in, you move RA either with a handset or, as in your case, with the slo-mo knob for RA. After the exposure is finished, turn the camera towards the star trails. In the image here (assuming good polar alignment), you would need to rotate the camera about 40 degrees counter clockwise.

Hmm, interesting. Everything about this setup just screams: "This will never work!", so you'll probably get some nice pictures out of it. 😁 Please share.

A bit off topic. This is where raspberry pi based solutions have an advantage. They're so cheap that I actually have two identical computers. If one decides to kick the bucket, I can just swap it and be good to go in no time. And installing from scratch took me just a rainy afternoon last month, without the need for a keyboard/screen. The down side for most people is being unfamiliar with linux. It does have more of a learning curve than windows. As with anything else in this hobby, the proverbial cat gets skinned in more ways than one.

An Windows altetnative to a laptop would be a compute stick or a nuc. You can configure a nuc to your needs, and it has more usb ports than a laptop. Use microsoft rdp from your main computer to access the nuc. Just a thought.

A cheaper alternative to a laptop is a raspberry pi with Ekos/Kstars. There are several commercial options available, based on this configuration: stellarmate atik base asiair or more diy, astroberry Even if you decide to go for windows, these options are worth considering.

You will need a seperate guide camera. A good introduction to astrophotography is this https://www.firstlightoptics.com/books/making-every-photon-count-steve-richards.html With the skywatcher ED80 or the skywatcher 130P-DS, you can use a scope for guiding. Our sponsor, FLO, offers complete guide bundles (guide scope & camera). Also of interest is this link, where you can see how much of the night sky is captured by a combination of scope and camera. http://astronomy.tools/calculators/field_of_view/?fov[]=3||266||1|1|0&fov[]=109||266||1|1|0&messier=51

In my opinion, with that combination and your intended use, you're asking for trouble. As @johninderby already pointed out, the scope is not suited for deep sky astrophotography. The combination you suggest has a too small field of view ('crop') and a too small imaging scale, making it too slow. If you can stretch your budget, go for something like this in stead https://www.firstlightoptics.com/pro-series/skywatcher-evostar-80ed-pro-heq5-pro.html As pointed out in the thread that John linked to, if you already have a dslr, start with that. (But you will the need a so called flattener with this scope) An alternative is this telescope https://www.firstlightoptics.com/reflectors/skywatcher-explorer-130p-ds-ota.html With one of these mounts https://www.firstlightoptics.com/skywatcher-mounts/skywatcher-heq5-pro-synscan.html https://www.firstlightoptics.com/skywatcher-mounts/skywatcher-eq5-pro-synscan-goto.html

Very nice catch. Personally, I like version 1 better, but I would apply scnr green at the very end of the process. Maybe only at 50% strength.

I run Ekos/Kstars on my sbc (Rock64 with emmc card instead of SD card) and connect to it from my windows laptop with MS remote desktop. Both the sbc and my laptop have a wired network connection. I save images on the sbc and download them after each session with ftp. Image transfer time from camera to emmc card is 0.5 seconds or less. Ftp to my laptop is even faster. This is with 4.6 MB/image for my camera. Hope this helps.

That’s a very nice event horizon. I have only one problem with it; the shadow side of the event horizon is darker than the black hole. Is that proof that there is Hawking radiation?

Well, you allways have your connections ”down under”, and a dark site on Lizzard island.

You must be working on an all sky dark nebula panorama, I guess. great image. Again. 😉

The article that @Waddensky linked to, argues that the stars are behind the nebulosity, and so not part of it. If correct, there shouldn’t be any interaction between the stars and the nebula, other than light reflection. Here’s another article on the matter. http://adsabs.harvard.edu/full/1977ApJ...217...83A

As I see it, there are filaments going in two directions, and an area inbetween with crossing filaments. Much like interfering waves. This is easier to see in some images than in other.

Not at all. There’s a nebula named after about any animal you can think of.

Yeah, me too. I observe a lot of things going wrong. Fortunately, I don’t have to worry about eye pieces. 😶

All other PI users call it 'High Dynamic Range Composition', or possibly just 'Pixelmath'. 😉 Fabulous blend, Göran. This camera is one of the first (with the ASI6200) astro cmos cameras to have a 16 bit ADC, and a dynamic range of 14 stops (bit). I suspect that this is the reason why you can achieve such amazing depth in only a short time. The camera can handle the photons that the RASA sucks in, in both the bright and the dim areas.

If it ain't broke, don't try to fix it. With your RASA at the imaging scale you have, you don't need super accurate guiding. But if you ever put your new toy scope on the NEQ6, you may need to clean and adjust it first. Imo, mounts are like cars, they need regular service. We don't expect a car to run year after year without changing oil and adjusting the brakes. So why should we expect a low cost mount to function at sub arcsecond accuracy without any TLC? I've had this mount for more than four years now, so service was overdue.

This story started about nine months ago, in the middle of astro season. The tracking performance of my mount degraded, and those times when I didn't give up, the guide rms could be close to 2" (at an imaging scale of 1.2"/pixel). Especially DEC guiding was pretty bad. Removing the backlash did improve the tracking to some extent, but not enough, and my images where still blurry. If seeing isn't perfect, a guide rms of around 1" can be acceptable, but most of the time, the stars in my subs were elongated. During summer recess, I took apart the DEC stage of the mount and cleaned and regreased everything. The inside looked quite clean, but there were some particles that imo, shouldn't be there. There was some wear on the DEC belt, so I decided to replace it. I was very careful to remove backlash during reassembly, so the mount should now have a properly functioning DEC stage. And it did, DEC guiding was now a lot smoother, and with proper balancing and polar alignment, DEC rms was good. But now, RA was bad, and just before the start of astro season, I opened up my mount again, and cleaned the RA stage. This looked cleaner than DEC, and there wasn't much to do except remove excess grease in some places and regrease in other places. Again, I was careful to remove any backlash during reassembly. Even after the strip down and cleaning, RA guiding was still around 1 - 1.2", not low enough for my imaging scale. As it turned out the RA belt had always been too loose in my mount. Tightening it removed a 10 second period and made guiding a lot less erratic. The main period of my mount is now 120 seconds (one full rotation of the timing pulley), and not 10 seconds (one advance of each tooth on the timing pulley). Most of this period can be guided out using PPEC in PHD or the Ekos guide module. While I tested the mount, I noticed that the RA timing pulley wobbled. This was partly because the end cap of the pulley has a very poor fit. But that shouldn't affect performance. (What was a bit disturbing became apparent later on, when I had removed the pulley from the motor shaft.) Anyway I decided to replace the pulley with a better one. So I ordered two 12 tooth 2.5 mm pitch timing pulleys form Beltingonline, together with a spare belt. These pulleys don't have the right bore for the SW stepping motor shaft (5 mm), and I had a colleague drill a 5 mm bore with the lathe we have at my school. About a week or two ago, I replaced the original brass timing pulley with an aluminium one. And voila, guide rms went down to 0.63", with occasional 0.57" 'dip'. Guiding is now definitely seeing limited (with a 3 seconds exposure time for the guide camera). After removing the original pulley, I could examine it more closely. Skywatchers evidently decided that it is more economical to press a timing pulley into a brass tube that will act as a shaft adapter, than to make one from a solid piece of brass. The pulley is capped with a thin piece of metal in quite a sloppy manner. But this doesn't matter much. What does matter is how the toothed section of the pulley is pressed into the shaft adapter. As can be seen in the first image, this section isn't pushed straight in, and this causes the 120 s period in the tracking error. The slanted pulley causes the tension in the belt to vary over one revolution (120 s). Since this error is smooth, it can be guided out. But, imo, it is always better to avoid an error than to correct it. And that is why I decided to replace the pulley. The high tension in the belt puts a lot of stress on the timing pulley, and I hope the aluminium can stand this stress. If I find that tracking deteriorates again, because of the pulley, I can always put the brass DEC pulley on the RA motor shaft, ad the old RA pulley on the DEC motor shaft. Hopefully, this won't be necessary.

A very successful attempt it is. 👍

I think we have to consider pixel size. We need to include the complete geometry of the system, and that includes pixel size. Otoh, if the system is extremely undersampled, pixel size is irrelevant, and so is f-number. If the light from a star falls on only one pixel, no matter what size that pixel is, aperture is the only parameter that determines photon capturing ability.