malc-c

I downloaded the three subs and stacked them in deep sky stacker and even stretching the result I personally couldn't see the artefacts. Not sure what would happen if the darks and flats were added. Here's the resulting FTS file, and a screen shot. Can't answer your question as to what is causing the issue, but my guess is that is "generated" as part of the stacking process as, as far as I can tell, it doesn't seem to be part of the data captured. test.FTS

This is just a generalisation. It also depends on your own knowledge of Linux as to what road you go down, the Pi based systems or traditional PC and windows. Years back it was common to have separate applications for each aspect, one controls moving the mount and tracking, another guiding, another to select targets and yet another to control the camera and take the images. These days there is a lot more integration. APT for example has come along way form just sequencing using Canon dSLRs and can now control the mount through EQMOD and features a lot more than simple sequencing. NINA has been mentioned and that too is becoming the single application as it is a jack of all trades rather than the master on none. The good news is these are offered free and open source (or should that be donationware). We all have our own work flow. My gear is old, and wasn't supported by modern software such as NINA, and the developers were not interested in enabling the function for my dslr even though it was in the initial brief as the option is there. So I still use Cartes du Ciel, EQMOD, APT and PHD2 to control the gear and take the subs... You're workflow will be different

Personally I think there will always be case of elitism in any hobby. I remember 20 years when RC transmitters used 35 mhz the JRx3810 was the HEQ8 of its day. I paid out the £600 or so for one... A nice transmitter but did it make me personally fly the helicopters any better than a £150 Futaba ? - No ! But it did give out the message that I was serious about the hobby, and I admit it did give me a feeling of being "in that club" for want of a better phrase. I mean is there any difference in the basic fundamentals between a Ford Focus and a Ferrari? - they both have 4 wheels to run on, an engine to power it and seats on which to sit on... but one cost 10x the other and has a reputation for performance. I think its the same with astro gear. A Tak will take an image of a DSO much the same as my 200P, but the performance of the Tak and the precision of the mount makes the process less stressful and the results probably (definitely) superior. I wouldn't say that anyone owning a £20000 Tak rig is an elitist, but they certainly get respect from others much the same way a Ferrari draws a crowd of envious onlookers. But seeing some videos on Youtube, owning a Ferrari doesn't necessary make them a better driver....

I would assume taking a load of Darks, Flats and Bias images ??

The image Nothing, just that £ for £, $ for $ you get more aperture with a dob than any other type of scope. It's your scope, make it how you like For DSO's ideally you need a fast (f5 or less) scope. Yes - it gathers more photons So why ask if a 6" is better than a 4" or 5". I can see the difference if you were questioning a 4" vs an 8" mirror, but does an inch really make things not feasible ? May I suggest that you spend some time reading up on the relationship between aperture, focal length and focal ratio, together with the practical magnification you will get and thus the image size you'll probably get. This may probably help you refine your options

Dobsonian are the simplest to construct, but f10 ??? - The resulting image form a 4" f10 will be dark when used with high magnification Dobs are normally associated with large mirrors (termed light buckets) The size of the mirror becomes important when considering long focal lengths - Long focal lengths are typically aimed at planetary observations, and so you need a lot of light to give good contrast when using short focal ratio eyepieces otherwise the resulting image will be dull and lack contrast at high magnification. Long focal length scopes are not best suited for imaging faint DSO's You really need to think of the overall package and what it is that you want to view. That will dictate to a degree what size mirror and what focal length to go for

What mount will you be using. Two 4" f12 OTA's is going to weigh a fair amount, so even if you managed to grind two sets of optics to the exact focal length so they collimated correctly they would be useless unless the mount can support them and keep them solid. Personally, if you have never ground any optics before then you would be better off attempting the 6" scope, but even then I would prepare for a lot of frustration, it's not easy.

Just spend a few hours (days?) reading through all the previous build threads and pick out parts that you want to use in your own build. I took inspiration form a couple of SGL members, but merged in the dwarf wall to suit my own needs.

Nope, should be no need to change anything other than the port number in EQMOD as the computer might issue a news port number. EQ5 - that's a decent rig then 👍

That's one way, but using cheap barlows to give a high magnification and then cropping a full image may not give the best results ?? - The OP would need to play about and see what works best, starting with his current equipment... Last time I played about using stacked barlows to increase the focal length (and hence magnification) the poor quality and impact of adding additional glass between the sensor and the target resulted in a lot of aberration and artefacts

If your handset has a USB connection like the one on the right in this image then yes all you need is an A to B USB lead as per section 7 on page 21 of the manual you don't need any USB to serial adaptor and serial cable Sounds like a a decent set up - possibly on the limit for an EQ3 weight wise, as the Nikon D610 is around 800g for the body. The proof will be in the results and guide graphs :)

Yes, if using the handset as the "EQDIR" cable between the mount and PC than the handset does indeed need to be set to PC-Direct mode (unless it's a newer version with USB apparently). It will show up in device manager as a com port. Basically the ASCOM platform is a system that allows compatible hardware and software to communicate between them. So for example a CCD camera will be ASCOM compliant by using agreed protocols written into its ASCOM driver. This means that you can have confidence that it will work with PHD2 if a guide camera, or imaging programs like NINA or APT. In order to mount control you need an ASCOM compliant "driver" which is where EQMOD / GSServer comes in. Being ASCOM compliant it is "seen" by any other ASCOM compliant application that needs to move the mount, such as the planetarium application or guiding application. Anyway, hope that helps you get an understanding what ASCOM is, and glad to hear you are now up and running

Have to disagree...... When it comes to Luna imaging you don't need a 3000mm focal length or an expensive dSLR with video recording. (Seems I have to repeat what I said in that other post ) - MS Lifecam - 720p can be had for £30 from Amazon. Connected to a 1000mm reflector it will give decent images of the Moons landscape without the need for any Barlows Take a few 1000 frames from the AVI and stack - Job done

Yes, Like Dave I now image remotely, so its less of an issue. But originally I used to spend the nights in the observatory whilst imaging. The observatory is 4.8m x 2.1m and split into a scope room and a "warm" room. The warm room has 50mm insulation under the floor, and 30mm in the walls and roof. The scope room has no insulation at all so it is more or less the same ambient temperature as the outside air. The floor is 18mm external marine grade ply, and like Dave, in the scope room is covered with foam matting which has saved the odd eyepiece / camera over the years.

Seems they got it wrong... "Astronomers say that a rocket section set to crash into the Moon in March did not come from Elon Musk's space exploration company as they first thought. Instead they believe it is probably a Chinese rocket stage launched for a lunar mission in 2014." https://www.bbc.co.uk/news/science-environment-60378119

Best way to think of it is that the clutches are really just "locks". The motors drive a shaft and thus the shaft doesn't move unless driven by the motors. The mount can rotate around the shaft when the "locks" are released, and as such wouldn't get moved when the motors are running. Engauge the "locks" to grip the shaft and thus the mount now only moves under the power of the motors.

My build uses a suspended floor using traditional joist hangers and 18mm ply. The pillar was concreted into a big hole in the ground and the floor doesn't make contact with the pier as it has a 4mm air gap around it. As the brickwork has a DCM the floor remains warm and dry. Solid concrete will be cold on the feet if you intend to spend your time in there whilst observing or imaging

Ingenious concept, but I think I'll stick to traditional wooden roll off roof design. It may withstand some high winds, but if we get a heavy snow fall one winter I wouldn't hold up much hope of it not collapsing.

Thanks for the replies guys, didn't really want to look a gift horse in the mouth so to speak, as it was nice to be gifted a camera. I already have an MS HD Livecam adapted for use as a luna / planetary camera, along with a trusty old Philips SPC900 CCD webcam (640 x 480 max), both work well for that role. I believe the SV205 is USB3, but even on my main PC, a 4 core 8 thread Ryzen 1500x, with 16GB DDR4 ram it was dropping frames 50% of the time when exposure was increased passed 31ms. The observatory PC is only a humble dual core Pentium with 4GB of DDR3 ram, so no idea how that would cope. For use as a guidescope, well that would be a non starter as there is no way to fit it to the finder due to the fact the camera doesn't use a standard T / C ring I'm sure I'll find a use for it some time. Shame there is no lens attachment so it could be used like a poor mans Polemaster

Looking at the drawing for the SV205 it may not even be possible to connect the camera to the finder. The camera seems to have a proprietary external thread of M26.5 x 0.5mm on the part from its body where the eyepiece tube normally fits, so would need a ring with the fine outer diameter finderscope thread of M51 x 0.75 with an internal M26.5 x 0.5.....

Looking for some advice / predictions before I go making big changes to my observatory set up. My Explorer 200P is permanently mounted in the observatory with a Canon 400D as the main imaging camera, and an original QHY5 mono camera attached to a 9 x 50 finder as the guidescope. I have been gifted a SVBony 205 by a kind and generous member and whilst this seem like a good Luna and Planetary camera I can't find any information on how well it performs as a guide camera. So hence the question. The QHY5 is so old that I can't find any info on the sensor other than it has 5.2um x 5.2um pixels and is mono. The SV205 uses a SONY IMX179 with a Pixel Size of 1.4µm x1.4µm, and is a colour camera. Now assuming I can attach the SV205 to the finderscope and get focus (yet to have a play) how would it perform on paper when used with PHD2. From what I can see in Sharpcap, the QHY5 is more configurable for frame rates. The finder focal length is 181mm if that helps - If it transpires that the SV205 is great at imaging the moon / Jupiter / Saturn etc then rather than a guide camera then I'll reserve its use for the occasion when the planets are better placed before I go pulling apart a perfectly balanced and configured set up.

True, but the previous poster only posted a week ago on the 5th Feb

Thank you for the details. First thing is to confirm the setting of the EQDIR cables com port setting assuming that windows has installed the FTDI driver. In device manager right click on the com port and select properties. - So Launch device manager > Ports (COM & LPT) > PORT > Right click >Properties > Port setting tab The bits per second should be set to 9600, data bits 8, Parity None, stop bits 1, flow control None If any of the values are different, such as bits per second set to 115200, change them to the values above I don't use NINA, but I believe it either used a native built in connection to Skywatcher mounts, or if using ASCOM need an ASCOM driver such as EQMOD or GSServer as the interface between NINA and the mount. Either of these will need installing and configuring. EQMOD, being around for over a decade is well documented and covered in post on the forum, so a bit of searching or reading will cover that.

It would be helpful if you guys detail how you are connecting the mount and to what equipment, PC, Pi etc and if you are using the same EQ5 mount as the OP ?

Uhmmm so the new revision boards have what may be some flaws. Thanks for posting your findings and glad you have managed to repair the old board.